Pledge To Stakeholders

Note: As a company moves from stakeholder-driven feature teams to empowered product teams, there are some fairly significant changes to how the product teams need to interact with stakeholders, and it’s important that product teams and especially product managers realize this requires changes on both sides of the equation.  This is a follow-up article to one I wrote a few months ago: Pledge To Customers.  

An empowered product team is designed to solve problems for our customers or our business, in ways that our customers love, yet work for our business.

We define a stakeholder here as someone not explicitly a member of a product team, yet represents a key constituency, area of the business, or special expertise.

Creating a solution that customers love is usually not that hard (assuming the product team has direct, unencumbered access to the users and customers, and the product data).

But creating a solution that the customers love and also meets the many, often competing needs of the different parts of the business, can be very challenging.

We need to ensure our solutions can effectively be marketed, sold, and serviced.  We need to ensure we can fund the product, and we can effectively monetize that product.  We need to be able to operationalize the product.  We need to ensure the product is compliant with relevant regulations, respects privacy laws, partnership agreements, and does not have unintended consequences on people or the environment.

We know we can’t do all this alone.

But we also realize that to create any product, there will be literally hundreds if not thousands of decisions that will need to be made.  Bringing all the relevant stakeholders together for every decision is not only an excessive use of time and money, but we also know that committees very rarely innovate.

That’s because stakeholders are not working directly with the enabling technology (just as our customers are not), so they are not in a position to know what’s just now possible.  It is this combination of enabling technology with real customer problems and real business constraints that produces innovative products.

We also recognize that in order for a stakeholder to build a respectful, trusting relationship with a product team, the onus is on the product leadership to ensure that every product team has a competent product manager that has put in the work to understand the various constraints of the business, and to be an effective partner to the stakeholders.

Expecting stakeholders to trust a product manager that does not have this foundation is not only unrealistic, but also unwise.

On the other hand, even though product managers are on the product team to represent these various business constraints, very few product managers know all of the relevant business dimensions in sufficient depth.

Therefore, a product team’s pledge to stakeholders is that each product manager commits to engaging directly with each of their relevant stakeholders, and working to learn and understand the various constraints and needs represented by each area.

Further, product teams realize that it takes time to build this knowledge and this trust, so whenever they are considering a solution that might impact a particular stakeholder, that product manager pledges to show a prototype of the proposed solution to the stakeholder, so that they can consider the implications of this change before the team builds anything.

Hopefully, if the product manager has correctly understood the various constraints, this only takes a few minutes for the stakeholder to take a look and give a thumbs up.  

However, in the event there is a problem, the product team can quickly iterate on the prototype until the stakeholder believes the solution will now work for the business.

Sometimes this will be easy, and other times getting a solution that works not only for customers, but also for multiple stakeholders each with different needs, may require many iterations to identify a solution that solves for all parties.  And even then, the solution that solves for all parties may end up being something that none of the stakeholders realized was possible.

More generally, the product manager pledges to work towards the desired business outcomes. The product teams know that shipping features won’t necessarily solve the underlying problem for the customer or the business. The product team is committed to pursuing the necessary results.

But the pledge is to not build – and certainly not to ship – any solution that does not meet the critical needs of the business.

In the event that something does manage to get built, or worse, to ship to customers, that is not viable for the business, the product team pledges to correct the situation as quickly as possible, and to determine how the error occurred so that it is not repeated.

The product managers pledge to be respectful of your time, and to earn your trust.  They also pledge to be transparent.  Stakeholders are welcome and encouraged to participate in testing with users and customers.  They are welcome to take a look at any of the prototypes created.  They are welcome to view the data on the product – both how the products are used, and the results of live data tests.

Working together, product teams and stakeholders can solve problems for our customers and our company in ways our customers could not have imagined possible.