product strategy – Product First

A roadmap is a tactical plan for executing your business strategy. The roadmap should clearly communicate how you will build products that deliver predictable business impact.

Note that I’m saying “how you will,” not “how you can.” There are infinite things you can build. But a good roadmap, and a good product team, will focus on the most impactful opportunities. These opportunities solve a significant unmet user need, are viable and feasible, and align with your vision, mission, and core values.

A good product roadmap should:

be useful for the whole organization
be human-readable
evolve in response to external change
clearly communicate quantifiable impact
clearly communicate quantifiable risk
fit on one page

A roadmap is also a promise. You are promising that you’ve done your homework and identified the best possible opportunities, and you are committing to move quickly enough to seize these opportunities before they expire. You are also promising the opportunities that you decided against including in the roadmap will not distract you from these focused goals.

If that sounds like a tall order, it is. Creating these kinds of roadmaps is a science, not an art.

The GRIDS Framework

This series proposes a framework for generating a product roadmap that represents the few focused opportunities that can provide real impact to your business.

This framework starts at the strategy level and explains how to distill, from many opportunities, the ones that are right to pursue. We’ll also discuss tools for saying no to the wrong opportunities. Rather than a prioritization framework, this is a decision-making framework that can help you choose, communicate, and commit to impactful work.

The first letter of each of each step in this distillation process happens to spell “GRIDS,” so I’m calling this the GRIDS framework:

Gather & group
Review & respond
Investigate
Decide
Share

Step 1: Group like ideas

Group ideas that are similar in scope or spirit first. Take note of duplicates, as this might be a signal that there’s a significant unmet opportunity.

Step 2: Review & respond

This is an initial triage to sort out ideas that are in conflict with any of your filters. If you’re unsure, pass that item into the next step. It’s important that your product team have a confident, documented understanding of each of these filters:

Business strategy
Mission &
Vision, &
Core Values
Customer need

We’ll talk about why you need each of these in-depth later. This process must be collaborative and transparent.

Step 3: Investigate

For remaining items, look for a marriage of user need and business value. This is where opportunities exist. Evaluate the size of the opportunity and the scope of the user need. Be creative. If you’re evaluating at a specific solution, peel away the tactical layer — the solution part — and look for the user pain point it’s aiming to solve. Validate that user need. Does solving that pain point generate business value for you? Understand the cost of action on these opportunities as well.

Step 4: Decide

Don‘t “prioritize.” Decide.

Step 5: Share

Publish the most impactful opportunities — the ones you’ve decided to take action on — on your roadmap. Map them according to business impact and confidence. Note that “business impact” is a variable dimension that may not be revenue.

Your roadmap should fit on one printed page, so that it’s consumable at-a-glance. This final output should be accessible to everyone in your organization.

The GRIDS framework will help you create roadmaps that succinctly communicate business impact at a glance, ensure alignment, and provide actionable direction for fast-moving teams. It also ensures the opportunities to which you commit resources are easily quantified in terms of potential value and confidence in delivering that value. Done well, everything that makes it on your roadmap will address user needs and build business value while amplifying your business strategy and staying true to your vision, mission, and core values.

A note about inputs

This series assumes that you have more ideas, feature requests, and opportunities than you know what to do with, which is exactly why I’ve created a framework for filtering these down to a manageable, actionable list. If that isn’t the case, start with this post on divergent thinking and ideation, and then come back.

Step 1: Gather and group ideas

The first step of the GRIDS framework is to gather all of your ideas into one central place so that you can filter them.

Gather

Let’s say you have a ticketing system where people send feature requests to the product team. These might come directly from users, or from your customer success team, or from other people in your department or on other teams, or all of the above. You might even have different systems for tracking different kinds of requests. It’s probably an overwhelming mess and some of those items are likely 3+ years old. Correct? Let’s fix that.

So let’s start by making sure we’ve gathered everything we need to triage into one single location. Then, group similar requests and ideas together.

Group

In effect, you are de-duping your data. Don’t just delete duplicates, however. Do not delete anything yet. Yes, you might already know that you aren’t going to act on some of these. Save judgment for the next step. Even if you think an idea is terrible or in-actionable, do not delete it. These ideas, even the bad ones, are data, and we don’t want to lose any data. Right now we only want to collate and de-duplicate so that we are starting with a clean list in a single location. We are not passing judgment yet. I think about this as “lossless” vs. lossy compression.

Take note of duplicates

