If you ever want to see a product manager squirm, ask them what a PM does.

Unlike designers and developers, there aren’t any hard skills product managers can point to that contribute obvious value to customers. But that doesn’t mean they’re expendable. Quite the opposite.

Almost all mature software companies seek good product managers. One good product manager is worth multiple good engineers. Good product managers ensure the right things are being built. A team of the best engineers working on the wrong things will not amount to much. One good PM making incremental improvements with average engineers can accomplish amazing things.

The official occupation is relatively new but has gained popularity over the last decade. According to Glassdoor in 2022, product manager positions are in the top 10 best jobs in the United States.

So what is product management?

The short answer: Product management is the process of strategically overseeing the development and success of a product throughout its lifecycle.

The long answer: It’s much more nuanced than that. Keep reading.

Product managers help to decide what features or functionality to build and communicate the plan with the team and stakeholders. They must understand why they’re being built and be able to prioritize when it is best to build them. Product managers can influence how solutions are built but designers and developers should ultimately decide how a solution is designed and architected.

Product managers work directly with customers, UX, development and other internal teams. They are responsible for solving customer problems while simultaneously generating money for the company. PMs must align their product’s roadmap with the company’s vision.

The day-to-day responsibilities vary depending on expectations and the size of the company. The smaller the company, the more hats a PM is expected to wear.

In immature organizations, PMs are treated like rovers, expected to fill unowned holes that the rest of the company can’t (or doesn’t want to) fill. While PMs should expect to be generalists, they shouldn’t be the company dump yard.

Product managers are like movie directors

Historically, people with product management skills were some form of a creative leader. They may not have had all of the skills to accomplish their goals themselves but they collaborated with skillful people to accomplish them.

Much like how a movie director probably doesn’t have the lighting, camera, visual effects, writing and other production skills. But, they should still be able to bring each of these skill sets together to create an end-product viewers value.

Even Steve Jobs didn’t have the engineering skills that Steve Wozniak had but he knew how to harness Wozniak and others’ skills in ways that customers valued.

Product management — you build, you measure, you learn

Regardless of their title, in every case, certain characteristics are the same. Each is a creator. They’re problem solvers. They facilitate solutions that people value.

But unlike movie directors, product managers don’t have an “end” to their product. The process is continuous.

Take Apple for example. It’s been around since 1976. It started with a simple product – Apple I – an assembled circuit board that lacked a keyboard, monitor and other basic features. Since then it has evolved to become the hardware and software ecosystem that it is today.

Not every product that Apple has created is still around. Apple I, the iPod and iTunes are a few examples of products that have lived out their life cycles. Apple has adapted to market needs to create, improve and discontinue certain products.

There are many definitions for the product management process. A common pattern is depicted well in Eric Ries’ Lean Startup as the Build > Measure > Learn loop.

These three phases are summarized as follows:

• Build – Turn ideas into products.
• Measure – Measure how customers respond.
• Learn – Learn whether to pivot or persevere.

Every loop constitutes a Minimum Valuable Product (MVP) where the smallest value is incrementally delivered to customers. The goal is to learn, then adapt those learnings to the cycle. The Lean Startup method informs product teams “how to drive a startup – how to steer, when to turn, and when to persevere – and grow a business with maximum acceleration.” (source)

The aim is to speed up the time between each cycle. The faster the cycle, the more likely the product is to win customers compared to competitors.

Figure out problems before jumping to solutions

Great solutions require getting to the root of customer problems (also known as Jobs to Be Done). Immature product organizations often jump straight to solutions (or features) they assume customers want. Mature product organizations take sufficient time to understand what problems they’re solving first.

Before entering the build, measure, learn cycle, product managers must have a starting point to understand the customer’s problems. As the product evolves, the learn phase more clearly informs what problems the product can solve.

Once enough problems are defined, they should be organized into a list of “problems to solve”. This list contributes to the product’s roadmap.

Roadmaps vs backlogs

A product’s roadmap is a ranked, visual representation for what the product team is planning to release in the near-to-medium term. It represents epic-level (large project) goals, is linked to business-metrics and is strategic in nature.

A product’s backlog is a ranked list of user stories, designs, bugs, technical debt and other tasks. It represents individual tickets that a developer can work on and is tactical in nature.

With the input and approval of business stakeholders, product managers own the product roadmap and backlog. They need to maintain both a 50,000-foot, holistic view as well as execute at ground-level.

Frameworks for roadmap prioritization

There is more than one way to prioritize what development will work on. The ultimate goal is to focus limited resources on the right things. Some common prioritization frameworks include:

1. WSJF
2. RICE
3. User story mapping

Common pitfalls with roadmap prioritization

There isn’t a perfect prioritization framework. In absence of any system at all, teams tend to default to less desirable methods. Some of these include:

1. HiPPO: Whenever there’s a lack of data, the default decision goes to the highest paid person’s opinion (HiPPO). To mitigate this, product managers are supposed to make prioritization decisions based on data and customer-validated information.
2. Money: A primary incentive of companies is to make money. This isn’t a bad thing — companies can’t survive without money. But focusing solely on money can cause them to make shortsighted decisions. Product managers should focus on win-win solutions where customers are willing to exchange their money for the value the product provides.
3. Shiny-object-syndrome: Immature companies constantly shift focus to the latest shiny object that grabs their attention. When priorities are constantly shifting it’s difficult to get the right things done. Product managers need to be disciplined and know when to say no.
4. Fires: As Stephen R. Covey pointed out in 7 Habits For Highly Effective People: “Most of us spend too much time on what is urgent and not enough time on what is important.” Focusing on too many urgent things (like reacting to customer-fires or the latest hype) can distract from taking care of important things. Mature product managers balance an appropriate amount of attention to urgent and important things.

