M6 Define Product Requirements

Welcome to
Product School!
MODULE 6 - DEFINE PRODUCT REQUIREMENTS
Agenda
WEEK 1 WEEK 2 WEEK 3
Understand Customers & Problems

Course Introductions Competitiveness, primary & secondary activities, customer
Validate an Opportunity Hypothesis
Instructor & trainee Intros journey maps
Effort vs. user value, A/B testing & customer interviews
Introduction to Product Management Create an Opportunity Hypothesis

PM skills, goals & methodologies Qualitative & quantitative methods, setting goals
Define Product Requirements
PRD, MVP & roadmaps
Set Product Objectives
User personas, metrics & use cases
WEEK 4 WEEK 5 WEEK 6
Start Building Develop Your Product II Get Hired

Design processes, product vs. design & sketching MVC, API design & team management Retrospectives, public speaking & resume reviewing
Develop Your Product I

Market Your Product Deliver and Present
Development methodologies, engineers & product, design
Channels, messaging & insights Capstone Project
patterns
Agenda Accelerated
DAY 1 DAY 2 DAY 3 DAY 4 DAY 5

Strategy & Discovery Research & Define Design & Develop Launch Present
Create an Opportunity Hypothesis Start Building Market your Product

Course Introductions Deliver & Present
Qualitative & quantitative methods, Design processes, product vs. design Channels, messaging & insights
Instructor & trainee Intros Capstone Project
setting goals & sketching
Get Hired
Introduction to Product Validate an Opportunity Develop Your Product I
Retrospectives, public speaking &
Management Hypothesis Development methodologies,
resume reviewing
PM skills, goals & methodologies Effort vs. user value, A/B testing & engineers & product, design patterns
customer interviews
Develop Your Product II

Set Product Objectives Define Product Requirements MVC, API design & team
User personas, metrics & use cases PRD, MVP & roadmaps management
Understand Customers & Problems

Competitiveness, primary &
secondary activities, customer
journey maps
Index > Session
Agenda
1. Writing and Using PRDs
2. Define an MVP
3. Roadmapping
Module 6 > Section 1 > Writing and Using PRDs
Writing and Using PRDs

Product Requirement Document (PRD)
What is a PRD? In waterfall places, they’re HUGE documents that

detail everything in-depth
1. A communication tool
Lean advocates use them as examples of everything
2. A way to work with the other project
wrong with waterfall
stakeholders, writing down key elements of the
project We view them as living documents where you want to
make them useful/readable. PRDs need to be updated
3. A place to centralize project background
as you learn new info + make decisions building the
HOWEVER, PRDs are a bit contentious in the product
product community
PRD lifecycle
Planning Production Post-Release
Organize your thoughts Track what’s going on to get Others in the company (like
things built support) can learn about the
product
What’s in a PRD? Title Personas
Change History User Scenarios (Use cases)

Contents of a PRD vary from company to
company. There are general things you’ll find Overview Requirements (User Stories)
in most PRDs.
Objectives Features Out
Success Metrics Designs
Messaging Open Issues
Timeline Q&A

TITLE
Give this project a distinct name. Overview Requirements (User Stories)
Timeline Q&A

CHANGE HISTORY
Provide a description of each important change Overview Requirements (User Stories)

in the PRD, including who changed it, when
and what & why. Objectives Features Out
Timeline Q&A

OVERVIEW
Overview Requirements (User Stories)
● What is this project about?
● Why are you doing it? Objectives Features Out
Timeline Q&A

OBJECTIVES
● What will this let the customer do?
● What are our high level internal goals Objectives Features Out
for doing this project?
Timeline Q&A

SUCCESS METRICS
What metrics indicate that you’re achieving
your internal goals for the project?
Timeline Q&A

MESSAGING
What’s the product messaging marketing will
use to describe this product to customers?
Both new and existing.
Timeline Q&A

TIMELINE
What’s the overall schedule you’re working
towards?
Timeline Q&A

PERSONAS
Who are the target personas for this product,
and which is the key persona?
Timeline Q&A

USER SCENARIOS
Full stories about how various personas will
actually use the product in context.
Timeline Q&A

REQUIREMENTS
What need will your product satisfy and how?
Timeline Q&A

FEATURES OUT
What have you explicitly decided not to do and
why?
Timeline Q&A

DESIGNS
Include early sketches, and over the course of
the project, link them to the actual designs
once they’re available.
Timeline Q&A

OPEN ISSUES
What factors do you still need to figure out?
Timeline Q&A

Q&A
Common questions about the product along
with the answers you’ve decided. This is a
good place to note key decisions.
Timeline Q&A
Get the PRD Template here.

