Building Products

A framework for discovering what customers want and building it efficiently

IntroductionThere 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

Customer FocusChapter 1

@cjbohnert 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

@cjbohnert 5

Outcome Driven InnovationDeveloped 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

@cjbohnert 6

Example Jobs, Outcomes, Constraints

Job Desired Outcomes ConstraintsMake 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

@cjbohnert 7

Problems vs. SolutionsSimply 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.

@cjbohnert 8

Credit: Intercom (https://www.intercom.com)

What do you build?Chapter 2

@cjbohnert 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 throughoutMarketing communication plan for release Validate hypothesis KPI’s

Qualitative user feedbackDesign Explore

design hypotheses

Visual design

Design guidance, reviews & improv

DevFeasibility review Pull work committed to in

sprint

< Problem Space Solution Space >

@cjbohnert 11

Phase 1: ExploreGoalIdentify 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

@cjbohnert 12

Example

Job Outcomes

Answer questions about my products from potential buyers

Minimize the time elapsed getting an answer to a customerMaximize the customer satisfaction with the answer to their questionMaximize 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: FrameGoalAdd context to your outcome statements in the form of job stories. Job stories help to clearly frame the problem before diving into solutions.

MethodAlan Klement’s 5 tips for writing job stories1. Refine a situation by adding contextual information2. Job stories come from real people, not personas (#themattressinterview)3. Design modular job stories which features (solutions) can plug into4. Add forces to motivations5. Job stories don’t have to be from a specific point of view

@cjbohnert 14

Job StoriesWhen {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.

SituationThe situation or event that triggers the motivation

MotivationThe abstracted goal

* Do not commingle the motivation with the solutions. Abstract the solution!

Expected OutcomeWhat the end user expects (or desires) to happen.

@cjbohnert 15

Example

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 themselvesWhen 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: ConceptGoalAt 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

@cjbohnert 17

Example

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: RefineGoalNow 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

@cjbohnert 19

Example

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 questionsAs 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 quicklyAs 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-cycleMature ProductIf 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 ProductBut 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

@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

@cjbohnert 22

Opportunity AnalysisImportance = % 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

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

Need not metNeed fully met

User Satisfactio

n

User Dissatisfaction

Delighter Feature

Performance Feature

Must-Have Feature

Credit: Noriaki Kano

@cjbohnert 24

Delight!

The Feedback LoopChapter 3

@cjbohnert 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

HYPOTHESIS

BUILD

MVP

MEASURE

KPI’S

LEARN

@cjbohnert 27

HypothesesOutcome 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.

Outcome StatementMinimize 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 FormatI 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

Who Who is the intended end user of the feature?

WhatWhat action is the customer going to perform?

* This should be measurable. Otherwise, how will you know if you were right?

ReasonWhy do you think the customer will perform the action? What is their underlying motivation?

* This relates back to the desired outcome

@cjbohnert 29

FailureIf 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

@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.

@cjbohnert 31

MVP

@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.

@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

HYPOTHESIS

BUILD

MVP

MEASURE

KPI’S

LEARN

Job/Outcome

Explore Frame Concept Refine

Validate Develop

@cjbohnert 34

Not a Linear ProcessSprint 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

@cjbohnert 36

Map Your Product• 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/

Scoping Work for Development

Chapter 4

@cjbohnert 38

Requirements… the old way

@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

@cjbohnert 40

Unpacking featuresEpics• 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

task

task

task

task

task

task

epic

story story

task

task

task

task

task

epic

storystory

@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

@cjbohnert 42

User StoriesAs 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

Who Who is the intended end user of the feature?

WhatWhat is the customer trying to do?

WhyWhy 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)

@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 developmentHowever, user stories are not an excuse to cut corners on thinking through featuresUse 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

@cjbohnert 45

A picture is worth 1,000 words

@cjbohnert 46

User Stories vs Job StoriesHistory• 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 storiesMy TakeIt’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

@cjbohnert 47

BugsNot all bugs are created equalP1 = A bug that is directly impacting revenue and/or breaking a key customer interaction (URGENT)

– Patch Release CandidateP2 = 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

@cjbohnert 48

ChoresWhat 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.

@cjbohnert 49

Story SizingSizing 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

@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

Agile WorkflowChapter 5

@cjbohnert 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 planhttp://agilemanifesto.org/principles.html

@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!!!

@cjbohnert 54

Sprint Example

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)

@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

@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

@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)

@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?

@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– 😀 😐 😩

@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)

Icebox Backlog Sprint

Partially defined stories / placeholders

Stack-ranked, fully defined stories, ready to size

PlannedSized story in stack-rank

In ProgressStory has been pulled by a dev and work has started

FinishedDeveloper has completed work and story is ready for QA

DeliveredStory has passed QA and is ready for UAT

DoneStory has been accepted by the product owner

ReleasedStory 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

@cjbohnert 63

User Story Map

• 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

Agile Team StructureChapter 6

@cjbohnert 65

Team Size

@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.

@cjbohnert 67

Function Delivery Team 1

Delivery Team 2

Delivery Team 3

Product Mgt Carol Jason Garret

Design Max Laura Jon

Development BobChuckCarl

ChuckDeniseAinsley

MichelleDonaldLuke

Function Delivery Team 1

Delivery Team 2

Delivery Team 3

Product Mgt Carol Jason Garret

Design Max Laura Jon

Development BobChuckCarl

ChuckDeniseAinsley

MichelleDonaldLuke

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 BobChuckCarl

ChuckDeniseAinsley

MichelleDonaldLuke

Cross functional structure

@cjbohnert 68

Team MandateYou 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)

@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

@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

StakeholdersChapter 7

@cjbohnert 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.

@cjbohnert 73

Contract with StakeholdersStakeholder 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

@cjbohnert 74

@cjbohnert 75

Stakeholder Touch-points

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 MeetingsAt minimum, meet with your joint stakeholder team once per sprintMeeting focus• Not a demo – future looking• This is the time to explore concepts and clarify prioritiesSchedule 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.

@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.

Roadmap PlanningChapter 8

@cjbohnert 79

Myth

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

@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’

@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!

@cjbohnert 82

Four bucketsYour 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

@cjbohnert 83

Focus will shift over time

Bugs & MaintenanceOptimizationNew FeaturesBig 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?

@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.

@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

@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

Epic Size Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5Start ¼Release 1/27

Start 1/25Release 2/17

Start 2/15Release 3/9

Start 3/7Release 3/30

Start 3/28Release 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.0Utilization 83% 83% 79% 79% 100%

ResourcesChapter 9

@cjbohnert 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