O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Book club INSPIRED How To Create Tech Products Customers Love

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
Product management
Product management
Carregando em…3
×

Confira estes a seguir

1 de 32 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Book club INSPIRED How To Create Tech Products Customers Love (20)

Anúncio

Mais recentes (20)

Book club INSPIRED How To Create Tech Products Customers Love

  1. 1. Book club INSPIRED How To Create Tech Products Customers Love 2020-01-22
  2. 2. People Product Process Culture
  3. 3. There is a tremendous difference between how the best companies produce products and how most companies produce them
  4. 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. 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. 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. 7. Dual Track Agile From Waterfall to Agile
  8. 8. People
  9. 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. 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. 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. 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. 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. 14. Product
  15. 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. 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. 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. 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. 19. Process
  20. 20. Product Discovery Product "discovery” by thinking Product discovery best practice Value Usability Feasibility Viability
  21. 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. 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. 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. 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. 25. Discovery Planning Scope & plan Customer Discovery Program • 6 reference customers • with people and time to work closely together Story Map
  26. 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. 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. 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. 29. Culture
  30. 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. 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

×