What does “Strategy-First” Product Development mean?
It doesn't mean months of research. It means three questions, answered honestly, before you write a single line of code.
People hear "strategy-first" and think it means months of research. That's not it. It means asking the right questions before committing resources to answers. Those questions don't take months. They take days. Sometimes hours."
I hear it at least twice a week. A founder walks in with a roadmap that reads like a wish list, a team that's been building for six months, and a metric that hasn't moved. When I ask them to walk me through the last three features they shipped, the answer is always some version of the same thing: it seemed important at the time.
That's not a strategy problem. That's a sequencing problem. The building happened before the thinking. And once the code is written, the thinking feels optional — because the feature already exists.
Strategy-first doesn't mean slow. It means the thinking happens before the building, not during it. And that shift in sequence, even if it only takes an afternoon, changes everything about what you end up with.
Why Teams Skip the Thinking and Go Straight to Building
It's not laziness. The honest reason is that building feels like progress and thinking feels like delay. When a team has engineering capacity, a backlog of feature requests, and a founder who is excited about a direction, the path of least resistance is to start. The wireframes come later. The user interviews happen in parallel. The strategy document gets written after the sprint.
This is how you end up with what I call speculative engineering: features built on the assumption that someone will want them, rather than on evidence that someone already needs them. The code is real. The problem it solves is theoretical.
THE COST EQUATION
A decision made at the strategy stage costs an afternoon. The same decision made after the feature is in production costs weeks of rework, a confused user base, and often an engineer who's quietly updating their CV. The sequence matters more than the speed.
Why Teams Skip the Thinking and Go Straight to Building
Most founders can answer the three questions quickly. The problem isn't the questions — it's the honesty. "We think a lot of users have this problem" is not an answer to Question 1. "It would probably hurt retention" is not an answer to Question 2. "We could do a v1 in a sprint" is not an answer to Question 3.
Here's what honest answers look like in practice.
Question 1 — Who specifically will use this?
The answer needs a name, a role, and a specific conversation. Not "enterprise HR managers" — "Sarah at Atlassian who told me last Tuesday that her team spends four hours every Monday reconciling leave requests in a spreadsheet." If you can't get to that level of specificity, the problem isn't validated yet.
Question 2 — What happens to the business if we don't build this?
The honest version of this question cuts through a lot of roadmap noise fast. If the answer is "our existing users keep doing what they're doing," that's a signal the feature is a vitamin, not a painkiller. If the answer is "we lose the Atlassian deal and three others like it," you have urgency with evidence. The business impact test separates nice-to-haves from must-haves before you've written a single line of code.
Question 3 — What's the simplest version we could ship in two weeks?
This question forces scope honesty. Most founders answer it with a feature. The right answer is a test. What is the minimum experiment that tells you whether the hypothesis in Question 1 is correct? Two weeks isn't a constraint — it's a forcing function that stops gold-plating before validation.
Real Example
When Figma was deciding whether to build FigJam, the team didn't immediately scope a full whiteboarding product. They asked who specifically was being underserved, what happens to the business if designers keep using Miro for brainstorming, and what the simplest version looked like. The result was a focused MVP, not a feature war with an established competitor. They knew the 'who' before they wrote the 'what'.
Think Slow, Act Fast, It's About Sequence, Not Speed
The phrase gets misread. Founders hear "think slow" and assume it means a research phase that burns three months before any code gets written. That's not what it means.
Think slow means: be deliberate about the questions you answer before you start. It means spending an afternoon — not a quarter — on the three questions above. It means walking into the sprint with evidence, not assumptions.
Act fast means: once you have honest answers, build without hesitation. You've done the hard thinking. You know who the user is. You know what changes if you solve the problem. You know what the minimum version looks like. Now you build fast — because you're building the right thing.
The founders who get this wrong aren't slow thinkers or fast builders. They're fast thinkers and fast builders — which means they think while they build, and the product ends up carrying all the weight of decisions that should have been made on a whiteboard.
Have you ever saved time by not building something? The best product decisions I've seen aren't the ones where a founder moved fast and shipped something brilliant. They're the ones where a founder asked the three questions, didn't like the answers, and chose not to build. That's strategy-first in its most valuable form.
What Strategy-First Looks Like for Real Companies
CASE STUDY
Notion
Notion didn't launch with everything. They launched with a document editor that was intentionally limited — no integrations, no databases, no team features. The strategy question they answered first was: who specifically is paying to switch from Google Docs, and what would have to change for them to do that? The answer was a specific segment of knowledge workers who needed connected documents, not a feature-complete platform. They built for that answer first. Everything else came after the hypothesis was proven.
CASE STUDY
Superhuman
Rahul Vohra ran Superhuman through a ruthless strategy test before scaling growth. He didn't ask 'how do we get more users?' He asked: 'who would be very disappointed if Superhuman went away, and what specifically would they miss?' That's Question 1 and Question 2 run in reverse — on an existing product. The answer shaped every product decision for the next two years. The thinking came before the building, even after the product existed.
The Afternoon That Pays for Itself
The three questions take an afternoon to answer properly — if you answer them honestly. But they eliminate the speculative building that eats engineering budgets at scaling companies. They save you the six-month build, the low-adoption launch, the re-architecture sprint.
Before your team starts the next feature, ask the room: can we answer all three questions with evidence, not assumptions? If the answer is yes, build fast. If the answer is no, you've just saved yourselves a sprint.
The thinking happens in hours. But it has to happen before the building. That small shift in sequence changes everything about what you end up with.
A question I'd genuinely like to hear your answer to: what's the most expensive feature you ever built that didn't need to exist? Reply, or send me a note. I read everything.
If you want the one-page checklist I walk founders through before every feature kickoff, it's a free download.
→ Grab the Strategy-First Feature Checklist
Interested in learning more about x-enabler?
Leave a comment!