From Intuition to Evidence: Harnessing the power of Founder Intuition (part 2)
Learn how to channel founder intuition into a focused, testable hypothesis your team can align around.
Founders rarely suffer from a lack of ideas. The real risk is a wide vision that tries to serve everyone and delights no one.
Founder intuition is a founder’s built-in pattern recognition, that is, 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.
What you will get here: a simple way to turn gut feel into a focused, testable hypothesis your team can align around.
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 which is 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.
🧠Common stakeholders include:
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. Then make trade-offs explicit to avoid the Franken Customer Trap (To read more about overcoming the franken-customer dilemma read here).
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 proves it worked (e.g., time saved, errors reduced, revenue created, confidence gained).
⚙️Tips to make this useful
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.
Copy and Paste Problem Worksheet:
Stakeholder:
Job:
Problem (in their words):
Time (moment in time which this problem occurs):
Value signal (what proves it worked):
Notes:
- 1–2 sentences per line.
- Use first-person quotes where possible.
- Keep terms consistent across stakeholders.Example:
Stakeholder: Agency research lead
Job: Deliver a Monday tracker deck the CMO can trust.
Problem (in their words): “I spend hours cleaning weird spikes and I’m never sure if they’re fraud or real.”
When it happens: Friday afternoon data pull; spikes flagged in two key metrics.
Value signal: Weekly clean-up ≤ 30 minutes and error rate < 1% on those metrics.
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.
Note: Writing forces clear articulation in a shared language. It turns private intuition into a concrete artifact the team can read, challenge, and build on.
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.
Do this next (3 steps, 10 minutes)
List 5 stakeholders your product touches. Circle one primary.
Write 3 J-P-V lines for that primary stakeholder.
Draft one POV and one kill/continue rule you can test in the next sprint.
Next: From Intuition to Evidence: Clean Evidence for Problem-Validation (part 3)
Previous: From Intuition to Evidence: How to Structure Founder Intuition Without Killing It (Part 1)