From Intuition to Evidence: Harnessing the power of Founder Intuition (part 2)
Founder intuition is a founder’s built-in pattern recognition, in other words, an instinct for where value might emerge, which problems matter, and how new tech could unlock them. It’s powerful, but it’s also blurry by nature. Intuition often flags “a need”, but it may not always clearly delineate whose need it is (market, business, buyer, user, or stakeholder). When those voices get blended, the vision naturally needs to widen to cover everything that seems promising. However, the wider the initial vision the more likely it is that founders build in “roadmap drift”, where you chase a solution broad enough to interest everyone, but becomes a solution not specific enough to truly delight any one stakeholder group.
The fix isn’t to mute intuition; it’s to focus it with structure. Practically speaking, this means that as founders you must first untangle the stakeholder problems and then spend time mapping the identified needs to individual problem spaces for each stakeholder.
1) Identify your Problem Spaces: Map the stakeholders
The first practical and easiest step is to list out the real people your product touches. This is especially important in B2B, where it is easy to fall into the trap of building for the Franken-Customer - the mash-up persona that blends buyer, user, and approver into one vague entity (sometimes colloquially referred to as “the customer”). With the Franken-customer, no single human has its combined needs, which means building a product to satiate this composite persona risks designing a product from truly serving any one individual group. Take the time to pull the stakeholders apart so that you can more properly empathise with and understand each group that touches your product so that you can better understand what value they each expect to obtain from your product.
- Payer (budget owner/renewal)
- Primary user (daily workflow)
- Admin/Operator (implements/maintains)
- Approver/IT/Sec (risk & compliance)
- Exec sponsor (business outcome owner)
Pick one primary stakeholder to win first, and identify the secondary stakeholders to satisfy, make trade-offs explicit to avoid the Franken Customer Trap.
Modern product practice is to follow a “user first” paradigm, where the primary objective is to focus relentlessly on providing value to the user, meaning the user becomes your primary stakeholder. Just keep in mind that “user first” does not mean “user only” especially when dealing with complex products that touch multiple stakeholders.
Within complex B2B buying decisions, you need to treat each and every stakeholder as if they have veto power on the purchase and renewal of your product, which is why it is so important to clearly delineate each of the users so that you can start to better understand their individual needs.
2) Stand in their shoes: Map out their problems
Once you’ve identified stakeholders and chosen your primary and secondary audiences, the next practical step is to map what you know about each one: the tasks they perform, the problems they hit while doing them, and the value they’re seeking (time, money, risk reduction, peace of mind, effort saved).
This is just to level set everything that you think you know about them - to give you a preliminary problem space that you can assess, test and evaluate.
The way to approach this is that for each stakeholder list out every known problem they have that might be worth solving by capturing them with three crisp lines:
Job - the task they’re trying to complete including the context of what this job fulfills.
Problem - the pain in their words including the context of when it happens.
Value - the outcome that the proves it worked (e.g., time saved, errors reduced, revenue created, confidence gained).
- Write 1–2 sentences max per line; avoid solutions or features.
- Use first-person quotes when possible (“I can’t trust our forecast”).
- Keep terms consistent across stakeholders so you can compare like-for-like.
The idea is to follow a systematic approach to build a comprehensive understanding of the problem space for each stakeholder. Most importantly, writing forces clear articulations using a shared language. It turns your private intuition into a concrete artifact the team can read, challenge, and build on. When it is time to act, the team is not guessing at what is in your head; they are working from a simple, testable model.
3) Pick a problem or cluster of related problems to validate
You’ve mapped stakeholders and their problem space. Now choose one area of focus (a single problem or tight cluster of problems) to validate. Problem-Validation forces you to surface, challenge, and test the assumptions sitting under your problem narrative.
Importantly, problem-validation doesn’t just focus on establishing commercial signals (which is an extremely important signal), but instead focuses on ensuring that you understand exactly all of the intricacies and the nuances of the problem you are solving. As you will discover in the next section about evidence, problem-validation is about sharpening the problem itself to ensure that what you build truly solves the stakeholder problem.
Selection criteria (use 5–7 minutes):
Payer value: Solves something the payer cares about (renewal/ROI).
User must-win: Enables the primary user to succeed clearly.
Severity & frequency: Pain is frequent and costly today.
Feasible now: A testable slice in 4–6 weeks (concierge, prototype, pilot).
Evidence access: You can reach real users quickly for interviews/tests.
Leading indicator: You can measure early proof (time saved, error rate, conversion, $$).
Write one testable POV (per your pick):
For [stakeholder/segment], who [pain in their words], we believe [intervention/change] will [outcome] as measured by [signal/metric] within [timeframe].
Declare non-goals (for this cycle):
List 3 valuable ideas you won’t do now to avoid Franken-Customer scope creep.
Set kill/continue rules upfront:
Define what “enough signal” looks like before you collect evidence.
Now move into Clean Evidence with a precise bet to test.
