Validate the user, buyer and budget owner as three separate markets. A working workflow in Accra does not prove that a buyer in Berlin will sign, or that a budget owner in New York will approve the spend.
In 2007, M-PESA launched in Kenya after a pilot built around microfinance loan repayments. Customers used it for something broader and more immediate: sending money to other people. The original premise had not captured the job people chose to hire the service for. Nick Hughes, then at Vodafone, helped develop the idea; the shift in customer behavior is documented in CGAP’s paper Mobile Payments Go Viral: M-PESA in Kenya.
That is the moment worth holding onto when a product spans Accra, Berlin and New York. The first promising signal can be real and still answer the wrong question.
Three people can validate three different things
A user in Accra can tell you whether the product survives a real working day. They reveal where the workflow breaks, which data arrives late, what someone will tolerate on a phone, and whether the AI output saves enough effort to be used again tomorrow.
That is product validation. Treat it with respect. Spend time watching the current process before you ask people to describe it. Ask for the spreadsheet, the WhatsApp thread, the approval chain, the handoff that gets lost every Friday afternoon. A polished demo can hide the cost of changing behaviour.
The buyer in Berlin is evaluating a different proposition. They may care about the same workflow, but they also need a defensible reason to choose you over doing nothing, extending an existing tool, or asking an internal team to build a smaller version. Their question is often less “does this work?” and more “can I take responsibility for this decision?”
The budget owner in New York may sit even further from the workflow. They need a clear commercial case: what money is being spent, whose budget carries it, what happens if the project stalls, and why this deserves attention ahead of the other items already waiting for approval.
One product can earn enthusiastic user feedback and still fail in the buying process. That outcome does not make the user research worthless. It tells you exactly which market remains unproven.
Write separate validation questions before you build
I have found it useful to keep three columns beside any early product assumption.
For the user: What repeated task becomes easier, faster, safer or less frustrating? What would make them return next week without being chased?
For the buyer: Which measurable problem are they buying relief from? What evidence would let them explain the purchase internally?
For the budget owner: What is the smallest commitment that proves this is worth funding? A paid pilot, a defined team, a limited workflow, a review date.
These questions sound obvious when they sit on a page. They get blurred quickly once a founder has a prospect waiting, a demo that finally works, and a runway that makes every encouraging conversation feel like traction.
That pressure creates a familiar mistake: treating the person who enjoys the demo as the person who can move the deal. Sometimes they are. Often they are the source of the most useful product truth and none of the purchasing authority.
Mina’s strong candidacy. The evidence for buyer demand was still missing. is the kind of distinction that matters here. Strong signals can support a decision without completing it.
Design the test around the handoff between markets
The useful test is rarely “Will people use this?” on its own. It is “Can a user get value, can a buyer recognize that value, and can the budget owner approve a first paid step?”
That means putting the handoffs into the test early.
If the user is in Accra, ask them to use the product on a live task with the constraints they already have. Capture the before and after in their own language. Avoid translating their experience immediately into a generic productivity claim.
Then take that evidence to the Berlin buyer and ask for a decision, not praise. Would they sponsor a narrow paid use case? What would need to be true before they involved procurement or finance? Which person needs to see the result?
Finally, test the New York budget conversation at the actual level of commitment you expect. If you need an annual contract, a conversation about a free trial will not tell you enough. If the realistic first step is a limited pilot, make that scope and price visible. You are testing the buying motion alongside the product.
This may feel slower than collecting sign-ups. It usually removes a more expensive delay later, when the team discovers that every enthusiastic user depends on a buyer who cannot explain the spend.
Keep the evidence attached to the person who gave it
Do not combine feedback from all three groups into one slide called “market validation.” Label it by role, location and decision power.
A user’s complaint about onboarding may require product work. A Berlin buyer’s concern about implementation may require a clearer service boundary. A New York budget owner’s request for a smaller first commitment may require a different commercial package. These are separate decisions, and treating them as one produces vague fixes.
M-PESA’s early users showed that the real job was larger than the original premise. Your own validation can do the same, provided you let each market answer its own question. Before the next build cycle, write down one assumption for the user, one for the buyer and one for the budget owner. Then make each of them take a real action that could prove you wrong.
Comments
No comments yet.