A finished roadmap can still hide an unfinished product decision. Before funding another quarter, a founder needs evidence that one customer problem is painful enough to change behaviour, command budget, or survive repeated sales conversations.
Consider Kwame, an illustrative composite of founders I have worked alongside while building products across African, European and US markets. At 8:17 on a Monday morning in Accra, he was staring at twelve polished feature cards arranged across his laptop screen. His coffee had gone cold beside a notebook containing one sentence, underlined twice: “Which problem makes them act now?”
Twelve features and no reason to choose
Kwame’s team had spent months building an AI operations product for small logistics companies. The roadmap looked credible. It covered document extraction, delivery alerts, reporting, staff permissions, invoice checks and a dashboard designed for buyers who wanted to see everything at once.
The team could explain every feature. They could demonstrate each one without the product failing. What they could not explain was why a customer would move money from another priority to buy it this quarter.
That distinction became urgent at 10:30, when the lead engineer asked whether to begin the next reporting module or improve invoice matching. Either choice would consume most of the remaining development capacity before their next funding conversation.
The bad ending was clear. They could spend another quarter completing the roadmap, reach the end of their runway, and discover that customers admired the product without needing it. Twelve green status labels would offer little comfort then.
I have seen this tension appear in different forms. A founder in Ghana weighs an engineer hire against two more months of runway. A team in Germany considers a contract that pays now but pulls the product towards one buyer. A US startup has enough capital to keep building, which can make the underlying uncertainty easier to postpone.
A detailed roadmap gives uncertainty somewhere tidy to hide.
The conversation that broke the tie
Kwame stopped the planning meeting and opened notes from recent customer calls. The team had asked what buyers wanted, then translated each answer into a possible feature. Customers had responded generously. Faster reports sounded useful. Better alerts sounded useful. A cleaner dashboard sounded useful too.
Useful was too weak a standard for the next quarter.
They returned to one call with Abena, a fictional operations manager created for this scenario. She had described sitting in a warehouse office after closing time, comparing invoices against delivery records because two totals did not agree. If she approved the wrong figure, the company could pay for work that had not been completed. If she delayed approval, drivers and suppliers would start calling the next morning.
That was the first problem in the notes with a visible consequence, an immediate decision and a person already doing painful manual work to avoid a loss.
The team called two more prospective buyers that afternoon. They asked about the last time invoice and delivery records disagreed. They asked who noticed, what happened next, and what the buyer did before going home. They avoided pitching the planned solution.
One buyer had assigned a staff member to check records manually. Another treated mismatches as a recurring cost of operating. The evidence remained incomplete, but the decision became narrower. Kwame postponed the reporting module and gave the next build cycle to proving whether invoice matching could remove a problem buyers already spent time and attention containing.
This is the same discipline behind Ruth’s refusal and Daniel’s decision to validate demand. A customer’s polite interest carries less weight than the behaviour surrounding a problem.
Pain leaves evidence behind
A painful customer problem usually leaves traces before your product arrives. Someone maintains a spreadsheet, repeats a check, calls a colleague, delays a payment, hires temporary help or accepts a recurring loss.
Those traces matter because stated preference is cheap. A prospect can request a dashboard during a call and forget about it by lunch. Existing behaviour shows what they already consider important enough to fund with time, money or risk.
Before committing another quarter, I would look for four things in the founder’s notes:
- The problem happened recently enough for the customer to describe a specific moment.
- The customer already uses a workaround.
- Failure carries a consequence they can name.
- Solving it belongs to someone with the authority or budget to act.
None of these proves a market alone. Together, they provide a stronger reason to build than a feature vote or an enthusiastic reaction to a demo.
The decision can still go wrong. Honest product work keeps that possibility visible. Validation reduces uncertainty; it does not erase it.
What Tuesday looked like
By Tuesday morning, Kwame’s roadmap contained fewer promises. Nine feature cards had moved into a later column. Three remained, each tied to the invoice mismatch workflow the team intended to test.
The board looked less impressive.
The company’s next question was better.
Instead of asking which feature could make the product feel complete, the team asked what evidence would justify another week of engineering. They planned a narrow test around real records, the person responsible for checking them and the decision that followed a mismatch. If buyers would not provide data, time or access for that test, the team would treat the hesitation as evidence too.
That is the practical value of an unfinished roadmap. It leaves room for customer behaviour to change the plan before the plan consumes the company.
On Friday, Kwame could still decide that invoice matching was too weak a wedge. He might return to one of the other eleven ideas. But he would make that call with a week of sharper evidence, rather than another polished feature waiting for a reason to exist.
Comments
No comments yet.