What goes into building a great product? Simple solutions to real problems. Great products focus on customers. They are intuitive. No instruction manual needed. Great products also help the business. They simplify operations. Make customer support easy.

How do PMs build a great product? Vision. Strategy. Buy-in. Execution. I’ve had my fair share of failures as a product manager. Here’s a line-of-sight framework to building products that I’ve developed through a lot of trial and error.

Build great products through vision, strategy, buy-in, and execution.

It starts with a vision

Imagine for a second that you were looking at a map. It’s easy to figure out where you are. Now you need to go somewhere. How do you start? What direction should you walk? Are you walking to a car or train that will let you speed up? How do you make sure you accelerate in the right direction? It’s simple. You choose a destination. A goal. A vision of where you want to be. In the software world, the product vision is the destination.

There is no single template for product vision. It should provide focus, motivation, and alignment. It’s the company’s north star. The founder, CEO, or CPO is responsible for creating the vision — but everyone owns it.

A roadmap is the product strategy

It’s easier to view the roadmap as a product strategy — the things product teams are doing to realize the product vision. Think back to the map example. There is always more than one way to get to a destination. Depending on traffic, construction, and the number of left turns the route alters. Business needs will fluctuate. Market conditions will change. The product strategy is flexible. It can adapt to change while continuing to move toward the product vision.

Product strategy is easy to organize using a Kanban-style feature board

 

We organize product strategy into phases. Movement between phases is flexible and allows for course corrections. Here are the phases to use in reverse-order:

• Released: Customers can use the feature. It’s released. It’s in the wild. PMs are collecting information about how customers are using it so we can iterate.
• Build: The feature is in active development or testing. Some parts of the feature may be in beta or behind a feature flag.
• Ready to Build: PMs know what to build and are awaiting engineering capacity.
• Design: The feature is being designed based on team input and what the customer needs.
• Research: PMs understand the opportunity the feature presents. Product teams are defining the demand, cost, and feasibility of a new feature.
• On Deck: The feature is something that should be part of the product strategy. This is the first step toward being more than an idea.
• Backlog: Ideas. Dreams. New stuff. It all goes into the product backlog. The best way to have a good idea is to have lots of ideas.

PMs avoid several pitfalls when the roadmap is reframed as product strategy:

• Pitfall 1: PMs will forecast what to build in this quarter, the next, and a couple more after that. The reality? Any estimate is, by definition, inaccurate. It’s hard to forecast what to build beyond 6–8 weeks out. Anything further is our best guess according to current conditions.
• Pitfall 2: Roadmaps are a “finalized” list of features. It’s the opposite. Agile is all about managing risk. It allows for adaptation based on measurement and learning. This means PMs may change directions if needed. Using a waterfall approach for the roadmap renders agile useless.

Those are the mechanics of product strategy — how PMs turn an idea into a released feature. Let’s examine how PMs generate ideas.

Ideas are generated from discovery and feedback

There are two primary ways to get ideas on what to build. Through product discovery and product feedback.

In the discovery process, PMs are on a mission to define the problem their product will solve. They do this by talking to customers. Interviews provide anecdotes that help us understand what the product needs to do. Product teams (PM + UX + Engineering) take the lead. The discovery process helps us understand the need and feasibility of features. PMs use a variety of experiments to understand features that solve problems and those that don’t. They treat everyone as a customer — including the rest of the business. Product managers need to understand their problems too.

Quantitative and qualitative feedback helps identify gaps in the existing product. Customer-facing teams are the primary collector of feedback. The product teams use this input to pick high-impact features that address one or more gaps.

Ideas are the fuel for the product strategy. Each idea should move the product closer to the vision. PMs build the feature backlog using this input.

Getting buy-in

Once the PM has an initial strategy mapped out they need buy-in from the rest of the business. They work with a couple of different groups to make that happen.

The top-level organization structure is the Leadership Team. This team includes senior product development leaders and key customer-facing leaders. They guide the product strategy. They provide product teams with the proper guidance on what to focus on at a high level. This is a key input for setting product-level goals and KPIs.

Product Advisory Teams ensure the product strategy focuses on the right things. The PAT members come from customer-facing teams. Product managers collaborate with the PAT to communicate:

• New features that are available to customers.
• Features that are in development.
• Features planned for upcoming development.
• Medium-term product strategy.
• The priority of burning issues or critical bugs escalated by the PAT.

PATs provide a great deal of depth to each feature by providing their department’s point of view. The PAT ensures alignment between departmental objectives, product vision, and product strategy. PMs make adjustments to the strategy based on their input.

Product development teams execute the product strategy

Once the teams align on what needs to get done the product managers break things down. They create epics and user stories* that go in the product backlog. The product backlog* is the list of all the work that needs to get done. It usually contains user stories, bugs, technical tasks, and knowledge acquisition. The PM and engineering team refine the backlog every week. They aim to define two to three sprints worth of work is always defined and prioritized. After every iteration, we revisit the product strategy and start planning the next feature.