Product Signal Beats Product Hope
How to separate a durable customer instinct from a fragile solution idea, test the right uncertainty, and stop weak bets before they consume the roadmap.

On this page
- 1.Separate the instinct from the idea
- 2.Proven, better, new
- 3.Name the uncertainty before choosing the test
- 4.Define the bet completely
- 5.Belief and hope are different
- 6.Read signal by strength
- 7.Strong signal often reduces friction elsewhere
- 8.Use AI to increase learning, not active bets
- 9.The bet review
- 10.Anti-pattern: prototype accumulation
TL;DR
- A strong instinct about customer pain can survive several failed solution ideas. Do not confuse commitment to the problem with commitment to one implementation.
- Test the most consequential uncertainty with the cheapest credible evidence. A prototype is one instrument, not the default answer.
- Define success, failure, and abandonment conditions before the result arrives. Hope is what remains when a bet has no stop rule.
Product teams rarely fail because nobody had ideas. They fail because weak ideas remain alive after the evidence has stopped supporting them.
The discipline is not perfect prediction. It is separating what you believe about the customer from the solution currently carrying that belief, then designing a test that can change your mind.
That is thinking in bets.
Separate the instinct from the idea
Mark Pincus describes a useful product-making distinction: your underlying instinct may be right while the idea placed on top of it is wrong. His shorthand is deliberately provocative: instincts are right more often than ideas.
The exact percentages are not the point. The separation is.
An instinct sounds like:
Small business owners lose valuable leads because they cannot answer calls while doing the work.
An idea sounds like:
Build an autonomous voice agent that answers every call and books every job.
The instinct can be valid while the idea fails on trust, cost, latency, workflow fit, or customer preference. Teams that fuse the two interpret rejection of the voice agent as rejection of the problem. Teams that separate them can test another approach without restarting their understanding of the customer.
For every initiative, write both statements:
- Customer instinct: the durable observation about pain, motivation, or behaviour.
- Solution bet: the current intervention you believe could improve it.
Protect the first only while evidence supports it. Treat the second as expendable.
Proven, better, new
Pincus's Proven Better New framework offers a practical way to analyse a product idea without demanding novelty everywhere.
Proven identifies patterns customers already understand and value in the current platform, audience, and context. Proven is not a product that worked for somebody else ten years ago. It must transfer credibly to this situation.
Better names the improvement users can recognise. “More innovative” is not better. Faster setup, lower cost, fewer errors, stronger control, or a materially better experience can be.
New is the unproven element that gives people a reason to switch, try, or care. New carries the largest uncertainty. Isolate it so a weak onboarding flow or missing table-stakes feature does not prevent you from learning whether the new idea works.
Use the framework as an analysis tool, not a recipe. Some products win with proven and better alone. Others introduce a new capability that changes the category. The value lies in knowing which part of the bet requires evidence.
Name the uncertainty before choosing the test

Teams often choose a prototype because it is easy to make. That reverses the logic.
Start with the uncertainty:
| Uncertainty | Best first evidence |
|---|---|
| Does this problem matter? | Observation, customer interviews, behavioural data, support evidence |
| Can we explain the value clearly? | Narrative, concept statement, landing page, sales conversation |
| Can users understand the interaction? | Sketch, clickable flow, or working prototype |
| Can the model perform the task? | Eval set against representative cases |
| Will people change behaviour? | Concierge test, live pilot, or limited production release |
| Can we operate it safely and profitably? | Production-shaped test with real integrations, controls, and cost measurement |
The cheapest test is not the one that takes the least time. It is the least expensive test capable of resolving the uncertainty.
A polished prototype is wasteful when the team still disagrees about the problem. A document is insufficient when the risk sits in an interaction. An offline eval cannot prove adoption. Match the evidence to the decision.
The discovery chapter turns this into a lifecycle.
Define the bet completely
A useful product bet has six parts.
1. Observation
What have we seen in customer behaviour, operations, market structure, or technology?
2. Belief
What do we believe that observation means?
3. Intervention
What will we change for which user?
4. Expected outcome
Which behaviour or business result should move, by how much, and over what period?
5. Evidence threshold
What result would justify more investment?
6. Abandonment condition
What result, cost, failure, or elapsed time would make us stop or materially change direction?
Write the sixth part before building. Otherwise the team will reinterpret every weak signal as a reason to continue.
Belief and hope are different
Belief has evidence and a mechanism. Hope has attachment.
You believe a feature will improve activation because users repeatedly fail at one observed step, the intervention removes that friction, and a controlled release changes the behaviour. You hope when the metric is flat but the team explains that customers need more education, more features, another redesign, or another quarter.
The phrase “it just needs more time” should trigger a review of the original abandonment condition.
Stopping is not failure. Continuing without a credible mechanism is.
Read signal by strength
Not all positive evidence deserves equal weight.
Use a signal ladder:
- Opinion: someone says they like or want it.
- Attention: they click, join a waitlist, or request access.
- Effort: they invest time, data, setup, or organisational approval.
- Behaviour change: they alter an existing workflow and return.
- Economic commitment: they pay, expand, renew, or accept a meaningful trade-off.
- Durable outcome: the product repeatedly changes a customer or business result.
Each rung answers a different question. Waitlist growth is evidence of attention, not retention. Prototype enthusiasm is evidence of interest, not operational fit. Revenue from a founder-led pilot may not prove repeatable demand.
Name the rung. Do not promote the evidence.
Strong signal often reduces friction elsewhere
When a product has real pull, several parts of the system tend to improve together: users tolerate rough edges, explain the value to others, return without prompting, and create pressure to expand access.
This does not mean every good product launches effortlessly. Regulated procurement, hardware, network effects, and behaviour change can delay visible adoption. It means the team should know which friction is structural and which is evidence that the value is weak.
Ask:
- Is the barrier outside the product, such as procurement or regulation?
- Does the user continue pushing despite the barrier?
- Are we seeing repeated behaviour or isolated enthusiasm?
- Which part of the mechanism is proven, and which part are we explaining away?
Signal is contextual. The standard still needs to be explicit.
Use AI to increase learning, not active bets
Cheaper implementation lets teams test more. It also tempts them to keep more ideas alive.
The strategic advantage comes from faster closure, not a larger portfolio of half-tested prototypes. Limit work in progress. Finish the evidence loop. Archive weak bets with a written reason so the same idea does not return three months later without new information.
AI can help generate variants, analyse feedback, build test harnesses, and simulate edge cases. Synthetic users cannot validate human demand. Model-generated enthusiasm is not product signal.
The bet review
For every active bet, ask:
- What customer instinct are we testing?
- Which solution idea currently carries it?
- What is proven, better, and genuinely new?
- What uncertainty blocks the next decision?
- Which evidence would resolve it?
- What would make us stop?
- Which signal rung have we actually reached?
If the team cannot answer question six, the initiative is not a bet. It is a commitment disguised as an experiment.
Anti-pattern: prototype accumulation
The team can now build a working concept in an afternoon. It creates five. Stakeholders like different options, so all five remain alive while research and engineering continue around them.
Two weeks later, the team has more software and less clarity. Nobody defined which uncertainty each prototype addressed or what evidence would eliminate an option.
Cheap construction multiplied indecision.
A sharper bet resolves the problem: one uncertainty, one credible test and one decision at the end.
Outcome-Driven Thinking defines the result worth pursuing. Taste supplies judgement where evidence cannot choose. Thinking in bets keeps both honest.
v3.1 · Updated July 2026