Take note of — literally notate — repetition. If an idea has come in 8 times in the last 3 years, this may be a signal that there’s a very painful unmet need here that we should find a solution for.

Call for entries

If you or your team have ideas that aren’t listed yet, add them! We want to start with everything in one place. Whether it’s a visionary idea you’ve been brewing for a few months or feedback from a customer survey, everything you might possibly want to devote resources to needs to be pooled in one place.

This may take a day or two, and can be a tedious process. But it’s important to clean up your inputs to make our next step easier. The output of this process is a clean list of unique ideas, with an indicator of how many times this idea has been brought up.

The idea queue is not your product backlog

Don’t mistake this list of ideas for your product backlog. This is simply a list of unique ideas. There are more decisions that need to happen for each of these items before you decide whether or not it’s actually going to become a part of your product backlog. This is an important distinction, because your product backlog is part of your roadmap, and remember — the roadmap is a promise. Items on your backlog are the opportunities that you intend to act on that you believe will deliver business impact. And you are committing to delivering on those in time to grab the available market opportunity. We’re not there yet.

Before moving on, you can choose to publish this clean list in a place that the rest of your organization can view. “Here’s everything that our product team is about to triage” you can offer. “If you have anything to add, please do!” Showing your team that you take their ideas seriously makes people feel heard and respected. And giving people permission to offer up their ideas may uncover opportunities that wouldn’t have otherwise surfaced.

Output of Step 1:

A clean list of all unique ideas in one central place. Each is notated with the number of times this idea has come up.

Step 2: Review and respond

No matter where or from whom an idea originated, every single idea must go through triage before there’s ever a conversation about whether or not it should be on the roadmap.

“…surveying and understanding your inputs is arguably… the most important thing that you and your team should be doing before you go ahead and plan your roadmap.”
— Sherif Mansour, Principal Product Manager, Atlassian

Review

Take the output of step 1 — your list of ideas — and review each item. I recommend doing this as a team, with voices from product, design, and development included. Sort by the ideas that were most requested to least. Do a quick sanity check to decide whether or not each idea really represents an impactful opportunity, and should pass to the next step.

For each item, you’re going to ask yourself:

Does this effort align with our core values?
can we see a line from this request to our company vision?
is this effort on-mission?
will this effort amplify our business strategy?
is there a user need for the output of this effort?

If the answer to one or more of these is a definitive “no,” put it in the reject pile. If the answer to all of these is “yes,” then this is truly an idea worth investigating.

If you aren’t sure about an idea, let it pass to the next step. Allow your stakeholders and team members to help you triage later. You’re accepting a little bit of bloat here because you’re rejecting the risk of making the wrong call. We’ll dig into those uncertain opportunities more in the next step.

This review should take no more than two minutes per idea. Don’t spend hours on one item. We’ll investigate further later. We’re not trying to quantify potential business impact here; we’re simply deciding if we should carve out time to investigate the potential impact.

Ultimately, this step is much more about the ideas that you choose not to act on than anything else. Whatever items pass this step are now officially on your product backlog, and become the input for Step 3.

Transparency is key

There’s a wonderful video created by Harrison metal, a VC firm, that I really recommend watching if you’ve got three and a half minutes.

I found two important takeaways from this video. First, your review criteria must be consistent and should be published. So that earlier checklist — your vision, mission, core values, business strategy, and user needs — should be published and be able to be referenced by anyone in your org. (And while I haven’t gotten there yet, I’ll be publishing articles about each of these — stay tuned.)

Respond

Second, you should respond to the ideas that did not make it onto the backlog. The easiest way to do this is by publishing the reject pile. But if possible, respond directly to the original contributor to let them know why you are, or are not, moving forward with their idea. This is data that is often lost. That missing feedback loop, when decisions are made to not take action, leads to a tremendous amount of frustration for people who may have had a request or an idea that they thought was really great or very important who never see that come to fruition. It can erode their trust in your department. It can erode their willingness to work with you on other things that you may really need from them. And it also fails to give them the feedback loop of why you didn’t take action on it. And that feedback loop is a very important part of communicating to your organization what’s really important for the product team to deliver to help the business. You should clearly communicate what the product team is focusing on and what they can expect from you.

The art of saying “no”

