These notes of Marty Cagan’s workshop “How to Create Tech Products Customers Love” introduces Marty himself and talks about root causes of product failures.
The way Marty successfully builds digital products is influenced by multiple methods and techniques. He describes himself as “only collecting technologies and methods which just worked at other places”. He sees himself as an evangelist for methods.
For him key influencing methods / approaches are:
- Customer Development
- Lean Startup Techniques
- Product Discovery Techniques
- Product Analytics
- Lean UX Techniques
- Design Thinking
- Agile Methods
The origin of the overall workshop is from Marty’s time at Netscape. At the time the browser war was still open and it turned out that the common way of developing products – the way Microsoft did it at the time – didn’t work for the internet age any more. Most interestingly, most of the basic principles were defined at Marty’s Netscape time and were altered slightly until today.
“big bang” releases are those happening less frequent than every two weeks.
Root Causes Of Product Failure
Why product development typically fails?
IDEAS – The source of ideas
Typically, the source of ideas are customers, managers and other stakeholder of the product. These groups of people typically don’t know what’s possible to do today from a technology perspective. Furthermore, they don’t really know what they want or need until they see it. Hence, great companies involve their tech people in the idea generation process. They typically are the best source of innovation.
Apple builds tons of prototypes to lower the risk of failure building a device (e.g. iPhone).
BIZ CASE – Business Case Fallacy
The business case is positioned too early in the overall process. At such an early time in the process nobody has a proper idea on cost to implement the idea nor any idea on the benefit. All information is based on guessing or experience, no evidence on the assumptions can be provided at this time.
Typically, the product roadmap is confused with a committed list of features. Two reasons for the existence of roadmaps:
- The leadership team of a company wants to ensure the teams are working on the most important topics
- They want to know when it’s due for delivery
The BING team at Microsoft confessed they’re “only” able to ship 10% of their roadmap items “on time”.
- Roadmaps are not trusted by stakeholders because they don’t deliver on time
- It takes 3-4 iterations until the items on the roadmap actually provide value – the “time-to-result” is ways more important than the “time-to-market”
- Roadmaps are prohibitive to reach the real product goals since they’re too focused on features
But customers always ask for product roadmaps. What to do? Customers usually don’t want to have feature roadmaps, they want to get an understanding of the future product vision, where is it heading to?
REQUIREMENTS – The Role of Product
The typical requirement gathering job is no longer relevant in modern product development. The job of a Product Owner (as known from agile) is typically 5-10% of the role of a Product Manager. PO is the operative job working with the agile team in delivery. The PO and the PM need to be the same person.
The real work of product teams is not to optimize existing features, but to innovate, to create new solutions to specific business problems. The methods presented in the workshop aim to deliver winning products faster. Not through longer work hours, but a smarter and more predictable way.
DESIGN – The Role of Design
Design is referred to as UX, visual design, experience design. Typically, in waterfall models design is brought into the process ways too late. The waterfall-model enforces the “lipstick-on-the-pig”-model and is doomed for failure.
BUILD and TEST – The Role of Engineering
Software Developers provide only 50% of their value if being involved in build and test only. They need to be involved in product discovery as well, not only in product delivery. Outsourcing a whole engineering team (agency model) doesn’t work (see Hertz / Accenture case https://www.adweek.com/brand-marketing/accenture-seeks-to-dismiss-multimillion-dollar-hertz-breach-of-contract-lawsuit/).
BUILD and TEST – The Role of Agile
In the waterfall product development model the only place for agile methods is during build and test. It only lives in the engineering department.
DEPLOY – Output not Outcome
The whole waterfall process is tailored to deliver output and not outcome.
DEPLOY – Customer Validation Too Late
In the waterfall product development process the customer sees the product only after it’s deployed. Customer validate it by accepting or neglecting the product. The opportunity cost with this approach are extremely high and dangerous for the overall business!
The whole process takes way too long to validate the overall effort of building the product. Building a MVP which takes 4 month is ways too long. A startup needs 50-100 iterations to have a successful version ready for market fit. Typically, a MVP takes 4 hours to a few days. Microsoft has a patient leadership team. It takes typically 4-8 years to launch a product and 4-6 iterations until the product is really great (e.g. Internet Explorer, Bing, …).
“It’s not about processes; don’t be religious about process.Marty Cagan
It’s the outcome to focus on.”
Three Key Themes in Product Development
“The riskiest thing you can do is not to take risks.”Diane Greene
Tackle risks up front – as early as possible. In digital product development there are four risks to address:
- [HARD] VALUE risk – will they use / buy it?
- [SOLVED] USABILITY risk – can they use it?
- [SOLVED] FEASIBILITY risk – can we build it?
- [HARD] BUSINESS VIABILITY risk – will our stakeholder support it? Will it work for the business?
The value risk and the business viability risk are hard to tackle, usability and feasibility however are covered with methods and tools.
It’s the job of the product manager to address these risks before engineers build the product.
“To innovate you need to collaborate.”Marissa Mayer
Define products collaboratively, not sequentially. It is a big advantage to have teams geographically collocated – sitting in the same room ideally. If that’s not possible for whatever reasons the minimum setup is to have the Product Manager, the Product Designer and the Tech Lead at the same location. All other models simply don’t work.
Most times the innovation is driven by engineering (e.g. iPhone). A good example for all-on-site is balsamiq. A good example for all-off-site is Invision. Invision is a organizational setup where all people work remote – it’s part of the DNA. In this case, the distributed Product Manager / Product Designer / Tech Lead works – because of the culture of the company.
Focus on business results, not output. Performance is measured by results.
“As a venture capitalist, we don’t care how many features were shipped last quarter or last year. Instead, we look at the business results, and whether the team is building a product that customers love.”Ha Nguyen
Ask yourself these questions:
- Is the team setup to build features – or to solve real business problems?
- Is the team empowered? Product teams exists to solve problems in ways that your customers love, yet work for the 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