The 8-Step Product Management Process [with Examples]

Define the problem or opportunity

The product management process involves first defining the problem or opportunity at hand. Your product should be solving a real need for customers or taking advantage of an unmet opportunity in the market. Without taking a step back and defining the problem or opportunity clearly, you risk building a solution for a problem that doesn’t exist at all.

To kick off our product management process, let’s ask some basic questions:

• What are customers trying to achieve? Think about real customer needs. Try to get to the root of what your target customer groups really want to achieve or what their end goals are. This will help you to work backwards from there to build the right solution.
• Why do customers need to achieve this outcome? Think about why the goals defined above are so important to customers. Think about the positive outcomes they may be after and really dig into why that matters to them. This will help you identify some real pain points that can be addressed by your product.
• What’s wrong with the status quo? This is a really important question. Why are customers unhappy with their status quo? Are they using another product that isn’t meeting their needs? Is it outdated or hard to use? Is it too expensive? Really get into the customer experience and seek to understand why they would be unhappy with the current solution.

This type of data can help to define your early user personas. The best way to gather this kind of information is by speaking directly to the people who may be interacting with your product. This can be done in a number of different ways such as interviews, surveys or workshop style focus groups.

It’s important to note while doing these interviews, that although users are often very adept at saying what they want, they are often not good at saying what they need, or revealing points of innovation.

If using surveys or questionnaires to gather data, it’s important to ensure that these are not written or structured in such a way as to lead the respondents. The writing of questionnaires has a good deal of science behind it and there is a danger that they can be written in such a way which will only yield the answers the surveyor wants to read.

These questions will help you to really narrow in what the problem or opportunity is. It can be tempting to simply set out to build a great product. But a great product must come from a very well-defined problem statement that is aligned to real customer needs.

Conduct competitive analysis

In the first step, we started by asking questions about the potential customers’ needs and started to build out user personas for our potential new product.

Now it’s time to dig further into the market and analyze the competition by answering a few questions:

• Who (if anyone) already plays in the same space, or delivers a similar offering?
• What will be your “Unique Selling Point” (USP) or your differentiator versus other products?
• What is the size of the market that you are targeting?
• What are the strengths, weaknesses, opportunities and threats (SWOT) of your competitors?

This market research phase is critical to put the customer feedback found in step #1 into context. Keep in mind that this competitive analysis work could be done by a product manager or by a market research team that is hired out.

Either way, it’s a critical early step in the product management process to ensure the product vision aligns to the realities of the competitive landscape.

Design possible solutions

At this point we have clearly defined the problem or opportunity with competitive analysis and market research. Now we are ready to start to map out the way you are going to address them.

At this stage you are merely identifying the mechanisms that will be used to address the problems or opportunities raised. There are many approaches to designing possible solutions, but let’s look at a couple common ones.

Approach #1: “Goals, Bets (hypotheses) & Initiatives” approach.

Let’s look at an example:

Goal: Help people get from one place to another without the hassle of calling a traditional taxi

Bet: A simple ridesharing request application that allows users to request car pickups on demand would solve this need.

Initiative: Build an application that allows users to request pickups on demand.

Simply put, a product manager can define a series of Goal/Bet/Initiatives that are aligned to the data collected in focus groups or via market research. It’s best to collaboratively develop many Goal/Bet/Initiative scenarios to ensure successful idea management.

Approach #2: Happy paths or user journeys

In this approach, you design very simple wireframes or sketches that map out potential happy paths for a new solution. This approach seeks to show the path that a real customer would take to achieve their desired outcome with your solution.

Let’s look at an example:

With this approach, you’re walking through the solution as a user would, at a very high level. Keep in mind that a product manager could use both approaches to help clarify the product vision.

Test your solution idea with a prototype

Once you have decided on the design and method by which your product will deliver its solution(s), it will now be possible for your development teams to build a working prototype. Your prototype doesn’t need to be a highly polished, functionally-rich finished product, merely something that allows you to test and validate (or dispel) your assumptions.

It is often said of prototypes that the organization should be at least “a little bit embarrassed” to release them to the public, which means that, if everything works 100% then there has been too much effort put into productionising the prototype before its release.

