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.<\/p>\n
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:<\/p>\n
1. You want to ensure you are building and delivering products that are valuable, useable, feasible, and business viable:<\/p>\n
2. To stop delivering products that don\u2019t fulfill all of the above – launching products without solid validation increases your risk of:<\/p>\n
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\u2019re heading, developing a valuable product will be very challenging!<\/p>\n
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.<\/p>\n
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.<\/p>\n
What are OKRs?<\/strong><\/p>\n Let\u2019s break it down a bit:<\/p>\n 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.<\/p>\n Product discovery doesn\u2019t 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\u2019s worth noting that Phase 2 never really ends, it\u2019s a continuous cycle of product discovery that feeds Phase 3, Continuous Product Delivery.<\/p>\n Part 1 – Opportunity stage<\/strong><\/p>\n 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\u2019 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 \u201cwhy?\u201d behind what users are doing. You can also use surveys to further validate behaviors and problems that have been uncovered.<\/p>\n Part 2 – Solutions stage<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n Part 3 – Live testing stage<\/strong><\/p>\n Testing prototypes with a small group of target customers is useful for getting a steer on direction, but once you\u2019ve done that you will need to scale up your testing to see if there is demand for your idea.<\/p>\n 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.<\/p>\n 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.<\/p>\n Part 4 – Design, feasibility, and viability stage<\/strong><\/p>\n Once you have your solution(s) to take forward, it\u2019s 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.<\/p>\n As your product is starting to take shape and you move towards the build stage it\u2019s 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.<\/p>\n 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. Again, it\u2019s worth noting that Product Delivery isn\u2019t a one-time exercise, it\u2019s something that happens continually and is powered by the validated work coming from the Continuous Product Discovery cycle.<\/p>\n Part 1 – Build stage<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n Part 2 – Launch stage<\/strong><\/p>\n Before launching any new product it\u2019s 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.<\/p>\n When you\u2019re ready to press the button try and avoid releasing on a Friday (unless you\u2019re prepared to work over the weekend!) as things inevitably go wrong when you\u2019re not around.<\/p>\n Launching a new product or solution is always a good moment for team celebration – time to grab a virtual cake or pizza!<\/p>\n Part 3 – Monitoring stage<\/strong><\/p>\n Once the first version of your product is out in the wild it\u2019s important to monitor your data over time – everything from customer feedback to quantitative data to ensure that you\u2019re on track to meet your success metrics as well as keeping any regular health metrics steady and unimpacted by your work.<\/p>\n If things go awry you can iterate on the fly or return to do further product discovery if it\u2019s not clear why your solution isn\u2019t 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.<\/p>\n 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\u2019s take a look at the most prominent ones, starting with the most recent:<\/p>\n Dual Track Agile<\/strong><\/p>\n 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.<\/p>\n In Dual Track Agile there are two \u201ctracks\u201d 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).<\/p>\n In today\u2019s 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.<\/p>\n You don\u2019t 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.<\/p>\n Lean<\/strong><\/p>\n In 2011 Eric Ries published his infamous book, Lean Start-Up, \u00a0advocating 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.<\/p>\n 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.<\/p>\n Ries also popularised a concept called the \u201cFive Whys\u201d – a technique used to find the underlying causes or roots of a customer problem.<\/p>\n Agile Product Development<\/strong><\/p>\n 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.<\/p>\n There are 12 agile principles in total and in combination, they guide teams to increase responsiveness to change, productivity and efficiency:<\/p>\n 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.<\/p>\n Waterfall<\/strong><\/p>\n Originally dating back to the 1970s, the Waterfall methodology is now widely viewed as outdated by many businesses. Winston W Royce\u2019s 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!<\/p>\n 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 \u201ctop-down\u201d 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.<\/p>\n 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.<\/p>\n 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 \u201cwhy\u201d behind the proposed plan.<\/p>\n 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.<\/p>\n Modern product development\u00a0teams need to strike a balance between communicating to their teams and stakeholders what\u2019s coming next versus locking themselves into hard deadlines and deliverables, especially when we consider the role of product discovery.<\/p>\n Teams can achieve this by keeping roadmaps simple and high-level.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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:<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":17,"featured_media":17484,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"inline_featured_image":false,"footnotes":""},"categories":[372],"tags":[],"yoast_head":"\n\n
Phase 2. Product Management: Continuous Product Discovery<\/h3>\n
<\/h3>\n
Phase 3. Product Management: Continuous Product Delivery<\/h3>\n
\nIdeally, 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.<\/p>\n<\/h2>\n
Product Management Process: Methodology<\/h2>\n
\n
Product\u00a0Roadmap<\/h2>\n
<\/h2>\n
Product Management Process: From MVP to MMR<\/h2>\n
<\/h2>\n
Product Management Process: Best Tools List<\/h2>\n
\n
<\/h2>\n
Wrapping up<\/h2>\n