User stories aren't the tale for discovery

From the volume of blog posts. Show and tell decks and confluence pages you’d think that writing user needs in user story formats would be the road to success. And though it’s a method that some teams find useful it’s not something I ever advocate. And particularly not when a team is exploring what problems to solve (problem discovery).

User needs in user story format, with their “As a [user], I want [action] so that [benefit]” structure, tend to cram needs into a narrow solutionised scope.

This is their point. But to do so they fudge complex things into bite-sized chunks. In discovery or as a vehicle to document the messy reality of a user’s needs, it means missing the broader picture.

A user story might encapsulate a single user’s immediate desire, but it often fails to reflect the collective needs and aspirations of the entire user base. Or the context and why behind the how.

User needs aren’t really a single thing. They’re a complex patchwork.

User needs in user story formats tend to emphasize “how” over “why.” They fixate on the solution before understanding the problem. This can lead to a rush toward building features without a deep comprehension of the underlying issues.

I like building things. I like solving problems. So I need to make sure I’m solving the right problem.

To address user needs effectively, it’s best to spend some time to uncover the root causes of pain points. And give yourself and the team a pause before getting into solving a problem. This way you avoid just recreating whatever burning platform or missed opportunity you’re trying to patch up.

Problem statements can offer a more thoughtful approach by succinctly articulating the core issues and context. Other techniques like journey maps or storyboards that provide a visual narrative of the user’s entire experience can also be useful. Helping the team and related teams or stakeholders to share in the uncovering of hidden pain points and opportunities for improvement.

These tools help teams to shed light on the emotional, and contextual aspects of user interactions, which can be as critical as the functional ones when in discovery.

To truly understand and address your user’s actual needs, it is essential to deliver a comprehensive vision, acknowledge the intricate problems users face. A format of user needs in a story format funnels your thinking and articulation into solutions and simple actions.

The truth isn’t like this. And when you’re exploring and prioritizing the problems to solve. This isn’t what you need. Teams that do this build the wrong thing. They build solutions that miss the why.

A simple method to knowing whether you should write user needs like this is … can you and every member of your team explain in detail how your user thinks and how they act in a given circumstance?

If not. Leave the user story format behind. Leave that format for development of the solution. Not the storytelling of what your user needs and how they act. And get better at writing and sharing richer tales of your users and what they need from you and your product or service.