This Stew that We Call Product Management

While interviewing for a product manager position, a product manager at the would-be company asked me: “What is your product process?” After some pontification, I landed on an analogy (since, you know, it’s hard to explain what we do, even to ourselves):

The set of activities that make up modern SaaS product management are like a stew with a handful of ingredients.

These ingredients are:

1. Understanding business objectives
2. Understanding customer outcomes
3. Discovering and validating solutions
4. Defining the feasibility of solutions
5. Developing and delivering the product
6. Evangelizing and launching the product
7. Tracking, measuring, and further discovering

These ingredients are thrown into a huge stew called product management. And as much as we like to think that the product management process happens linearly, product management is not a linear, lock-step process. Instead, on any given day, we’re scooping out of the stew for whatever outcomes we’re targeting or problems we’re trying to solve. Also, knowing where one ingredient ends and another begins is quite vague, and probably not helpful, since all of the ingredients blend together.

#1: Understanding business objectives

At the deepest root of product management is understanding business objectives. Business objectives are why a product exists in the first place. Objectives provide the high-level guidelines throughs answers to questions like:

• Why does the business or product exist at all?
• What is the business attempting to accomplish?
• How does our business generate revenue?
• Who is our target market?
• How is the business trying to grow for the foreseeable future?
• What business constraints does the product team need to work within?
• What key results is the product responsible for, and how do those translate to business value?

Knowing the objectives your business is targeting help you to align your product efforts, metrics, and results. As product people, we like to know that we’re having an impact on the world — one of the best ways is to know that we are driving the success of the business through our product management efforts.

Product managers are seen as the bridge between what “the business” wants and the creative talent found in developers and UX professionals. Product managers facilitate the critical communication that is needed among these cross-functional teams.

#2: Understanding customer outcomes

A deep understanding of your business sets the foundation for understanding your customers. And not simply understanding your customers as personas or users, but driving a deeper understanding of them as humans, and to go even deeper to understand the outcomes they are trying to achieve. (You can replace outcomes with your own favorite word or framework, like problem, need, job to be done, request, friction, goal, progress, etc).

To drive deep into understanding your customers, consider asking them questions such as:

• Why do you use our product?
• What are you trying to accomplish using our product?
• How did you solve that problem before?
• What problems does our product not solve for you?
• What alternatives do you have to using our product?
• If the product disappeared tomorrow, how would that affect you, if at all?

This ingredient is often described as discovery. Marty Cagan and Teresa Torres are two of the great thought leaders in this space. And really, discovery and dealing with humans who interact with your product is the fun part of product management, at least for me. All sorts of frameworks, tools, and techniques have been developed to help with this ingredient, such as:

• Contextual inquiry
• Customer journey maps
• Customer interviews
• Jobs to be Done Theory

