Builders Need Strategy Now

Why "just build it" is not enough anymore

"Just build it" used to be a useful correction.

It cut through theater. It got the team out of decks and into contact with the work. It punished abstraction when abstraction was only a way to avoid making.

But speed is not strategy. A team can now move quickly in the wrong direction with more polish, more confidence, and more artifacts than ever. The execution-only builder — the role that earned authority on speed and craft inside a chosen direction — is no longer enough when the chosen direction is the unresolved question.

What is scarce now is the judgment about which thing the team should be building at all. That means choosing the problem, the refusal, the user, and the disappointment the product is willing to create on purpose. None of that is a deck. It is the new shape of the work.

Strategy, at this level, is not a three-year plan. It is the sequence of product refusals and product bets that gives the work a direction. This user, not that one. This problem, not the adjacent one. This next bet, because it makes the next useful bet possible.

That does not make product builders a substitute for every strategic function around them. Market structure, distribution, pricing, capital, competitive timing, and company appetite still matter. The builder's responsibility is not to own all of that alone. It is to stop pretending those forces are elsewhere when they are already shaping what gets built.

What this kind of strategy is not

"Strategy" is one of the most over-claimed words in product writing. It can mean almost anything, which means it usually does mean almost anything, which means the word stops doing work. Naming what builder-held strategy is not is the cheapest way to keep the word honest.

It is not market analysis. The work of mapping segments, sizing opportunities, and reading category dynamics belongs to the people whose craft is to do it well. A builder who picks up a market deck and starts redrawing it is mostly performing strategy in someone else's lane.

It is not competitive positioning. Where the product sits in the competitive landscape, what message it carries to which buyer, which differentiators it leans on — that is the work of the people who own the brand and the go-to-market motion. The builder informs it. The builder does not own it.

It is not pricing. Pricing is its own discipline. It depends on willingness to pay, contract structure, sales motion, and a half-dozen other inputs the builder does not see. The builder can break pricing easily by making a product judgment without checking; the builder cannot fix pricing alone by making a product judgment well.

It is not go-to-market. Channel strategy, expansion motion, partner ecosystems, sales enablement — none of that is what this chapter is asking the builder to hold. Those functions exist for a reason, and they are usually better held by the people who specialize in them.

What is left, when those four are subtracted, is the part of strategy that lives inside the build itself: which problem the product is solving, which problem it is refusing, what the next bet makes possible, what the cost of saying yes is. That is the strategic work the builder cannot delegate without losing the call. Everything else can stay in the lane it belongs in.

This narrowness is what keeps the word usable. A builder who claims strategy in the wide sense will find the wide sense calling on them — to write the GTM brief, to defend the pricing, to map the competitive landscape — and lose the build at the same time. A builder who claims the narrow version stays inside the work that produced their authority and uses strategy as the filter that authority earns.

The leverage lens

The cleanest way to convert "think strategically" from a vague obligation into a usable filter is to ask, of any product bet, what it actually improves for the user. A good bet improves at least one axis in a way the user can feel; a bet that improves none of them is not a bet — it is occupied calendar time.

Clarity. Does this make the user's understanding of their own work sharper? Some products do not change what the user is doing; they change how clearly the user can see what they are doing. The dashboard that names the right metric, the report that surfaces the missed pattern, the empty state that tells the user what to look at first — all of these are clarity bets. The wrong clarity bet adds another chart to a screen that already had six.

Speed. Does this remove time from a task the user is going to repeat? Speed bets are the most legible kind because they show up in metrics, but they are easy to fake — a system that saves the user three seconds and adds a confirmation dialog later has made the user slower. Real speed bets compound across sessions; fake ones photograph well in a demo.

Confidence. Does this let the user act when they would otherwise hesitate? Confidence is the part of product value that rarely gets named. The system that explains its reasoning, that shows the consequences of the action before the user takes it, that lets the user undo without panic — those are confidence bets. The user who can act without anxiety uses the product more, and uses it for harder things.

Quality. Does this make the work the user produces better than it would have been without the product? Quality bets are unfashionable because they take longer to land and are harder to measure than speed. They are also the bets users come back for. A writing tool that helps a user write a better email beats a writing tool that helps them write a worse email faster.

Coordination. Does this reduce the number of conversations a team needs to have to stay aligned? Coordination is invisible work; the team with bad coordination loses two hours per person per week to standups, status updates, and re-explaining context. Products that absorb that work — by making state visible, by making decisions traceable, by making handoffs cheap — are coordination bets, and they tend to be undervalued by the teams that build them.

Decision-making. Does this make a decision the user has to make either better or unnecessary? The most leveraged form of product value is removing a decision the user did not need to be making, or surfacing the right context for a decision the user did. A product that sits between the user and a decision they make often is in the most strategic position any product can be in.

Run a tempting roadmap item through the lens.

“Add an AI summary to every project update.”

Clarity: maybe, if the summary names what changed and what needs attention. Speed: yes, if it saves people from reading every update. Confidence only appears if the source material is visible and the summary marks uncertainty. The real test is whether the summary changes the next decision, or only produces a paragraph of compressed noise.