A few key factors to consider when building your prototype:

• Prototypes are not the same as proof of concepts. If you’re not ready to devote substantial resources into a prototype build, your project might be better suited to build a proof of concept first.
• Prototypes should be realistic, but not necessarily fully functional. You do not need to have every feature included in a prototype.
• Prototypes should not be heavily focused on visual design. Your goal should be to test the functionality of major product features, not test design elements.
• Prototypes help to enable constant product improvement. As you build one version of the prototype you should gather feedback from internal stakeholders, existing customers, and others before making revisions.

Keep in mind that the prototyping phase could be as quick as a few weeks or as long as months or even years for complex products. A product manager should be heavily involved in all prototyping work to ensure it aligns with the overall product strategy.

Analyze prototype feedback

After the prototype has been built, it’s time to get feedback from real users and internal stakeholders. There are various ways of capturing feedback from users, such as on screen dialog boxes, surveys, interviews, screen tracking or analytics. Regardless of the method, a product manager should collect all of this feedback via a formal feedback collection mechanism.

Feedback will come from many sources, with it being quite common for internal and especially senior stakeholders to provide feedback on the product. It is important to resist the uninformed opinion of senior people, otherwise the unintended HIPPO effect can take place (Highest Paid Person’s Opinion), whereby undesirable or low value changes become prioritized. User, feedback, customer feedback, and data led insights must always take priority.

Such valuable feedback can be prioritized against other build work and fed into the product development team, forming a continuous feedback loop between the product team and the customer, ensuring that continuous improvements are promptly and regularly built in, allowing for feedback to be continuously provided.

Create a product roadmap

Once you have tested your prototype and gathered feedback, you are now in a place to create your product roadmap.

The roadmap is a forward running guide for the delivery of functionality and capability within the product. The roadmap guides the product and delivery teams so that they can plan for the next large theme and value stream to be delivered, mapped against the product goals that you are aiming to achieve.

The best roadmaps start out at a high level as “themes” (large focus areas that span the organization). These themes can then be disseminated down into “epics” (large bodies of work) before we are able to create a user story (a single and discreet piece of work).

Eventually the product roadmap of high level themes (matched to specific value metrics) can have sufficient detail added to it to allow it to map all the way down to a “user story map” or a list of high level user facing opportunities and problem statements.

Build an MVP

In this step, we start turning our plans, ideas and vision into a working software product. During the prototype phase, we may already have built some throwaway low quality code to help us validate assumptions, but it’s at this stage that we get serious and start building a robust, secure, market ready product.

It’s worth checking out our “starting a software project” article for this phase, so that you ensure you have all the necessary things in place before starting, as well as deciding how to structure your team, and whether to insource or outsource.

Once your team is in place, they should be guided by the final product vision to write small, incremental, inspectable releases of the product, which are reviewed regularly by the wider product team.

By now, the product manager should have identified a minimum viable product, or a minimum subset of functionality, which the development team should be working towards. Features that aren’t included in this MVP should be added to the product backlog, and it is the product manager’s responsibility to manage this product backlog.

During the build phase, the product team should be proactive, demanding and exacting stakeholders. They should make sure to hold the build teams accountable by confirming that the deliverables required to meet the product vision and provide a great user experience are achieved.

Analyze customer feedback and iterate

Once the minimum viable product has been built, you’re now in a place to release the product to the end user to allow them to start actively using it. This is where a key feedback loop starts to fire up, as the feedback from users is a highly valuable source of information about where to target improvements.

Product teams should ensure that they have many sources of information regarding the user's journey and that they are built into the product as early as possible. For example, whilst it is simple to email or phone up users of the system to ask them their qualitative opinions, it can be far more useful and efficient to build in automated surveys, suggestion boxes and analytics tracking to gain a greater quantitative insight into the bottlenecks or friction points in your system.

Early adopters or repeat customers are likely to have the most passionate views about your product and hence will be good sources of both positive and developmental feedback. If you engage these individuals not only will you gather valuable information, but you will convert these users into lifelong advocates by considering their views.