What problem are you try to solve. For a variety of reasons agile teams often face situations where product leaders and business stakeholders are handed solutions and requests for features. Problem Canvas is a facilitation method based on LEAN UX to help teams ensure they understand the problem they are trying to solve.
4. 4
Common Challenges
• We are doing too much order taking
• Features are requested with little or no data
• PMs and POs are doing too much solutioning on their own
• How do we get engineers and designers earlier in the process?
• Feature backlog filled with “Wouldn’t it be cool if…”
• What is the problem are we are trying solve?
5. 5
“Problem Canvas” – Based on Lean UX practices
LEAN UX, Designing Great Products with Agile Teams.
By Jeff Gothelf and Josh Seiden
Find it on: amazon.com
Objectives:
• Bring cross-functional team members into early
stages of planning.
• Established shared understanding of the problem.
• Balance customer POV and business requirements.
• Emphasize data driven solutions.
• Frames solutions as hypotheses.
• Helps teams to prioritize features, and identify MVP
6. 6
Problem Canvas Template
Problem Statement
Customer POV Data Business POV
Customer Outcomes Business Outcomes
Desired customer behaviors (observable) Desired market response (measurable)
Our [product/service] is intended to achieve [these goals].
We have observed that the product/service isn’t meeting [these goals] which is causing [this adverse effect] to our business.
How might we improve [product/service] so that our customers are more successful based on [these measurable criteria]
Facts, observations, and data illustrating the
nature and extent of the problem.
Persona Need
(verb)
Insight
(Pains/Gains)
Stakeholder
Group
Need
(verb)
Insight
(Pains/Gains)
8. 8
Hypotheses Template
WE BELIEVE THAT:
We will achieve …if this customer… …can achieve… …with this feature
[business outcome] [persona] [user outcome] [feature]
9. 9
9
Running the Exercise: Problem Canvas
• Completing a problem canvas is
a hyper efficient way for the
team to define and establish a
shared understanding of the
problem they are trying to solve.
• Who should participate:
• Product Manager(s)
• Product Owners (if available)
• Engineering Lead
• UX Designers
• Key Stakeholders
How To:
1. Product Manager - drafts the problem statement and
assembling supporting data
2. Schedule 60-90 min meeting to complete the problem canvas
• Prior to the meeting Reproduce the Problem Canvas on a
whiteboard
1. Review/revise problem statement as a team
2. Capture supporting data, and brainstorm ideas for
additional data to strengthen the problem statement.
3. Select key personas (using Alaska Airlines personas),
and brainstorm needs and insights
4. Brainstorm customer outcomes – behaviors to be
observed
5. Select key business stakeholders (roles - gate agents,
crew, call center agents, etc.) and brainstorm needs and
insights.
6. Brainstorm business outcomes – measurable business
results
3. Update Epic:
• Review/Revise Epic – Title, Size, Score Rating
• Attach a digital picture of the problem canvas
10. 10
Lessons Learned
• Use a third-party facilitator
• Avoid making a required step or stage
• Manage the size of the room – best with groups of 5-8 people
• Include all three roles: business | technology | design
13. 13
Q2 2020 Q3 2020 Q4 2020
3 Quarter Road Map
<Value
Stream>
Important Dates >
<contact>
Product Road Map Template
Large
Large Large Large
Medium
Medium
X-Large
Large
Medium
Medium
Large
• Notes • Notes • Notes
Epics
Recurring
(ROB)
Medium
Medium
Large Large
Medium
Medium
Large
Medium
Medium
Large
Medium
Medium
Medium
Medium
Medium
Medium Medium
X-Large
Medium
Medium
Medium
TBD /
Unfunded
Medium
Medium
MediumMedium Medium
Medium
Medium
Shared
Conference (Aug 4-8)
User Conf (Nov 10)
Event (Aug 26-28)
Notes de l'éditeur
Instructions
Identify the epics or ‘big rocks’ planned for the current quarter, next quarter and then the quarter after.
Copy/paste blocks of appropriate size to build out each quarter of the road map
Replace sizes with title text (keep titles to 2-3 words for readability).
Orient the blocks however makes most sense within each quarter.
Treat quarters a containers or ‘buckets’, and locate blocks in the quarter where work will be completed.
Break large efforts expected to cross-cut multiple quarters into pieces to keep them contained in a quarter.
Important Dates
Important dates are included across the top as a reference
Epics are represented as blocks within each quarter – but otherwise do not align with any timeline
Relative T-shirt Sizing:
Sizing is specific to each team – there is no absolute or shared definition of size
Pick one or two anchor epics to define a large
Epics that are smaller than the anchor are mediums
Epics bigger than your anchor epic are X-larges
Avoid small and XXL if possible, by combining multiple smalls or breaking up XXLs
Legend
Green = Epics: large user stories or discrete deliverable based projects
Blue = Recurring, time boxed activity or budgeted level of effort each quarter
Purple = Other programs – define your own
Need more colors? Add your own (with in reason – best to keep to 3-4 colors)
