Product Culture & Transformation
One transformation technique Marty recommends is the Discovery Sprint. He recommends to do a Discovery Sprint when a team struggles to learn how to do product discovery, when the team has something big and critically important to solve or if the team is just moving too slowly. Marty talks more about it on his blog https://svpg.com/discovery-sprints/ and refers to the Book “Sprint” by Jake Knapp et al.
Another is named Pilot Teams. The idea behind the Pilot Teams is to create success within a smaller protected environment and convince doubtful or fearful or lazy people to follow the change process. The principle is borrowed from the technology adoption curve (aka “Gartner Hype Cycle”) – some people are early adopters, others are less eager. Chris Jones from SVPG talks about this technique in “Pilot Teams“. With these pilot teams the idea of A/B testing – well known from product development – can be applied to organization development as well.
Outcome-based Roadmaps is yet another way to start the transformation process. Simply continue working with product roadmaps, however introduce two differences. First, annotate every roadmap item with its associated expected business result. Every time this item is discussed highlight the expected business result. Second, after the launch of an roadmap item report immediately the actual result vs. the expected result. So, during the next 3-12 month the opportunity assessment information will get its way into the roadmap. For prioritization try to move away from prioritizing ideas to problems.
Common Product Discovery Pitfalls
Marty mentions several pitfalls he experienced and saw teams struggle with. He talks a lot more in his blog post on “Product Discovery: Pitfalls and Anti-Patterns“. Here’s just a summary and some notes.
- Confirmation-biased Discovery
The team and / or the stakeholders are not really interested in the results of Discovery, they just need affirmation.
- Product as Prototype Discovery
The team pretends working on a prototype implementation but it takes too long to actually get the prototype shipped (e.g. 4 month).
- Partial Team Discovery
Not Technology, UX and Product go see the customer, it’s only Product + UX.
- One-Dimensional Discovery
The team focusses only on quantitative or qualitative validation and draws wrong or incomplete conclusions.
- Big Bang Discovery
The team works on a single, big release shipped within a lengthy time frame. They don’t work in an iterative mode.
- Outsourced Discovery
The organization / stakeholders hired a “creative” agency to do the creative Discovery work. The implementation should then be picked up by the team.
Culture Baseline of successful companies
“If we get the culture right, most of the other stuff will happen naturally on its own.”Tony Hiseh, CEO Zappos
- Tackle Risks up Front
- Value Risk – will they use / buy it?
- Usability Risk – can they us it?
- Feasibility Risk – can we build it?
- Business Viability Risk – will our stakeholders support it?
- Define Products Collaboratively, not Sequentially
- Product Management
- Product Design
- Focus on Business Results, not Output
- Product teams exists to solve problems in ways that your customers love, yet work for your business.
This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.
- #1 Foreword
- #2 Introduction & Root Causes of Product Failures
- #3 Key Terms & Concepts
- #4 Product Teams & Product People
- #5 Product Vision & Objectives
- #6 Product Analytics
- #7 Product at Scale
- #8 Product Development Process
- #9 Product Discovery Principles
- #10 Product Discovery Techniques
- #11 Product Culture & Transformation