There are many well understood and widely adopted methodologies for building software products. However, the nuances in application often differ widely from company to company. This deck articulates a framework that I have developed over my career. Some concepts are exclusively my own. Some borrow wholesale from people much smarter than myself: Eric Ries, Anthony Ulwick, Michael Cohn, Clayton Christensen, Alan Klement (I cite sources extensively throughout this deck). This framework takes an inherently unpredictable, creative process, and makes it repeatable while maintaining flexibility. There is lots of room to adapt and innovate within this framework, both individually and as a team. However, I think it is important that a product organization in a company (developers, designers and PMs) speaks a consistent language and shares the same fundamental methodology. That’s what this framework provides.

1. Building Products
A framework for discovering what customers want
and building it efficiently

2. Introduction
There are many well understood and widely adopted methodologies for building software products.
However, the nuances in application often differ widely from company to company.
This deck articulates a framework that I have developed over my career. Some concepts are
exclusively my own. Some borrow wholesale from people much smarter than myself: Eric Ries,
Anthony Ulwick, Michael Cohn, Clayton Christensen, Alan Klement (I cite sources extensively
throughout this deck).
This framework takes an inherently unpredictable, creative process, and makes it repeatable while
maintaining flexibility. There is lots of room to adapt and innovate within this framework, both
individually and as a team. However, I think it is important that a product organization in a company
(developers, designers and PMs) speaks a consistent language and shares the same fundamental
methodology. That’s what this framework provides.
Chris Bohnert
https://www.linkedin.com/in/cbohnert
2

3. Customer Focus
Chapter 1

4. “People do not want a quarter-inch drill,
they want a quarter inch hole”
Theodore Levitt, Harvard Professor
-----------
So…don’t focus on making a better drill. Focus on finding better ways to create
a quarter-inch hole.
In other words, focus on the problem not the solution
4@cjbohnert

5. Outcome Driven Innovation
Developed by Anthony Ulwick in early 90’s and built upon by Clayton Christensen
(The Innovators Solution, 2002).
Outcome driven innovation is built around the theory that people buy products and
services to get jobs done. As people complete jobs, they will measure success
against certain measurable expected outcomes.
• Jobs: The tasks or activities our customers are trying to complete
• Outcomes: The metrics our customers use to define the successful execution of
a job. A single job will have multiple desired outcomes. An outcome statement
should include the {Direction} + {Unit of Measurement} for the job being
performed. I view outcome statements as the inverse of problem statements.
• Constraints: Factors that could prevent or limit our customer’s ability to complete
the jobs with our product. Constraints inform the viability of the solution.
Credit: ‘What Customers Want’ by Anthony Ulwick
5@cjbohnert

6. Example Jobs, Outcomes, Constraints
Job Desired Outcomes Constraints
Make a ¼” hole Minimize the time it
takes to produce a ¼”
hole
Minimize the manual
effort it takes to produce
a ¼” hole
Maximize the
consistency with which I
can produce a ¼” hole
I must be able to
transport the tool to the
job site on my tool belt
The tool must operate
without an electrical
outlet available
6@cjbohnert

7. Problems vs. Solutions
7@cjbohnert
Simply making a product better isn’t always enough. Eventually someone will develop a
completely new way to solving your customer’s problems and your existing product will
be obsolete. This is creative destruction.
“Makers of vacuum tubes improved year by year the power of vacuum tubes. Customers
were happy. But then transistor radios came along. Happy customers of vacuum tubes
deserted vacuum tubes and ran for the pocket radio.”
William Edwards Deming, “System of Profound Knowledge”
Instead…
• Clearly understand and articulate the PROBLEMS your solving for your customers
and WHY those problems are important (i.e. underlying customer motivation)
• Constantly ask yourself if there is a better way to solve those problems, even if it
means disrupting your existing product.

