How is Software Different?

“Bricks & mortar” product management

Product management is a mature discipline for physical or “bricks & mortar” products in industries such as groceries, retail goods, planes, trains, automobiles.

Designs and manufacturing for physical products have long lead times and therefore design and manufacturing takes place before the discipline of product management gets involved. Even incremental changes to physical products can take a long time to implement. Eg. Changing the recipe of a breakfast cereal might involve sourcing new suppliers, reconfiguration of processing plants, extensive testing and certification. The evolution of physical product is a series of discrete increments.

The first Product Managers were part of marketing departments. Development of ideas around product management throughout the 20th century has honed the focus to understanding customer needs and finding a way to satisfy those needs using what are termed “the four P’s”: the right product, in the right place, at the right price, using the right promotion. Or alternatively “the 4 C’s”: commodity, cost, communication, channel. Either way, their metrics are sales and profits.

This makes sense. New physical products have long development and production lead times, so Product Managers focus on things they can control like place, price, promotion, and leave the development of the underlying product to others.

Software and how it’s different

By contrast, for contemporary technology products – and especially those involving software – discovery of product requirements occurs throughout the development process. Ideal solutions are arrived at through continual development both before and after first use by customers. In fact, in many cases product development never ends, and evolution of the product becomes a continuous process. This means the very nature of product management is different. Product management must be involved from the beginning of product development and that involvement must continue as the product changes over time.

The consequence is that, in the software world, separation of product management from product development is not feasible.

Product Managers can no longer rely on place, price, promotion to succeed. Aligning product development with other contributors relies on understanding the customer’s needs and the organisation’s intentions for the product, something product management is uniquely positioned to do.

In the modern world, product management is about owning the vision, design, and execution of a product. Product Managers may not be expert-level professionals in any one aspect, but they are involved in conceiving, planning, designing, developing, verifying, validating, testing, launching, iterating, and retiring products.

Some product management frameworks draw a stark distinction between “new product development/acquisition” (Technical Product Manager) and “commercialization & manufacturing operations” (Commercial Product Manager or Marketing Product Manager). In the “bricks and mortar” world, where product developments typically have long lead times, this makes sense – product managers spend most of their time commercialising already-developed products.

However, software (especially given the nearly universal adoption of agile methods) is fundamentally different in that product development happens continuously and never ends.

Comparing physical vs technology product management

Here are some of the key differences between physical product management and technology product management.

Physical Product Management Technology Product Management
Product is “given” to the Product Manager Product Manager decides what to build
Product changes have long lead times Products have short lead times
Big design up front Continuous change and redesign
Manufacture/duplication costs time+money Manufacturing / duplication is instant & free
Difficult to add value after development Easy to continually add value

The bottom line is that technology products (especially those based on software) are different, and these differences mean that traditional product management does not work. A new approach is needed, aligned with agile methods.

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.