The lens does not say whether the feature is fashionable. It says what kind of value the feature is allowed to claim.

Choosing problems on purpose

Choosing problems is the part of strategy nobody finds satisfying. It is mostly subtraction.

The first move is to write the list of problems the product is currently solving — not the features, the problems. Most teams cannot do this without arguing for an hour about what they actually do. The argument is the work. The list at the end is usually shorter than the team thought, and contains at least one problem nobody had said out loud was on the list.

The second move is to write the list of problems the product is not solving on purpose. This is harder. It requires the team to admit that there are users they have decided not to win, jobs they have decided not to do, and adjacencies they have decided not to chase. Without this list, every quarter becomes a referendum on whether the product should also try to do the next thing. With this list, the question stops being open.

The third move is to write the list of problems the product is solving badly because it should not be solving them at all. Every product has a few of these — features that exist because someone asked for them once, that the team maintains because removing them would be embarrassing, that absorb attention out of proportion to their value. Naming them is the first half of the work; cutting them is the second half, and the second half is the one almost nobody does.

Choosing problems on purpose has a real cost. The team that says no to a customer with money is going to feel that no in the next renewal conversation. The team that cuts a feature is going to hear from the users who liked it. Strategy without that cost is not strategy — it is preference dressed up as a roadmap. The strategic builder is the one willing to pay the cost in the meeting it lands in, instead of paying it later in a product that was trying to be everything.

A worked no, in the room that did not want to hear it

A team is one quarter into a B2B operations product. A senior account asks for a feature: a custom export of analytics data into the format their compliance team prefers. The account is the third largest in the book. The customer success lead is presenting the request as a churn risk. The CEO has the request on this week's executive update. The PM is willing to sequence it next sprint.

The roadmap item is "Custom compliance export." It runs through the leverage lens like this. Clarity: none — the account already understands their compliance requirement. Speed: none — the export is run quarterly. Confidence: none for the broader user base. Quality: possibly negative — the export expands the surface area of the compliance feature, which the team is already deferring maintenance on. Coordination: none for the broader team; some for one user. Decision-making: none.

The lens says no. The room wants yes.

The strategic builder writes one paragraph, before the planning meeting, in the doc the meeting will use. The paragraph names the leverage answer: this item improves nothing the broader product owes its users, and it adds maintenance to a surface the team has already chosen to under-invest in. The paragraph names the cost of saying yes: a quarter of an engineer's time, a deepening commitment to a custom export pipeline that the team will quietly hate, and a roadmap that is now governed by the loudest customer rather than the strategy the team set in calm. The paragraph names the cost of saying no: a difficult conversation with the customer success lead, an explanation to the CEO, and the possibility — not certainty — that the account churns over a feature the broader strategy says is the wrong thing to build.

The paragraph also names the honest move that respects both: build a one-time export script, run it manually for this customer for the next two quarters, do not put the surface in the product, and use the time to ship the broader compliance work the strategy actually points at.

The room does not love the paragraph. The customer success lead is annoyed. The PM is mildly relieved that someone wrote the cost down. The CEO asks a sharp question about the churn risk and is given a sharp answer: the account churn risk is real, the cost of building the wrong product to prevent it is also real, and the team's job is to hold both costs at the same time rather than treat the loud one as the only one.

The team ships the manual export. The account does not churn that quarter. The next quarter, the broader compliance work lands and the manual workaround retires itself. The strategic call held because the cost of saying no was named in the same room the cost of saying yes would have been hidden in.

The point of the example is not that the call always lands. It is that the call has to be made in writing, with the cost named, in the room where the decision happens. A roadmap item that fails the leverage lens but is shipped anyway is a strategic erosion the team can recover from. A roadmap item that fails the leverage lens, is shipped anyway, and is not named as a cost at the moment of shipping, is a strategic erosion the team will repeat.

Holding strategy without becoming a strategist

The trap on the other side of "builders need strategy" is "builders should become strategists." That trap is worth naming explicitly, because the people most likely to read a strategy framework are exactly the people who would lose authority over the product by leaving the work that gives them the authority.

The point is not to leave the build and write decks. The decks are mostly performative; the strategic clarity that matters lives in artifacts the team is already producing. It lives in the spec — the line that says "the product is not for X" and means it. It lives in the prototype — the version that strips out the four features the team thought were essential and is honest about whether the product still works. It lives in the pull request — the engineer who pushes back on a direction because the user the team chose is not the user this code serves.

Strategy held inside the build looks different from strategy held next to it. It is shorter. It is sharper. It is more often a refusal than a chart. It is most useful when it is wielded by the same person who is going to ship the next thing, because the refusal lands at the moment the build would have started instead of two weeks later in a slide review.

What is being asked of builders is not the abandonment of craft for abstraction. It is the integration of the strategic call into the craft itself. The builder who can hold that call and stay in the work makes the product sharper because the same hand is making the calls and shipping the consequences.

That does not make strategy as a discipline disappear. It makes strategic judgment harder to outsource.