Product Development Process

The new mantra in product development is:

“Move Fast and Don’t Break Things.”

In 2014, Facebook changed its mantra for developers from “Move Fast and Break Things” to “Move Fast with Stable Infra”. Only moving fast doesn’t bring the business benefit home. At a certain tipping point the engineering organization introduces more “broken things” than they’re able to fix in the long run – speed of the organization stalls or declines.

The new mantra relies on two cornerstone principles Release Quickly and Often and Release with Confidence. Releasing quickly and often leads to small and quick iteration cycles. These foster quicker learning and fuel innovation. Releasing with confidence keeps damage away from your brand, your revenue streams, your customer base and your employees. Confidence refers to accurate software, reliable and well-performing releases, scalable software and released software without privacy or security concerns.

A good example of a well performing product organization is Google Search. They run a total of 15 product teams. They work on over 2.000 product ideas – no product optimizations – in Discovery with less than 500 built in Delivery. The ratio is 4:1 – 4 ideas in Discovery, 1 get build. They aim for 10.000 ideas in Discovery with less than 500 being built. See “Rigorous testing” from Google for further information. Google mentions in this article they did 595.429 Search quality tests, 44.155 Side-by-side experiments, 15.096 LIve traffic experiments resulting in 3.234 Launches – in 2018 alone!

The industry benchmark in well operated digital product development organizations is to kill 75% of ideas in Discovery. If not a minimum of 50% of the ideas are killed then it’s Design, not Discovery and a clear signal of a malfunctioning organization.

Issues of Conventional Agile

“Agile is all about building and delivering software, but it says almost nothing about how to come up with a valuable product backlog.”

Marty Cagan

Agile software development helps a lot, but doesn’t say anything about building a valuable backlog. It is completely blind on the value side, answering the what should be built. Marty discusses a solution to this issue – dual-track agile – on his blog.

Issues of Conventional Agile:

• Thanks to agile, teams move faster. But agile doesn’t provide teams with a valuable goal.
• Moving fast without a goal leads to feature chasing. The goal of agile is to produce more output, not necessarily more business results or more value. This is especially tricky with mature products where removing features might provide more value to the business and customer (use A/B testing to understand the value). Also in mobile products more features most often fail – they distract more since there is too less inventory – and finally don’t have an impact.
• Engineers are most time only coders and don’t contribute further more to the overall value generation process.
• In agile it’s very hard to predict any dates and make commitments since it’s based on user stories only.
• UX Design suffers because there is simply no place for UX in agile. The sprint iteration doesn’t reserve time slots for UX to work as part of the iteration. If engineering is ready to go UX should be ready as well but usually start right now to work as well.
• The architecture of the system suffers as well. Fast moving teams produce more technical debt. Without really knowing good ways to solve an issue, suboptimal long-term solutions are implemented and increase the need to repair architectural decisions.
• The rest of the company – marketing, sales, customer support … are brought in too late into the process.

Salesforce rolled out agile by the book about 15 years ago. As a consequence the whole UX & Design team threatened to quit because conventional agile didn’t include UX & Design at all. So, after some discussion Salesforce included UX & Design in their agile working model and pivoted from the Conventional Agile approach.

Continuous Discovery and Delivery – Dual Track Agile

“Discovery, by definition, means you don’t know the answer when you start.”

Ed Catmull, Co-founder of Pixar

“Dual-Track Agile” emphasizes the parallelism of Product Discovery and Product Delivery. They happen all the time in parallel. The Discovery track is all about fast learning, building a validated product backlog. Delivery is all about creating software that could be released with confidence, shippable software. The Discovery track is led by Product, Delivery by Engineering.

Product Discovery provides missionaries with purpose. In Discovery, the key risks are addressed and meaningful answers to these questions give guidance to the team. The given answers are all validated, there is enough evidence proving it will work.

• Will they buy it? (Value)
• Can they use it? (Usability)
• Can we build it? (Feasibility)
• Can our stakeholders support it? (Viability)
• Bonus question: Should we build it? (Ethics)

When all critical questions have good and validated answers, describe what to build in Delivery. Therefore, use e.g. JIRA stories with prototype and UX design (prototype-as-spec).

It is, however, not needed to validate all risks all the time in discovery before putting anything into the backlog. The trio of people (PM, PD, TL) does the risk assessment (takes 5 minutes talking). Pick and choose the techniques to validate if needed. Don’t be religious about the process.

Example: At ebay, one base assumption is: create a safe place for transactions. This assumption is the root cause for the overall reputation system within ebay.

Discovery and prioritized backlogs

“Don’t prioritize your backlog – simply try thousands of ideas!“

Marty Cagan

Follow only those ideas in favor of the overall business objectives. Don’t spend too much time thinking about them, just try them. One iteration in Discovery means: One new idea or another approach to an older idea.

Put the ideas that work into the product backlog. If the product backlog is empty switch to “feed-the-beast” mode and allow the teams to work on e.g. technical debt or other meaningful tasks. If the product backlog is too full – means more than 2 weeks of work – you have a rotten backlog. Here, ideas will no longer be valid or well memorized if too much time has gone before going into Delivery.

Good example for a Product Discovery phase and how fast they were collecting evidence and pivoting: BMC Business Modell Competition – First Place Winner: Owlet (https://www.youtube.com/watch?v=f-8v_RgwGe0)

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