Transformed · Marty Cagan · 2024

Initially, I was skeptical about this one, as it's been plagued with delays and it seems the author changed midway through the process, with Marty stepping up to rescue the book.

The book addresses the criticisms of Marty's previous works, which were seen as idealistic, theoretical, and not applicable beyond Silicon Valley. INSPIRED shared the best practices from top product teams, while EMPOWERED shared the techniques from product leaders to foster an environment for their teams to excel in the product model. TRANSFORMED provides some practical advice on how to close the gap. Given the scarcity of resources on Product Operating Models, some will be disappointed that Marty focused only on principles and stopped short of recommending a particular process.

Key Takeaways

The product operating model is for companies that need to power their business with technology. It's not a single process, but a conceptual model based on principles that strong product companies believe in.

It focuses on consistently creating technology-powered solutions that customers love and that work for the business, while getting the most out of the investment.

There is no single right way to build products. The authors identified things that are true at great product companies.

Reflect on your current model - IT model (business & IT separate), project model (project-based staffing & funding), or sales/marketing-driven.

The motive to transform usually comes from a competitive threat, compelling prize, or frustrated leaders. Many companies fail at the first attempt.

The CEO needs to be the chief evangelist for the product model. Transformation requires changes from everyone, starting with the product org raising its game.

Product leaders need to take responsibility for up-skilling their people and fixing hiring mistakes. Your ownership equals your credibility.

Transformation Defined

Shift from projects to continuous improvement of products. Use analytics, A/B testing, monitoring.

Don't serve stakeholders with feature teams. Solve customer problems that create business value. Hold teams accountable for outcomes, not output.

Give teams problems to solve and desired outcomes. Find solutions that are valuable, usable, feasible and viable.

Do product discovery to determine what will work before building. Test ideas 10-100x faster than building.

Collaborate with stakeholders to find solutions. Expect some resistance to the change in control.

The model requires high-performing teams with excellent people. This is why transformation is hard.

Create a compelling, customer-centric product vision. Drive necessary org changes as a product leader.

Do product strategy to identify the most important problems to solve. Create focus by turning insights into actions.

Product Model Competencies

Product teams solve hard problems in ways customers love that work for the business.

In exchange for autonomy, the team is accountable for finding the best solution.

Expect product leaders to spend 80% of time on staffing and coaching. Lead with context, not control.

Create product vision, team topology, product strategy, and team objectives. Evangelize relentlessly.

Product Model Concepts

Empower cross-functional product teams with problems to solve. Focus on outcomes over output.

Give teams meaningful ownership and expect collaboration, even when disagreeing.

Do product strategy - focus on a few goals powered by insights. Be transparent about decisions.

Do product discovery to minimise waste. Assess risks, run rapid experiments, test responsibly.

Do continuous product delivery via small, instrumented releases with monitoring and infrastructure.

Foster a product culture of principles over process, trust over control, innovation over predictability, and learning over failure.

The Product Model in Action

Partner with customers for direct input. Make few commitments and fulfil them. Test extensively.

Build trust between Product and Sales to create happy, reference-able customers together.

Collaborate with Product Marketing on market insights, go-to-market, messaging, pricing, sales enablement.

Partner with Finance to fund teams vs projects. Judge teams on outcomes, not feature delivery.

Reset stakeholder relationships to collaborative partnership. Build trust via transparency.

Interact frequently with execs for context sharing and decision-making. Make limited, high-integrity commitments.

Transformation Techniques

Do a swift assessment on how you build, solve problems, and decide what to solve. Evaluate competencies and concepts.

Update job definitions, fix discipline people ratios, engage engineers, revamp recruiting, provide coaching and onboarding.

Optimise team chemistry, durability, and topology. Improve architecture, discovery, strategy, vision, funding, and culture.

Use pilot teams, stakeholder coaching, quick wins, and relentless evangelism to drive adoption.

Overcoming Objections

Address customer objections about capabilities, dates, roadmaps, releases, data, and pursued products.

Handle Sales concerns over customer input, vision, special deals, competitors, and losing control.

