A primer on Product Planning & Delivery
Everything you need to know to become a great product manager
You have your vision and strategy in place and have worked your way through establishing key Product-Market fit hypotheses.
Now, it’s time to turn those validated hypotheses into values for customers.
In this article, we will see how the product planning and delivery take place. We will cover the following topics -
Product Roadmap
Product Requirement Document
Product Delivery
Validated learning
Let’s dive in👍
Product Roadmap
Many organizations create a product roadmap for product planning and share it with their internal teams and customers.
Product Roadmap can be considered as a charter that defines what will get build and when. There is no hard and fast rule on the timeline and duration of a roadmap. It could be yearly, semi-annually, or quarterly - depends on the organization's context and culture.
Before discussing further, here is a sample roadmap -
A roadmap helps set up the vision for the team up front. It’s a great way to communicate the vision and goals with the internal and external stakeholders. It helps in making the teams aligned with a common goal.
However, one common pitfall to avoid while using a Product Roadmap is making it too detailed - making it a laundry list of features.
Marty Cagan explains -
The issue is anytime you put a list of ideas on a document entitled “Roadmap”, no matter how many disclaimers you put on it, people across the company will interpret the items as commitment.
-Marty Cagan
Businesses are usually not static. The goals and priorities change quite often. So does the Roadmap. When you make a too detailed roadmap and share it with various stakeholders, it often becomes challenging to reclarify the change when the roadmap changes due to the changing priorities.
One solution to this problem is to make the product roadmaps intentionally vague, and that’s an art a PM has to learn. The roadmap should communicate the vision and plan but should not be too detailed.
Product roadmaps should be very simple and high-level. They should reflect your current thoughts on which objectives are the most important. Is it taking the product international? Supporting mobile devices? Supporting additional personas? Addressing key usability issues? The roadmap is not intended to be a spec, and it¹s not a laundry list of features.
-Marty Cagan
Product Requirement Document
The most common tool a PM uses to communicate the requirements to the team is the Product Requirement Document.
A PRD captures what feature would be built and why; it defines the goal, scope, risk, and success criteria.
Here are the various elements of a sample PRD -
Title: Give this project a distinct name.
Change history: Provide a description of each important change to the PRD, including who changed it, when, and in what specific way.
Overview: Briefly, what is this project about? Why are you doing it?
Objectives: What will this let the customer do? What are our high level internal goals for doing this project?
Success metrics: What are the success metrics that indicate you’re achieving your internal goals for the project?
Messaging: What’s the product messaging marketing will use to describe this product to customers, both new and existing?
Timeline/release planning: What’s the overall schedule you’re working towards?
Personas: Who are the target personas for this product, and which is the key persona?
User scenarios: These are full stories about how various personas will use the product in context.
Requirements/features in: These are the distinct, prioritized features along with a short explanation as to why the features are important.
Features out: What have you explicitly decided not to do and why?
Designs: Include any needed early sketches, and link to the actual designs once they’re available.
Open issues: What factors do you still need to figure out?
Q&A: What are common questions about the product, and answers to those questions?. This is a good place to note key decisions.
Other considerations: This is a catch-all for anything else, such as if you make a key decision to remove or add to the project’s scope.
Product Delivery
In the next step, the requirement usually goes through the build phase. The designers and engineering team takes precedence and work their way through the build phase to deliver the feature.
Credits - https://productcoalition.com/
Often product features are released in multiple iterations. Very few features become perfect from day 1. Depending on the context, a product team decides the types of product release they want to pursue -
Alpha Release - This is the release when the feature which you are developing is incomplete or partially complete. Suppose you have developed the seat selection in a Ticket booking system, but the payment implementation is not yet done. In this case, you can release it to testers to test the initial phase of a feature. A lot of Open source products do their Alpha release.
Beta Release - This release is done when the product feature is complete and all the development is done, but there are possibilities that it could contain some bugs and performance issues. This release is mostly done to users who test the product and who can report the bugs. Even UAT (User Acceptance Testing) phase could be considered as a Beta release.
General Availablity - This is when you make a feature generally available for customers, and often this falls under the product’s maintenance contract. Any issues faced by users on this feature to be supported by the maintenance team.
Credits - https://productcoalition.com/
Build - Measure - Learn
Last but not least, we need to understand that the product planning and delivery works in an iterative manner. In The Lean Startup, Eric Ries introduces a concept called the validated learning through the Build-Measure- learn feedback loop. He says it’s important to measure the impact of the feature built and then learn from the data and build your next opportunity hypothesis based on that. It’s a continuous iteration process till the startup reaches the Product-Market-Fit. For a startup, the success depends on its efficiency to optimize the validated learning through the build-measure-learn feedback loop.
The measurement is usually done by creating success metrics for the product. Check this post to understand more about product success metrics.
To wrap this up, a PM plans for the features and priorities in the Product Planning stage. A product roadmap is typically a tool used for this. A roadmap defines what will be built and when.
The product requirement document captures the detailed requirement and is a great tool to communicate the design and delivery teams' requirements.
Once some features are built, product teams, including a PM, consider releasing the feature - Alpha, Beta, or GA.
It’s imperative to measure the impact of any feature that goes to the customers; an objective measurement enables a PM to understand what’s working and what's not and build the next opportunity hypothesis from that.
Sincerely,
Arkapravo
That’s all for this post. If you wish to read more, here are some of my other posts -
To receive more such articles in your email, consider subscribing. 👇
Click here to learn more about the Product Hub Newsletter.
Reference -