Book club discussion. INSPIRED How To Create Tech Products Customers Love

1. Book club
INSPIRED
How To Create Tech Products
Customers Love
2020-01-22

2. People
Product
Process
Culture

3. There is a tremendous difference between
how the best companies produce products and how most
companies produce them

4. The Root Causes of Failed Product Efforts
Product
1. Source of ideas – stakeholders driven
2. Product roadmaps – a prioritized list of features
3. Business case – impossible to quantify
People
4. Product management – gathering requirements
5. Design – “lipstick on the pig”
Process
6. Engineers brought too late
7. Agile enters the process too late
8. Project‐centric process
9. Customer validation happens too late
10. Wasting our time and money
At least half of our ideas are just
not going to work.
The real difference is how you deal
with this.

5. Three Principles of Success
1. Risks are tackled up front
– Value risk (customers not will buy it)
– Usability risk (users will not use it)
– Feasibility risk (engineers cannot build with the time, skills, and technology available)
– Business viability risk (the solution will not work for the various aspects of the business e.g. finance, legal)
2. Products are defined and designed collaboratively
3. It's all about solving business problems
Product discovery is the most important core competency
of a product organization

6. Product Discovery and Delivery
 Product discovery and delivery are separate tracks ongoing in parallel
 Discovery done primarily by product manager, product designer and tech lead
 Delivery done primarily by engineers
Scalability
Reliability
Performance
Maintainability
Value
Usability
Feasibility
Viability

7. Dual Track Agile
From Waterfall to Agile

8. People

9. Product Teams
A determining factor of success in delivering a product
 Typical product team
– Product manager
dedicated to the team
– Product designer
if there is a user‐facing experience
– Tech lead and 2 to 10 engineers
• self-organized
• empowered
• able to quickly adapt
A dedicated product manager to a team is an absolute must
for self-management

10. Product Manager
 CEO of the product
– product discovery
– sales & marketing
– business development
– services
– financials
 Product manager has an ultimate responsibility
for the product success
 Product success is measured by the business
outcomes
“Behind every great product
there is someone who led the
product team to combine
technology and design to solve
real customer problems”

11. Product Designer
It‘s much more than user interface
 Responsible for
– product discovery
– holistic customer experience
– prototyping
– user testing
– interaction and visual design
 Absence of product design leads serious problems when
– product manager try to do the actual design or
– product manager don't provide the designs but high‐level user stories to the team

12. Supporting Roles
Teams might also have
• Represent the market to the product team –
the positioning, the messaging, and a winning
go‐to‐market plan
• Deeply engaged with the sales channel and know
their capabilities, limitations, and competitive issues
Product Marketing Managers
• Continuously doing two kinds of rapid learning
– qualitative: understanding the problems to solve
– quantitative: assessing how well our solutions
solve the problem
• If the company does not have user researchers, then
the product designer will take these responsibilities
User Researchers
• Most companies have a blended approach
– engineers write some of the automated tests e.g.,
the unit level tests
– test automation engineers write the higher‐level
automated tests
Test Automation Engineers
• Do quantitative learning and
• Help teams
– collect the right sort of analytics,
– analyze the data,
– plan live‐data tests,
– understand and interpret the results
Data Analysts

13. Principles of Structuring Product Teams
1. Alignment with investment strategy
2. Minimize Dependencies
3. Ownership and Autonomy
4. Maximize Leverage for shared services
5. Product Vision and Strategy
6. Team Size
7. Alignment with Architecture
8. Alignment with User or Customer
9. Alignment with Business
10. Structure Is a Moving Target
Principles
1. Team Skill Level
2. Importance of Speed
3. Importance of Integration
4. Source of Innovation
5. Company Size and Locations
6. Company Culture
7. Maturity of Technology
8. Importance to Business
9. Level of Accountability
Factors to consider

14. Product

15. Product
– describes the future in 2-5 years
 to communicate the direction
 to inspire the teams make it a reality
 is 1 of most effective recruiting tools
– is always a bit of a leap of faith
Vision
– describes a sequence of
products/releases to realize the
product vision
Strategy

16. Principles
1. Start with why
2. Fall in love with the problem, not the solution
3. Think big
4. Don't be afraid to disrupt yourselves
5. The product vision needs to inspire
6. Embrace relevant and meaningful trends
7. Skate to where the puck is heading
8. Be stubborn on vision but flexible on the details
9. Realize that any product vision is a leap of faith
10. Evangelize relentlessly
1. Focus on one target market or persona at a time
2. Product strategy needs to be aligned with
business strategy (delivery)
3. Product strategy needs to be aligned with sales
and go‐to‐market strategy
4. Obsess over customers, not over competitors
5. Communicate the strategy across the
organization
Vision Strategy

17. Product Roadmap – outcome vs. output
 Outcome‐based roadmaps
– stated as business problems to solve
(not a prioritized list of features)
– defines the business value to the
teams and business
– ensures that teams work on the
highest‐business‐value items first
Why
OutputWhat
Outcome

18. Product Objectives and Key Results
 Product teams need the business context
– product vision and strategy
– product business objectives
– product business results
 Product over functional OKRs
– focus on the product team level
– functional objectives should be
incorporated into the relevant
product teams objectives
Product teams need to have product OKRs
for which they feel accountable

19. Process

20. Product Discovery
Product "discovery”
by thinking
Product discovery
best practice
Value
Usability
Feasibility
Viability

21. Processes
 Product discovery
