Most of us work in companies that, despite good intentions, are far from perfect. This means navigating systems that don’t always set us up for success. In product development, that often looks like feature-driven roadmaps, top-down decision-making, and relentless pressure to hit release dates—sometimes at the expense of real value.
How can we shift from this kind of environment to one that is more product and impact driven? That is what the book Transformed: Moving to the Product Operating Model by Marty Cagan explores.
Overview
Marty Cagan’s books have become biblical in the product world. But one of my main critiques of these books (which is sacrilege in the product management community) has always been how idealistic they are. It’s easy to talk about what an ideal state is, but it is difficult or impossible to achieve it.
This book attempts to address bridging the gap between your current organization and an ideal product-driven organization. While I still feel like it doesn’t have all the answers for many large or legacy companies, it brings together many of the principles from Inspired and Empowered and explores how to move beyond a traditional IT/delivery model into a product-operating model, which consists of changing how you build, changing how you solve problems, and changing how you decide which problems to solve.
The product operating model is not a process, or even a s single way of working. It is a conceptual model based on a set of first principles that strong product companies believe to be true. Principles such as the necessary role of experimentation, or prioritizing innovation over predictability.
The book explores the need to change culture and mindset in order to focus on better delivery, empowering teams, and creating valuable products and experiences.
So let’s explore some key ideas.
Key Takeaways
Focus on Solving Problems
Product teams exist to solve problems, not just deliver features.
Unfortunately, many technology-powered companies still view product and engineering as feature-delivery groups. As the book says, this is the old “IT model” where sales or business stakeholders request features or projects and expect the engineers and product team to simply deliver.
This is not how good organizations function and not how we create value for our businesses and customers.
Product teams (including product management, engineering, UX, etc) exist to solve problems. A feature is a hypothesis about what might solve that problem. So product teams shouldn’t be given lists of solutions, but rather be given important problems to solve and the ability to solve those problems.
Organizational Shift
Keep reading with a 7-day free trial
Subscribe to Prodity: Product Thinking to keep reading this post and get 7 days of free access to the full post archives.