Picture walking into a hardware store where, instead of asking what you need to fix, the clerk hands you a catalogue of 160 tools and says: "browse and find what you need." That's exactly what most digital products do today.
The problem isn't a lack of features. It's that products are built around tools, not around user goals.
- A product organised by capabilities forces users to translate between "what I need" and "what's available".
- A product organised by goals eliminates that friction entirely: the user arrives, states their situation, and the product responds.
Architecture: The Tyranny of the Catalogue
For years, the default model for digital products has been the feature catalogue. Menus, tabs, filters, dashboards packed with widgets. Everything available, everything visible — and equally irrelevant if the user doesn't know exactly what they're looking for.
This mistake has a clear origin: products are designed from the inside out. The product team knows the system's capabilities and faithfully exposes them. But users don't think in terms of features; they think in terms of situations. "I need to close this month with the accounts reconciled." "I need my team to stop sending me email updates." "I want to know if this client is going to renew."
Nobody wants to browse 160 tools. They want to solve their specific situation. If your product doesn't speak that language, they'll move to one that does.
The rise of AI has amplified this problem. It's now easier than ever to add capabilities — a model that summarises, one that classifies, one that predicts. The result is products that accumulate raw power but don't solve any specific thing better than before. Stacking capabilities without strategic direction is the most expensive trap in modern product development.
JTBD: Design From the Situation, Not the Solution
Jobs-to-be-Done isn't a trendy methodology. It's a brutal question: what does the user hire your product to do? Not what your product does — what job does it solve for someone in a specific situation.
When you answer that question honestly, the product's architecture shifts. Features don't disappear, but they reorganise around intentional flows. The user doesn't browse; they progress. They don't search; they're guided.
This has direct implications for how features are prioritised, how onboarding is designed, and how product success is measured. A solid early validation process should surface those jobs long before a single line of code is written.
The test is simple: can your user describe in one sentence what specific task they just completed with your product? If the answer is vague or generic, you have a catalogue, not a product.
At Room 714 we work with teams who've already built the product and can't figure out why it doesn't retain users. Most of the time, the diagnosis is this: too many tools, too few clear goals. If that sounds familiar, it's time to ask the right question before adding one more feature.
