By now, most founders and product managers know not to fall into the “build trap” — in other words, getting stuck building products nobody wants.
To avoid this trap, the consensus approach is to spend the minimum amount of effort to validate an idea before investing further resources, also known as MVP (or MLP/MTP if you’re a hipster).
Ironically, this MVP mindset can often lead to a more silent, sometimes deadly problem: the path dependence trap.
Let’s explore what it is and why it’s dangerous.
What is path dependence?
Simply put, path dependence means our past choices can limit our future options.
This concept might remind you of the sunk cost fallacy, but they’re not quite the same. With the sunk cost fallacy, you stick to the same path to avoid wasting past investments, even though you could still change course.
Path dependence, on the other hand, puts you in a position where you really can’t veer off the course you’re on.
Let’s look at an example:
We’ve all seen this illustration by Henrik Kniberg that explains how iteration works. The idea is simple. If you’re trying to help users get from point A to point B, you start with a bare-bones yet functional solution and gradually move toward a more advanced one.
This is a good metaphor, but for the sake of illustrating my point, let’s look at it through a literal lens:
Do you see where things don’t add up?
Creating a skateboard is nothing like making a bike, and making a bike is a world away from manufacturing a car. This is not a linear progression. Each solution targets a particular use case and persona. Moving from one product to another isn’t a pivot — it’s a hop.
Pivoting is mostly a matter of “want.” Hopping is mostly a matter of “can,” and most teams that hopped ended up face-planting.
Types of path dependence
There are a few types of path dependence you should beware of:
Problem dependence
Every product starts with a problem. But if you pick the wrong problem or the wrong customer to solve it for, it doesn’t matter how brilliant your solution is. You won’t be able to turn it into a successful business.
Product managers often complain that their leadership teams can’t commit to a use case or ICP, but that’s because it’s really not easy. If you get too specific too soon, every research, every follow-up research, every action, and every data that comes with those actions will hinge on the initial problem.
But what if that problem isn’t big enough? You often won’t know until much later, especially if you’ve been head-deep in the solution space.
Example: Let’s say your product is an inventory management software for SMBs. You notice that you’re getting good traction from self-storage businesses (thanks to an influencer in the space endorsing it), so you decide to go all in on this segment. After all, every startup veteran hammers on about the importance of focus, so this seems like the right thing to do.
You start building niche features for this underserved market. The customers love your product, and the revenue is growing steadily.
However, after a year, the growth plateaus. You realize that the total addressable market (TAM) of self-storage businesses is simply not big enough for you to meet investors’ growth expectations. To extend your runaway, you start looking for similar markets to expand into, only to find out that the problems you’ve been solving are extremely niche. Ironically, your laser focus on this segment ends up being the very thing that sinks your business.
Solution dependence
No matter how fast your bike goes, it will never reach the speed of a car. You can’t turn a bike into a car by simply strapping an engine to it. The entire solution must be redesigned from scratch. The longer you wait, the more costly it gets. This is also often the case with software.
Example: You’re working on a workflow automation tool. To get it out the door faster, you decide to whip up a simple, linear flow builder.
This solution seems to cover most use cases, so you shift your focus to adding more integrations. A few years later, a competitor comes out with a visual flow builder from day one. You start losing customers to them because it is just so much more intuitive to build complex logic that way. Unfortunately, the fact that you have too many integrations and features built on top of the current solution means it will take you 2-3 years to launch a similar visual builder. That might be all the time it takes for your product to bite the dust.
The story of Sketch and Figma is perhaps the most vivid real-world example of solution dependence. Back in 2016, Sketch was the go-to choice for most designers. Designs done in Sketch were only local files, and teams needed additional tools for version control, prototyping, and design handover. But hey, it was simply how things were done back in the day, and no one seemed to be bothered by it.
Then boom! Figma came out of nowhere to take the market by storm.
Figma won because they went all-in on collaboration. Every design file is stored on the cloud and comes with built-in version control, file organization, and sharing. To ensure their web app can support all the resource-intensive operations, Figma’s team spent three years in the lab perfecting their technical infrastructure before launching — a hurdle Sketch simply couldn’t clear in time. By the time Sketch did, it was too little, too late.
Talent dependence
A company hires a particular set of talent to bring a vision to life. But if that vision doesn’t work out, it’s not easy to simply “reskill” the team to pivot to the next thing. That’s why startups are often recommended to avoid hiring specialists too early.
And even if the vision does gain traction, the company will continue to face similar challenges.
Some top contributors in the early stage won’t keep up with the company’s growth. Figuring out where they fit into the next phase becomes a tricky question.
Some areas of the business will need seasoned experts to scale, and those senior hires will set the direction for future hires. An early-stage startup that makes a wrong senior hire will typically take 6-12 months to re-fill the position, followed by another six months to get the person ramped up. That’s valuable time that could’ve been used to grow the company toward the next round of funding. If they make another wrong hire, the startup is practically dead.
The same problem can also happen at a local scale.
If a generally skilled person is assigned to the wrong project, it’s not easy to simply reassign the project to someone else. Managing egos, morale, and knowledge transfer can get messy.
Unlike changing a few lines of code, personnel decisions are hard to back off from. That’s why you should never underestimate the path dependence that these decisions create.
Brand dependence
When a product has been perceived in a certain way for a long time, it is hard to shake off that brand image, even if the reality of the product has evolved.
You don’t associate McDonald’s with health just because the company sells salad. You don’t see Salesforce as the go-to CRM for SMBs just because it offers an SMB solution.
This is why big companies often launch new brands to break into adjacent markets or unbundle an existing product.
How to avoid path dependence
The short answer is, you can’t.
Every action you take will have future implications. The only way to avoid path dependence altogether is to stand still, which is the worst option of them all.
“So, if you can’t avoid it, why sweat it? Let’s just adapt when we have to.”
While you can’t avoid path dependence entirely, you can still look ahead to understand the trade-offs you’re making. Most importantly, you will be far more prepared about when and how to change directions before it’s too late.
Here are some general tips to help you navigate path dependence:
Map out multiple possible paths
When making a decision, ask yourself:
- What follow-up options does each immediate option provide?
- What future options does each follow-up option lead to?
- and so on.
The idea is to help you identify the optimal paths to reach your long-term goal.
You can also map out potential paths backward, starting from where you want to end up (similar to Amazon’s Working Backwards method). By doing this exercise bi-directionally, you get to visualize whether the two flows converge. If they don’t, then something needs to be reconsidered.
Make sure that you also estimate the realistic effort it takes to go from one milestone to the next. Some options might be a direct progression from their previous step, while others might require a more convoluted journey to get to.
For example, if your product offers an email broadcast feature, the plausible next move could be to either add an automation builder or an SMS broadcast feature. But if you want to build an omnichannel automation builder, it will take multiple steps to get there, which can result in years of work.
Think far, act progressively
One of the biggest misconceptions about MVP is that because no one can predict the future, there’s no need to plan too far.
I totally disagree.
In most cases, you can get a good sense of the likely future paths by thinking ahead. Even if you get only 30% right, that is still a whole lot better than nothing.
Also, just because you plan ahead, doesn’t mean you have to do everything in one go. You can still execute in small pieces to validate your hypothesis step by step.
“But planning ahead takes time. Why not just ship something and learn?”
Yes, thinking ahead takes extra time, but the cost is tiny compared to what you’d spend on getting out of the wrong path later. Let’s also not forget that meaningful learnings don’t come easily.
If one extra day of planning can help you avoid a future trap that will take one year to overcome, it is absolutely worth it.
Don’t get trapped by sunk cost
The sunk cost fallacy is a common precursor to the path dependence trap.
Many companies can’t stand the thought of abandoning all that hard work they’ve put in. So they continue down a bad path until they can’t get out.
Combating the sunk cost fallacy is a big topic on its own. But at its heart, it all comes down to one thing: having the willingness to say, “We’re wrong. The work we’ve put in no longer matters. Let’s move on.”
Not all roads lead to Rome
In theory, all roads lead to success as long as you persist. In reality, some roads take weeks, while others take years, and most companies do not have the resources or luck to endure all the detours.
People often bring up Slack and Instagram as the ultimate proof that drastic pivots are possible. However, let’s not forget they are the textbook definition of survivorship bias — the exceptions, not the rule.
Having the ability to adapt is crucial, but it is not mutually exclusive with planning ahead. In fact, I’d argue that winning companies can make swift adjustments precisely because of their ability to map out alternative future paths (whether they realize it or not).
Of course, no one can predict the future with 100% accuracy. Finding that sweet spot between planning ahead and diving into action will always be a contextual decision. The key here is to train yourself to get better at striking this balance more efficiently. That way, you can charge ahead with confidence, secure in the knowledge that you’re ready for every twist and turn in your journey.