You don’t want to go send around a company-wide email about why you decided Jim’s idea was terrible. But you may want to send a personalized message to Jim thanking him for the time it took for him to write up that feature request, letting him know that you really appreciate his willingness to contribute to your team’s success, and you look forward to working with him in the future. Then, give Jim some insight into why you decided not to move forward with his idea. This person may really appreciate that you’re giving them more information than they’ve had in the past, and they might actually be able to come back with, “well, what if we did it this way?” You may find that the revised version of this that is more in line with your product goals is actually a really great idea that should be reconsidered.

The extra step of sending this feedback does take time, and it’s tempting to skip. But I strongly recommend you invest this time in those relationships. Done respectfully and well, you can say no to stakeholders who far outrank you, and they will thank you.

A note about conflicting needs

There will always be some business needs that have no bearing, or even sometimes a negative bearing, on your customers. Legal constraints, last-mile delivery logistics, etc. Because of this, you should only filter out the subset of your request queue that you are certain do not amplify your business strategy. Remember that your business strategy always includes some degree of risk mitigation. It’s a fair question to ask yourself “Am I in any way qualified to decide whether or not we should do this?” In the cases where the answer to that is no, such as infrastructure or compliance requests, that item should always pass this review and make it into the next step.

“Everything you do should be from the perspective of meeting a customer need, and that’s critical, but it is often not sufficient. It is wonderful in theory, and usually in practice, but there are always other constraints. There are always other tradeoffs that you need to make. Business needs that need to be met, technical debt that needs to be paid off, sales quotas that need to be met. The ideal of customer-centricity is an important one, but it’s hard to meet every single time. And sometimes you need to make a “bad tradeoff” to keep the business going. And part of the role of the product manager is making those calls, making those difficult decisions, those trade-offs, because at the end of the day you want to make sure you’re still there in the long term. And what you need to ultimately land on is having a sense of where you can compromise and where you can’t. That ultimately is the toughest thing for a product manager to learn.”
— Chirag Fifadra

A note about unrealistic expectations

Is it the product team’s responsibility to assess user needs. It is also the product team’s responsibility to propose strategic initiatives that both fulfill user needs and are on-mission. It is someone else’s responsibility to set sights on a vision and propose a mission to getting there.

In reality, you will seldom have a polished business mission and vision handed to you. If your company is lacking these inputs, it becomes the product’s responsibility to propose (and generate team-wide buy-in for) a product mission and vision. Working without these is to fiddle aimlessly in the dark, and is a waste of someone else’s money, many people’s morale, and your time. To knowingly do this, without trying to bridge those gaps and get back on course, is unethical.

Output of Step 2

Product Backlog: the opportunities you will put your resources to creating solutions for.
Reject pile: non-impactful resource vampires that no one should be working on.

Step 3: Investigate

For each item in the product backlog, we’ve decided to devote time to investigating which ones are the best opportunities to take action on. You probably don’t know exactly how much business value each of these ideas could create. You probably don’t know how much this could benefit — or annoy — your users. And you definitely don’t know the cost, the full cost, of devoting resources to this opportunity. So we need to find that out.

This is what most teams would call product discovery, and people usually start this too soon. By having first reviewing our ideas, and rejecting many, we’ve already focused on the most promising opportunities, and significantly reduced the amount of time that it’s going to take us to investigate where to spend the rest of our energy. We know that every single thing that we’re investigating is something with real potential, so morale is high. Morale is a lot higher than if we felt like most of these are probably never going to see the light of day.

Now, we investigate and learn enough to make a final call about whether each idea goes into development or gets tabled.

Validate the user need

The first step is always to validate the user or customer need. Without customers, you’re not in business, so there is no idea that will have any business impact if it does not materially benefit your users. This is where you should spend most of your investigation effort.

Desirability

Once you’ve validated that you’re dealing with a real unmet user need, the second step is always to question whether the solution proposed is the right way to address that need. It’s usually not. Always work backward from “what is best for our users?” What will they accept, adopt, pay for, and refer? What will seem obvious to them and what would be confusing? Elegant solutions should immediately make sense for the customers you have and the customers you want.

Feasibility

Make sure that your solution is technically feasible and financially viable. You will need your technology team to weigh in on the technical cost of building that solution. How many engineers would it take? Would you have to hire more? Does our current tech stack support this solution, or would a large refactor or re-platform have to take place to lay the necessary foundation? Does the technology even exist to do what you’re trying to do? If so, how mature is it? Can you risk building a product on unproven tech?

Viability

Does your team have in-house capabilities to deliver on this idea? Or would you need to partner with someone? Does your solution mandate new processes, or have an expensive downstream impact on other teams, like sales or customer service? Do you really have what it takes to solve this unmet need? What are the non-technical costs in goodwill, trust, etc. that you’d need to expend to gather the right resources to even start working on this solution?

