Over the last 15 years working as an operator, I’ve seen many different kinds of projects. Some succeeded. Some didn’t. Some had great products, others didn’t. Some teams kept moving forward, while others eventually collapsed.

For the past six years I’ve been working inside the Web3 ecosystem, and one pattern keeps repeating itself.

The reasons for failure are always complex. Markets shift, teams break, funding dries up. But there is one factor that appears far more often than people like to admit: operational mistakes.

You can have a brilliant idea, a talented team, a polished MVP, and even grant funding. But if no one is capable of turning all of those pieces into a functioning operational system, the chances of success drop dramatically.

Web3 loves ideas.

But companies are not built by ideas alone.

They are built by execution.

And execution is operations.

After years of observing Web3 teams up close, I keep seeing the same three problems appear again and again.

Most Web3 projects start with an exciting idea.

And that’s natural — belief is the starting point of every venture.

Your idea feels revolutionary.
No one else is doing it.
Or if they are, they’re doing it wrong.
Or maybe you’re solving a problem people haven’t even noticed yet.

From your perspective, the future is obvious.

So sleeves get rolled up and development begins immediately.

Sound familiar?

This is exactly where the first major problem appears.

In traditional startups, launching a product without at least some form of market research is almost unthinkable.

But in Web3 we often convince ourselves that we’re building future technology for future problems, and therefore validation somehow doesn’t apply.

But a few simple questions still matter.

Does this solution actually improve someone’s life?

Is anyone actively waiting for this product?

Are there already dozens of teams quietly building the exact same thing somewhere else?

Because here’s the uncomfortable possibility:

There’s a decent chance nobody actually needs the solution at all.

Startup literature often calls this stage problem–solution fit³ — validating that the problem truly exists before investing significant time building the solution¹.

Without this step, projects risk building impressive technology that nobody ends up using.

Web3 has seen this pattern repeatedly.

For example, during the 2017 ICO boom, hundreds of projects raised millions promising decentralized solutions for nearly every industry imaginable — social networks, cloud storage, data markets, prediction platforms.

Many of those projects disappeared not because the technology was impossible, but because there was no real market demand².

Even more recently, countless NFT infrastructure tools launched during the 2021 boom — marketplaces, analytics dashboards, minting platforms — only to discover that the number of actual users was far smaller than expected once speculation slowed down.

When experimentation is the goal, that’s completely fine. Innovation requires experimentation.

But when the goal is to build a sustainable product, skipping validation becomes the first major operational mistake.

The longer I spend in Web3, the more I notice something interesting.

Many founders simply don’t like planning.

Web3 attracts passionate builders driven by strong ideas and ideological motivation. And passion can absolutely build remarkable things.

But passion alone does not replace structure.

I’ve heard the same sentence many times from founders:

“Planning doesn’t matter yet — we don’t even have a working product.”

My usual response is simple.

If there’s no plan, there’s a good chance the product will never appear.

Trying to build a company without planning is a bit like driving to a completely new city without GPS.

You might eventually get there. But there’s a good chance you’ll take unnecessary detours and arrive much later than expected.

Even the most experimental startups usually maintain some basic structure — product roadmaps, milestone plans, or frameworks like OKRs (Objectives and Key Results).

Planning doesn’t eliminate uncertainty.

But it dramatically increases the probability that something actually gets shipped.

Without structure, projects tend to drift.

And drifting projects rarely deliver products when the market actually needs them.

The third problem is the most common — and the least discussed.

Operational chaos.

Creative founders and revolutionary ideas rarely come with operational discipline. And that’s completely understandable.

Web3 is a creator-driven ecosystem. Many founders are engineers, protocol designers, or visionary builders.

Operations is rarely their natural focus.

But the real issue isn’t that founders struggle with operational structure.

The real issue is that many teams don’t even recognize the problem exists.

Hiring a COO often feels unnecessary, expensive, or even absurd to early-stage teams.

