Product Opportunity and Idea templates for modern Product Managers
How do you know what to build? The answer to this question, like many others in the Product Manager world, is “it depends.” Knowing what to build starts with preparing to plan what to build. This sounds like pre-planning, which sucks the life out of a software delivery team, so lately I’ve been working on a few tools that help you prepare to plan without even knowing that you’re doing it. Planning is a practice that is unique to your organization’s needs, how fast your market moves, and who’s on the team doing the work. If the team doing the work understands how work is identified and prioritized, they’ll be armed with the autonomy to make decisions which helps them move faster.
These are tools that have helped my team move fast while navigating dependencies, competing priorities, and changing market and business dynamics. What I love about them is that it puts the team in the driver’s seat, maximizing communication across organizations, and focuses on understanding customer pain points and problems to be solved.
Two planning tools to live by:
The first is the Product Idea Template. It’s a document that can be used to collect ideas that need to be flushed out more at a later date. This is basically the whiteboard approach. Sometimes teams get wrapped up in the details of an idea and this can cause some level of decision paralysis. The Product Idea Template gives the team a place to write the idea down with some additional questions, and put that idea somewhere so that they can focus on it later. It gives teams permission to move forward without knowing all the answers.
The second is the Product Opportunity Template. This document is meatier, more robust. It’s used to collect data, customer conversations, problems to be solved, jobs to be done, and where to get more information. A collection of these documents can be prioritized to build a product roadmap or direction, and can be used by the delivery team to help form a project kickoff.
How I use these documents:
Don’t let your customer research sit in a notes document. Product teams that work to understand their customers are always in the field listening and talking to users, demoing ideas, researching opportunities, pain points, etc…