The Product Paradox
The Product Paradox is the opposing forces of trying to have a simple strategy and the complexities of the details of implementing the product.
Peter Mullen from Envoy talks to Product Podcast hosted by Product School about how to develop a strategic product roadmap. From working in product management, I found going from product strategy to the ‘doing’ of the development that was shown transparently was a challenge, I couldn’t find anything that gave me a structure on how to do that. Listening to the podcast with Peter Mullen gave me a lot of inspiration, so I listened to his ideas and build on them to develop a process and am sharing it with you. It may help give you guidance that you can adapt based on your needs.
There is a template you can use on Miro here part of the Miroverse.
Overview of the product development process
Before we go into the product process, there are:
Discovery for understanding the problem space
Ideation to create potential solution ideas
Prototyping to generate low-cost representations of the ideas
Requirements for design for users and technical
Build/develop the product
Testing to validate the technical implementation, viability of the business model and product-market fit to identify desirability from users and customers. From a software perspective, this may also include alpha and beta testing.
Launch into the market through relevant routes to market strategies
Stable release
Release Candidate (aka gamma/delta)
Release to Manufacturing (aka release to marketing)
Progressive roll-out (~1%) or general availability (100%)
Production/live release aka Gold (end-of-life support)
For further developments to iterate and continuously improve the product, post-launch the following stages are:
Requests: Request for new features or changes to existing functions
Plan: The release's structure is defined and a plan is outlined to stay on track
Design and build: Developers implement updates and changes.
Testing: Deployed to testing environment for non-functional and functional testing. Bugs found and developers address.
Deployment: Release is implemented in the live environment and made available to users. Updating users of changes and new features.
Post-development: Release moves to the support phase where bugs are recorded and requests are made for changes in a product backlog
With that context in mind, let’s get into the steps from product strategy to backlog.
Overview of the steps from vision to doing
Product Vision: What is the vision and strategy for the product? This can be outlined using a variety of product strategy canvases such as Pawel Huryn’s. The product strategy must align with the company’s strategy. To have a clear problem outline, you could use problem statements and How Might We questions.
Challenge: The next phase is outlining who has the challenge in more depth than what is in the canvas by using personas and answering the questions: What are the key customer pain points and opportunities we are trying to solve? What value are we trying to deliver to our customers? E.G. 50% reduction in time taken for X.
Setting SMART objectives: what value are we trying to deliver to our customers? e.g. 50% reduction in time taken for X. These are Specific, Measurable, Attainable, Relevant and Time-bound.
Capabilities and Features: The objectives can be broken down into features, and user stories, each with its own value and what it entails. To ensure it is customer-focused, to bring in the user journey mapping tool to consider the customer goals and what value the customer is looking for from the solution.
Initiatives: These are bodies of work that are set to reach the product strategy. What initiatives will help me achieve that goal? What features will we logically release together to deliver incremental value to the customer? What are our priorities?
Scope: A one-pager can be created for each initiative: problem, opportunities, who it’s for, success metrics, risks, assumptions, and open questions, should be SMART for every initiative.
Prioritisation: Features are evaluated based on value and effort to decide what is the priority. P0 is ‘Must Do’ to achieve the goal of the initiative; P1 is ‘Should Do’ where users want it but could do without it, P2 is ‘May Do’ which is nice to have if have the time and maybe risky/time-consuming. Priorities initiatives against each other and determine which will help reach the goal. Initiatives, features and priorities are outlined to show what the work looks like. Estimate impact/effort with engineering/dev to get a sense of workload and to see which is more valuable.
Can use other things to prioritise and ensure alignment to vision/goals with ROI consideration, e.g. RICE framework: value vs effort, KANU framework and story mapping. Impact vs effort with different quadrants. You can also apply to initiatives or features and this can be automated.
Timeline: Build out a timeline to know when the MVP will be launched, so it’s important to plan and forecast the launch or a different version through an MLP, Minimum Loveable Product, and when the team will deliver different features and initiatives. Then, look at all initiatives and see how many initiatives you can do together. The schedule should be vetted by devs/engineering and shouldn’t be shared externally.
Epics and Tasks: How will we organise work for each initiative? These can be organised by initiative into epics with tasks or stories assigned to each epic.
Product roadmap: To provide an overview of what initiatives are happening now, next and in the future can be represented on a roadmap to answer the question: When will we deliver our releases to our customers now and in the future? The roadmap is presented internally as things can change and don’t want to misrepresent timelines.
Organise tasks and progress: To organise the tasks and progress made, could be shown on a Kanban board such as on Trello or Notion, or in more detail on software such as Jira.
Measure results against the product goals: To hold people accountable, use the right instrument built into the roadmap such as KPIs and OKRs that align with North Star metric. Get results from the right user segment and consider other aspects such as acquisition, referral and revenue to drive transparency and review results with wider teams.
Iterate and improve: The roadmap will evolve and should be assessed monthly, whereas startups could be more frequent and perhaps weekly. Take into account user feedback as customers should be giving feedback or researching qualitative/quantitative feedback on vision and initiatives to always validate problems and solutions at every stage. Release early and often to get in front of customers, review results from product analytics, get customer feedback through calls and leverage the customer success team/sales team. Perhaps set up a beta programme as this has a lot of value in capturing bugs and user feedback before a wider release. Analyse customer feedback to find areas of improvement with fast feedback, then follow-through with iterations.
The Miro board
The Miro board brings together the templates available to help provide you with the tools to complete the stages from product strategy and vision through to the ‘doing’ of the work, and measuring results to iterate and improve the product.
You can access the Miro board here.
Make Products That Matter
If you’d like to learn more about product development from idea to post-launch, check out my book ‘Make Products That Matter’ on Amazon, available in the UK, EU and US.
