Managing Stakeholders

The customer isn’t always right

Some product companies are customer-centric to the exclusion of all else. While sounds good in theory, it’s almost never a sustainable way to go about product management. Why? Competing demands.

Stakeholders 1.jpg

Senior management says “make it look like an iPhone app”. Marketing says “make it at least as good as the competition”. Sales says “our biggest customer wants XYZ feature”. Development say “we need to stay consistent with design patterns in the last version”. A significant customer says “we want ABC feature” (and they have a big cheque book).

Listening to customers is obviously important: if your customers are not satisfied, you will fail. However, blindly following customers – even the biggest ones with the biggest cheque books – is a strategic mistake that derails your longer-term product vision.

As Product Manager, how should you go about navigating all the concerns within your organisation? The key is to effectively identify and manage the key stakeholders. This post offers some practical advice on how to get started with this fraught – but critical – aspect of a Product Manager’s role.

Getting started

It is pointless building some feature that might work for the customer, but then at an internal review meeting find out you’re not authorised to deploy what was created, or that a key executive expected a different feature to be delivered first. If you’ve spent much time in a product management role, you will have seen this happen (perhaps more than once!). Every time a key stakeholder’s needs are not met, or they are blind-sided with something unexpected, some confidence is lost in the product team.

The Head of Marketing might give you a deadline for your product’s roadmap. How can you better understand the motivation behind the request and her choice of that deadline? A big new sale might depend on adding a major new feature within 3 months. How can you know more about what the sales team is really trying to do? Perhaps that specific feature is not what’s required; it could be a problem solvable in other ways. These are just a couple of examples illustrating the stakeholder management challenge.

Understanding what stakeholders want from you

In the spirit of the mantra “think before you act”, it is important to identify product stakeholders and analyse their concerns and constraints, before putting a plan in place to manage them. To manage stakeholders means ensuring not only that they understand the issues and problems with product management, but that they are clear you are creating solutions that work for both customers and the product organisation.

What does success look like in respect to managing stakeholders? It is all about establishing and nurturing trust. Trust is a two-way street. Stakeholders typically look for three main things from product management. First, that their concerns are understood. Second, that solutions the organisation comes up with addresses those concerns. Third, that they get timely updates on important changes or decisions. In return, product management should be able to expect stakeholders to provide the space needed to steer the product to the best possible solutions, even if this means diverging from what was originally planned.

If any of these are not true, you are headed for trouble. The first two are a result of you demonstrating what you will provide to stakeholders. The third is what you expect to receive back from stakeholders.

The importance of clear communication

Unless you demonstrate the fundamentals of solid and effective product management – deep understanding of customers, technology, the domain, the business context – you are unlikely achieve the required level of trust from stakeholders, no matter how hard you try. Assuming you do have this understanding, the only way to demonstrate it is through continual and effective communication. Therefore, the advice presented here will be useless unless you first find a way to get effective communication with key stakeholders to occur at regular intervals. Preferably this is one on one with each stakeholder, which is the best way to understand things from each of their unique points of view.

In a start-up there are usually only a handful of stakeholders – typically the founder(s), the product team, and perhaps some people who sell, deploy, and support the product. However, once a product-focussed firm grows to a size where Product Manager roles are required, specialisation will have taken hold in other parts of the organisation.

Stakeholders in a product organisation belong to one or another functional unit of organisation: executives, engineering, business development, marketing, service and support, legal and compliance, or finance. Let’s look at the nature of each and practically what it means for effectively managing each type of stakeholder.

Tips for specific types of stakeholders


Engineering teams build the product. They consist of creative and technical roles like architect, developer, designer, tester. They need to know the vision for the product and how their work contributes to getting there.

  • Try to avoid getting bogged down in details; your job is to explain the why (not the how)
  • Be positive and take every opportunity to communicate the “big picture”
  • Focus on outcomes and how the product will lead to company-level results
  • Use narrative style; for example, tell stories about the product and use real-world scenarios to illustrate general concepts
  • Explain, explain, explain, and never assume people understand you the first time
  • After communicating a concept, get the engineers to explain it back to you – this way you can check for shared understanding and enable two-way communication