Measuring impact

For each idea, we need to know how we’re going to measure success. What KPI — key performance indicator — will we use, and what change in that number do we expect to see? Remember, that number can be a range.

We’ve also hopefully identified control metrics — things we do not want to see change. We also want to be honest about our confidence level — how certain are we that we know enough about this opportunity to know if we can definitely impact our KPIs?

If an item is really uncertain, and you have low confidence in your quantitative impact, ask yourself if it can be broken into smaller, less risky pieces to help you learn more about that unknown opportunity in smaller stages at less cost.

“Knowledge can be seen as the opposite of risk. So when uncertainty is high, our focus is knowledge acquisition. We focus on things like user experience prototypes, technical “spikes”, or experiments.”
— Agile Product Ownership in a Nutshell

The cost of delay

Opportunity is a moving target. User needs and expectations change over time. The competitive landscape changes, and what may be technically impossible today may be very feasible tomorrow.

“The features and products that we ship have a limited half life, and the longer it takes them to get to market, the less value that they have.”
— Dave Wascha

Don’t miss your window of opportunity.

Output of Step 3:

A Product Requirements Doc, or something similar (you can call it whatever you want) that spells out the potential business and user impact, and how you’ll measure this impact. Now, you should have a clearer picture of the impact of each opportunity and the true cost of choosing one opportunity over others. From that data, you decide.

Step 4: Decide

Once you understand the desirability, feasibility, and viability of each of your options, it’s time to make decisions about where to expend limited resources to make the biggest impact on the business. It’s very important to understand that a prioritization process can assist in deciding which opportunities to chase, but it is not a decision. Prioritization helps us identify which things have the most potential; decisions help us not be distracted by everything else.

Prioritization identifies potential; decisions prevent distraction.

“A priority is observed, not manufactured or assigned. Otherwise, it’s necessarily not a priority.
Got that? You can’t “prioritize” a list of 20 tasks any more than you can “uniqueify” 20 objects by “uniqueness,” or “pregnantitze” 20 women by “pregnantness.” Each of those words means something.
An item is either unique or it is not. A woman is either pregnant or she is not. An item is either the priority or it is not.”
— Mud Rooms, Red Letters, and Real Priorities

As humorous as this is, I still think the “prioritization” process is a useful tool. It’s just important to understand prioritization is just a process; decisions are the necessary output.

Prioritization frameworks

There are countless prioritization frameworks for understanding impact and cost. The skill of prioritization is understanding when to apply each of these frameworks. There are two ways of thinking about this — decision making frameworks vs. force-rank frameworks. Whichever framework you use, there are two important things to know about the prioritization process:

The first rule is that this exercise must be done collaboratively. Teams that make these decisions together are more likely to feel good about the decisions. The people who will be executing this work — your development team and design team — should be a part of this collaborative process. Now, you should still prepare for this meeting, and walk in with a recommendation and a request for feedback on that recommendation from design and development. You shouldn’t be asking them to do your job for you. But you should be open to their input, and make sure that they feel their discipline concerns have been appropriately weighed. My husband refers to this as having “strong opinions, weakly held.” Come prepared with a proposal you can defend, but be willing to change it after team input.

Second, prioritization is unique to each team and company. No framework can replace understanding your business and your resources well enough to do these calculations. You will need to understand and take all of your unique constraints into account. Be open-minded — is this really a constraint, or just a habit? But also be grounded in reality about what you can feasibly achieve. Some business value delivered is better than no business value delivered because a project got derailed.

“A good plan violently executed now is better than a perfect plan executed next week.”
— Gen. George S. Patton

Output

Is NOT simply a prioritized list. The output is a subset of your prioritized list — the right opportunities that you have decided to focus your resources on.

Step 5: Share

The final step in this process is to plot the decisions you’ve made on a roadmap that everyone can reference. The point of a roadmap is to convey the tactical plan you will execute to meet strategic goals. You’ve decided what those tactical plans are, now we need to illustrate how they will meet our goals.

Horowitz Law

A roadmap needs to be understandable at-a-glance. People higher up than you, with different and riskier work on their plate, don’t have time to reverse engineer how you’ve put this together. It should be obvious at a glance, on one page. A best practice, that I jokingly dubbed the “Horowitz Law,” is that the roadmap should fit on one printable sheet of paper, and be readable on one slide in a presentation. No amount of long-winded explaining, previous success, or data will have the same impact on someone as that “Oh! I get it!” moment they can only realize from a well-composed, 1-page work of art that should be your roadmap. Use your data-ink ratio wisely.