Manage other common objections from LOB, Success, Marketing, Finance about control, involvement, urgency, promotion, accountability.

Conclusion

1. The CEO must be the chief evangelist of the product model and can't delegate the transformation.
2. Technology enables transformation but is secondary to having teams staffed with the right skills.
3. Strong product leaders who understand the product model can lead product management, design and engineering.
4. Empowered product managers are essential.
5. Product designers craft customer experiences that customers love. They elevate design from a supporting role to a central one.
6. Empowered engineers form the engine of consistent innovation by enabling and encouraging empowered engineers.
7. An effective product strategy based on quantitative and qualitative insights focuses on leveraging the talents of the teams to get the most out of the technology investments.
8. Redefining stakeholders relationships is one of the most difficult but essential aspects of successful transformation.
9. Continuous evangelism by product leaders is needed to land the product vision, strategy, and importance of moving the focus to outcomes and transformation.
10. Successful transformation requires corporate courage from executives and other senior leaders to acknowledge difficulties and make the leap to a fundamentally different model, even when the current one is not yet broken.

Full Book Summary · Amazon

Subscribe Button 

Quick Links

David Bland on testing business ideas · Podcast

Evaluating Frontier Models for Dangerous Capabilities · Paper

Foundational principles of privacy by design · Paper

Why the chat interface isn’t a panacea for AI interaction · LinkedIn Post

Competitive research cheat sheet · Tweet

If your strategy can be applied to a laundromat, it's not a good strategy · Tweet

Journalist exposes the information meta has kept on her since she was 11 · Paid Article

The infinite library problem, choosing what to learn · Article

Why timezones are so hard for programmers · Article

The Six concerns for Separation of Concerns · 2001 · Aksit et al

Despite a common agreement on the necessity of the application of the separation of concerns (SOC) principle, there is not yet a consensus for its key issues. The separation of the concerns is usually based on the adopted programming paradigm, the applied method or even the programming language. This paper presents the so-called six `C' properties that can be applied as a guideline for defining and evaluating the approaches that adopt the SOC principle.

The 6 Concerns:

1. Concern-Oriented: focusing on distinct aspects of a system.
2. Canonicality: ensuring that each concern is handled in one place only.
3. Composability: the ability to combine concerns together effectively.
4. Computability: the concerns should be computable or able to be processed by a computer.
5. Closure Property: the ability of a system to remain complete and coherent after a concern is added or modified.
6. Certifiability: it should be possible to validate each concern independently.

View the Paper

Book Highlights

Lean UX advocates a team-based mentality. Rockstars, gurus, ninjas, and other elite experts of their craft break down team cohesion and eschew collaboration. Jeff Gothelf and Josh Seiden · Lean UX

How you choose to represent data not only affects the way your systems are built, but also the problems your systems can solve. Chip Huyen · Designing Machine Learning Systems

It is often said that a strategy is a choice or a decision. The words “choice” and “decision” evoke an image of someone considering a list of alternatives and then selecting one of them. There is, in fact, a formal theory of decisions that specifies exactly how to make a choice by identifying alternative actions, valuing outcomes, and appraising probabilities of events. The problem with this view, and the reason it barely lightens a leader’s burden, is that you are rarely handed a clear set of alternatives. In the case at hand, Hannibal was certainly not briefed by a staff presenting four options arranged on a PowerPoint slide. Rather, he faced a challenge and he designed a novel response. Today, as then, many effective strategies are more designs than decisions—are more constructed than chosen. Richard Rumelt · Good Strategy / Bad Strategy

When you start a Discovery Story you switch into that mindset, and when you are done you switch out again. Martin Christensen and Marcus Castenfors · Holistic Product Discovery

The world is full of mediocre, middle-of-the-road companies creating mediocre, middle-of-the-road crap, but I’ve spent my entire life chasing after the products and people that strive for excellence. Tony Fadell · Build

Best of X

Breaking through to a better idea by subtraction, rather than addition, is the most satisfying kind of breakthrough Jason Fried