Stakeholders and the Product Model
By Chris Jones and Marty Cagan
Moving to the product operating model is about moving from shipping roadmaps of features (output), to solving problems for your customers and your business, as measured by achieving business results (outcomes).
But the changes required to do this reach beyond the product organization (the product teams and the product leaders). They also impact the company’s stakeholders.
You are a stakeholder if you are responsible for some key aspect of your company’s business. This may be business operations, or P&L responsibility for some unit of the business, or it may be part of a service group like legal, finance, or HR.
Most importantly, you’re a stakeholder if you are not directly part of the product organization, but are still reliant on that group to create technology solutions that support your business needs and constraints.
The purpose of this article is to provide some practical guidance on how to effectively engage with your product organization.
The Foundation for Effective Collaboration
There are three key areas that form the foundation of how to most effectively engage with product teams: sharing business context; how work is framed; and providing access to customers, users and data.
1. Sharing Business Context
One of your most important roles is to help your product partners understand your business context and constraints, so that they can find a solution that will actually work for the various parts of the business.
Every business has many constraints, ranging from go-to-market considerations, to industry regulations, to financials (both costs and monetization), to business partnerships, just to name a few.
What makes product work difficult is that solutions must solve for both customers and also for the various dimensions of the business. Product leaders and product managers rely on you to gain the necessary understanding: recommended reading, introductions to key people, or specific guidance from you.
2. Framing Work As Problems To Solve
The primary reason most companies move to the product model is because roadmaps of features so seldom generate the necessary business results.
There are many reasons for this, but the key to understand is that our initial thoughts on how to best solve a problem are very often not able to deliver the necessary results. This is true no matter where the idea comes from, and no matter how smart the person may be. The best companies understand this.
So what the product teams do is reframe the many requests for features and projects (no matter where they originate) as problems to solve, along with a definition of success. This provides the product teams with as much room as possible to discover a solution that meets the various needs and constraints.
So it’s most helpful to share the specific problem you need solved, who specifically you need that problem solved for, and how you will measure success.
To be sure, it is entirely normal that you may already have some ideas on what the best solution approach may be, and you should feel free to share those ideas. Just remember that in the product model, the product team is empowered and accountable to discover a solution that delivers the necessary results. Sometimes this will require investigating multiple approaches to discover a solution that solves for both the customers and your business.
3. Providing Access to Customers, Users and Data
To discover and deliver successful solutions, product teams require direct, unencumbered access to customers, users and data.
As you’ll see below, the process of discovering effective solutions involves frequent access to customers and the data that shows how our products are used.
If you have any concerns about product teams interacting with customers or users, you should discuss these directly with the product leaders. It is normal that product teams are trained in how to conduct themselves with customers.
Similarly, product managers may need your help getting access to product data. In some cases, it’s necessary to control access for reasons of privacy or governance, however this can all be accomplished with tooling and authorization controls.
At the end of the day, your product teams will need to have direct access to customers and to product data in order for them to deliver the business results you are counting on.
Product Development In The Product Model
Instead of a slow, document-heavy process, you should expect to see two main activities proceeding rapidly, in parallel, all the time.
The product teams will be working to discover solutions to the important problems to solve, and then delivering those solutions to your customers. We refer to these activities as product discovery and product delivery.
– Discovering Effective Solutions
Instead of written documents or presentations, in the product model, you will typically see many prototypes of proposed solutions. These are very quick to create simulations of the solutions that your customers would see, so that you can judge whether this solution approach would meet your needs.
Importantly, this happens before the product is built. This is how your product partners demonstrate they understand your business constraints, and give you the opportunity to provide feedback while changes are still easy and inexpensive to make. More generally, this is how the product team assesses whether the proposed solution would be viable for the business.
These prototypes are also typically tested with users and customers to assess whether the proposed solution is both usable and valuable (the customer would buy, or choose to use, the solution). And finally, the prototypes are also tested with the engineers to ensure the proposed solution is feasible (we have the skills, time and technology to build a production quality solution).
The prototypes your product partner shares with you will sometimes expose you to new, enabling technology that makes certain solutions just now possible. Today, this often involves generative AI. But it can involve any technology that’s relevant to the solution.
– Delivering Effective Solutions
Once the product team is confident that the solution will provide the necessary results, the engineers on the team will proceed to build a production-quality solution, which includes instrumenting the product so that you and the product team can immediately see whether the new offering is generating the necessary business outcomes.
If not, the product team will immediately investigate the reasons, and proceed to iterate until the desired business results are achieved.
But once the desired outcome has been achieved, you and the product teams you collaborated with can celebrate these results, and proceed to the next important problem to solve.
The Product Model in Practice
A few important notes when it comes to applying the product model:
– Keeping The Lights On
Thus far we’ve been discussing how the product teams pursue the important problems to solve.
However, it’s also true that for most business stakeholders, there is an ongoing set of more minor work that is necessary in order to keep the business running. These items are often called “keeping the lights on” and include tasks such as essential business reporting, business compliance changes, and fixing critical issues that may arise.
Moving to the product model does not make these ongoing items go away, and it is normal for every product team to be doing this work alongside working to solve the larger problems discussed in this article. Note however that if the amount of keep-the-lights-on work climbs too high, then the company will have to decide whether it has the resources to also work simultaneously to move the business forward.
There is no need to overcomplicate these keep-the-lights-on items. They typically do not need to be expressed as problems to solve with business results to achieve, and there won’t usually be product discovery activities associated with them.
– High-Integrity Commitments
While overall the product model is about moving from features and dates (output) to problems to solve and business results (outcomes), of course in every product company there are situations where we need to know precisely when a specific capability will be delivered. But unlike in the prior models, we need to be able to trust this date.
For these situations, the product teams are trained in providing what’s called a high-integrity commitment. This is a date you can count on, but it requires some product discovery work by the product team that will be delivering on this commitment. These come at a cost, so they should be used sparingly, but in return, these are dates you can trust.
– Navigating Product Teams
It is very common that there may be multiple product teams contributing to a single product offering from your company (this is referred to as the team topology). That doesn’t mean you’ll need to engage with each of the product teams to get something done.
The leaders in the product organization will usually be your primary contact, although they may direct you to a specific product manager where necessary.
Whoever it is you engage with, you should expect that person to proactively engage with you on your needs and your business, and they should always be striving to increase their understanding of your business and your customers.
Keep in mind that a product leader or product manager is likely working simultaneously with multiple stakeholders, so that they can come up with solutions that satisfy the various, sometimes conflicting, constraints.
– True Collaboration
While the nature of the interaction between stakeholders and product teams changes with the move to the product model, most companies that have experienced the difference will tell you of the power of true collaboration, where product teams and business stakeholders work together to deliver effective solutions for the company’s customers, yet that work for the business.
Learning More
This article was meant to give stakeholders a concise summary of the key differences to expect when moving to the product model. For more detail on the product model itself, see this overview article.
For a much more thorough explanation of the product model, as well as detailed discussions of the common objections and concerns from each of the major types of stakeholders, please see the book TRANSFORMED: Moving To The Product Operating Model.