For over a decade, the user story has been the bedrock of agile development: “As a [user], I want [action], so that [benefit].” It’s a simple, powerful format. But is its power fading?
I’ve seen a growing number of teams hitting the limits of this structure. Too often, user stories become a feature factory checklist, where the “so that” clause is a weak justification for a pre-determined solution. The focus shifts to the action, not the user’s underlying problem or motivation. This is how we end up with features that technically work but fail to deliver real value.
This has fueled a shift toward more outcome-oriented frameworks, like Jobs to be Done (JTBD). Instead of “As a user…”, we frame the work around the user’s context and goal: “When [situation], I want to [motivation], so I can [expected outcome].” This small change forces a massive mindset shift. It moves the conversation from “What are we building?” to “What problem are we solving?”
Aligning a team around a deep understanding of the customer’s context is the most critical part of a PM’s job. It requires synthesizing insights from every user touchpoint—interviews, support tickets, sales calls—into a coherent picture. Having a central hub for this qualitative data, like the systems we build at https://leera.io, is no longer a nice-to-have; it’s essential for truly understanding the ‘why’ behind the work.
What’s the reality on your team? Are you still finding value in the traditional user story format, or have you evolved to something more focused on problems and outcomes?