Slides Vasu Vadlamudi recently used in his discussion w/ mentees of The Product Mentor. The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…Better Decisions. Better Products. Better Product People. Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community. http://TheProductMentor.com

1. Numbers and Limits
Balancing data and design
April 17, 2016

2. Who is this guy?

3. Overview
● What’s the problem?
● How do we fix it?
● Getting better at both

4. Data mindset vs Design mindset
A data mindset is... A design mindset is...
● focused on users as groups ● focused on users as individuals
● measurable ● intuitive
● incrementally focused ● blue-sky thinking
● focused on identifying and weighing
different solutions
● focused on identifying, then solving, the
right problem

5. Common problems
“Numbers don’t tell the whole story. How can you boil down someone’s experience
into a single metric?”
“The a/b test results were obvious; why can’t we all just move forward with the
winning variant?”
“I don’t know whether to trust my head or my heart.”
When data thinking and design thinking disagree, what do you do?

6. Common problems

7. What is a PM?
Analytical
User empathetic Organized

8. What does a PM do?
Analysis
Product
design
Project
management

9. Conflict boundaries
Analysis
Product
design
Project
management
This is where
design lives...
So conflicts
arise here...
and here

10. Overview
● What’s the problem?
● How do we fix it?
● Getting better at both

11. General principles
● right situation, right mindset
● settling differences of opinion
● data skepticism

12. Right situation, right mindset
● What might tip you toward relying on data, and what might tip you toward
design thinking?
○ userbase
○ product maturity
○ internal stakeholders

13. Settling differences of opinion
● what objective information can you gather before building anything?
● how do you design features and roadmaps to generate answers for you?

14. Data skepticism
Control (original) Variant
New feature XYZ is here! Do you
want to try it out now?
Try it Cancel
New feature XYZ is here! Do you
want to try it out now?
Try itCancel
This is an example; no actual users were harmed in the making of this slide

15. Data skepticism
● CTR increased from 15% to >19%
● this is huge! we’re gonna be rich!
● where else can we apply this learning?
Also an example

16. Data skepticism
Also an example

17. Release process: in theory
Write specs In dev
Write specs
Live!
In dev
January February March
Release 1.0
Release 2.0
April
Live!
Write specs In devRelease 3.0
May
Live!

18. In practice...
Write specs In dev
Write specs
Live!
In dev
January February March
Release 1.0
Release 2.0
April
Write specs In devRelease 3.0
May
Live!
Write specs
In dev
X X X
1. Design and specwriting
takes longer than planned,
but team isn’t happy and
aligned with the output...
2. ...causing dev to start late
and take longer because team
is thrashing on release’s design
while engineers are working
3. Meanwhile, your next
release hasn’t started
because 2.0 is dragging

19. One solution
(If needed)
Explore
design
Add extra time for
exploring and aligning
on problem and solution
space; get stakeholders
to agree upfront
Write specs In dev
Write specs
Live!
In dev
January February March
Release 1.0
Release 2.0
April
Live!
Write specs In devRelease 3.0
May
Live!

20. Overview
● What’s the problem?
● How do we fix it?
● Getting better at both

21. Hybrids are great

22. Further reading
● Andrew Chen’s blog, http://andrewchen.co
● Good PM, Bad PM by Ben Horowitz
● Don’t Make Me Think
● The Design of Everyday Things