Most product failures are not engineering failures. The code shipped. The features worked. The app launched on time. The failure was in the thinking that preceded it -- confusing a list of features with a coherent product.
Feature thinking vs product thinking
Feature thinking starts from capability: what can we build? It produces roadmaps that read like catalogues -- filters, notifications, export, dark mode -- without articulating why any of those things serve the person using the product. The backlog fills. The product gets more powerful and somehow less useful.
Product thinking starts from the person and the job they are trying to do. It asks: what is the outcome this person needs? What stands between them and that outcome? Then it builds the smallest set of capabilities that removes those obstacles.
The difference shows most clearly in what gets cut. Feature teams find cutting painful -- every backlog item represents a request. Product teams find cutting easy, because the question is simple: does this serve the job, or not?
The three failure modes before launch
Scope without a north star -- no clear statement of what outcome the product enables, so every feature is equally valid. The result is a bloated MVP that does many things adequately and nothing distinctly.
Personas without behaviour -- building for 'the busy professional' is a demographic, not an insight. What does that person actually do, step by step, on a Tuesday morning? The behaviour is the insight.
Validation that confirms instead of tests -- asking 'would you use this?' is not validation. People are polite. Real validation measures whether people actually complete the primary job, and where they fail. Failure points are the product.
One question that changes everything
Instead of 'what should we build next?', ask 'what is stopping our user from achieving their goal right now?' The backlog is a tool for answering that question. It is not the strategy.