You Don't Have a Roadmap Problem. You Have a Problem-Definition Problem. - ProductFTW #77

More than once, a company has hired us to help build its product roadmap. They knew the feature list they wanted to build, thoughts on who could help them build it, and even a rough idea of the economics.

What they couldn't tell us was why.

The Pattern

Here's how these engagements generally started. The founder handed us a detailed feature list, asked us to help prioritize and sequence it, and to identify the right partners and tools to execute it. Straightforward consulting work, or so it seemed.

We started asking our usual questions. For each feature: 

• Why this? 
• Who is it for? 
• What problem does it solve for them?

The answers kept coming back to the same place:

• "Competitors charge for this."
• "We think we can monetize this."
• "X company does this, and they're growing."

Every justification was rooted in revenue or competitive positioning rather than specific user problems. Not because the founder was careless or inexperienced. In fact, the opposite has been true. These founders knew their industry deeply, had strong domain expertise, and understood the economics of the space. However, that expertise was pulling them toward solutions before they had clearly defined the problems those solutions were meant to address.

They had jumped from "I have a vision" to "Let's pick partners and start building" without the critical middle step of defining the problem that needs to be solved and for whom.

Why This Happens

When you know a space well, it feels natural to skip the discovery phase. You already know what the market looks like and what competitors offer.

The problem is that knowing the industry is not the same as knowing your users. Industry knowledge tells you what exists. User knowledge tells you what's missing, what's broken, and what people are actually struggling with day to day.

There's also a pull toward revenue-based reasoning. "We can charge $X per month for this feature" sounds like a business case, but revenue is an outcome, not a reason. If the feature solves a real, painful problem, the revenue will follow. If it doesn't, no amount of pricing strategy will make users care about it.

One particular example of this pattern stands out. A client insisted on adding financial services to their platform because they saw revenue potential. They skipped discovery entirely and when they launched, their users didn't trust the new features. A new KYC process was rolled out to enable the new features, but it felt invasive and users didn't understand why the platform was suddenly asking for their financial information. On top of that, the features took an old-school, in-person B2B payment process, modernized it, and made it digital. It turned out that their users liked the in-person process because it was an opportunity to interact with their customers, and they didn’t want to lose that touchpoint. 

The features went unused and the revenue never materialized. The lesson from that engagement was clear: you cannot monetize a problem that your users don't have.

This isn’t just a startup problem, though. Facebook made the same mistake when it launched Libra in 2019. I’m sure the business case seemed very compelling. There were billions of users already on the platform, so if Facebook could tap into their wallets, there was tons of revenue potential. They skipped the most important question of whether their users actually wanted Facebook to handle their money. The answer was no. After several attempts to make it work, including a couple of rebrands and a shift in strategy from a multi-currency coin to a stablecoin, the project was sold for parts in 2022 and then collapsed a year later. 

Compare that to Starbucks Rewards and the Starbucks app, which have been wildly successful. Starbucks solved two problems for its users: waiting in line and fumbling with payment. The app lets people order ahead, pay from their phone, and earn rewards for something they were already doing. The financial layer made an existing habit faster and more rewarding. Today, rewards members account for over half of Starbucks’ US revenue. 

The Deeper Issue: You Can't Prioritize Without Problems

Another consequence of trying to build a roadmap based on revenue assumptions rather than user problems is that you lose the ability to prioritize.

When someone asks us to help them sequence a roadmap, we need a basis for deciding what comes first. That basis has to be grounded in something real. Specifically, it comes down to two questions: How painful is this problem, and how many of your target users experience it?

When every feature's justification is "we think we can charge for it" or "competitor X has it," you've lost that decision-making framework, and everything looks equally important. There's no way to distinguish between a feature that will drive adoption and one that will sit in a menu untouched. 

How We Reset the Roadmap

When we see this pattern, we don't start by rearranging the feature list. We roll back the conversation to the step that was skipped.

The first thing we do is understand the people who will actually use the product. We start with the classic product exercise of defining personas or actors to make sure we understand who a company’s customers are, and then map features to each persona. 

From there, we ask "why" and refuse to accept revenue as the answer. The questions we always drive toward answering are: Which specific user problem does this solve, and how do we know that problem exists? This is where a founder's domain knowledge becomes so valuable. They usually know the pain points from years of industry experience, they just haven't connected those pain points to the features on the list in any structured way, or they’ve overindexed on how they would like to do something, when they themselves might not actually represent their user base. 

Once we understand all of this, some features get sharper and more urgent, while others fall away. A feature might sound exciting, but when you examine it closely, the actual user problem it addresses is marginal. Maybe the pain is real, but it affects so few users that it doesn't justify the engineering investment. Revenue upside alone can't answer those questions, but problem definition can.

After we've done this work, prioritization becomes more straightforward. The features that address the most painful, most frequent user problems go to the top. Features that are nice to have or address marginal problems go to the bottom. 

None of this means revenue is irrelevant. It means that revenue, as a validation point, comes later in the process. The order matters: 

1. Is there a real problem? 
2. How big is it, and how many users does it affect? 
3. Will solving this problem pay for itself or justify the investment, whether through direct revenue, reduced churn, lower support costs, or protecting the company's reputation? 

Revenue is still a key consideration, but it’s just not the one driving the conversation before we've answered the first two questions.

The resulting roadmap usually looks very different from the one the founder walked in with. Not because the features changed, but because the ordering now reflects what users actually need instead of what the company hopes to charge for.

The Test

If you're reading this and wondering whether your own roadmap has the same issue, here's a simple test. Pick any feature on your roadmap and try to complete this sentence:

"We are building [feature] because [specific user] currently struggles with [specific problem], and we know this because [evidence]."

If you can fill in every blank with confidence, you're in good shape. If the best you can do is "we are building this because competitors have it" or "we are building this because we think we can charge for it," you don't have a roadmap problem. You have a problem definition problem.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Product Requirements Field Guide — ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.