Executives are the senior leaders and managers with P&L responsibilities, including the CEO and other senior roles like CIO, CMO, Regional Director. They are mostly interested in strategy and the big picture, but they are likely to also want to know how projects are tracking from a financial point of view – cost/benefit, return on investment, etc. The key issue for them is to understand how the product is contributing to the success of the company.

  • Always be ready with “water cooler pitches” that neatly capture the value current product initiatives will bring to the company
  • Explain how specific current and prioritised product initiatives are giving various parts of the business optimal value – whilst “water cooler pitches” are useful, make sure you’re ready with the details too
  • Find a way to ensure executives get consistent messages from other stakeholders – executives may be immediately concerned (and rightly so!) if they notice communication gaps or misalignments between teams
  • Know the key numbers of current projects – for example, if a high-profile product feature is running late, make sure you are across the details of why and what is being done about it

Business development

Business Development sells the product to new and existing customers, so making more sales and achieving their budgets is what they care about. They want to understand how the product or new features are going to give them a competitive edge in the market, usually right now or in the current year. They can also provide valuable input as they spend a lot of time in the market and with customers.

  • Always explain how product initiatives can help them make more sales
  • Have evidence ready to illustrate how the product can help the team’s sales results
  • Listen to their feedback and suggestions, but be sure to carefully check all assumptions and assertions before changing anything in your product plans


Marketing manage the branding and positioning of the product They want to know what’s unique about the product and how it can benefit the customer. You can help them create effective stories around the product.

  • Involve marketing as early as possible in all product initiatives
  • Personas can be effective tools to communicate how the product fits into marketing, branding, and positioning (marketing will be familiar with customer archetypes and customer/market segmentation)
  • Talk about the “big picture”: explain how the product will make the world a better place and improve the life customers
  • Think about how you can provide input for marketing to create compelling stories around your product: you need to distil the essence of your product’s uniqueness for them

Service & support

Service and support teams ensure product success. They are roles like product consultants and helpdesk personnel. Like marketing, they are a valuable source of information and feedback from customers. And they deal with customers daily, so they are interested in the details: customer experience, workflows, business rules and so on.

  • Focus on how the details relate to the bigger picture; for example, if you have discussions about specific functionality, make sure this is framed by the objective the customer has or the problem the customer is solving
  • Listen to their feedback and utilise detailed data they collect on users; often service and support people are the best people to help you test hypotheses you have about the product
  • Watch out for patterns in their feedback – the “hidden voice of the customer” might uncover big surprises!

Legal and compliance

Legal & Compliance make sure products comply with relevant laws, standards, and policies. These are roles such as company legal officer, or quality system audit teams.

  • Engage legal and compliance people as early as possible; it can be difficult or expensive (or sometimes impossible) to retrofit their requirements after product development has started
  • These are detail-oriented people who value evidence and formal artefacts, so make the effort to understand the level of detail they require


Finance make sure the product complies within the financial framework and constraints of the company. This might be a company accountant or CFO, or a finance division.

  • Finance teams will have regular (statutory) reporting requirements, for example monthly reconciliations of costs and/or revenue; make sure you understand their cadence and comply with it
  • Remember to view all financial numbers and reports with targets in mind; an actual financial result alone doesn’t mean much until you can compare it to the objective you set out to achieve (variances mean more than raw actual numbers)
  • Take advantage of reporting and analytical capability your finance team can provide, to better understand the value of product development efforts; often you can work with finance to design regular reports of costs and compare to revenue generated, for example

Stakeholder management techniques

Interest/power vs influence

A useful way to classify stakeholders is to plot them on matrix with interest/power on one axis and influence on the other.

First some definitions. Interest means how engaged the stakeholder is in your product initiatives. Power is a measure of the ability of the stakeholder to make changes or decisions to your product initiatives. Influence is the degree to which the stakeholder is connected to others in an actionable way.