Storytelling in user scenarios
User scenarios help make PRDs really useful. Writing stories to talk about the customer
and the product is the most effective way to
Science has shown we think in stories, not
help your team empathize with the customer
bullets.
It makes your teams’ brains behave as if
A product manager needs to communicate
they’re the customer, implicitly
effectively & make everyone on the team
communicating the results of your customer
empathetic to the customer.
development work.
Understand the customer’s needs and how the
product fits into his life.
Storytelling in user scenarios
Set Up Action Result

● What persona is the hero of the ● What happens when they use ● What’s their life like once they
story your product achieve their goal
● What are they trying to achieve ● What steps do they go through
● How do they get/find your ● Mention any friction points
product they might encounter--all
products have rough edges
Be authentic
Perfection isn’t a priority
Being authentic lets you figure out where to

focus on improving the product AND helps
you find hidden barriers to adoption
If you find yourself writing awkwardly to

include a feature, you likely don’t need that
feature.
UX isn’t your story

EXAMPLES
Keep requirements high-level if possible Bad: “There should be a calendar for viewing
X” because it states the solution the PM came
up with as the only solution (a calendar)
Just like everyone has product feature ideas,
everyone tends to have UX ideas BUT let the
Better: “As a user, I want a way to see X over
UX designers do their jobs. the next 3 months so that I might plan for the
future”
PMs might be technical but it doesn’t mean Better because it doesn’t imply a calendar and
you know the best code. Let engineers figure shows why we want a way to view dates
out the best data structures.
Deepen your understanding of
storytelling and how to apply it in
Product on our Product Leader
Certification.
On-Demand Module 3: Product

Storytelling
Live Module 5: Communication,

Documentation & Storytelling to
Influence
Shopping the PRD around
After you’ve established at a high level what

the opportunity space is and started the PRD,
you need to:
1. Start shopping that document around to

other stakeholders
2. Get buy-in from them
3. Establish the project’s scope clearly
4. Ensure it’s feasible

Sample flow
You write the first version of the PRD in

Word/Google Docs.
It’s a good idea to start your PRD draft

somewhere private.
Ok to put TBD in spots (maybe success

metrics).
In general, you want the background,

objectives, maybe metrics, and maybe key user
scenarios/epics focused on the high-level
features.
Get your boss’s buy-in
Get any needed approvals from your boss with

the first version.
Teammates and managers are an asset.
Get their thoughts/feedback.
People who have been there longer might have

insights you don’t know about!
Engage the design lead
Share the PRD with the design project leader

and incorporate feedback.
Design is close to the user.
Engage them before approaching engineering,

design’s feedback might affect the technical
scope.
Discuss the spec with them and incorporate

their ideas/feedback. You’re not telling them
what to do.
Engage the engineering lead
Share the PRD with the engineering project

leader (don’t forget the design lead!) and
incorporate feedback.
With the design lead (ideally), engage the

engineering lead and get feedback.
This move will help you figure out what’s

technically feasible, and get some very rough
time/difficulty estimates.
They might offer technical info that enables a

new solution.
Keep other stakeholders involved
Make sure other key stakeholders are included.
You don’t want someone to feel like they’re

being dictated to.
You also want to listen to their input, even if

you ultimately say no (with a justification) so
that the person stays willing to provide
feedback in the future.
IN FACT, if you have someone who’s not a

stakeholder but who’s really interested, get
their feedback, too.
Work together
PM
The Problem
PM owns the problem.

Design provides the solution.
Engineering implements it.
Products are a team effort and it is much better for Design
The Solution
collaboration if you approach it as “defining the
problem + generating solutions together”. Engineering
Builds It
This approach helps reveal constraints and produce
new ideas along the way.
It also helps everyone stay focused on the user and get

the best solution.
Share with the team
Move the PRD somewhere more public.
Get the team’s questions, input, etc.
Note any good ideas, and…
1. Not right for this initial version?

2. Record them in the icebox
Remember
As you shop the PRD, listen to

people and let them feel
they’ve been listened to.
Rephrase what the person’s
saying in your own words and
repeat it back to them.
Present to a wide audience
Possibly share with the company.
You’ll likely be presenting rather than sharing

the PRD.
This doesn’t mean reading your PRD in front

of a mic but actually assembling a presentation
(depending on the org).
Remember
As you build the product,

update the PRD, note key
decisions, and collaborate.
The PRD is really only done
when you release the
product.
Key takeaways
PRD is a great tool to...
1. Gather your thoughts.
2. Clarify your thoughts and objectives.
3. Communicate WHAT you're building and WHY.
4. Gather feedback.
Module 6 > Section 1 > Writing and Using PRDs > Exercise Unmute and share Estimated time: 110 minutes
Breakout Group Discussion:

Write a PRD
Follow the steps to write your PRD:
1. Organize your team’s thoughts on the

initiative you are focusing on.
2. Translate your ideas into a plan: state

goals, success metrics, features in and
features out.
3. Use usability notes and user comments.
4. Discuss the feedback and answer all the