8. 8@cjbohnert
Credit: Intercom (https://www.intercom.com)

9. What do you build?
Chapter 2

10. Process
Explore Frame Concept Refine Develop Validate
PM
Identify jobs &
desired
outcomes thru
Market/ User/
Product
research
Add context
to outcomes
with job
stories
Refine KPI’s
& validation
plan
Write user
stories
Manage workflow, track burn-
down, UAT throughout
Marketing communication plan
for release Validate hypothesis KPI’s
Qualitative user feedback
Design Explore
design
hypotheses
Visual design
Design guidance, reviews &
improv
Dev
Feasibility review Pull work committed to in sprint
< Problem Space Solution Space >
10@cjbohnert

11. Phase 1: Explore
Goal
Identify customer jobs and desired outcomes… or more to the point, uncover
opportunities where customers have a problem fulfilling an important, desired
outcome
Method
• Interview/survey/observe/shadow customers and/or potential customers
• Study your competitors
• Dig into your analytics to uncover friction in your product
• Session recordings of existing customers using your product
11@cjbohnert

12. Example
12
Job Outcomes
Answer questions about
my products from potential
buyers
Minimize the time elapsed
getting an answer to a
customer
Maximize the customer
satisfaction with the answer
to their question
Maximize the conversion
rate to purchase for each
customer interaction
You are building a 2-sided ecommerce marketplace allowing sellers to post hand-
crafted products for sale
@cjbohnert

13. Phase 2: Frame
Goal
Add context to your outcome statements in the form of job stories. Job stories
help to clearly frame the problem before diving into solutions.
Method
Alan Klement’s 5 tips for writing job stories
1. Refine a situation by adding contextual information
2. Job stories come from real people, not personas (#themattressinterview)
3. Design modular job stories which features (solutions) can plug into
4. Add forces to motivations
5. Job stories don’t have to be from a specific point of view
13@cjbohnert

14. Job Stories
When {situation}, I want to {motivation}, so that I can
{expected outcome}
example
When a new potential buyer asks a question on the
website, I want to be notified, so I can answer their
question quickly.
14
Situation
The situation or event that
triggers the motivation
Motivation
The abstracted goal
* Do not commingle the
motivation with the
solutions. Abstract the
solution!
Expected Outcome
What the end user expects
(or desires) to happen.
@cjbohnert

15. Example
15
Job Outcomes Job Stories
Answer questions about
my products from potential
buyers
Minimize the time elapsed
getting an answer to a
potential buyer
When a new potential
buyer asks a question on
the website, I want to be
notified, so I can answer
their question quickly.
When a new potential
buyer visits my page on the
website, I want them to be
able to find resources so
they can potentially help
themselves
When I get a question from
a new potential buyer that I
have answered previously,
I want to be able to reuse
the old response, so that I
can answer it more quickly
You are building a 2-sided ecommerce marketplace allowing sellers to post hand-
crafted products for sale
@cjbohnert

16. Phase 3: Concept
Goal
At this point, you have a pretty good idea of the problem you’re trying to solve
and a hypothesis of the motivation and outcomes. Now it’s time to propose
solutions
Method
• IA & Wire-frame explorations (low-fidelity)
• Get user feedback to vet solution hypotheses (Use-case testing, Card-
sorting, Prototype testing)
• Provide visibility for stakeholders – no black box
• Design should consult with dev team to ensure viability
16@cjbohnert

17. Example
17
Job Outcomes Job Stories Solution Hypothesis
Answer questions about
my products from potential
buyers
Minimize the time elapsed
getting an answer to a
potential buyer
When a new potential
buyer asks a question on
the website, I want to be
notified, so I can answer
their question quickly.
I believe at least 50% of
sellers will adopt SMS
notifications to message
with potential buyers
because 90% of them have
a smartphone.
I believe at least 30% of
sellers will download an
iOS app to message with
potential buyers because
40% of them have an
iPhone.
I believe at least 50% of
sellers will prefer to
communicate with buyers
via email because the
majority of our sellers are
older and don’t like to text.
You are building a 2-sided ecommerce marketplace allowing sellers to post hand-
crafted products for sale
@cjbohnert

18. Phase 4: Refine
Goal
Now that you’ve decided which solutions to test in the product, it’s time to write
user stories.
Method
• Visual designs
• Copy writing
• Define business-rules/logic
• INVEST in good user stories
18@cjbohnert

19. Example
19
Job Outcomes Job Stories Solution Hypothesis User Stories
Answer questions about
my products from potential
buyers
Minimize the time elapsed
getting an answer to a
potential buyer
When a new potential
buyer asks a question on
the website, I want to be
notified, so I can answer
their question quickly.
I believe at least 50% of
sellers will adopt SMS
notifications to message
with potential buyers
because 90% of them have
a smartphone.
As a seller, I want to be
able to opt-into SMS
notifications and enter my
phone number so that I
start receiving notifications
when potential buyers ask
me questions
As a seller, I want to
receive an SMS with the
full question text within 5
minutes of a potential
buyer posting it, so that I
am aware of the question
quickly
As a seller, I want to be
able to reply back to the
SMS question and have
the system route the
answer to the potential
buyer on my behalf.
You are building a 2-sided ecommerce marketplace allowing sellers to post hand-
crafted products for sale
@cjbohnert

20. Product Life-cycle
Mature Product
If you’re working on optimizing a mature product, you’re probably analyzing
ways to remove friction from existing features that address well understood
jobs and outcomes. In this case, you want to focus on identifying and iterating
on under-served outcomes.
Ex. from Facebook: https://www.youtube.com/watch?v=bKZiXAFeBeY
Start-Up / Early Stage Product
But what if you’re building a brand-new product or resetting/pivoting a product?
How do you get started when there are infinite directions to explore?
An opportunity analysis is a quantitative tool to score desired outcomes
20@cjbohnert

21. Outcomes How important is the following? How satisfied are you with your
current solution?
Minimize the number of phone calls it
takes to reschedule a lesson 1 2 3 4 5 1 2 3 4 5
Minimize the number of phone calls it
takes to cancel a lesson 1 2 3 4 5 1 2 3 4 5
Minimize the number of calendars I have
to keep in sync 1 2 3 4 5 1 2 3 4 5
Maximize transparency of availability on
my schedule for students 1 2 3 4 5 1 2 3 4 5
Quantitative Analysis
21@cjbohnert

22. Opportunity Analysis
Importance = % Top 2 Box-Score (4 or 5)
Satisfaction = % Top 2 Box-Score
Opportunity = Importance + max(Importance – Satisfaction, 0)
10-20 = Underserved Opportunity
Credit: ‘What Customers Want’ by Anthony Ulwick
22
Outcomes Importance Satisfaction Opportunity
Minimize the number of phone calls it takes to reschedule a lesson 9.0 9.2 9.0
Minimize the number of phone calls it takes to cancel a lesson 2.0 1.8 2.2
Minimize the number of calendars I have to keep in sync 9.2 1.5 16.9
Maximize transparency of availability on my schedule for students 2.4 8.8 2.4
@cjbohnert

23. Kano Model
• Look for
opportunities to
delight users –
but don’t over-
invest
• Be mindful that
low opportunity
outcomes may
still represent a
‘must have’
feature
23
Need not met
Need fully met
User
Satisfaction
User
Dissatisfaction
Delighter
Feature
Performance
Feature
Must-Have
Feature
@cjbohnert
Credit: Noriaki Kano

24. Delight!
24@cjbohnert

25. The Feedback Loop
Chapter 3

26. The Feedback Loop
“Success is not
delivering a feature.
Success is learning
how to solve the
customer's problem.”
Mark Cook
VP of Products, Kodak Gallery
26
HYPOTHESIS
BUILD
MVP
MEASURE
KPI’S
LEARN
@cjbohnert

27. Hypotheses
Outcome statements are, implicitly, your value hypotheses (per Lean Start Up
methodology). If it’s helpful, you can state them as such.
Validating your outcome statements can entail multiple solution hypotheses – each of
which test a specific solution to satisfy the outcome statement.
27
Outcome Statement
Minimize the time elapsed getting an answer to a
potential buyer
As a hypothesis: “I believe sellers want to minimize the
time elapsed in getting an answer to a potential buyer
because they want to create a good first impression”
Solution Hypotheses
(1) I believe at least 50% of sellers will adopt SMS
notifications to message with potential buyers because
90% of them have a smartphone.
(2) I believe at least 30% of sellers will download an
iOS app to message with potential buyers because 40%
of them have an iPhone.
@cjbohnert

28. Solution Hypothesis Format
I believe {target customer} will {do this action} for {reason}
• Statement must be testable
• Statement must have the potential to fail. Starting with “I believe” opens
the door to being wrong
28
Who
Who is the intended end user
of the feature?
What
What action is the
customer going to perform?
* This should be
measurable. Otherwise,
how will you know if you
were right?
Reason
Why do you think the
customer will perform the
action? What is their
underlying motivation?
* This relates back to the
desired outcome
@cjbohnert

29. Failure
If your solution hypothesis failed, you must determine why
• Maybe there is a problem with the outcome you’re targeting. It could be
wrong altogether, apply to a different market segment or, while valid, be of
low value to the customer
• Alternatively, your solution hypothesis might be wrong – meaning the
outcome is real, but your design didn’t solve it appropriately
29@cjbohnert

30. “You watch for patterns. You see what people love,
and you see what they are trying to do. Then, you
and your team use your product expertise to
implement features that help people accomplish
those things. It’s important to note that the way you
design it may not be exactly what people expect.”
Biz Stone
-----------
There are multiple ways to solve problems – and a team needs good product
instincts to deliver a winning solution. Don’t undervalue your instincts.
30@cjbohnert

31. MVP
31@cjbohnert

32. Validate
• Did we accomplish what we set out to do?
– If Yes – What else did we learn that can help us do even better?
– If No – What did we learn that can help us correct course?
• Know what metrics you’re trying to move before you build the mvp.
• Hold your team accountable for what you set out to measure… but constantly
challenge the assumptions for why you are measuring it.
• Measure inputs, not outputs. For example, leads, sales or revenue are outputs.
Conversion rate and order size are inputs.
• Invest in good analytics from the start. If you can’t measure it, you can’t move it.
• Understand the whole ecosystem. Web apps, especially B2C, are systems. It’s
easy to move one metric by cannibalizing from another part of the system. For
example, discounting might drive conversion rate, but tank AOV.
32@cjbohnert

33. Accelerate the Loop
• The goal is to get through this
feedback loop as quickly as
you can in order to learn as
much as you can in the
shortest amount of time… In a
startup, this means more
cycles of learning before you
hit the end of your runway.
• Every time through the loop
you’re building 1 or more
MVP’s or iterating on your
MVP
• If you don’t keep iterating on
your MVP after launch, then
you don’t really have an MVP,
but likely just a shitty product
read more
33
HYPOTHESIS
BUILD
MVP
MEASURE
KPI’S
LEARN
Job/Outcome
Explore Frame Concept Refine
Validate Develop
@cjbohnert

34. Not a Linear Process
34
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
/ /
• Remember… the goal is to learn how to solve customer problems, not just
to ship code
• You have to be open to where your hypotheses take you… even if that’s a
new project altogether
@cjbohnert

35. “After folding my first company, I did a
retrospective and counted 32 different
projects – most of them, whole new products
or product variations – I’d started (and
almost never completed) in the prior year. I
realized this may have had something to do
with my failure.”
Ev Williams
-----------
Even while you’re iterating quickly, you need to maintain a clear product vision
35@cjbohnert

36. Map Your Product
36
• Mind maps are a great way to both deconstruct jobs and stay out of the
weeds
• Organize the mind map around jobs (i.e. what the customer is ‘hiring’ your
product to do)
• A mind map:
– Lets you see early in a products life if you’re missing something… it’s
the bird-eye view of what you plan to build
– Helps you maintain feature over-sight and avoid bloat through the life of
a product
– Gives the rest of the organization a quick snap-shot of what you’re
building… easy to share
• http://www.xmind.net/
@cjbohnert

37. Scoping Work for Development
Chapter 4

38. Requirements… the old way
38@cjbohnert

39. Agile Requirements
• Requirements emerge & evolve as software is developed
• Requirements are developed in bite-sized pieces
• Requirements should look for the simplest way to deliver value
• Collaboration & communication between all team members is essential
throughout the process
• Agile teams are empowered to make final decisions
39@cjbohnert

40. Unpacking features
Epics
• A set of features that address one or
more desired outcomes for a job-to-
be-done
User Stories
• A description of work to be done in
order to deliver a feature that adds
value for the end user of the product,
irrespective of the order that is it
implemented.
Story Tasks
• The individual tasks that must be
completed by devs in order to deliver
the story
40@cjbohnert

41. Epics
• Problem statement
– Encompass the Job-to-be-done & Outcome statement
• Job Stories
– Depending on the size of the epic, there may be multiple job stories.
However, if it gets too large, you might want to break it up
• Solution Hypotheses
• KPI’s
– How will you validate the epic?
– This will likely go beyond just the solution hypotheses
41@cjbohnert

42. User Stories
As a {customer role}, I want to {goal}, so that I can {benefit}
example
As a seller, I want to receive an SMS with the full question text within 5
minutes of a potential buyer posting it, so that I am aware of the
question quickly
42
Who
Who is the intended end user
of the feature?
What
What is the customer trying
to do?
Why
Why is the customer trying to
perform the task described?
What benefit do they derive
at the end?
* The why is important
because it opens the door to
other ways of solving the
problem for the customer
@cjbohnert

43. Good User Stories are…
• Independent: User Stories should be independent of one another so they
can be delivered separately
• Negotiable: User Stories are not a contract or detailed specs. They are
descriptions of features that can be fine-tuned during development.
• Valuable: User Stories should be valuable to the end user. They should be
written in user language. They should be features, not tasks.
• Estimatable: User Stories need to provide enough information to estimate,
without being too detailed.
• Small: User Stories should be the smallest unit of value you can deliver to
the end user
• Testable: User Stories need to be worded in a way that is testable (not too
subjective)
43@cjbohnert

44. How detailed should a story be?
Detailed enough for the team to start work, with the understanding that further
details can be clarified during development
However, user stories are not an excuse to cut corners on thinking through
features
Use whatever documentation necessary to illustrate the user story, including:
• Business rules/logic
• Scenario trees (if/then diagrams)
• Sequence diagrams
• User flow diagrams
• Mind maps
• Wireframe & visual designs
• Copy, including error states, alert messages, etc
44@cjbohnert

45. A picture is worth 1,000 words
45@cjbohnert

46. User Stories vs Job Stories
History
• Job stories stem from the Jobs-to-be-done framework developed by Tony
Ulwick in the early 90’s and built upon by Clayton Christensen.
• User Stories define a specific solution (otherwise they wouldn’t be
estimatable or testable)
• Job Stories abstract the solution and focus on the motivation. @alanklement
lobbies for job stories instead of user stories
My Take
It’s not either or… you can use both
• Job Stories work well early on – when breaking down epics and during
design phase
• User Stories work well for defining work to be done in the sprint
46@cjbohnert

47. Bugs
Not all bugs are created equal
P1 = A bug that is directly impacting revenue and/or breaking a key customer
interaction (URGENT)
– Patch Release Candidate
P2 = A bug that is causing customer friction, but not directly impacting revenue
– Candidate to move into current release (PM)
P3 = A bug that is impacting internal processes only, but is not impacting
customers
– Moved to Icebox until further prioritization
47@cjbohnert

48. Chores
What qualifies as a chore?
• Research spikes: Any feature-set that requires discovery by the dev team
should receive a research spike. Research time should be accounted for in
the iteration velocity (i.e. reduced feature velocity).
• Internal data requests / SQL scripts
• Trivial development tasks such as placing a tag on a page, etc.
48@cjbohnert

49. Story Sizing
Sizing is done in order to capture the amount of new value your team can
deliver to customers within a sprint. This is called the team’s velocity.
Points are no meant to be an exact measure, but a relative sizing. Some teams
find it helpful to use a rough calculation like 1 pt = .5 dev days (this is optional,
but I like it)
What get’s sized?
• Only stories are sized
• Tasks, bugs and chores are not sized because they do not independently
deliver new value to the customer
• Epics are not sized because they are too big to estimate accurately
49@cjbohnert

50. Backlog
• For agile to work, you must have a prioritized backlog. Stories in the
backlog are ‘ready-to-be-sized’
• Binary prioritization
– Take any two items and specify which one is more important. Place that
one at the top of the backlog. Continue with each new item until the
entire backlog is stack-ranked.
• Periodically review your backlog to remove the junk
50@cjbohnert

51. Agile Workflow
Chapter 5

52. What is Agile?
The term ‘agile software development’ originated from a group of industry
thought-leaders meeting in Snowbird, UT in 2001.
Agile is an umbrella term for processes that define ‘how’ software gets built
efficiently (inc. Scrum, Extreme Programming, etc)
Agile Manifesto
• Individuals & interactions over processes & tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
http://agilemanifesto.org/principles.html
52@cjbohnert

53. What is a Sprint?
• A sprint is a way to time-box work… not necessarily when you release to
production. In fact, sprints have nothing to do with releases. I know some
companies that do weekly sprints and release multiple times during the
week and others that do monthly sprints and only ship product twice a year.
• Dev should move from highest to lowest priority stories in the release
(allowing for dependencies and other tech considerations)
• UAT happens throughout the sprint as stories are completed. Developers
demo the story to the PM.
• TALK!!!
53@cjbohnert

54. Sprint Example
54
Week 1 Week 2 Week 3
M T W Th F M T W Th F M T W Th F M T W Th F M T W Th F
Sprint Planning
& Commitment
UAT
Complete
Retro Prod Release
Development w/ daily scrums… QA and UAT throughout
Demo
Backlog Grooming
@cjbohnert

55. What sprint cadence is right for you?
• Things to consider
– How are you going to manage QA during the sprint?
– Are you planning to release at the end of every sprint, do you release
throughout the sprint or do you release after several sprints?
• Remember you’re goal is to shorten the feedback loop – so ship as
frequently as possible… when the features are ready (because
MVP doesn’t mean crappy)
55@cjbohnert

56. Sprint Planning & Commitment
• Schedule: 1st day of the sprint
• Attendees: Entire delivery team (PM + Dev + Design)
• Sprint planning is a time to discuss and size features. Goal is for the team to
commit to the sprint
• The Dev team agrees to deliver the stories in the sprint on time and on
quality. The PM agrees to avoid making changes during the sprint
• Commitment does not preclude ongoing communication to refine stories
56@cjbohnert

57. Backlog Grooming
• Schedule: Time-box specific times during the sprint
• Attendees: Entire delivery team (PM + Dev + Design)
• Group should review the top of the backlog, looking at roughly 2-3 releases
of work.
– Discuss, at a high-level, the design approaches for upcoming stories
– Discuss feasibility and alternate solutions
– Identify complicates/high-risk stories that may require a research spike
57@cjbohnert

58. Daily Stand-Up
• Schedule: Every morning
• Attendees: Entire delivery team (PM + Dev + Design)
• Quick! No more than 15 minutes… ideally less.
• Go in a circle and talk about 3 things:
– What you did yesterday
– What you plan to do today
– Any challenges/blockers you need help resolving
• Every member of the team takes a turn (PM, Dev, Design)
58@cjbohnert

59. Sprint Demo
• Schedule: End of every sprint
• Attendees: PM + Stakeholders (Dev/Design optional)
• PM should demo (in a QA or staging environment) the new features that will
be delivered in the sprint
– It is important to show actual, working software. No slides or
screenshots!
– Tie the features back to WHY. What hypotheses are you testing and
how will they impact the business?
59@cjbohnert

60. Retrospective
• Schedule: End of every sprint
• Attendees: Entire delivery team (PM + Dev + Design)
• Also called an “Adapt Meeting” or just “Adapt”
• Each team should figure out their own agenda for the retro
• Categorizing feedback:
– Liked, Lacked, Longed for
– What went well, What didn’t go well, What do we change for next time
– 😀 😐 😩
60@cjbohnert

61. The Life of a Story
• Stories should be stack-ranked in the sprint based on the order they should be
completed. Things to consider when stack-ranking: most valuable stories first,
most complex stories first
• Pull (don’t push) work. Developers pick the stories based on the stack-ranked
order.
• Developers should avoid “squatting” on stories… limit the amount of work ‘in
progress’ for each developer (Kanban boards can be helpful)
• Developers shepherd the stories through the sprint, culminating in a UAT demo
to the product owner (PM)
61
Icebox Backlog Sprint
Partially
defined
stories /
placeholder
s
Stack-
ranked, fully
defined
stories,
ready to
size
Planned
Sized story
in stack-
rank
In Progress
Story has
been pulled
by a dev
and work
has started
Finished
Developer
has
completed
work and
story is
ready for
QA
Delivered
Story has
passed QA
and is ready
for UAT
Done
Story has
been
accepted by
the product
owner
Released
Story is
making
customers
happy!
@cjbohnert

62. User Acceptance Testing
• Devs demo the story before moving to done
• UAT is not the same as QA. It is not the time to validate every edge case.
You’re just trying out the feature to see whether it accomplishes what was
asked for in the story.
• Best to have the end user validate if possible / no telephone
62@cjbohnert

63. User Story Map
63
• More granular than a roadmap
• Most project software supports this, including Pivotal Tracker & Jira
• Don’t plan too far ahead… more than 1 quarter is probably too much
@cjbohnert

64. Agile Team Structure
Chapter 6

65. Team Size
65@cjbohnert

66. Team Composition
• Teams should be able to solve problems with no dependencies on external
resources. This mean cross-functional teams
– Product Manager x 1
– UI Designer x 1
– Developers x ?
• Teams in larger organizations might also include QA, User Research and
different disciplines of designers (ux vs visual) and developers (front-end vs
database). In these cases, it’s easy to have team sizes swell or to create
share resource pools. Resist both as much as you can.
• This does not mean that functions can’t also share and collaborate. For
example, if you have 3 teams, you may have 3 designers that, while
working on different delivery teams, collaborate together within their
function.
66@cjbohnert

67. Function Delivery Team 1 Delivery Team 2 Delivery Team 3
Product Mgt Carol Jason Garret
Design Max Laura Jon
Development Bob
Chuck
Carl
Chuck
Denise
Ainsley
Michelle
Donald
Luke
Function Delivery Team 1 Delivery Team 2 Delivery Team 3
Product Mgt Carol Jason Garret
Design Max Laura Jon
Development Bob
Chuck
Carl
Chuck
Denise
Ainsley
Michelle
Donald
Luke
Laura works within
her delivery team to
solve customer
problems & ship
product
Function Delivery Team 1 Delivery Team 2 Delivery Team 3
Product Mgt Carol Jason Garret
Design Max Laura Jon Laura works with her
fellow designers to
brainstorm solutions
and ensure consistent
designs patterns and
styles
Development Bob
Chuck
Carl
Chuck
Denise
Ainsley
Michelle
Donald
Luke
Cross functional structure
67@cjbohnert

68. Team Mandate
You can align teams around
• Customers
– Ex: 2-sided marketplace has buyers and sellers, each with unique
needs that drive the business
• Funnel/Metrics
– Ex: Growth teams have become very popular. You might have team
focus on growth (i.e. acquisition) and engagement (i.e. retention)
• Product/Feature stacks
– Almost never a good idea, unless you have a very stable
business/product
– Works well for Google (search isn’t going away and needs a dedicated
team – or army)
68@cjbohnert

69. Regardless of the area of focus… Frame a big, audacious problem for the
team to solve!
------------
“I believe that this nation should commit
itself to achieving the goal, before this
decade is out, of landing a man on the moon
and returning him safely to earth.”
JFK, May 1961
69@cjbohnert

70. Team Mandate is Critical
• Allows teams to form subject matter expertise
• Builds ownership and accountability
• Problems… not Solutions: If you have a smart team, they will perform better
if they are solving problems with their own solutions rather than
implementing solutions developed by other people
70@cjbohnert

71. Stakeholders
Chapter 7

72. Who is a stakeholder?
• Anyone in the organization that has a vested interest in the product and can
provide input on problems and solutions.
• Stakeholders are a resource for the product team. Their goal should be to
help the product team build the best product possible.
• However, it is understood that stakeholders will lobby for their constituency.
72@cjbohnert

73. Contract with Stakeholders
Stakeholder Responsibilities
• Provide input on prioritizing
epics
• Help unpack epics by:
– Clarifying requirements
– Brainstorming ideas
– Offering subject-matter and
domain expertise
• Stakeholders do not
– Write user stories or other
requirements
– Triage bugs
– QA user stories
Product Responsibilities
• Provide stakeholders with
visibility into releases
• Communicate key learnings to
the team
• Clarify and abstract use cases
from stakeholder requests
73@cjbohnert

74. 74@cjbohnert

75. Stakeholder Touch-points
75
Week 1 Week 2 Week 3
M T W Th F M T W Th F M T W Th F M T W Th F M T W Th F
DemoSprint Summary Email
(Stakeholders)
Stakeholder
Meeting
Release
Email
@cjbohnert

76. Stakeholder Meetings
At minimum, meet with your joint stakeholder team once per sprint
Meeting focus
• Not a demo – future looking
• This is the time to explore concepts and clarify priorities
Schedule a standing meeting at the same time within the cadence of the sprint
(Ex: the 2nd Wednesday of each sprint @ 2pm). This allows stakeholders to get
used to the schedule.
Circulate an agenda before each joint stakeholder meeting. If your asking
stakeholders to prep prior to the meeting, be sure to leave enough time when
circulating the agenda. Remember, they all have jobs outside of supporting the
product team.
76@cjbohnert

77. Functional Breakouts
• If you have multiple stakeholder groups with specific needs, functional
breakouts may make sense.
• A functional breakout allows for detailed conversations germane to a
specific subset of stakeholders (typically by function, like marketing or
customer support)
• Establish a cadence for meetings that makes sense for each group. For
example, the marketing team may require weekly 15 minute meetings
whereas the finance team may operate better in a monthly hour long
meeting.
77@cjbohnert

78. Roadmap Planning
Chapter 8

79. Myth
“Agile development means we don’t do
long term planning. We shoot from the
hip!”
79@cjbohnert

80. Agile = Smart Planning
“Agile planning balances the effort and
investment in planning with the knowledge
that we will revise the plan through the
course of the project.”
Mike Cohn, ‘Agile Estimating & Planning’
80@cjbohnert

81. What is a roadmap?
• A statement of intent, identifying problems we plan to solve given what we
know today
• A map of dependencies between products & teams
• A mechanism to make clear trade-off decisions when priorities shift
• A tool to provide context for the agile teams working autonomously &
transparency to the rest of the organization
• A living document… Fluid!
81@cjbohnert

82. Four buckets
Your potential roadmap time is split into four areas
• Bug fixing & maintenance
• Feature optimization
• New feature development / Feature extensions
• Big swings / New products
How much time you spend in each will depend on your product & business
maturity, the traction you have in the market, technical debt, etc.
More info here
82@cjbohnert

83. Focus will shift over time
83
Bugs & Maintenance
Optimization
New Features
Big Swings
Early Stage Startup
• Focus is on new product
& features
• Searching for
product/market fit
Maturing Company
• As you get traction in the
market, focus shifts
towards optimization
• More customers = more
maintenance
@cjbohnert

84. How far ahead should you plan?
That depends on your business. What works well for a consumer startup
doesn’t fit an enterprise SaaS company.
• If your horizon is too long, you will waste effort planning for things that never
happen
• If your horizon is too short, it’s the same as not planning at all … you’re just
reacting
To consider:
• How frequently are you releasing?
• Do you have entrenched customers that need lengthy upgrade cycles?
• How stable is your business/industry landscape?
84@cjbohnert

85. Roadmap best practices
• Roadmap planning should not be an annual process. It should be an
ongoing activity.
• Make the roadmap visible. Post it in a central location online for the entire
company and discuss it (esp. changes) in stakeholder meetings
• Make the roadmap realistic. Consistently missing deliverables makes the
rest of the organization lose faith (and interest) in a product roadmap.
Involve the dev team in WAG-sizing and pad estimates to account for
unknowns.
85@cjbohnert

86. What goes on a roadmap?
A roadmap is a high-level planning document. It is important to stay out of the
weeds.
You should include:
• Epics
• Velocity placeholders (ex: 10% allocation of the team’s time for bug-fixing)
Individual user stories and bug tickets do not belong on a roadmap. There are
other tools help visualize user story distribution into sprints, like a User Story
Map
86@cjbohnert

87. Aligning Roadmap to Sprints
• Gets the entire organization talking in the same language (sprint #’s)
• A single company roadmap highlights dependencies between teams, especially non-dev
dependencies (for example, aligning product marketing messaging for go-to-market)
• Layering in design time ensures your keeping a consistent cadence
87
Epic Size Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Start ¼
Release 1/27
Start 1/25
Release 2/17
Start 2/15
Release 3/9
Start 3/7
Release 3/30
Start 3/28
Release 4/20
Epic 1 3 3.0
Epic 2 6 design 3.0 3.0
Epic 3 1 design 1.0
Epic 4 2 2.0
Epic 5 5 3.0
Bandwidth 4.0 4.0 4.0 4.0 4.0
Allocation: bug fixing 10% 10% 5% 5% 25%
Avail bandwidth 3.6 3.6 3.8 3.8 3.0
Booked 3.0 3.0 3.0 3.0 3.0
Utilization 83% 83% 79% 79% 100%
@cjbohnert

88. Resources
Chapter 9

89. Resources
• Clayton Christensen, The Innovator’s Solution (2002) & The Innovator’s
Dilemma (1997)
• Mike Cohn, Agile Estimating & Planning (2005)
• Alan Klement, http://alanklement.com/
• Eric Ries, The Lean Startup (2011)
• Anthony Ulwick, What Customers Want (2005)
• http://agilemanifesto.org/principles.html
@cjbohnert 89