So, the interest/power axis indicates how likely it is that the stakeholder will make changes or decisions (if they choose to do so), while the influence axis indicates how large the impact will be if the stakeholder makes changes or decisions (if they choose to do so).

High interest/power & high influence

The most important stakeholders are the ones with both high interest/power and influence. An example might be the Marketing Director. They own (at least) the marketing, branding and positioning of products, so they have very high power, interest, and influence over product initiatives. These stakeholders are where you should focus your efforts. Involve these people in all key decisions and consult with them regularly.

High interest/power & low influence

It is important to keep those with high interest/power but low influence informed but try to limit consulting with them on the areas in which they have an interest. An example might be a Regional Director with P&L responsibility; thus, they might control a regional sales team, but with no direct influence over product or engineering. Given that their influence is limited, you might decide to consult on product initiative relevant to major sales in their region or involve them in some low risk areas.

Low interest/power & high influence

Those with low interest/power but high levels of influence present some risks. An example might be a Training Manager. Whilst they have little interest/power over initiatives for your product, they might have significant influence in other parts of the business that your product depends on. You should consider their objectives and strive to avoid getting them offside. Whilst they do not have significant interest/power to offer, their influence gives them to ability to derail product initiatives if they become hostile.

Low interest/power & low influence

Those with low interest/power and low influence are the least important. An example might be the accounting department in an organisation where financial decisions are made by the CEO. It is probably OK to just include them in regular general communications, for example status update emails. You can also aim to move them higher on the interest/power axis if you think they can add more value.

Stakeholders 2.jpg

Once you have identified stakeholders, you can place them on the map, based on their relative interest/power and influence. This places each stakeholder into one of the four quadrants.

Mapping stakeholder relationships

You can then also identify which stakeholders influence each other (indicated with arrows on the diagram). This can help when developing a stakeholder management plan. An example of a completed map of stakeholders by Interest/Power versus Influence is shown below.

Stakeholders 3.jpg

Agreement vs trust

It can be useful to plot stakeholders on a map of Agreement versus Trust.


Allies are in close agreement with you and trust your thinking, strategy, and plans. You should acknowledge the quality of your relationship and seek their advice and support. It is also good to acknowledge the doubts they have with respect to your vision and plans and take meaningful action to address them.


Associates generally agree with your thinking, strategy, plans but don’t necessarily trust you. To manage them, share information about what you are doing and listen to what they are doing. Try to find a way to agree how you are going to work together and keep working at it.


Opponents are people with whom you have a relationship or where trust exists, but they disagree with your strategy and plans. Acknowledge the quality of your relationship and leverage the fact that it’s based on trust. You can use that trust to clarify your position, explore their perspectives, and identify the underlying reasons for differences. Try to create inclusive solutions.


Adversaries are the worst case. These are the people with whom you do not have a relationship or where issues of trust exist, and they disagree with your strategy and plans. Listen to their point of view and use the technique of explaining it back to them, to better understand their position. Try to share your vision for the product and product initiatives. Don’t avoid discussing areas of disagreement and try to find common ground. At the very least, try to move them up to the “undecided” area on the quadrant diagram, but acknowledge that you can’t convince everyone all the time.

Stakeholders 4.jpg