questions.
Make sure to use the PRD Template here for this task.
Time for a break
Stretch, breathe,
grab a drink
Estimated time: 5 minutes

Index > Session
Agenda
2. Define an MVP
3. Roadmapping
Module 6 > Section 2 > Define an MVP
Define an MVP
Define an MVP
● What delivers real customer value?
● This is the starting point to define the

MVP.
● You’ll prioritize building that part first

& might even be the initial product you
release.
MVP = Bad Product
Product is still going to be designed well,

engineered well, tested thoroughly.It is
something customers would want.
Simply means you don’t build all the

potentially non-essential bells and
whistles. Prioritizing doing the core
product really well.
MVP
Visualize the core product and why an MVP

is beneficial to customers.
Imagine a product with just one button.
It’s obvious what to do, right?

MVP
Adding 1 button = x2 product’s complexity
Every new feature = more complex
Focus on the ones that really let customers

be effective
MVP
Having lots of features doesn’t mean your

product solves all of a user’s problems.
It means your product is complex with many

features customers never use.
Be smart about adding features!

MVP
Companies are usually reluctant to ship just an

MVP and end up shipping a little more than a
+
pure MVP.
EXAMPLE: Hardware companies can’t release

hardware updates, so you plan for more than an
MVP.
How do we define an MVP?

Step 1: What value are you delivering?
Write down WHAT you’re doing and WHY

you’re doing it.
This will help you focus.

Step 2: List all the features and why

each matters
BUT, you can’t write any high-level feature not

mentioned in the press release/product review.
This step forces you to make sure you’re only

listing the features you thought mattered.
Step 3: Cross out features that don’t aid the

core value proposition
Will be uncomfortable, and you might feel like you’re

eliminating too many features/creating too barren
products → That’s OK.
This will help you identify the MVP, which you can
focus on building, and then you can add features later.
Key takeaways
1. Define your core problem.
2. Figure out a list of features.
3. Cross out features you don't need.
4. All these step build your MVP.
Then, have a clear success metric!

Index > Session
Agenda
2. Define an MVP
3. Roadmapping
Module 6 > Section 3 > Roadmapping
Roadmapping
Why do we need roadmaps?
1. Operationalize workstreams with a

large team
2. Create and hit timelines
3. Find gaps/need help areas
4. Communicate progress efficiently

Product Roadmaps
Formal definitions of the vision and projects to

execute to achieve their goals = ROADMAP
● Smaller companies = short-term

roadmap (3-6 months)
● Very agile companies = shorter
● Hardware companies = longer

What’s in a roadmap?
● High-level projects by the team
● Rough timeframes
● Goals and courses of action
Designed to be an “at-a-glance item”.

Roadmap tools
There’s a variety of tools to create roadmaps

like general presentation/spreadsheet tools.
We’re going to introduce you to tools that

PMs use to manage tasks, sprints and
presentation.
Access the Roadmap Template here.

What should a roadmap include?
1. Engineering tasks
2. Design tasks
3. Legal
4. PR
“Anything that’s required for the
5. Etc. project to succeed”
You may want to have different views or

boards to avoid confusion, but good not to
assume it’s only for engineering.
Outcome vs output
Another approach for some applications.
● Improvement is the outcome of outputs.

● Explain in the form of a roadmap what
these desired outcomes are.
Update your roadmap regularly
You don’t know the future.
If your plans change, someone might ask why

you didn’t deliver on an item on the roadmap.
Deepen your understanding of
Product Roadmaps with our
Product Leader Certification.
On-Demand Module 1: Building and

Communicating Strategy
Live Module 2: Translate Your

Product Strategy Into Action
Key takeaways
1. Always have a roadmap that meets your team's

needs.
2. Include cross-functional collaboration as

needed in the roadmap.
3. Don't make it for engineering only!

Q&A

M6 Define Product Requirements

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

M6 Define Product Requirements

Uploaded by

Copyright:

Available Formats

Welcome to

WEEK 1 WEEK 2 WEEK 3

Understand Customers & Problems

Introduction to Product Management Create an Opportunity Hypothesis

WEEK 4 WEEK 5 WEEK 6

Start Building Develop Your Product II Get Hired

Develop Your Product I

DAY 1 DAY 2 DAY 3 DAY 4 DAY 5

Create an Opportunity Hypothesis Start Building Market your Product

Develop Your Product II

Understand Customers & Problems

1. Writing and Using PRDs

Writing and Using PRDs

Product Requirement Document (PRD)

What is a PRD? In waterfall places, they’re HUGE documents that

Planning Production Post-Release

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Give this project a distinct name. Overview Requirements (User Stories)

Objectives Features Out

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Provide a description of each important change Overview Requirements (User Stories)

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

● Why are you doing it? Objectives Features Out

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas

Change History User Scenarios (Use cases)

Objectives Features Out

Success Metrics Designs

Messaging Open Issues

What’s in a PRD? Title Personas