A product process is typically something like Strategy → Discovery → Specification → Build → Delivery.

We on product teams understand most of these, but many companies struggle with “strategy”. It’s often mocked, and often with reason.

What is it for? What makes a good one?


A PM, a developer, or a designer reading a strategy should think “Yes! I know what to do next.” Product should fall out of a strategy naturally and quickly.

A key component of “actionable” is persuasive. Our colleagues are the first market test of a strategy; if they are not won over, we have work to do.

Where projects don’t support a strategy, we drop those projects. If this never happens, the strategy is underdefined.


A strategy characterizes the bet we wish to make. Is it a $10,000 bet, a $100,000 bet or a $1,000,000 bet? One month, three months or six months? What are the opportunity costs?

The strategy offers a clear picture of success, and a time frame by which it will be visible.

A good strategy is a hypothesis. Another word for “accountable” is testable.

We lose some bets; this is normal and good. We make decide to double down or to cut losses, and we do so crisply.


A strategy is expected to do its homework. We talk to users and their proxies.

We engage with data scientists — not for the numbers, but for epistemology. The data scientists I know are great at turning philosophies into hypotheses. They describe what is knowable, and what is not, and why that’s OK.

We characterize uncertainty. When we make assumptions, we label them as such, and we don’t mistake them for facts. We understand Bayes.