– Will the customer buy, or choose to use it? (Value)
– Can the user figure out how to use it? (Usability)
– Can we build it? (Feasibility)
– Does it work for our business? (Viability)
– Describe what will be build in delivery
 Product delivery
 Customer development
– Marketing & sales
– Services
 Supporting processes
– Finance
– Legal
– Security
– Partners
Product discovery is the primary
responsibility of the product manager
Product manager works with
key stakeholders and brings their considerations
and constraints into the product team

22. Product Discovery processes & techniques
Get the ideas in front of real users and customers early and often
Discovery
framing
Discovery
planning
Discovery
ideation
Discovery
prototyping
Discovery
testing
Opportunity Assessment
Customer Letter
Startup Canvas
Identify the risks
Story Map
Customer Discovery Program
Scope & plan
Customer Interviews
Concierge Test
Customer Misbehavior
Hack Days
Generate ideas
Feasibility Prototype
User Prototype
Live-Data
Hybrid Prototype
Learn at a much lower cost
Testing Feasibility
Testing Usability
Testing Value
Testing Business Viability
Test the risks
techniquesgoals

23. Product Discovery principles
1) We cannot count on our customers to tell us what to build
2) The most important thing is to establish compelling value
3) Good user experience is usually even harder, and more critical to success
4) Functionality, design, and technology are inherently intertwined
5) We expect that many of our ideas won't work out, and the ones that do will require several iterations
6) We must validate our ideas on real users and customers
7) Our goal in discovery is to validate our ideas the fastest, cheapest way possible
8) We need to validate the feasibility of our ideas during discovery, not after
9) We need to validate the business viability of our ideas during discovery, not after
10) It's about shared learning
Embrace the concept of an iteration in discovery
(10–20 iterations per week)

24. Discovery Framing
Identify the risks to be tackled during the discovery
Startup Canvas
for a new product or business
Opportunity Assessment
for a feature to a medium‐sized project
1. What business objective is this work intended to address? (Objective)
2. How will you know if you've succeeded? (Key results)
3. What problem will this solve for our customers? (Customer problem)
4. What type of customer are we focused on? (Target market)
Customer Letter
for larger initiatives

25. Discovery Planning
Scope & plan
Customer Discovery Program
• 6 reference customers
• with people and time to work closely together
Story Map

26. Discovery Ideation
Generate ideas
Customer Misbehavior
customers use the products to
solve problems other than what’s
planned for
Hack Days
Customer Interviews
Many forms & techniques, informal and formal,
with/without user research methodology
1. Are your customers who you think they are?
2. Do they really have the problem you think they have?
3. How does the customer solve this problem today?
4. What would be required for them to switch?
Concierge Test
Going out to the actual users and
asking them to show you how
they work

27. Discovery Prototyping
Learn at a much lower cost
Live-Data
 Very limited implementation, 5-10 percent
 Not a commercially shippable
 Has none of the productization: all use cases,
automated tests, internalization, localization,
performance, scalability
Hybrid Prototype
• High‐fidelity user prototype but with an actual
person behind the scenes performing manually
what would ultimately be handled by automation
• Referred as Wizard of Oz prototype
Feasibility Prototype
• Algorithm concerns
• Performance concerns
• Scalability concerns
• Fault tolerance concerns
• Use of a new technology
• Use of a new third‐party component or service
• Dependency on new changes by other teams
User Prototype
• Smoke and mirrors with nothing behind
• Could be high or low fidelity

28. Discovery Testing
Test the risks
3. Testing Feasibility
 Do we know how to build this?
 Do we have the skills on the team to build this?
 Do we have enough time to build this?
 Do we need any architectural changes to build this?
 Do we have on hand all the components we need to build this?
 Do we understand the dependencies involved in building this?
 Will the performance be acceptable?
 Will it scale to the levels we need?
 Do we have the infrastructure necessary to test and run this?
 Can we afford the cost to provision this?
4. Testing Business Viability
 Marketing, Sales, Services, Finance, Legal, Partners/Vendors, Security
 User Test, Product Demo, Product Walkthrough
1. Testing Usability
Three important cases to look for
1. The user got through the task with no problem/help
2. The user struggled but got through
3. The user gave up
2. Testing Value
 Demand Testing Techniques
 Qualitative Value Testing Techniques:
Using Money, Reputation, Time, Access to demonstrate value
 Quantitative Value Testing Techniques: A/B Testing, Invite‐Only
Testing, Customer Discovery Program

29. Culture

30. Establishing a Strong Product Culture
• Experimentation
• Open minds
• Empowerment
• Technology
• Business
• Skill‐set and staff diversity
• Discovery techniques
Innovation Culture
• Urgency
• High‐integrity commitments
• Empowerment
• Accountability
• Collaboration
• Results
• Recognition
Execution Culture

31. Establishing a Strong Product Culture
1. Customer‐centric culture
2. Compelling product vision
3. Focused product strategy
4. Strong product managers
5. Stable product teams
6. Engineers in discovery
7. Corporate courage
8. Empowered product teams
9. Product mindset
10. Time to innovate
Top Attributes of Innovative Org
1. Technical debt
2. Lack of strong product managers
3. Lack of delivery management
4. Infrequent release cycles
5. Lack of product vision and strategy
6. Lack of co‐located, durable product teams
7. Not including engineers early enough in discovery
8. Not utilizing product design in discovery
9. Changing priorities
10. A consensus culture
Top Reasons for Loss of Velocity