Many supporting roles have become experts in this ingredient, such as UX or product designers and user researchers. Product managers need to be humble enough to learn from the expertise of these roles, yet also provide enough leadership to guide those experts to objectives based on the business objectives (see ingredient #1).

Find some way to involve your developers in this ingredient. Some may not like it, others may outright fight you about it; but a 30-minute phone call with a customer explaining an issue and a developer listening in will save a product manager hours and hours of explaining and debating.

This ingredient also requires a delicate balancing between qualitative data (interviews, recorded sessions, journal entries, etc) and quantitative data (analytics, funnels, heat maps, etc). Be sure that you choose the right data gathering method for what you are trying to achieve, and to always temper that data with some other type of data (for example, customer interviews that are targeted at a specific dropout point in a funnel).

#3: Discovering and Validating Solutions

Discovering customer outcomes is not enough; product managers also need to discover potential solutions for those problems. For this particular ingredient, PMs rely heavily on their User Experience Designers. UXD’s are experts in UI and thinking about the user’s experience with every click or tap. In fact, they may even take the lead in this ingredient while the PM slides into more of a participant role. UX researchers also help during this ingredient.

Again, various frameworks and techniques have been developed to help you with this ingredient:

• Human Centered Design
• Usability testing
• Wire frames, mockups, and prototypes
• a/b testing
• Beta testing
• “Do things that don’t scale”

I have long been a fan of Directed Discovery, as described by Nate Walkingshaw at Pluralsight. One threshold they hold is that they do not release new features into the general release until they have a net promotor score of at least 60 in their beta phase. That level of validation and testing ensures that they never release functionality that doesn’t solve customer problems in a satisfying, delightful way.

The developers on your team also need to be involved in at least a small way during this ingredient, if only for the same reasons as #2. One of your primary responsibilities as the servant-leader of the product team is to help your developers gain deeper empathy for the people who use their work product. Additionally, because devs are “in the trenches” of the product, they can be an invaluable source of innovative ideas for solutions.

#4: Defining the feasibility of solutions

Technical feasibility is probably the biggest constraint that product managers need to work within. This is the ingredient in which you will rely heavily on your tech lead and other developers. They will be deeply involved in evaluating the prototype, reviewing existing infrastructure or architecture, understanding data flows, and help you know what can feasibly be built.

At this point, you need to dive deep with you tech lead and developers to make sure they understand what they’re building, and more importantly why they’re building. They might not want all the details, but they need to understand at some level what the market is doing, how and why your business is responding, and where the product fits in the bigger picture.

Activities that you will be involved in for this ingredient include:

• Backlog groomings
• Scoping/Planning meetings
• Epic and story writing (and revising)
• Acceptance Criteria writing

If you involved your devs earlier on, then hopefully the surprises and technical “gotchas” are few at this stage. That earlier investment pays off. Still, you will be negotiating, persuading, and giving and taking with your developers. When sizing a particular story, do not pressure your devs for estimates if they are unsure or need to research a specific point. Time box the research and let them come back to the table with more knowledge.

Some questions to ask your developers at this point:

• What technical constraints do we need to account for?
• (When making a trade off decision) What are the known implications of our options?

The primary value that you provide in this ingredient is prioritization. I repeat: ruthless prioritization. Good developers want to solve hard problems, take pride in their craftsmanship, and see multiple ways to build solutions. Your job is to keep them focused on the most important problems or outcomes and having just enough product (read: the minimum viable) to solve those problems or outcomes. Deciding on the priority of what to build has so many factors involved, including items on this not exhaustive list:

• What are the business objectives your product is supporting?
• How critical to solving customer’s problems is a particular feature?
• How many customers will be affected by what you’re building?
• What is the technical effort required to build what you’re planning?

Every company and every product will have different factors in determining priority. As product manager, your primary job is ensuring that developers are working on the most important problems and features.

#5: Developing and Delivering Product

Now you need to lead the team in actually building out what you and the team have defined together. In this ingredient, product relies on any number of project management frameworks, such as waterfall or agile in all its flavors (Scrum, Kanban, SAFe, etc). These frameworks often get conflated as the entirety of product management. The truth is they are not. They are development execution frameworks that are focused on output. While absolutely critical to being successful in product management, development is only one ingredient of this whole stew that we call product management.

These agile frameworks often get conflated as the entirety of product management. The truth is they are not. They are development execution frameworks that are focused on output. While absolutely critical to being successful in product management, development is only one ingredient of this whole stew that we call product management.

You’ll spend time in daily stand ups, clarifying stories and acceptance criteria, and constantly helping developers know what is the most important tasks to be accomplishing.

You may have the luxury of being able to partner with some type of project manager. Whether that person is a product owner, agile coach, scrum master, the form doesn’t really matter. What does matter is that you partner closely with this person, so they can ensure that the product vision is executed and that the user stories and acceptance criteria are written, organized, and moved through whatever dev process your business has in place.

Perhaps you don’t have that luxury, and you are filling that role yourself. If so, be deliberate to not allow these activities to take all or even the majority of your time. You need just enough of this critical ingredient to keep the stew balanced, but not too much. If you do allow too much, then this one ingredient will overpower everything else in the stew.

#6: Evangelizing and Launching the Product

As your product is being built, you need to start getting the company, your customers, and the market excited about your product. Doing so comes in many forms, all with their various target messaging and timing.

Roadmaps fit within this ingredient. Roadmaps are a great tool to communicate and evangelize what your team is working on and planning on working on next.

You will need to develop deep partnerships with cross-functional departments all across the company. For example, you will need to partner with:

• Marketing, so that they know what to communicate to the broader market
• Sales, so that they know how to position the product/feature, what the value proposition is, and answers to customers’ FAQs
• Customer support, so that they can answer questions and complaints from customers
• Customer success, so that they can help customers take full advantage of the new product or feature and help drive adoption
• Other product teams, so that they can coordinate their product offerings or discuss how your products need to work together

Product walls are a popular and fun way to evangelize the product. You can provide mockups in a public place (usually best if near the break room or kitchen, or some other central, high-traffic area). Leave out some sticky notes and pens next to a note soliciting feedback, and you’ll be surprise what great ideas and critiques will come from your coworkers in other departments.

Evangelizing becomes particularly important when you are preparing to launch a new product or feature. A product manager simply can not market, sell, support, or train on the product entirely alone. Your job is to rally all of these cross-functional experts to your vision, so that they can go execute in their respective disciplines. Resist the urge to launch simply because the product has passed QA; instead, work on getting other departments ready to support the product before, during, and after launch.

#7: Tracking, Measuring, and Further Discovering

Most product teams celebrate the launch. And it’s justified: you and the team have been working hard to get that product out the door! But the product launch is not the end—it is the beginning.

The product launch is not the end—it is the beginning.

Launches are the beginning of watching the data, looking at the analytics, combining those analytics into meaningful metrics. You should be asking yourself questions such as the following:

• Is the new feature achieving the outcomes hoped it would?
• How many users have used the new feature?
• Where are users falling out of the flow or experiencing friction?
• Are users satisfied with this solution?
• What business value is this solution providing?

Which brings ingredients 1 and 2 back into play. If you find, through testing or launching into the wild, that your feature is not achieving the outcomes you hoped it would, you may have to make the hard decision to cut it. And, by watching the data around the new features, you will begin to see further opportunities to enhance the product or build entirely different products.

TL;DR

Product management is not a linear process, but successful product managers pull from a variety of toolsets to manage their products. They lead teams not through arbitary authority by through expertise and influence. Managing a product is not for individuals who are simply idea people, nor is it for those who want to dictate features, nor for those who want a single, correct, reliable answer. Product management is the world of best guesses, decisions with just enough information, being able to learn from failure fast, and making sense of the vague stew that we call product management. (And BTW, I was offered and accepted the position. Perhaps my stew analogy helped afterall.)