Practical tips for managing stakeholders

  • Avoid meetings that bring together most or all stakeholders. It is better to meet one on one, ask questions, provide feedback, and take opportunities to address issues. Groups lead to design-by-committee (see next point).
  • It has been said that a camel is a horse designed by committee[1]. Products are best not built by committee. Don’t let the collective of your stakeholders become a committee. Your job as Product Manager is to understand, make sense, and filter stakeholder needs – not to ensure they are all met, committee-style.
  • You will inevitably need to say no to stakeholders, even important and senior ones. If you have done your analysis thoroughly and built trust through competency and you communicate context effectively, you will have laid the groundwork for success when the day comes to say “no” to a C-level executive.
  • Involve stakeholders early and often. If you wait until a solution has been created to involve stakeholders, it is probably too late. Take advantage of agile methods, which encourage us to “fail early and fail often” – that’s the best way to learn quickly before it’s too late.
  • Effective product management means making sure your solutions are valuable and usable (for your customers), feasible (for your development teams) and that they deliver for your stakeholders.
  • Avoid getting into debates that pitch your opinion against a stakeholder’s opinion. Opinions are like noses – everyone has got one! Instead, always redirect conversations and debates to evidence and facts. Perform experiments. Collect data. Analyse customer feedback. Share your learnings transparently. Value getting the right answer over being right.
  • Some stakeholders won’t understand what your product does, why it exists, or they might even perceive it as a threat. This is OK. Be understanding and sympathetic, but not condescending. Take the time to continually explain the vision and value of your product and product initiatives. Don’t assume others will understand the first time you explain it to them. Every stakeholder has a different role with a unique context and set of challenges, and your product is probably only peripheral to their world.


Remember, important stakeholders can make or break your success as a Product Manager, so pay close attention to them. Be proactive. Identify they key stakeholders. Understand their concerns. Communicate regularly. Manage according to your own analysis of their needs. Don’t ignore customers… but conversely, don’t get so caught up in external customer concerns that you forget to manage effectively your key internal stakeholders.

[1] No dromedarian offence intended.

More on Prioritisation

Previously, we covered how Product Managers and Product Owners can practically apply the “4-quadrant” idea to prioritise product backlog items. Sorting features into the 4 quadrants is a very general way to think of prioritisation.

Today, I want to introduce a few other useful and practical ways to frame the relative priority of features. Each requires a different mindset and when used collectively, they allow you to consider features from different perspectives. Looking at features from several different angles in this way can help when you are faced with tricky prioritisation decisions.

The Kano model

Often Product Managers are faced with a choice of improving existing features or building entirely new features, and because the nature of these options is so different, it can be difficult to figure out how to prioritise one over the other. A useful way to frame these kinds of decisions is to think through how likely it is that a feature will satisfy customers. You can then weigh this up against the expected cost to implement the feature, and decide which features make economic sense.

The most commonly used example of this approach is the Kano Model, created in 1984 by Noriaki Kano of the Tokyo University of Science and still used widely by organisations of many types. The idea is to plot the relative positions of features on a chart with customer satisfaction on one axis and level of functionality on the other. The potential for customer satisfaction by functionality can be determined by market research techniques like surveying customers, subject matter experts, and/or internal stakeholders or by leveraging satisfaction scoring results from previously implemented features. Exactly how you determine customer satisfaction scores is up to you – the point is to end up with meaningful relative scores of the features you need to prioritise.

The Kano Model defines five categories of features.

Performance features

Performance features – are the most important features to customers; the ones that make your product useful and unique. For these features, customer satisfaction is directly proportional to how well your product performs them.

They are well-known (eg. for an enterprise product, they would appear in RFQ and RFP documents), they are readily measurable (it is easy to compare how well different product provide these features, relative to each other), and satisfaction is easy to relate to the level of functionality.

Examples of performance features are battery life in a mobile phone or picture quality in a television. The more a customer gets of these features, the more satisfied they are. Performance features are sometimes referred to as one-dimensional features.

More Priority 1.jpg

Basic features

Next, basic features are the “must haves” in your product; the features your customers take for granted. For the product provider, there is only down-side for these features. If your product does them poorly, customers are dissatisfied, but if your product does them well, customers just remain neutral. Think of providing these as the minimum price for your product to enter the market.

Basic features are taken for granted. They are not always explicitly stated, but if they are missing, the customer will actively express their dissatisfaction.

More Priority 2

From a prioritisation point of view, the two important things here are (i) incremental investment in basic features yields large improvements in customer satisfaction, but (ii) no matter how good the functionality is, it won’t lead to positive customer satisfaction. In other words, once you have “good enough” basic functionality, it’s usually wasteful to invest more in it.

