Solving A Process

A process is a journey from point A to point B. Point A could be the current state and point B could be the desired outcome. Usually, it is the how that is solved for. For example, how do I make $10K per month?

One direction to take is to look for how it has been done by people who've already achieved that, then replicate the steps more or less to fit your current situation.

I think this is an easier straightforward way to solve a process based on the knowledge base of successful precedents and proven methodologies.

Besides, the bigger the knowledge base, the higher the chances of succeeding.

What I like about the modern age isn't necessarily the multiplicity of options at our disposal, but more so how it facilitates a broader viewpoint on problem-solving through instant access to collective experiences and diverse solutions.

Of course, we have to be open to it and seek it out ourselves but I think it's really mind blowing that we've reached this level through which solutions to almost any challenge are just a research away.

Image Source

Filling The Gaps

Now, solving a process implies that there's a problem in a process. In concrete terms, it's just identifying bottlenecks, inefficiencies, or gaps between the current state(point A) and desired outcome(point B).

Recently, I've been a bit obsessed with condensing timeframes and have created mental models on how to walk, drive or fly from point A to point B.

Walking symbolizes the slow but steady traditional path. Being an artisan, for example. Day in and day out, meticulously crafting your way forward through personal experience and direct learning.

You build relationships one at a time, grow organically through trial and error, and move forward safely but slowly.

Arguably, it's the approach that most start with and it takes the longest. When the outcome is time sensitive, it's really a drawback but the good side is it builds the strongest foundations and deepest understanding of your craft.

With driving, accelerated progress is made through leveraging existing systems. Think of it as using the infrastructure that others have already built.

Why bother paving your own road, when you can follow established frameworks, use proven tools and methodologies, and learn from those who've gone before you?

I reckon it is the stage we start taking calculated risks, but with relatively safety nets of proven systems.

Flying as a concept, seems really cool to me. In this mental model, such a concept can best be represented as quantum leaps through innovative approaches.

We challenge traditional methods and leverage cutting-edge technology to create exponential results.

In a business setting, you move away from serving one client at a time, to building a digital product that can serve tens of thousands simultaneously.

Image Source

Both driving and flying make use of leverage, but the difference between them is the former leverages existing systems while the latter builds new systems. As in, building scalable systems from day one and taking bold, calculated risks that could dramatically compress your timeline to success.

External Factors At Play

As a creator/builder/developer, knowing when to walk (build foundations), when to drive (scale efficiently), and when to fly (take calculated leaps) is important for maximizing impact and minimizing wasted effort.

In certain cases, you need to walk before you can drive.

But other times, you might as well take that bold flight to reach that desired outcome faster before the opportunity window closes or the landscape changes entirely.

Some days, that's how I feel more or less with crypto, in general. Maybe it's the knowledge FOMO or just pure emotional FOMO or just both.