About the Author: Pramod Nammi is an accomplished Product Manager with extensive experience in recommendation systems and content monetisation. TechBullion invited Pramod to share his expertise on using Jobs-To-Be-Done and Outcome Statements in PRDs due to his profound understanding of product management and his proven ability to bring clarity and precision to complex projects. His insights are invaluable for product teams looking to streamline their processes and achieve successful outcomes.
Product Requirement Documents or PRDs are important tools in project management. The product team faces a common issue when clients or stakeholders cannot articulate their needs clearly. This ambiguity often wastes time and resources as the team attempts to navigate the project without a clear direction.
PRD is a comprehensive document that serves as an instruction manual for building either an entire product or a specific feature within it. In this article, I will dwell on implementing Jobs-To-Be-Done and Outcome Statements in the PRDs to clarify the project’s needs.
The Role and Importance of PRDs
Generally speaking, PRD is a project’s compass, guiding it from idea to reality. They ensure synchronisation among team members and help ensure that the final product aligns with the initial vision.
A well-constructed PRD not only helps teams focus on building the right features but also ensures they are built most effectively. It provides the clarity necessary for teams to prioritise tasks, manage resources, and maintain focus on the ultimate product goals. Having a well-built PRD is important for the following reasons:
- Clear Instructions
PRDs align cross-functional teams by providing clear instructions for designers, developers, and decision-makers.
- Avoiding Confusion
They prevent confusion by ensuring everyone involved understands what needs to be built, as the process is documented.
- Saving Time and Effort
Similar to having a recipe before cooking, PRDs save time and effort by ensuring all necessary information is available from the start.
- Adaptable to Scale
Whether building an entire product or a single feature, PRDs can adapt to the scale of the project.
The Common Mistake of Overlooking the ‘Why’:
A frequent mistake in writing PRDs is assuming that everyone involved in the project already understands the reasoning behind the product’s features. Let us take as an example a case when a software development team is tasked with creating a new messaging app. The project manager drafts a PRD outlining the app features, such as text messaging, voice calls, and file sharing.
However, the PRD lacks clear explanations of why these features are essential for the app and how they align with the overall goals and vision. As a result, the development team may proceed with building them without fully understanding how they contribute to the app’s value proposition.
This lack of clarity is sure to lead to misunderstandings and inefficiencies. To avoid this mistake, the PRD should include detailed explanations of the rationale behind each feature. For instance, the PRD could explain that the inclusion of text messaging is essential for enabling real-time communication between users, enhancing user engagement, and differentiating the app from competitors. The team in its turn can ask the below questions to dot all Is and cross all Ts.
- What is the overarching goal of the product?
- Who are the target users of the product?
- What problem or pain point does each feature address for the users?
- How does each feature contribute to the user experience or value proposition?
- What are the expected outcomes or benefits of implementing each feature?
- Are there any alternative approaches or solutions to achieve the same objective?
- How do the features align with the company’s business objectives and strategies?
- What are the potential risks or challenges associated with each feature?
A Misplaced Focus on Business Metrics
All too often, PRDs focus heavily on business metrics: increasing adoption, retention, and revenue. These metrics are important, but they don’t explain the feature’s purpose from the user’s perspective. Instead, they highlight the business objectives, which might not fully align with user needs. Further on we’ll talk about what a comprehensive PRD should include and how to craft it.
The Attributes of a Good PRD
First of all, a good PRD focuses on identifying the target users, understanding their pain points, and illustrating how the proposed features solve those problems. By clearly articulating the ‘why’, PRDs ensure that teams have a deeper understanding of the user problems they are solving and how the features contribute to those solutions.
Benefits of a well-crafted PRD include leadership alignment and team clarity. Decision-makers and stakeholders can quickly understand the purpose of the product, and engineers, data scientists, designers, and user researchers gain a unified understanding of the target audience and the intended impact. This keeps the focus on user satisfaction rather than purely business metrics.
Leveraging JTBD and Outcome Statements
Jobs To Be Done
The jobs-to-be-done framework was developed by Tony Ulwick, founder of Strategyn, an innovation consulting firm. Initially known as Outcome Driven Innovation, it focuses on identifying the outcomes customers seek, rather than the products they desire.
The jobs-to-be-done framework is about understanding what customers want to achieve when they use a product, focusing on their specific goals, or “jobs,” and the reasons they choose a product to get the job done. In this approach, the product team aims to uncover the real intentions behind customers’ purchases and usage of a product or service.
This theory shifts the focus from the product to the customer’s needs and motivations. It delves into why customers buy a product, going beyond surface-level explanations.
For instance, while someone might say they need a drill, digging deeper reveals they want a well-drilled hole. But the jobs-to-be-done theory goes further to uncover the ultimate goal: perhaps they desire the satisfaction of hanging a picture in their living room and making their home look cosier. This framework helps teams develop features that align closely with user needs.
Now we’ll take a closer look at how to articulate JTBD adequately. Let us imagine that we are a company developing a new fitness-tracking app. Our JTBD articulation is as follows:
“Our users need a fitness app to track their workouts and calorie intake.”
Though it sounds reasonable, this articulation simply describes the features of the app without going deeper into the motivations or desired outcomes of the users. Besides, it focuses solely on the surface-level need for tracking workouts and calorie intake, without considering the underlying reasons why users seek out such apps.
In this case, without understanding the deeper motivations, the product team may miss opportunities to differentiate the app and provide value beyond basic tracking functionalities. It overlooks the broader context and goals that users are trying to achieve when using the app.
Good JTBD articulation
A better JTBD articulation in this particular situation will be:
“When users ‘hire’ our fitness tracking app, their job to be done is not just to log workouts and monitor calorie intake, but to take control of their health journey and achieve their fitness goals. They want a tool that not only tracks their progress but also provides personalised insights and motivation to stay consistent and make meaningful improvements in their overall well-being.”
The thing is, that this articulation goes beyond the basic functionalities of the app and identifies the core objective of users:
- taking control of their health journey and achieving fitness goals
- getting personalised insights and motivation in this process.
This can help the product team prioritise features and design elements that directly address these needs, such as personalised goal setting, progress tracking, motivational reminders, and data-driven insights to support users in their fitness journey. Here we are focusing on the ultimate goal or outcome that users seek to achieve when using the product, rather than just the features it offers.
Outcome Statements
Outcomes are clear statements focusing on vital functions, services, and processes that affect customer satisfaction, student success, and support services. They explain what the audience will gain from an activity, service, or process.
Outcomes can be:
- Statements describing the desired quality of key functions and services in an administrative unit (e.g., timeliness, accuracy).
- Operational statements outlining what services should achieve (e.g., understanding, knowledge, awareness).
- Statements aiming to enhance students’ knowledge or understanding of specific concepts, including skills and values gained from educational experiences (e.g., Student Wellness Program measuring student knowledge of healthy habits).
When crafting an outcome statement, consider the actions needed to achieve the goal and the type of learning required to support it.
Proceeding with the fitness-tracking app example, let us consider the below outcome statement:
“Increase the number of users who download and use our fitness-tracking app.”
Obviously, this statement focuses solely on increasing app downloads and usage without addressing the underlying motivations or goals of the users. It lacks specificity regarding the desired outcomes related to users’ health or fitness progress. Moreover, there’s no mention of the quality of the user experience or how the app contributes to users’ overall well-being.
Good Outcome statement articulation
A more comprehensive statement would include the following information: by doing XYZ (feature capability), this feature will save the user N steps while they want to ABC (the job).
So a better option would look something like:
“By providing personalised workout recommendations based on user preferences and goals (feature capability), this feature will save users an average of 20 minutes in planning their exercise routines while striving to achieve their fitness objectives (the job).”
This statement specifies a measurable outcome: saving users time in planning their workouts. It identifies the feature capability (personalised workout recommendations) that enables this outcome. The statement quantifies the time saved (20 minutes) and links it to the users’ objective of achieving their fitness goals.
Using these principles, PRDs can effectively align teams, focus on user-centred design, and lead to the successful delivery of products that meet both user and business goals.