Yet strong operators are often the hidden force behind successful technology companies.

The role of operations is surprisingly simple:

A good operator does not create the vision.

A good operator turns the vision into a system that produces results.

The key KPI of operations is straightforward:

How much value can the company generate using the resources it already has?

Clear processes.
Defined roles.
Structured execution.

When these elements are missing, even well-funded projects can collapse.

Web3 has seen several high-profile examples of operational failure.

The collapse of FTX is one of the most extreme cases — not a failure of technology, but of governance and operational discipline.

Another example is the Terra/LUNA ecosystem, where rapid growth, insufficient risk management, and weak structural safeguards led to one of the largest failures in crypto history.

In both cases, the core issue wasn’t the idea itself.

It was the absence of strong operational systems capable of managing complexity at scale.

Sometimes the difference between a struggling project and a successful one isn’t the product.

It’s the operational engine behind it.

These are just three observations from a high-level perspective after 15 years working in operations and six years inside the Web3 ecosystem.

Each of these topics could easily fill an entire book.

But the core idea remains simple.

Strong ideas alone rarely build successful companies.

Execution does.

And execution requires structure.

Early-stage startups often don’t have the resources to hire an experienced COO — that’s completely understandable.

But having someone in the team who naturally thinks about processes, coordination, and operational clarity can make an enormous difference.

So the next time you build a team, ask a simple question:

Is someone responsible not only for the idea — but also for making the entire machine actually work?

Because great ideas are everywhere.

Functional systems are not.

If you're building in Web3 and struggling with execution, operations, or coordination — feel free to reach out.

1. Eric Ries — The Lean Startup
   https://theleanstartup.com

2. Marc Andreessen — Product Market Fit
   https://pmarchive.com/guide_to_startups_part4.html

3. Michael Seiber — Problem–Solution Fit
   https://www.ycombinator.com/library/5z-the-real-product-market-fit

This article was originally written in Lithuanian and translated into English with the help of AI.

Over the last 15 years working as an operator, I’ve seen many different kinds of projects. Some succeeded. Some didn’t. Some had great products, others didn’t. Some teams kept moving forward, while others eventually collapsed.

For the past six years I’ve been working inside the Web3 ecosystem, and one pattern keeps repeating itself.

The reasons for failure are always complex. Markets shift, teams break, funding dries up. But there is one factor that appears far more often than people like to admit: operational mistakes.

You can have a brilliant idea, a talented team, a polished MVP, and even grant funding. But if no one is capable of turning all of those pieces into a functioning operational system, the chances of success drop dramatically.

Web3 loves ideas.

But companies are not built by ideas alone.

They are built by execution.

And execution is operations.

After years of observing Web3 teams up close, I keep seeing the same three problems appear again and again.

Most Web3 projects start with an exciting idea.

And that’s natural — belief is the starting point of every venture.

Your idea feels revolutionary.
No one else is doing it.
Or if they are, they’re doing it wrong.
Or maybe you’re solving a problem people haven’t even noticed yet.

From your perspective, the future is obvious.

So sleeves get rolled up and development begins immediately.

Sound familiar?

This is exactly where the first major problem appears.

In traditional startups, launching a product without at least some form of market research is almost unthinkable.

But in Web3 we often convince ourselves that we’re building future technology for future problems, and therefore validation somehow doesn’t apply.

But a few simple questions still matter.

Does this solution actually improve someone’s life?

Is anyone actively waiting for this product?

Are there already dozens of teams quietly building the exact same thing somewhere else?

Because here’s the uncomfortable possibility:

There’s a decent chance nobody actually needs the solution at all.

Startup literature often calls this stage problem–solution fit³ — validating that the problem truly exists before investing significant time building the solution¹.

Without this step, projects risk building impressive technology that nobody ends up using.

Web3 has seen this pattern repeatedly.