Excitement features

Excitement features are features customers didn’t expect, but which delight them. In fact, the customers probably hadn’t even thought of them until they saw or used your product. They don’t cause dissatisfaction if missing, because without your product the customer would never have even known about them.

It is worth noting that delight decays over time. As products (and competitor products) mature, features that were once considered excitement features tend to become basic needs. To ensure customers remain satisfied, it is necessary to keep delivering new excitement features that delight.

A great example of an excitement feature is the inclusion of a digital camera in early smartphones. Customers were not expecting it, but it was something that made them go “wow!”. At the time, it was most definitely an excitement feature. More than a decade later, however, we all just expect any smartphone to have an integrated camera, so today it is considered a basic feature.

More Priority 3.jpg

From the shape of the satisfaction/functionality curve, you can see that excitement features are where you will get a lot of “bang for your buck”. Delivering any level of functionality in this category improves customer satisfaction, and usually more functionality rapidly moves the customer satisfaction needle.

Indifferent features

Indifferent features are those that the customer simply doesn’t care about. Customer satisfaction remains unchanged whether these features are in the product or not.

More Priority 4.jpg

From the location of these features on the chart, you can see that these types of features are best avoided. They are usually a waste of money. No matter how good your “indifferent” functionality is, it’s not going to increase customer satisfaction.

Reverse features

Reverse features are those that not only cause dissatisfaction: the customer would be more satisfied if the features were not there. In other words, these features annoy customers. You want to avoid these features entirely.

More Priority 5.jpg

Considering the presence vs absence of features

The aim is to create a product with an optimal mix of the first three categories: performance, basic, and excitement features. And to avoid indifferent and reverse features.

In order to come up with relative scores for proposed features, for each feature you need to determine or predict how customers would feel – in terms of satisfaction with your product – if they did have the feature, and also if they did not have the feature.

One way to do this is to consider a matrix of customer reactions to both having and not having a feature, as shown below (see Reference – this was first documented in a 1993 paper in a quality management journal).

Feature Absent
Like it Expect it Don’t care Live with Dislike
Feature Present Like it ? Excitement Excitement Excitement Perf
Expect it Reverse ? Indifferent Indifferent Basic
Don’t care Reverse Indifferent Indifferent Indifferent Basic
Live with Reverse Indifferent Indifferent ? Basic
Dislike Reverse Reverse Reverse Reverse ?

It can take a while to get your head around this matrix. To help, here are some examples.

  • If a customer dislikes a feature being absent but likes it being present, then that feature is a performance feature: the better you implement that feature, the more satisfied the customer will be.
  • If a customer expects a feature to be absent, but dislikes it being present, then that feature is a reverse feature: the customer will be more satisfied if the feature is absent.
  • If a customer likes a feature to be present but doesn’t care (or can live with) it being absent, then it is an excitement feature that could potentially delight the customer.

[REFERENCE: Note that the table and the ideas behind it are not new. In fact, this has been around for decades. A table like this was introduced by Fred Pouliot in a 1993 paper “Kano’s Methods for Understanding Customer-Defined Quality” in the Center for Quality of Management Journal.]

Practical tips

Here are some practical tips for using the Kano Model to help figure out the relative priority of features.

  • Use for features with tangible customer benefits

A product backlog inevitably includes many types of initiatives. The Kano Model is only useful for evaluating the relative priorities of product initiatives that provide tangible benefits for customers. For example, you can use it for a potential new module that solves a novel problem. But you cannot use it for a design refresh or technical debt repayment.

  • Select customer segments carefully

Most products are targeted at multiple customer segments, each with different needs and therefore, different responses to the product. Keep this in mind when selecting customers to survey for a Kano Model analysis. As an example, small businesses using an accounting package are probably less interested than enterprise customers in a feature that can match purchase order numbers to invoice numbers.

  • Customer maturity can influence results

