Product operating model assessment template

A product leader's checklist to better results in tech-powered companies.

Marty Cagan

's "Inspired" is a foundational book for tech-powered products. But for many product leaders, translating that inspiration into reality felt like trying to catch smoke. It was just too “inspirational” for folks who, like me at the time, had not seen what good looked like. Where to even start? What inevitably happened is that we started talking about adopting specific practices (e.g., Amazon's PR FAQs, Google's OKRs…) instead of principles. Then all hell would break loose once “outcomes vs outputs” was mentioned.

Some would tune out. Some would go back to the comfort of the feature factory. Some would implement processes but really didn't adopt the culture necessary for them to work. Even when some transformation and improvement happened, the heavy lifting of not being able to understand (and explain) the pieces of the puzzle burnt people out.

Thankfully, 3rd time's a charm. Cagan's latest book, "Transformed," cuts through the fog. It offers a clear framework for building a world-class product development organization for tech-powered companies. It frames the transformation problem in 3 big categories: 1. how we build, 2. how we solve problems, and 3. how we choose which problems to solve.

The three categories and the book's content are much easier to digest than in Inspired. But I still found it was missing a key piece of implementation: a simple checklist. So, based on Transformed's content, I made a simple checklist for product leaders to assess their product operating model:

Use red/yellow/green to evaluate each criterion.

And if you can't be bothered to open the spreadsheet, below is the list of items. Evaluate each of them with red/yellow/green:

1. how we build

1. Product teams release frequently (at least every other week, ideally multiple times a day in Continuous Delivery), and in small, reliable and decoupled increments. The opposite of this is big bang monthly/quarterly/yearly releases.

2. Product teams have a long life (don't constantly change in scope and/or members), so they develop deep tech, customer, and industry domain knowledge. The opposite of this is project-based staffing.

3. Engineering is not outsourced because it is a key product company capability.

4. Instrumenting the technology so we know it is working and how it's being used.

5. Monitoring the technology so we can detect problems before customers do.

6. Being able to prove the new capabilities deliver the necessary value before deploying widely.

2. how we solve problems

1. Every product team is assigned one or more business and/or customer problems to solve and outcomes to achieve, which they are accountable to.

2. The product team is empowered to discover a solution that is:
   1. valuable (the customer will decide to buy or use it),
   2. usable (the user will be able to figure out how to use it),
   3. feasible (your engineers know how to solve with the time, skills, and technology on the team), and
   4. viable (the solution will work for your business in terms of constraints in marketing, sales, finance, service, legal, and compliance).

3. PM, UX, TL, Engineers, and Data Analyst collaborate to identify the right solution, this is what is meant by an "empowered product team". The opposite of this is engineers just focused on building, designers just on design...

4. Product teams have unhindered and direct access to customers.

5. Product teams have unhindered and direct access to data.

6. Product teams have unhindered and direct access to business stakeholders.

7. The product team is not subservient to company stakeholders, but collaborative with them.

8. When a product team ships a feature but does not see the necessary impact, then they iterate on that feature or on their approach until they do or sunset the feature.

9. Every solution being worked on by a product team has a clear measure of success.

10. Product teams rapidly and cheaply test assumptions and product ideas to discover a solution worth building. What is "rapid" and "cheap"? The best product teams do 10 to 30 tests weekly. These tests must be at least one order of magnitude faster/cheaper than just building what they are testing.

11. Product managers are experts on how customers choose and use our products—both qualitatively and quantitatively—and also understand the market, the competitive landscape, relevant technology, and industry trends.

12. Product managers are experts in our business, which means they know how the product is funded, monetized, manufactured, marketed, sold, delivered, and serviced, as well as any legal, contractual, or compliance constraints.

3. how we choose which problems to solve

1. The company has a compelling customer-focused product vision.

2. There is an insight-based product strategy to identify the most critical problems that need to be solved to deliver on the business objectives. This means saying "no" to many things.

3. The team topology (org structure) is tailored to tackle the problems surfaced in the product strategy, while minimizing drag and dependencies between product teams.

4. C-level is bought in the insight-based product strategy and acts to increase focus by saying "no" to what is outside of the strategy.

5. Product team members are bought in the insight-based product strategy and acts to increase focus by saying "no" to what is outside of the strategy.

How is your company's product operating model?

Building a high-performing product development organization isn't easy, but with the product operating model checklist, you can transform your team from inspired to unstoppable.

If you found this article useful, please smash the “like” button. If you know anyone who could benefit from it, share it with them or on your social media of choice. This is a big help!