For years, the user story has been the bedrock of agile development. The classic “As a [user], I want [feature], so that [benefit]” format is tattooed on the brain of every PM. But lately, I’ve seen a growing conversation questioning if this beloved tool is still serving us, or if it’s unintentionally pushing our teams into a feature factory mindset.
The core issue is that user stories often jump straight to a proposed solution (the “what”) without deeply interrogating the user’s underlying problem or motivation (the “why”). This can stifle the creativity of our design and engineering partners, turning them into ticket-takers rather than problem-solvers. The focus shifts to shipping features instead of achieving outcomes.
This has led many teams, including my own, to experiment with alternatives like Job Stories (“When [situation], I want to [motivation], so I can [expected outcome]”) or simple, powerful problem statements. These formats re-center the team on the user’s struggle and the goal, giving them the autonomy to discover the best possible solution. It’s a subtle shift, but it has profound implications for team ownership and innovation.
How is your team approaching this? Are you still all-in on the classic user story, or are you evolving your approach to focus more on problems and outcomes?