DIGNALEGI

Worth reading. A personal index selected by Ratipcan Uysal.

Digna Legi guide / Product strategy

How to Build a Product Strategy That Can Be Proven Wrong

Build a product strategy that can be tested: state the causal claim, bound the downside, define the evidence, and decide in advance what would stop the bet.

By Ratipcan Uysal8 min read

A torn paper route splits at a mechanical test press; one branch continues and the other stops at a yellow gate.

Ask one question of your current product strategy:

What evidence would make us stop?

Most strategy documents cannot answer it. They describe a market, announce an ambition, list several priorities, and end with a roadmap. If the numbers improve, the strategy takes credit. If they do not, the team says execution was weak, the market changed, or more time is needed. The document can explain every outcome because no outcome was allowed to disprove it.

That is not a strategy. It is a funding request protected from reality.

A product strategy is a consequential claim about cause and effect. It says that a particular change, for a particular customer, should alter behaviour in a way that matters to the business. It concentrates resources behind that claim, accepts an explicit downside, and names the evidence that would justify continuing or stopping.

The point is not to predict the future accurately. Product work rarely permits that. The point is to make the choice precise enough for the future to answer back.

Turn the ambition into a causal claim

“Win the enterprise,” “become a platform,” and “use AI across the product” are not strategies. They may be directions. They contain no account of how the desired change will happen.

A causal claim has five parts:

For this customer, facing this constraint, changing this part of the product through this route to adoption should produce this observable behaviour.

The sentence is deliberately unforgiving. It exposes the gaps that broad language hides.

If the customer is “everyone,” the team has not chosen. If the constraint is a category such as onboarding or collaboration, the team has not diagnosed it. If the product change is merely a technology, the mechanism is missing. If the route to adoption is absent, the strategy assumes customers will somehow arrive. If the expected evidence is “engagement,” almost any activity can be presented as progress.

Diagnosis comes first because different product problems do not obey the same logic. Product Work Beyond Product Market Fit distinguishes feature, growth, scaling, and product-market-fit expansion work. A feature problem asks whether a capability creates enough customer value to justify its lasting cost. A growth problem asks which constraint in acquisition, retention, or monetisation prevents existing value from spreading. A scaling problem asks which bottleneck will soon stop the product or organisation from moving. An expansion problem asks why this company is unusually equipped to win with a new product or market.

Treating these as interchangeable produces expensive category errors. A retention problem becomes another feature launch. A scaling constraint becomes an innovation project. An expansion bet receives a large team before the company has earned clarity.

Reforge’s account includes a useful Pinterest example. According to Casey Winters, the company spent one year building Maps and Q&A products that had no material business impact and were later removed. The following year, changing the label “Pin It” to “Save” reportedly increased activation by 15 percent. The lesson is not that labels beat new products. It is that the right diagnosis can make a small intervention more strategic than a large launch.

The causal chain must include distribution. Brian Balfour’s Product Channel Fit argument is blunt: products adapt to the rules of channels; channels do not adapt to products. A collaborative product hoping to grow through invitations needs fast, shareable value. A product relying on search needs demand, indexable supply, and a reason that supply keeps growing. A high-touch enterprise product needs economics that can support the sales and implementation motion.

“We will find a channel after product-market fit” is not prudence. It may be evidence that the product and its path to customers have been designed as separate systems.

Before a roadmap exists, write the causal claim.

If the team cannot agree on the sentence, adding delivery detail will only make the disagreement harder to see.

Bound the downside instead of scoring confidence

Once a strategy sounds coherent, teams often assign confidence to it. The number creates an appearance of discipline: 70 percent confidence in the impact, 80 percent confidence in delivery, a weighted score precise enough to sort the roadmap.

The precision is usually fictional.

Jason Cohen’s Lost Confidence shows how placing confidence inside a prioritisation score can systematically favour small, familiar work. Incremental projects feel predictable. Differentiating bets do not. Multiplying value by confidence can therefore make a safe improvement look equivalent to a much larger opportunity before the team has confronted the actual choice.

Many product decisions involve uncertainty, not calculable risk. The team does not know the underlying probability that a new behaviour will spread or that a new market will care. A percentage does not repair that ignorance.

The useful alternative is to shape the bet:

  • What is the maximum time, money, and organisational attention we are prepared to lose?
  • What is the smallest complete version capable of producing meaningful evidence?
  • What customer action costs more than an opinion and therefore signals real intent?
  • What option remains if the bet fails?
  • Is the possible upside large enough to make the bounded downside rational?

