Customer Problems Before Feature Lists starts with a simple test: does this make the work more decidable, or does it only make the work easier to describe? Customer Problems Before Feature Lists: in product strategy, teams often mistake fluency for progress. Customer Problems Before Feature Lists: they can explain the issue, name the stakeholders, and produce a tidy artifact while the actual product choice remains untouched.

Customer Problems Before Feature Lists matters because operating systems decay when decisions stay implied. Customer Problems Before Feature Lists: the company keeps moving, but each team carries a different version of the truth. Customer Problems Before Feature Lists: one group thinks the bet is strategic. Customer Problems Before Feature Lists: another treats it as optional. Customer Problems Before Feature Lists: a third waits for a signal that nobody has agreed to produce. Customer Problems Before Feature Lists: the surface looks aligned until execution exposes the disagreement.

Customer Problems Before Feature Lists is the part of the series that moves the argument from vague agreement into a sharper operating question. Customer Problems Before Feature Lists: the post should therefore leave the reader with something more useful than a principle. Customer Problems Before Feature Lists: it should leave a sharper question, a better artifact, and a way to inspect whether the work changed.

Where the work breaks

Customer Problems Before Feature Lists breaks when the team keeps the conversation abstract. Customer Problems Before Feature Lists: abstract language lets everyone nod because nobody has to give anything up. Customer Problems Before Feature Lists: a real decision has a cost. Customer Problems Before Feature Lists: it changes priority, sequence, ownership, scope, customer contact, or follow-through. Customer Problems Before Feature Lists: if none of those things changes, the team may have had a good conversation, but it has not changed the operating system.

Customer Problems Before Feature Lists also breaks when teams use process as a substitute for judgment. Customer Problems Before Feature Lists: a meeting can collect updates without creating insight. Customer Problems Before Feature Lists: a memo can summarize context without recommending a choice. Customer Problems Before Feature Lists: a dashboard can show movement without showing whether the movement matters. Customer Problems Before Feature Lists: the repair is not more ceremony. Customer Problems Before Feature Lists: the repair is a clearer relationship between evidence and action.

Customer Problems Before Feature Lists has another failure mode: people protect optionality until the decision window closes. Customer Problems Before Feature Lists: optionality feels responsible because it avoids premature commitment. Customer Problems Before Feature Lists: past a certain point, though, optionality becomes a tax. Customer Problems Before Feature Lists: teams keep weak work alive, delay learning, spread attention thin, and make every downstream handoff harder.

What good looks like

Customer Problems Before Feature Lists is healthy when a team can say what changed after the conversation. Customer Problems Before Feature Lists: the change might be small: a narrower customer segment, a stopped feature, a clearer launch owner, a better research question, a different account plan, or a new review date. Customer Problems Before Feature Lists: small changes count when they remove ambiguity and create forward motion.

Customer Problems Before Feature Lists should make disagreement more useful. Customer Problems Before Feature Lists: good disagreement is not noise. Customer Problems Before Feature Lists: it is information about assumptions, risk, incentives, and evidence quality. Customer Problems Before Feature Lists: the operating move is to capture the disagreement in a form the team can test. Customer Problems Before Feature Lists: if the disagreement cannot be tested, it should at least be named as a judgment call instead of hidden as consensus.

Customer Problems Before Feature Lists should also protect the team from false completeness. Customer Problems Before Feature Lists: complete-looking artifacts can still avoid the most important question. Customer Problems Before Feature Lists: the test is whether a new person could read the artifact and understand the decision, the evidence, the tradeoff, the owner, and the next inspection point without reconstructing the whole history.

The useful artifact

Customer Problems Before Feature Lists needs an artifact that is small enough to survive normal work. Customer Problems Before Feature Lists: a useful artifact has five parts: the decision, the evidence, the tradeoff, the owner, and the review trigger. Customer Problems Before Feature Lists: anything beyond that should earn its place.

Customer Problems Before Feature Lists should name the decision in plain language. Customer Problems Before Feature Lists: if the decision is actually three decisions, split it. Customer Problems Before Feature Lists: if the decision has already been made, say that and use the artifact to clarify execution. Customer Problems Before Feature Lists: if the decision is still open, make the options visible enough that people can argue about the real choice.

Customer Problems Before Feature Lists should treat evidence with respect without worshiping it. Evidence has shape. Customer Problems Before Feature Lists: a customer quote, usage trend, sales objection, churn pattern, or support signal can matter a lot, but each proves a different thing. Customer Problems Before Feature Lists: the artifact should say what the evidence supports, what it does not support, and what would be strong enough to change the next move.

Customer Problems Before Feature Lists should make the tradeoff impossible to miss. Customer Problems Before Feature Lists: tradeoff language is the difference between a strategy document and an aspiration document. Customer Problems Before Feature Lists: the team should know what receives less capacity, what waits, what gets cut, what risk is accepted, and which stakeholder will feel the cost.

How to inspect it

Customer Problems Before Feature Lists can be inspected with four questions. What are we choosing? What are we refusing? Customer Problems Before Feature Lists: what evidence would change our mind? Customer Problems Before Feature Lists: what happens before the next review? Customer Problems Before Feature Lists: if a team cannot answer those questions, the work is not yet ready for more process. Customer Problems Before Feature Lists: it needs clearer judgment.

Customer Problems Before Feature Lists should show up in the calendar. Customer Problems Before Feature Lists: if the decision matters, it deserves a checkpoint. Customer Problems Before Feature Lists: that checkpoint does not need to be heavy. Customer Problems Before Feature Lists: it needs a defined signal, a real owner, and permission to change course. Customer Problems Before Feature Lists: without that, the team will keep carrying the decision as background anxiety.

Customer Problems Before Feature Lists should reduce the need for executive translation. Customer Problems Before Feature Lists: a senior leader should be able to inspect the work without redoing the thinking. Customer Problems Before Feature Lists: if the leader has to infer the customer, rebuild the evidence, guess the tradeoff, or identify the owner, the artifact is not doing enough operating work.

Field test

Customer Problems Before Feature Lists can be tested on one live piece of work this week. Customer Problems Before Feature Lists: pick something already consuming attention. Customer Problems Before Feature Lists: rewrite it as a decision, not a status update. Customer Problems Before Feature Lists: name the owner, the evidence, the tradeoff, and the review trigger. Customer Problems Before Feature Lists: then ask what changed because the artifact exists.

Customer Problems Before Feature Lists passes the test when the next action becomes more specific. Customer Problems Before Feature Lists: the next action may be a customer call, a killed initiative, a narrower scope, a pricing review, a product bet, a launch decision, or a management conversation. Customer Problems Before Feature Lists: the important part is that the work leaves the realm of explanation and re-enters contact with reality.

Evidence note: This is an operator-judgment essay grounded in Antoine's local source pack for Product Strategy That Actually Makes Choices and adjacent series context, including https://www.antoinebuteau.com/gtm-strategy-series-index/.

This is part 2 of 10 in Product Strategy That Actually Makes Choices.