If you were to ask 15 people from 15 different companies the question “What is Product Management?” or “What does Product Management do at your company?”, I guarantee you will get at least 15 different answers. I often get this question when working with clients when something is going wrong, and they need help determining, of all the “things” the product management team “should” be doing, what is the most important thing to help achieve their goals. The reason I think this happens is because of how undefined the typical Product Management role is at many companies.
This lack of definition comes in part from the evolution of Product Management from a Marketing role in the 1930s to more of a Program Management role in the 60s – 80s, which evolved with the rise of software products and agile methodologies to what we know as “modern” Product Management today.
This change in Product Management over the last 90 or so years was not something that happened in a planned-out way; there were no real courses in the universities that explained what the role should be and what it should do. It emerged as companies experimented with different ideas and determined what worked best for them. I will make a sweeping generalization here and say that consumer staple products (like clothing, hygiene supplies, and food) continue to have Product Managers that reside in the Marketing department and most resemble the “Brand Men” concept from Procter & Gamble in the 30s. B2B Manufacturing and companies tend to have Product Managers who are more like Program Managers, coordinating all the suppliers and logistics to bring the finished product to market. Then you have Product Managers working on software. This is where I find the most confusion about what a Product Manager does (or should do).
You can read more about the history of Product Management here.
In the previous examples (Consumer products and B2B manufacturing), you have something in common: a physical product being manufactured, marketed, and sold; and a specific set of skills needed by your Product Manager to bring them to market. I am not saying either is easy, just that their skills and role in the company are typically well defined and fairly consistent company to company.
In software companies, the roles are often very undefined, and you can roll the dice to guess where the Product team reports within the organizational structure. I have seen all of the following:
• IT (reporting to the CTO or CIO) – This can be a formal Product team responsible for Products or is just a handful of Product Managers working on projects. These PMs typically are asked to be more technical and focus a bit more on engineering engagement and product development and delivery.
• Marketing (reporting to the CMO) – This falls back on the more traditional role of Product Management and these PMs are typically more focused on market research, customer sentiment, product positioning, and product pricing.
• Operations (reporting to the COO) – I do see this less common, but when I do see it, the product team is focused mostly on feature delivery to satisfy customer requests that come through Sales, and Customer Success.
• A stand-alone Team (a CPO, reporting to the CEO) – While becoming more common, this is still quite rare outside the technology space. In this model, the PM is usually considered the General Manager of the products and has the widest set of responsibilities.
This isn’t even all the combinations I have seen; they are just the more common. I have seen things where Product Managers are in Marketing, Product Owners are in IT (but not part of the engineering team), and Program Managers in part of engineering, all in one company. I will be writing a separate article on different structures for product teams and what I think tends to work best. For now, let’s just recognize the lack of standards for how companies approach Product Management and why it creates confusion about what the product team should be doing.
Going back to one of my first questions, if you ask a variety of people what a product does, then you will get some variation of the following things:
Strategy
- Market Knowledge
- Competitive Knowledge
- Regulatory Knowledge
- Owning the P&L or Growth Goals
- Setting of Value Proposition
- Being the Product Spokesperson
- Setting the roadmap and goals
Marketing
- Understanding the buyer and behavior
- Segmenting the market and understanding growth areas/opportunities
- Speaking to the press about the product
- Writing use cases and white papers
- Setting pricing
Managing a live Product
- Measuring utilization and growth
- Optimizing user experience and performance
- Responding to issues
- Supporting the product’s social/online presence
Customer Success
- Publishing a customer centric roadmap
- Creating training materials
- Responding to customer requests
- Establishing user groups
- Presenting at customer conferences
Development
- Maintaining the backlog
- Coordinating SLDC ceremonies and routines
- Dealing with conflict
- Writing release notes
- Managing product releases
Design and User Research
- Surveying and interviewing customers on new ideas and customer satisfaction
- Testing ideas with prototypes
- Creating wireframes or even full UX mocks
- Establishing consistency between products
For Leaders
- Managing up to executives
- Mentoring and coaching of PM’s, Designers, and others
- Resolving conflict
Some of you would argue with me about whether or not the product is, or even should, be responsible for some of the items above. I would, depending on the circumstance, probably agree with you. If you have a strong business development and strategy team, then most of the items under strategy go to them. If you have a marketing team with product marketers then most of the stuff in marketing goes to them. If you have a capable customer success team, well, you get the idea.
However, when I am asked this question, it is not because the company has all those roles well defined and they have well-functioning teams in each role; it is when something is wrong. I had an old boss that used to say that “Success has many fathers, but failure is an orphan” (he actually used a less friendly word than orphan, but we will be PG for this article).
Regardless of what has gone wrong, when I am asked this question, it typically means that the company is not achieving their goals, and it is easy to focus on product-market fit and then look at any item in the above list and find deficiencies. In short, when a failure occurs because the product is not succeeding in the market, it is really easy to look at “all the things” that the product team could have or should have been doing and find areas for improvement (regardless of the actual team structure and areas of responsibility).
If you are an Executive and you find yourself or your company in this situation, how do you resolve it?
My typical advice when companies find themselves in this situation is to do a few things:
- Look at the Product Team you have, what you have historically asked them to do (and presumably hired for) and whether or not that is meeting your needs.
- If your needs have changed (or you are realizing they need to change), then you can set a path forward to adjust the team according to your new needs.
- If your needs have not changed, then you can just clarify with your leadership team what the roles and responsibilities are for the product team, and what they are not, and refocus your team on achieving the goals you have set instead of focusing on what the product team itself is or is not doing.
Things are not always so cut and dry, so most often a blend of items 2 and 3 need to occur. You need to make some adjustments to your team, AND you need to reset expectations by clearly defining roles and responsibilities for your product team.
If you are a Product Leader, how do you avoid getting into this situation or if you find yourself in it?
When I work with product leaders, I encourage them to recognize that a large part of their job is expectation management. If you find yourself in a company with an undefined Product role here are some do’s and don’ts.
Do
Start documenting what your product team will or will not be doing on a per project basis. This should be part of your initial project kick off and the detail of it will depend on where the company is on the waterfall to agile spectrum.
Don’t
Worry about creating a roles and responsibility matrix (probably a RACI matrix) on all the roles and responsibilities listed above. Unless there is an agreement amongst the leadership team to both do this activity and hold people accountable to it, it will end up being a waste of time.
Do
Communicate what you are and are not doing often and repeat yourself. When you hold product status update meetings or release readiness meetings or development previews make sure you repeat the goals of the work, and what you are working on and are not.
Don’t
Allow yourself to fall into the gotcha trap. Even if things are going well, somebody might ask “did you do X?”. If your documentation and your communications did not clearly state and repeat whether you were doing X then you will both feel and appear as you missed something. Somebody asking is not necessarily doing it to call out a gotcha. They are typically just thinking about how they believe something “should” be done and are asking about it. However, this approach is commonly used when something goes wrong and people want to point at things they believe “should” have been done to avoid the problem. So, when planning your work and the list of things you will be doing on a project and things you won’t be, make sure you are detailed enough to avoid this trap.
Do
Accept new inputs and adapt to change. You may have decided not to do some aspect of work, but you start to receive early indicators of failure in some way. Don’t be afraid to change tactics or plans and add or remove things to the list of things you are doing vs. not doing. Just make sure you communicate the change. For example, you may have decided early on that you have a lot of user feedback and internal support for a given idea, so you skip user research or prototyping. You start developing and release a few iterations of a minimal product and it goes poorly. The prudent thing to do would be to introduce some light user research to understand the disconnect so you can correct.
Don’t
Spend too much effort defending why you chose not to do something. If somebody is incredibly passionate about something and feels you should have done it, and has the authority within the company to force the issue, then your best approach is to simply find what you can trade off.
In most instances, product management is a game of trade-offs. You are trying to get to market in a reasonable time and cost to achieve some goal.
Simply bring this person into the fold and explain why you made the choices you did, and ask their help to either reprioritize your work, or to get the added resources added to your project to do the “thing” the person wants.
Do
Own your actual failures. This is the hardest one for me to write. Oftentimes when I see this big question, I see a company that does not manage failure well, meaning failure is not tolerated and those who admit failure usually don’t last long at the company. I can write a whole article on this topic, maybe even a book. However, even in such a company, if something is clearly your fault, meaning you were supposed to do something, and you did not, and that caused a real problem, then you should be the first to bring it up and to have a plan for how to correct it. If you do not do this, and the issue comes to light, then it opens additional critics on all the things you specifically said you would not do, but people have expectations that the product “should” do.
Don’t
Don’t accept the blame for all failure. In contrast to what is above, I know a lot of product managers that carry the full burden of success or failure on their shoulders. Look, wins or losses in a product are a team sport that relies on each department to do their part. I am not giving you license to play the blame game within your company. I am just telling you to not accept the blame yourself or your product team when it is not yours to accept. The definition of what the product “can” do is so wide; it is really easy to blame the product for just about anything. Don’t accept the blame but instead focus on how to fix the issue even if it was not your fault or responsibility.
OK, this is reaching the upper limit of my single article length. I touched on a LOT of topics here but tried to focus on how to define what your product teams should have responsibility for. Every company is different, with different strengths and weaknesses across departments, and what works well for one company may not work well at all for you.
If you would like me to write more about any of the topics above, then let me know. If I think it is in my roles and responsibilities, I will consider it!