Dimensions of a product roadmap

Before trying to place onto the roadmap, you should understand what a roadmap actually represents. Most roadmaps have 2 dimensions. Along these axes, you map your decisions to share with your team.

Confidence

This is the measure of how confident you are that you can deliver the business impact potential in a given opportunity. If you’re building to learn, things that are further away have more unknowns, so confidence inherently decreases over time. If appropriate, you could represent this dimension as a timeline. Most roadmaps do, but it’s important to understand that time is really just a proxy for confidence.

If it’s important to you to not commit to specific dates, you can use the headers “current,” “near-term,” and “future.” Most people use quarters (Q1, Q2, etc.) This is most appropriate for manufacturing and shipped products. In the tech world, this may be criticized for seeming “waterfall.” Know your audience. Don’t use buzz words; use the right words to communicate the important things to the right people.

Business value

This entire axis should map to an agreed-upon business strategy. I would label this axis with the type of business value you anticipate and the metric you define success for this strategy by. It’s important to remember that this success metric may not be related to revenue, depending on the stage of your company and the strategies you are employing.

We’ve decided what to work on based on this business impact, so higher priorities go at the top.

Optional 3rd dimension — Strategic initiative

If you manage multiple products, or a complex product with many different development teams, you may need to visualize their impact across different strategic goals of your organization.

You obviously can’t display 3 dimensions on a 2-dimensional sheet of paper or slide. Use a new page for each strategic initiative, and put the pages in priority order, first to last.

Roadmaps should also have…

A title! Be simple and straightforward. Let people know what they are looking at.
A contact name and email for the best person to reach out to if someone who is reading the roadmap has questions. This is probably you.
Your resource dependencies. It’s good to clarify that this plan is dependent on resources that, if altered, would impact delivery schedule and/or scope. These dependencies may include current team size, projected future team size, specialized skillsets, etc. This section should be about as long as this paragraph.

Tools

Use whatever tools are most comfortable for you. Yes, a product roadmap does get updated, but that should happen quarterly or monthly on extremely agile teams. It’s okay if it takes you a little time to translate the work you’ve done into a format that makes it easy for others to understand and appreciate that work. I usually do mine in Google Sheets and Slides. Another tool I really love is Airtable. And frankly, MVP is some sticky notes on a wall. At the end of the day, the goal is to communicate decisions to keep your team focused. Whatever tool empowers you to do that is the right tool.

Output of Step 5:

A great product roadmap that the whole team can reference!

Conclusion

Using the GRIDS Framework, you can reliably create product roadmaps that are actionable, understandable, and which represent real business opportunities. At the end of this process, the roadmap serves to document and communicate your decisions, but by the time you have it the hard work of reaching consensus is already done.

I recommend that you go through the steps in this framework at least quarterly. Ideally, I think this is a process that the product team does monthly, whether you make changes to your roadmap or not. Once a month gives you given new information in the market, new constraints, new user feedback, new ideas, and information about new resources gained or team members leaving. All of those factors may impact which opportunities are most impactful at a given time, and in feed into refining your roadmap.

Development process be damned

The GRIDS framework is completely development process agnostic. The output of this work can feed into any process, agile or not, that your development team uses to accomplish their goals.

Small details might differ, but ultimately this is a product-owned process. The output of the framework, a product roadmap, can be an input to any development process. Nothing about this should mandate that your development team change what they’re doing, for better or worse, this is not something that should cause pushback from a development team, because this does not necessitate a change on their part.

A note about success, and failure

“It is possible to commit no mistakes and still lose.”
— Captain Jean Luc Picard. Or whoever wrote that line.

I cannot guarantee that this framework ensures success. I do guarantee that it will provide objective structure for product decisions that can be more easily defended, empower you to say no to the things that are not the best use of your resources, and help you focus your efforts on impactful work. If all of those things are true and you are still not succeeding, I’d take a look at your higher-level inputs — your business strategy, vision, mission, and core values — and see if adjustments are needed. I’d also go back to your user research and make sure you’ve identified true needs and provided unbiased solutions for meeting them.

I hope this has been helpful. Let me know if you’d like me to discuss this framework with your team. If you have questions or ideas about anything in this framework, I’d love to hear your thoughts.

Processing…

Success! You're on the list.

Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.