This changes the conversation. “We are 60 percent confident” invites debate about a number nobody can calibrate. “We will give two people six weeks to get three customers through the complete workflow without bespoke support” defines exposure and evidence.

It also prevents a common failure: allowing the size of the investment to become the reason for continuing it.

The shape should match the kind of work. Product Strategy Is Really About Offense vs. Defense distinguishes investments intended to create meaningful upside from those intended to prevent material downside. Offensive bets need enough concentration to change the company’s trajectory. Defensive work needs a threshold: enough reliability, capacity, compliance, or parity to contain the risk, followed by restraint.

Defense is not less important. It has a different stopping rule. Reliability can always be improved. So can polish, performance, and internal efficiency. When a defensive initiative has no acceptable-risk threshold, it expands indefinitely and consumes the capacity for offense.

Some work is neither. It creates no meaningful upside and prevents no current material loss. Competitor imitation, premature infrastructure, and familiar improvements often survive because they are easy to explain—not because they deserve strategic priority.

A real strategy names the loss limit and the opportunity cost.

Without both, “focus” is only a description of what the team happens to be doing.

Decide how the strategy dies

The best time to define contrary evidence is before a team has been staffed, a launch date has been promised, and executive reputation has become attached to the plan.

After commitment, neutral evidence becomes difficult to interpret neutrally. Weak signals are reframed as early promise. Missed targets become timing problems. Customer resistance becomes an education problem. The strategy survives by changing the explanation rather than changing the decision.

Mike Fisher’s Red-Teaming Your Strategy argues that challenge cannot depend on someone being unusually brave or contrarian. Under time pressure, organisations become more decisive, not more reflective. If checking the argument is optional, momentum will remove the check precisely when it matters.

Red-teaming should therefore be procedural and proportionate. A reversible interface choice does not need a tribunal. A high-downside, ambiguous, difficult-to-reverse bet does need someone other than its author to search for disconfirming evidence.

Before commitment, answer four questions:

  1. What must be true at the same time for the causal chain to work?
  2. What evidence would we expect to see if the central claim were false?
  3. Which result earns more investment, and by what date?
  4. Which result stops or materially changes the bet?

The fourth answer is the kill condition. It should describe evidence, not emotion. “When leadership loses confidence” is not a condition. Neither is a lagging target so distant that the company must spend the full budget before learning anything.

A good kill condition sits close to the disputed mechanism. If the strategy assumes that security review blocks enterprise adoption, measure whether removing that friction changes approved deployments—not whether more prospects visit the pricing page. If the strategy assumes collaboration creates distribution, measure completed invitations that produce active collaborators—not the number of times the share button is displayed.

The condition does not need to force immediate cancellation. It can trigger a smaller team, a different segment, a revised mechanism, or another round of evidence. Its purpose is to prevent continuation from becoming the default.

A pre-mortem that cannot change the allocation is theatre. A red-team review that produces a longer risk register but leaves the bet untouched is documentation.

The test matters only if reality has permission to alter the decision.

Write one page before making slides

A strategy should be compact enough that its logic can be inspected without navigating a performance of certainty.

Write one page with these fields:

Change
What has changed in the customer, market, product, channel, or company? Separate observed facts from interpretation.
Causal claim
For which customer, facing which constraint, should what product change produce what behaviour through which adoption route?
Choice
Where will the company concentrate? What will receive less attention as a consequence?
Bet
What upside justifies the work? What is the maximum acceptable loss? What is the smallest complete test?
Evidence
Which observed behaviour earns more investment? Which evidence contradicts the mechanism?
Kill condition
By what date will which result stop or materially reshape the bet, and who has authority to act?

Only then write the roadmap. It is not the strategy itself.

The roadmap should express the order in which the strategy intends to buy evidence.

This one-page note should survive two readings. A sceptical executive should be able to identify the weakest assumption. A delivery team should be able to make local trade-offs without asking which ticket matters more. If neither can do that, the document has communicated activity rather than choice.

Let reality answer

A strategy does not become stronger when it becomes harder to challenge. It becomes more expensive to correct.

The goal is not certainty. It is a clear causal claim, concentrated resources, bounded exposure, and a fair test. That combination will sometimes prove the strategy wrong. This is not a defect in the method. Discovering a bad strategy while the loss is still bounded is one of the best outcomes strategy work can produce.

The dangerous strategy is the one that can absorb every result and continue unchanged.

Write the claim. Name the sacrifice. Limit the loss. Decide how the bet dies. Then let the world answer.

Sources and further reading