A more mature customer, with more sophisticated processes and better trained staff, will be more aware of features available in competitor products. For example, a heavy equipment OEM will likely be more familiar with maintenance scheduling features in competitor products than a newly established construction site.

  • Phrase questions around customer benefit (as opposed to your proposed solution)

As with any type of survey, the way you phrase questions can influence the answers you get. Because the Kano Model is used for features with tangible customer benefits (see above), a good approach is to phrase the question in terms of the customer benefits, rather than describing the solution. For example, “If you could review and approve multiple purchase orders, how would you feel?” is a better question than “If you had a multi-edit grid-style screen that showed purchase orders where you could click on individual orders to approve them, how would you feel?”.

  • “Relative importance” can help break deadlocks

You can ask customers to rank the proposed features in order of importance. This can help decide between features that end up with the same Kano Model score. If enough customers find one feature more important than another – despite expressing the same preference for having/not having both features – then you can be confident the one ranked as more important should be higher priority.

  • Test questions before customers see them

Just as you would with changes to the product itself, share your questions internally to verify they make sense, before releasing them beyond the walls of your organisation.

Kano Model – summary

A theme in this article is that as a Product Manager, you need to employ multiple approaches to prioritisation. There is no single right or wrong prioritisation method. The Kano Model is one approach that helps you consider customer satisfaction. It also shows how to create excitement, which is a way to distinguish your product from competitor’s products in the market.

Must, should, could, won’t (MoSCoW)

The second approach is to sort features into 4 groups: Must have, Should have, Could have, Won’t have (sometimes referred to as MoSCoW). You can then consider the capacity you have for implementing features and work backwards to decide which features of each category to add to your plans.

A useful way to apply this technique is to decide on how much effort you are willing to allocate to each of the first three categories and use this to turn your prioritised list into a time-based plan.

In the example below, the decision has been made to allocate at most 60% of available effort to “Must have” items, and then fill the remaining time with “Should have” and “Could have” items.

The principle here is consistent with agile methods, in that the aim is to prioritise items by reduced benefit, as opposed to increased cost. In other words, assume that schedule/cost is fixed, and scope can change, as opposed to the waterfall approach where scope is fixed, and cost/schedule can change.

We set out with the intent that a worst-case outcome delivers the “Must have” items, the expected outcome delivers the “Must have” and “Should have” items, and a best case outcome delivers everything (“Must have” + “Should have” + “Could have” items).

More Priority 6.jpg

The capital redeployment equation

Another approach is to consider the return on investment (ROI) of features, even after you have started working on them. The fact you have started implementing a feature does not mean you need to finish it. There are times when it is a wise business decision to abandon a feature.

It might sound simple, but it is worth spelling it out: when the future cost of a product initiative is higher than the future value of that initiative, it’s time for the initiative to end.

To determine an initiative’s end, you need the following metrics:

  • The value (V) of the remaining product backlog items
  • The expected cost (EC) of the work to complete the remaining backlog items
  • The opportunity cost (OC) of completing the remaining backlog items (in other words, the value of having the team work on some other initiative instead)

When V < EC + OC you are better off stopping the initiative and redeploying the resources away from the less valuable product initiative to more valuable initiatives. There might also be some costs to switch and not complete the initiative that is in progress, so you need to also consider those costs.

It is good to keep this “capital redeployment equation” in mind when considering prioritisation. Failure to do so can lead to inefficient use of resources and throwing good money after bad.


A key aspect of the product management role is prioritising what to build, and in what order. There are always competing demands, and there is always too much to do with too few resources. Prioritisation decisions can make or break the success of products and entire technology companies.

As with so many disciplines, in the uncertain world of technology products and business, continually adjusting your perspective and approach as new evidence comes to light is a sign of maturity.

And whilst this article is not an exhaustive coverage of all ways to approach prioritisation, hopefully it has at least prompted you to reconsider prioritisation to help ensure you consider more than one angle. Doing so not only improves the chances of getting these decisions right; it also gives you a way to explain your logic to key stakeholders, and a way to learn from those times when you didn’t make the optimal choice.