When designing digital products, it's essential to understand what users need and the goals they are trying to accomplish. Traditional user stories, particularly those framed as "As a user, I want to…" often miss the point of user needs entirely. They assume too much about the user and focus on predefined solutions rather than the real problem.
A more effective approach is Jobs to Be Done (JTBD), which shifts the focus from tasks users need to do to the outcomes they seek.
What Is Jobs to Be Done?
Jobs to Be Done is a framework that helps teams understand why users "hire" a product or service. JTBD focuses on users' motivations, challenges, and the progress they are trying to make.
For example, in an online learning platform, a typical user story might state: "As a student, I want to complete video lessons so that I can learn a new subject." This assumes that watching videos is the best or only way to learn, rather than questioning what the student truly needs to succeed. A Jobs to Be Done approach instead frames the problem like this: "When I am learning a new subject, I need a way to understand key concepts quickly and retain the information to apply it effectively."
JTBD focuses on the job rather than the feature, allowing for more innovative solutions and empowering the team to explore creative solutions. In this case, instead of relying solely on video lessons, the platform could explore interactive exercises, AI-driven personalised learning paths, discussion forums, or real-world application scenarios. By shifting the focus to what the student tries to achieve, teams can design more effective and engaging learning experiences.
The problem with traditional User Stories
User stories following the format of "As a user, I want to…" have several critical flaws:
1. Users don't want to do actions – they want outcomes
A common example: "As a user, I want to log in." No one wants to log in. Logging in is just a barrier to their goal—accessing their account, retrieving saved data, or continuing where they left off. By focusing on the job, we can explore alternatives like passwordless login, single sign-on, or even eliminating the need for login in some instances.
2. User stories assume we know who the user is
The phrase "as a user" is too generic. Users are diverse, and their needs change depending on context. A better approach is considering when and why someone performs a task rather than defining them by a static persona.
3. User stories prescribe a solution rather than uncovering a need
"I want to create tasks" assumes that task creation is the right approach. But what if there's a better way to manage work? A JTBD perspective asks what problem users are trying to solve, leading to potentially more innovative solutions.
4. User stories lack context
When and where does the user need to do this? What constraints are they working with? What frustrations do they experience? JTBD provides this essential context, making it more helpful in designing solutions that meet user needs.
5. User stories encourage a "Feature Factory" mentality
Traditional user stories reinforce the feature-factory approach, where success is measured by the number of features shipped rather than the actual impact on users.
Feature-factory prioritises delivering features quickly without evaluating whether they solve real problems. Teams using this approach often:
Work through a backlog of features without questioning their purpose.
Measure success by the number of releases rather than user outcomes.
Fail to revisit and refine solutions based on user feedback.
JTBD moves teams away from this mindset by shifting the focus from building features to solving problems. Instead of asking, "What should we build next?" teams ask, "What are users trying to achieve, and how can we best support them?"
Why you should think in jobs, not features
By focusing on JTBD instead of feature-based user stories, teams can create products that truly serve users rather than just fulfilling predefined requirements. It encourages a deeper understanding of user behaviour and allows for problem-solving innovation.
Ultimately, designing around Jobs to Be Done leads to better user experiences, stronger product-market fit, and more meaningful impact. Instead of asking, "What features do users want?" we should ask, "What are users trying to achieve, and how can we help them succeed?"
How Fruto works with Jobs to Be Done
At Fruto, we apply the Jobs to Be Done framework through in-depth user research. In our discovery phase, we:
Empathise with users by conducting interviews and discovery research to understand their expectations, needs, motivations, and challenges.
Identify the core jobs users are trying to accomplish and analyse the broader context of these jobs: when and where they occur, what obstacles users face, and what success looks like for them.
This ensures our designs meet user needs and exceed expectations with innovative solutions, giving the business a competitive edge.
