for Agile Summit Greece (Sept 2018), a talk on barriers for product folks to validate problems and solutions DIRECTLY with end users/customers rather than through stakeholders and intermediates
2. www.Mironov.com
• Veteran product manager/exec/strategist
• Organizing agile product organizations
• Smokejumper VP Product Management
• HP, Tandem, Sybase, 6 software startups
as product lead or CEO
• The Art of Product Management
• Product blog since 2002
About Rich Mironov
6. www.Mironov.com
• Get inside your end user’s heads
• 12-20 in-person interviews
• Open-ended questions
• Record session or take good notes
• Ask about…
• How their department or business works
• Biggest pain points, how they describe problems
• Current solutions, alternatives, shortcomings
• How they justify buying/using a new solution (ROI)
Extended In-Person Interviews
7. www.Mironov.com
• Confirmation bias
• Push for “yes,” explain away “no,” overgeneralize
• Availability bias
• Overweight/remember most recent instances
• Authority/bandwagon bias
• Executives or stakeholders say this is true
• Few interviews, assumed uniformity
• “All of our users have identical needs”
Validation Biases
8. www.Mironov.com
Most of the success / failure
of a product (feature) is
determined before we pick
our first developer or fill out
our first story card
8
9. www.Mironov.com
We don’t “gather requirements”
• Whole teams frame problems
• Collectively find elegant
solutions
• Earn user/customer trust,
love, renewals, referrals
Problem-Framing and Solution Design
Are Contact Team Sports
9
13. www.Mironov.com
Stable, complete
dev team
Users
(custs)
Prod Mgr
Value/Functional Area
Product Structure I Like
Prod Line
Dir
Stable, complete
dev team
Users
(custs)
Prod Mgr
Value/Functional AreaStable, complete
dev team
Users
(custs)
Prod Mgr
Value/Functional AreaStable, complete
dev team
Users
(custs)
Prod Mgr
Value/Functional Area
Frequent, in-depth, non-sales
learning conversations
Dev
Dir
14. www.Mironov.com
Learning conversations, problem
definition, solutions
Users
(custs)
Requirements
Product Structure I Don’t Like
Prod Line
Dir
Stable, complete
dev team
Users
(custs)
Prod
Manager
Stable, complete
dev team
Prod
Owner
Stable, complete
dev team
BA/TPM
15. www.Mironov.com
Requirements
Product Structure I Don’t Like
Stable, complete
dev team
Team
rotates
Users
(custs)
Stable, complete
dev team
Prod
Owner
Mkt
Mgr
Users
(custs)
Stable, complete
dev team
Prod
Mgr
Prod
Mgr
Users
(custs)
Support
Team
16. www.Mironov.com
“The Business”
Product Structure I Hate
CIO
Project team
from pool
BA
Project team
from pool
Tech
PM
Project team
from pool
Prod
Owner
Tech Requirements
Delivery Dates
Prod
Exec
Mkt
Mgr
CAB
Prod
Dir
Sales
Mktg
Prod
Mgr
Users
(custs)
“IT”
17. www.Mironov.com
• Write/accept/prioritize stories
• Available to team at all times
But invites waste and bad outcomes when…
• Proxies define needs
• No time, training or reward for
direct end user discovery
• Productivity focus vs. measuring end value
Narrow Scrum-Defined Product Owner Role
18. www.Mironov.com
Drives delivery and market acceptance of products (features)
• Targets segments, not individual users or customers
• “What does this segment need/how will we measure outcome?”
• Technical features and adoption
• Resolves inevitable competing business + technical priorities
• Motivates/aligns functional groups
beyond development team (marketing,
sales, support, partners, finance…)
How Is A Product Manager Different?
18
20. www.Mironov.com
1. Product managers/product owners need to
directly validate problems and solutions
• Most “requirements” lack context, confirmation
2. More handoffs means more waste
• Need to interview actual end users
3. Problem/solution thinking is a team sport
• Better outcomes, more engagement
Takeaways