The product management process can be challenging to define, especially since ways of working have evolved so rapidly in recent times. Here we will look at everything from why the process is so important to the different phases involved. We’ll also explore product management best practices, as well as some of the top tools to help you succeed.
Why is the Product Management Process Important?
There are many reasons that the product management process is so important, but ensuring that you are delivering value and impact and preventing waste in your business are two of the core points to consider:
1. You want to ensure you are building and delivering products that are valuable, useable, feasible, and business viable:
- Valuable for customers – products that solve a need or problem and customers choose to buy or use them
- Useable – customers are able to use your products with ease
- Feasible – to ensure that products can be built with the time, skills, and technology available
- Business viable – to ensure that products that work within the constraints of the business – for example, from a legal standpoint
2. To stop delivering products that don’t fulfill all of the above – launching products without solid validation increases your risk of:
- Wasted time, effort, and money- launching products that aren’t used or valued may result in costly maintenance or work to retire them (as well as the time and effort to develop them in the first instance). Product teams are not cheap to run so you want to ensure that you’re investing in the right products at the right time
Product Management Process: The 3 Phases of Product Development
Phase 1. Product Management: Defining Success
The first and arguably one of the most important parts of the product management process is to define what success looks like for your product. This could be a success for your customers, your business, or both. Without knowing where you’re heading, developing a valuable product will be very challenging!
Increasingly companies are adopting OKRs – objectives and key results – as a way to define success in their organizations. OKRs help teams and companies achieve hyperfocus on solving the most impactful user and business problems that matter most – they are also a way to decide what not to focus on.
Their use can also enable a culture of experimentation by articulating the desired outcome and letting teams find the best ways to solve for that as well as providing alignment, transparency, and clarity of purpose.
What are OKRs?
Let’s break it down a bit:
- An objective is a qualitative, far-reaching statement of what you’re trying to achieve. It’s an aspirational statement, not a task or granular outcome. It should be something that can be achieved in a quarter and be actionable by a team independently.
- Key results are quantitative, measurable outcomes (not tasks or a to-do list) that describe the impact you will have in reaching your objective.
- In an ideal world, your objective and key results should directly ladder up to a business level OKR and be agreed upon with both your team and key stakeholders.
Phase 2. Product Management: Continuous Product Discovery
Once you have defined success and have agreed-upon outcomes, the next step in the product management process is product discovery. There are several parts to this and the goal is to arrive at a validated solution that you have confidence will help you achieve your success metrics and deliver value for your customers. Each part can be tackled separately or there are other processes such as the Design Sprint which can help you cycle through the stages at speed.
Product discovery doesn’t have to include the entire team but it should include a Product Manager, Product Designer/UX Designer, and a Lead Engineer at a minimum. It’s worth noting that Phase 2 never really ends, it’s a continuous cycle of product discovery that feeds Phase 3, Continuous Product Delivery.
Part 1 – Opportunity stage
The first thing to consider during the opportunity stage is: What problem should we be solving? You can answer this by using data analysis to pinpoint problem areas in your users’ journeys. This might take the form of exploratory qualitative methods like depth interviews or ethnography to understand existing behaviors, uncover problems, and get at the “why?” behind what users are doing. You can also use surveys to further validate behaviors and problems that have been uncovered.
Part 2 – Solutions stage
Once you have identified a problem worth solving for your customers you can move onto ideation and potential solutions with the aim of finding the best way to solve it. There are 2 parts to this: ideation and prototyping. Ideation can be done as a team and including key stakeholders can help them to feel involved in the process. The goal of ideation is to go wide and explore multiple solutions to the problem at hand.
Once you have agreed on which ideas to take forward, you can create low-fidelity throwaway prototypes that bring propositions to life without the need for the full design. There might be specific assumptions or hypotheses that you want to test as part of this, which can be conceptualized in your prototypes and tested with your target customer to help you start to build confidence in the most valuable ideas to pursue.
Part 3 – Live testing stage
Testing prototypes with a small group of target customers is useful for getting a steer on direction, but once you’ve done that you will need to scale up your testing to see if there is demand for your idea.
Defining a baseline and success metric and using 404 or landing page tests are good ways to capture this information without the need for engineering the entire solution.
Once you have confidence in your ideas, you can do further live testing in the form of lightweight A/B or multivariate testing, again with relevant baselines and success metrics.
Part 4 – Design, feasibility, and viability stage
Once you have your solution(s) to take forward, it’s time to start thinking about how you should design and build the solution. At this point, you can still use high fidelity prototypes that test a UI, as well as conducting usability testing to ensure that your potential customers are able to figure out how to use your product. You can also extend this to a wider audience as a beta test to take in further feedback on your product before full delivery.
As your product is starting to take shape and you move towards the build stage it’s important to assess the business viability (including pricing) of your potential solution and you should be consulting with your Legal, Sales and Marketing teams, as well as any other relevant stakeholders.
Phase 3. Product Management: Continuous Product Delivery
When you have successfully validated your solution you can move on to delivering it in collaboration with your Product Designers and Engineers. As a Product Manager, you will be working with your team to define and shape the necessary work.
Ideally, you will identify iterative releases of your solution with the aim of releasing a first version that has impact, value and helps you meet your success criteria from phase 1.
Again, it’s worth noting that Product Delivery isn’t a one-time exercise, it’s something that happens continually and is powered by the validated work coming from the Continuous Product Discovery cycle.
Part 1 – Build stage
This stage is all about defining the work to be done with your Product Designers and Engineers. You may work with a tool like Jira to write up tickets that cover things like the acceptance criteria for the work, how it will be tested, a description of what needs to be developed and any relevant designs.
This part of the process is still highly collaborative with the team discussing feasibility and demoing work to ensure that things are going in the right direction.
Part 2 – Launch stage
Before launching any new product it’s important to ensure that you have communicated it to any key stakeholders – this might include your Customer Services team (so that they can inform you of any customer feedback) and Marketing, who may plan specific activities around the launch.
When you’re ready to press the button try and avoid releasing on a Friday (unless you’re prepared to work over the weekend!) as things inevitably go wrong when you’re not around.
Launching a new product or solution is always a good moment for team celebration – time to grab a virtual cake or pizza!
Part 3 – Monitoring stage
Once the first version of your product is out in the wild it’s important to monitor your data over time – everything from customer feedback to quantitative data to ensure that you’re on track to meet your success metrics as well as keeping any regular health metrics steady and unimpacted by your work.
If things go awry you can iterate on the fly or return to do further product discovery if it’s not clear why your solution isn’t having the desired effect. If things go well during monitoring then you should continue to build on the initial version to continue adding value over time.
Product Management Process: Methodology
Over the past 50 years, we have seen the rise and fall of several different product management process methodologies. There have been many changes due to the proliferation of new technologies. Let’s take a look at the most prominent ones, starting with the most recent:
Dual Track Agile
Sometimes referred to as continuous discovery and delivery, Dual Track Agile has been popularised in recent years by product gurus such as Marty Cagan and Teresa Torres. Marty Cagan and Jeff Patton originally coined the phrase after reading a paper on Adapting Usability Investigations for Agile User-Centred Design around 2012.
In Dual Track Agile there are two “tracks” of work – one where your team is figuring out what the right thing to build is (product discovery) and one where they are actually building it (product delivery).
In today’s world, we are in the fortunate position of being able to release software on a continuous basis – this means we can continually discover what we should be releasing and neither track ever ends.
You don’t need your whole product team to be involved in the product discovery track but it does work better as a collaborative process between Product, Product Design / UX, and a Lead Engineer at a minimum. It also requires a balance of the self-empowered team and stakeholder input to work well.
Lean
In 2011 Eric Ries published his infamous book, Lean Start-Up, advocating for customer-focussed discovery and experimentation. While the focus of this work was on start-ups, the concepts Ries talks about were adopted throughout the world of product development.
The methodology focuses heavily on the importance of product discovery – in particular customer research in the form of direct interviews, identifying a minimum viable product followed by quick testing and iterations to minimize waste in the development process.
Ries also popularised a concept called the “Five Whys” – a technique used to find the underlying causes or roots of a customer problem.
Agile Product Development
Back in 2001, around the time of the dot-com boom, 17 software developers defined the Manifesto for Agile Software Development. Old Waterfall ways of working were no longer fit for purpose in a world where market conditions were rapidly changing and so agile product development was born.
There are 12 agile principles in total and in combination, they guide teams to increase responsiveness to change, productivity and efficiency:
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective and adjusts accordingly
In practice, these principles mean leveraging self-organizing teams to address challenges, breaking down larger work into smaller chunks, delivering continuous value to the customer, and face-to-face collaboration as opposed to the detailed requirements documents of the Waterfall process, among other things.
Waterfall
Originally dating back to the 1970s, the Waterfall methodology is now widely viewed as outdated by many businesses. Winston W Royce’s paper on Managing the Development of Large Software Systems is widely believed to have been mistakenly interpreted at the time, resulting in the Waterfall model!
Some of the phases of product development that we are familiar with today are part of the Waterfall methodology such as design and build, however, the framework suffers from a “top-down” set-up often starting with a single idea backed up by a business case, followed in sequence by a roadmap, requirements, design, build, test and release in one big bang.
This way of working results in a lack of collaboration with no room for experimentation to find the best solution or iteration over time. It also vastly increased the risk of delivering products that have no value or impact.
Product Roadmap
At its heart, a roadmap is a plan that details the strategic goals, outcomes, and themes for a product team across several quarters. It also functions as a tool to communicate with stakeholders with the goal of articulating the “why” behind the proposed plan.
Traditional roadmaps that define which features will be delivered and by when are a bit of a hangover from the era of Waterfall, although some companies still use these.
Modern product development teams need to strike a balance between communicating to their teams and stakeholders what’s coming next versus locking themselves into hard deadlines and deliverables, especially when we consider the role of product discovery.
Teams can achieve this by keeping roadmaps simple and high-level.
Product Management Process: From MVP to MMR
Product management is all about taking an experimental approach and making releases on an iterative basis. There are several parts to this, starting with a Minimum Viable Product and cycling through to incremental releases of value by Minimum Business Increments.
MVP stands for Minimum Viable Product – it normally refers to a new product or service and centers around the testing of a hypothesis with the aim of identifying what customers find valuable. Initially, it takes the form of a lightweight, throwaway prototype that can be tested with potential customers.
MBI stands for Minimum Business Increment – it describes the smallest, releasable chunk of value targeted at a particular market segment and is informed by the MVP.
Also informed by the MVP, the MRF or Minimum Releasable Feature is the smallest feature that fits into an MVP or MBI. This is a complete and functioning feature in its own right that delivers customer value and can be released as a standalone item. It is also sometimes referred to as a Minimum Marketable Feature or MMF.
Finally, there is the MMR or Minimum Marketable Release. This is a collection of one or more MBIs – sometimes known as a Minimum Marketable Product or MMP.
Product Management Process: Best Tools List
As a Product Manager, you have a myriad of tools at your disposal to help you succeed throughout the product management lifecycle. Here are some of the most popular tools that can help you get the job done:
- Capturing customer feedback, messaging – Typeform, Google Forms, Intercom, Uservoice, Usertesting
- Onboarding – Pendo, Simpo
- Ideation and brainstorming – Miro, Lucidchart
- Workshopping – Mural
- Prototyping, product requirements – Marvel, InVision, Figma, Balsamiq
- Multivariate testing – Google Optimise, Optimizely, AB Tasty
- Presenting – Google Slides, Keynote, Powerpoint
- Communication and collaboration – Slack, Zoom
- Roadmapping, prioritization & backlog management- Product Plan, Roadmunk, Productboard, Craft
- Data and insights – Google Analytics, Mixpanel, Amplitude, Logi Analytics, Gainsight
- Product delivery – Jira, Trello
Wrapping up
In conclusion, there are many benefits to having a high-functioning product management process that practices continuous product discovery and delivery. As a Product Manager there are lots of things to consider, learn and do as your role is always evolving, as well as the products! We hope you have found this article useful – let us know how you get on.