For example, during the 2017 ICO boom, hundreds of projects raised millions promising decentralized solutions for nearly every industry imaginable — social networks, cloud storage, data markets, prediction platforms.

Many of those projects disappeared not because the technology was impossible, but because there was no real market demand².

Even more recently, countless NFT infrastructure tools launched during the 2021 boom — marketplaces, analytics dashboards, minting platforms — only to discover that the number of actual users was far smaller than expected once speculation slowed down.

When experimentation is the goal, that’s completely fine. Innovation requires experimentation.

But when the goal is to build a sustainable product, skipping validation becomes the first major operational mistake.

The longer I spend in Web3, the more I notice something interesting.

Many founders simply don’t like planning.

Web3 attracts passionate builders driven by strong ideas and ideological motivation. And passion can absolutely build remarkable things.

But passion alone does not replace structure.

I’ve heard the same sentence many times from founders:

“Planning doesn’t matter yet — we don’t even have a working product.”

My usual response is simple.

If there’s no plan, there’s a good chance the product will never appear.

Trying to build a company without planning is a bit like driving to a completely new city without GPS.

You might eventually get there. But there’s a good chance you’ll take unnecessary detours and arrive much later than expected.

Even the most experimental startups usually maintain some basic structure — product roadmaps, milestone plans, or frameworks like OKRs (Objectives and Key Results).

Planning doesn’t eliminate uncertainty.

But it dramatically increases the probability that something actually gets shipped.

Without structure, projects tend to drift.

And drifting projects rarely deliver products when the market actually needs them.

The third problem is the most common — and the least discussed.

Operational chaos.

Creative founders and revolutionary ideas rarely come with operational discipline. And that’s completely understandable.

Web3 is a creator-driven ecosystem. Many founders are engineers, protocol designers, or visionary builders.

Operations is rarely their natural focus.

But the real issue isn’t that founders struggle with operational structure.

The real issue is that many teams don’t even recognize the problem exists.

Hiring a COO often feels unnecessary, expensive, or even absurd to early-stage teams.

Yet strong operators are often the hidden force behind successful technology companies.

The role of operations is surprisingly simple:

A good operator does not create the vision.

A good operator turns the vision into a system that produces results.

The key KPI of operations is straightforward:

How much value can the company generate using the resources it already has?

Clear processes.
Defined roles.
Structured execution.

When these elements are missing, even well-funded projects can collapse.

Web3 has seen several high-profile examples of operational failure.

The collapse of FTX is one of the most extreme cases — not a failure of technology, but of governance and operational discipline.

Another example is the Terra/LUNA ecosystem, where rapid growth, insufficient risk management, and weak structural safeguards led to one of the largest failures in crypto history.

In both cases, the core issue wasn’t the idea itself.

It was the absence of strong operational systems capable of managing complexity at scale.

Sometimes the difference between a struggling project and a successful one isn’t the product.

It’s the operational engine behind it.

These are just three observations from a high-level perspective after 15 years working in operations and six years inside the Web3 ecosystem.

Each of these topics could easily fill an entire book.

But the core idea remains simple.

Strong ideas alone rarely build successful companies.

Execution does.

And execution requires structure.

Early-stage startups often don’t have the resources to hire an experienced COO — that’s completely understandable.

But having someone in the team who naturally thinks about processes, coordination, and operational clarity can make an enormous difference.

So the next time you build a team, ask a simple question:

Is someone responsible not only for the idea — but also for making the entire machine actually work?

Because great ideas are everywhere.

Functional systems are not.

If you're building in Web3 and struggling with execution, operations, or coordination — feel free to reach out.

1. Eric Ries — The Lean Startup
   https://theleanstartup.com

2. Marc Andreessen — Product Market Fit
   https://pmarchive.com/guide_to_startups_part4.html

3. Michael Seiber — Problem–Solution Fit
   https://www.ycombinator.com/library/5z-the-real-product-market-fit

This article was originally written in Lithuanian and translated into English with the help of AI.