Product teams should continuously improve the methods they use to prioritize their work. Strategically ranking what to work on and being disciplined about what not to focus on can be equally important.

Discovering potential solutions from customers

Once your customers’ problems are defined and prioritized, product managers work on discovering a solution to the top problem.

Some product discovery methods are covered in more detail here but here are some basics:

Customer interviews

Military strategist John Boyd observed:

“If we don’t communicate with the outside world — to gain information for knowledge and understanding — we die out to become a non-discerning and uninteresting part of that world.”

The same applies to product discovery. Product managers need to be in constant communication with customers. Without regular user-interviews, product managers will be out of touch with their needs.

Usability testing

Once a user’s needs surface through customer interviews, solutions are designed in prototype-form. These designs are validated with customers through usability testing.

This stage undergoes mini build, measure, learn cycles as customer feedback informs iterative improvements to the design. Prototyping solutions saves a lot of money. It’s much cheaper to iterate through designs than it is through development.

Surveys

Once customer interviews surface common patterns, surveys are a great way to validate interpretations of those patterns. Tools like Google Forms, SurveyMonkey or a simple email blast are great ways to collect targeted quantitative data.

Data analysis

“If you can not measure it, you can not improve it.” -Lord Kelvin

Just like we can’t navigate space without data, product managers can’t understand where to take the product without data. W. Edwards Deming observed:

“Without data you’re just another person with an opinion.”

Collecting, visualizing and analyzing data is essential to understand product usage and quality.

Planning actual solutions

Next comes the planning stage. This stage requires the most discipline. During the discovery phase your team got hyped up on some sweet ideas. Now it’s time to come down from the clouds and execute.

During the planning stage you need to decide what is and isn’t going to be delivered in the first version of the epic (aka MVP). Defining the MVP means delaying some good ideas. Just because some good learning was done in the discovery phase doesn’t mean the learning is complete. A goal in the planning stage is to release incremental, bite-sized value so that more learning can be accomplished quickly.

Product managers, UX designers and developers should be aligned with what the plan is. Here are each member’s responsibilities at this stage:

• Designers are responsible for having high-fidelity designs ready.
• Product managers write user stories and acceptance criteria. They ensure the tickets have the appropriate designs and assets that developers will need. They also ensure all other dependencies and documentation are ready.
• Developers should have already bought off on the feasibility of the design. They create technical tasks and review the product manager’s tickets and provide notes or feedback as needed.

This process is usually not linear. There is usually a lot of back-and-forth discussions, clarifications and negotiations. While the product manager doesn’t perform every part of this stage, they are responsible for driving it until a plan is formalized.

This shouldn’t take too long though. Being agile requires being flexible and quick through the planning stage.

Implementing your solution

Once the tickets are ready then the engineering team is ready to develop the solution.

During development there are sometimes unforeseen issues that come up that require clarification from the PM. Unforeseen issues like these should be the exception and not the rule. Everyone needs to be flexible. If documentation is always 100% accurate then that probably means the PM spent too much time planning. That’s not to say they shouldn’t try to write clear and complete requirements; but perfection can become the enemy of the good.

Throughout development, the PM and UX designer should review the functionality in a testing environment to ensure it’s meeting expectations.

Once the team thinks it’s ready, the QA team should test out the functionality against the user acceptance criteria and designs. They should also write automated end-to-end tests. All questions and issues should be raised to the PM for clarification or potential prioritization.

Measure your outcomes

After the tests have passed then the team releases the functionality to production. Often, this functionality is released incrementally to a small number of customers first to gauge customer responses and ensure unforeseen bugs are affecting fewer users.

Metrics of success should be defined ahead of time so that at the time of release, product managers already know what outcomes they’re looking for.

For example, usage is often a key metric. Knowing how to measure usage through a database query or an analytics tool is critical to understanding whether or not customers are using what you just built for them.

Reaching out to existing customers — particularly ones who have already requested the functionality — and asking them what they think is a qualitative way of measuring success.

If feedback is positive then it can be released to more users. If not, then the product team should pivot. Pivoting can be hard but necessary at times if circumstances require. If there’s a good reason to persevere then the build, measure, learn cycle continues.

Increasing speed and agility through product management workflow

Two keys to building a successful product are to speed up time spent:

1. Within each learning cycle - This is done by building each release as small (and still valuable) as possible.
2. In between each learning cycle - This is done by having quick processes to measure/learn about the effectiveness of what was just released and to plan what to build next.

Product teams that increase the speed of their build, measure, learn cycles will improve their product more within the same amount of time than teams with larger release cycles.

It’s like trying to establish understanding with a complex topic. What is more likely to accomplish that: an email thread or a verbal conversation? Nuance and clarification are more likely to surface in the quick learning cycles of verbal communication than TL;DR email threads. One reason is that the cost of clarification is higher and this barrier causes many to fill in the blanks with assumptions.

The same goes for building products. Increasing the speed of the product feedback cycle has the following advantages:

1. Better understanding of customer problems
2. No need to assume what solution should be built
3. Less wasted time and resources
4. Better product
5. Happy customers

Author’s Note

These guidelines are not meant to be prescriptive. Creative problem-solving principles were being applied well before product management was a profession. They will continue long after it has evolved. Take what makes sense and apply them to your circumstances. As 18th century artist Joshua Reynolds’ advised upcoming artists, there are three rules to being successful:

1. Study the rules
2. Study the great masters
3. Forget the rules! (source)