- Agile Product Development
- Agile Sprint
- Continuous Discovery
- Beta Test
- Customer Feedback
- Definition of Done
- Design Sprint
- Feature Flag
- Goal Question Metric Approach
- Lean Experimentation
- MVP (Minimum Viable Product)
- Objectives and Key Results (OKRs)
- Product Line
- Product Manager
- Product Owner
- Product Requirements Document
- Product Vision
- Product Strategy
- User Personas
- User Testing
- Value Proposition
Agile product development is a methodology that encourages product teams to focus on solving user problems in an iterative way, rather that the traditional waterfall methodology.
An agile sprint is a short period with concentrated effort to complete certain predetermined goals, with those goals often taking the form of a new, changed or removed feature within the product being developed.
Continuous discovery is the process of constantly experimenting, learning and applying what you learn. This kind of discovery helps inform product development decisions. It focuses on what you will be building next with an emphasis on constant feedback and iteration based on that feedback.
The backlog is a list of items your team may have decided to work on. In product management, it is often recommended that you break this up into a list of potential opportunities (the product backlog) and items already assessed and reviewed, ready to be worked on (the development backlog)
Beta testing is when you allow a user to try a new product or feature in the early stages of development, before it is formally released to the market or user base.
A beta test provides a minimum risk test of some software, website, or other digital product. The general idea is to find out more about the product before release by allowing users to access it and then collecting user feedback from them.
As a product manager, you constantly receive suggestions from your team and customers about possible improvements for the product. It’s important that you don’t take these as mandates for things you must do, but rather as an opportunity to understand what your users might be struggling with. This is why we recommend you refer to these suggestions as just “feedback” or “customer feedback” (depending on the audience giving you these nuggets.) The terms “customer request” or “feedback request” imply you are requested to build whatever the suggestion might be and add unnecessary pressure. This is where you will be exercising your ability to say no, but nicely.
Development teams often talk about the “definition of done”. It’s the term they use to describe when a piece of work is complete. It usually includes criteria like unit tests, documentation, and whatever sort of integration work that needs to happen to essentially dot all their i’s and cross all their t’s.
A design sprint is a process that helps answer business questions through design, prototyping and user testing. It is a way to quickly validate if the ideas you are considering are worth moving forward, and if so, how and what that might look like. For more details, check out GV’s Design Sprint homepage.
A feature flag is the ability to turn features on and off in an application so that product teams can experiment and learn. Product teams can use feature flags to decide whether a feature is available for their users – either all users, a proportion of users or no users. It’s a way of launching a new feature in a controlled way, in order to learn whether it works correctly “in the wild” – i.e. it is valuable and useful for the user base.
The Goal Question Metric approach, or “GQM”, is an approach to software metrics that improves and measures the quality of software.
Product management initiatives represent a key part of your theme based product roadmap. An initiative represents a broad piece of work that you wish to undertake, and can be expressed as a problem to solve.
Product management is all about ensuring your product solves your customer’s real-world problem. Experimentation enables teams to take an MVP and build on it, learning and prototyping as they go.
An MVP is the barest, most minimal version of your product that is functional enough to attract early adopters. While an MVP can show value at its early stage for first adopters, the greatest benefit of building an MVP is to learn what works, and what doesn’t (also known as lean experimentation!). Create a feedback loop and iterate on your MVP to turn it into a product that delights your customers and grows your business.
Objectives and Key Results (OKRs) are objectives that, if achieved, will bring measurable improvements to your product, service, company or organization. Each objective is divided into key results which make it easier for teams to assess their progress as they attempt to achieve their objective.
Your roadmap initiatives will focus around wanting to achieve a certain objective or goal. As you wrap up these initiatives, it’s important to look back and do a retrospective on your work. These are your outcomes.
Outcomes are about understanding and learning from the process, and seeing how you can apply what you’ve learned to improve your work in other initiatives. It’s advised that you focus on impacting positive outcomes for your users, as this will then lead to positive business outcomes such as increased revenue and adoption.
By having a roadmap that focuses on objectives and outcomes, you place emphasis on building a product that constantly learns and improves from customer needs, rather than just putting out new features simply to satisfy demand without any particular purpose.
Your portfolio is made up of all of the products and product lines your company offers. Whether you have a single product or a variety of them, they’re all still part of your overall portfolio.
Often a portfolio will also require a single roadmap view. That is, a roll up of all products and product line roadmaps into a single document known as the portfolio roadmap. This enables teams to understand cross-functional work and strategy across the entire portfolio level.
A product is any component that requires a vision, strategy, objectives, and a set of outcomes for a team to reach. This could be an actual software of physical product your company offers, or can even be a team that is treated as a product in order to keep strategy in place.
A product line is a group of products that make up a section of your overall portfolio. These products are marketed under the same brand name for the company.
As an example, your company may have multiple product lines such as computers, tablets and software, which all contribute to the portfolio of products the company may offer.
Often a product line will also be made up of multiple roadmaps, one for each part of the products that may require a separate strategic document. The product line will roll up these multiple roadmaps into a single document known as the product line roadmap. This enables teams to understand cross-functional work and strategy across the product line.
The job of a product manager is to discover market problems, and then define what should be built within their product to solve these problems. Their goal is to improve outcomes for the people who use their product. They must identify those ideas that should provide value for the business, and then help the rest of the business to turn those ideas into reality.
Being a product manager revolves around setting strategy and managing the discovery side of the product development process. The specific roles and responsibilities will change based on the growth stage of the product and company itself. For example, you might start out with a junior product management role and eventually evolve into leading a team. Or, for those that are part of a scrum environment, you might instead be a product owner.
Product Owner is a role you play on a scrum team. Product manager is the job.Melissa Perri
For more on the history of the product manager role, check out Martin Eriksson’s blog post.
Product Requirements Document
A product requirements document or PRD is an artefact used to define, in great detail, exactly how a new feature should work. In theory, the PRD introduces certainty and definition which makes it easier to build a solution.
The problem with PRDs is that they can be too prescriptive, and restrict the ability of a product team to fully understand a problem and iterate to a good solution. Working to a level of detail that’s too deep can result in a very well spec’d out feature that just doesn’t solve the problem it’s meant to solve.
Rather than focusing on defining a solution, it’s more valuable to start small, build an MVP, learn from its usage and iterate from there. Say goodbye to the PRD 👋!
Your company’s product vision is the overall idea of what the organization should be and do, and how it fits within the market as a unique offering. Often set out by the founders, it will include the company’s core values and mission.
Your product strategy is the path you will take to achieve your vision. Your strategy will often outline things like what your target audience is, what your objectives are, and even what marketing channels you will be focusing on. The information in your strategy informs your roadmap, which lays out the problems you’re aiming to solve as you move towards your product vision.
Some well known documents to help outline your strategy and vision are:
ProdPad provides you with two similar documents. The portfolio and the product canvas are a combination of the three canvases listed above, focused on ensuring you have all the information needed to outline a killer strategy, with added flexibility and customization.
Requirements are a set of documents and processes needed to move an idea forward. It usually involves running discovery, analysis, and validation of an idea – then distilling that into specs that will help your development team execute it accordingly.
The roadmap is, above all, a communication tool. It is used to describe what you are working on, why you are working on it, and what the benefits of this work are. ProdPad CEO and Co-founder Janna Bastow likes to describe the roadmap as a “prototype for your strategy” – and ProdPad is the home of the Now Next Later roadmap!
User personas are fictional representations of your test users that help your team to understand and empathize with the user for whom they’re building the product.
User Testing is part of the continuous delivery and design sprint processes. It involves evaluating products, prototypes and mockups to real users. This helps you validate things are moving in the right direction.
Your company’s value proposition is part of your overall strategy. It outlines the value which will be experienced by your market, and the unique way in which you solve their problems.