Responses (1)

It isn’t uncommon to have a lot of ideas on a product backlog. Ideas flow in from executives, customers, sales, support, and just about everyone. It is common to hear that a good Product Manager is one who knows how to say “no”. I would take it a step further and say that a good Product Manager knows how to build a framework that can help them to say “no” ideas that don’t move the company forward and “yes” to those that do. My aim in outlining my process below is to show one method for organizing several competing themes into a product roadmap.

Understand Business Objectives

Everything starts with asking questions. First, I would work to understand the company; where it fits currently in the industry, what is the target segment within the industry where the product offering falls short, what opportunities exist to expand market reach, what are the biggest problems that the company could solve for its customers and users. The goal here is to gain a deep understanding of the company’s objectives over the next year or so. Everything that is being worked on within the company should roll up in some way to the overall objective of the company.

Classifying Themes

By understanding where the company is and where leadership hopes to take the company, I can begin to look the backlog of work and identify common themes. The goal is to reduce the complexity of a backlog consisting of hundreds of stories and features into overarching initiatives. I want to look at each theme from a high enough level to ask the question “Does this move us toward our company objective or not”. Often the answer won’t be a simple yes or no but asking this question first could help to eliminate some of the themes that are going to be a lower priority.

Themes can be created to encompass underlying tickets in a number of ways. They can also be created before the tickets and refined down to the story level. When creating major themes for work, I ultimately focus on ensuring that the work I’m doing is both effective and efficient for the company. In short, I need to make sure that every theme moves the company toward the company objective.

Next, I want to have some objective way to categorize each theme. At this higher level, I find it helpful to try to put the remaining themes into the Eisenhower Matrix. This matrix simply places any work to be done into one of four categories:

1. Urgent AND Important
2. Less Urgent but Important
3. Less Important but Urgent
4. Less Urgent AND Less Important

Category 1: Plan these items first.

Category 2: Schedule these items. Don’t forget about them.

Category 3: Delegate if possible. This can be through integrations, contractors, partners or even temporarily filling the urgent need with operations instead of technology.

Category 4: Any items (unlikely) should be dropped entirely.

From my experience, most of the themes that remain after the initial prioritization will likely fall into categories 1 and 2. So now I would work to find more quantifiable metrics to help prioritize these categories.

Determining Value

Any work that a company undertakes should provide value to the business, the customer, or the underlying technology. The goal at this stage in determining prioritization, is to give a best estimate for the value provided from each theme to the major stakeholders. This can be accomplished through quantitative or qualitative measures. For example, if the theme in question relates to improving an onboarding flow, you could review submitted tickets for any that have a root cause in onboarding issues. You could also call customers to ask about their onboarding experience and how that shaped their perception of the product. The main work is to understand for every category just what they stand to gain if the work that makes up this theme is completed.

Ideally, a high value theme would provide value to all three categories of stakeholders. I think a simple value rating from each category between 1 and 10 is helpful to add a subjective metric by which each theme could be measured.

As a quick example, the theme “Create the best onboarding experience in the industry” could provide business value by decreasing post-sales activity costs, opening new market segments, or providing useful differentiation amongst competitors. It could provide customer value by lowering their costs to switch systems. It may provide only a low amount of value to the underlying technology but could reduce bugs associated with a more involved onboarding experience. The key is to work to understand all of the value from each theme to each stakeholder category.

Again, goal is to move complex ideas into a simplified framework to help fill in the gaps caused by so many variables and to stay focused on the most important work.

Now that themes are categorized on the Eisenhower matrix and have defined values provided for each of the major stakeholder categories, I can begin to prioritize work in the backlog. Within the first category, I would look for themes that have the highest value and place those first, working my way toward lower value themes in the first category. Then I would move onto the second category following the same prioritization of higher value items first.

It is important to note that sometimes it makes sense to do work that would provide a high level of value to one stakeholder even if the overall value of the theme is lower than another. This is where understanding the overall company direction is helpful. For example if the company wants to have the best customer experience in the industry, an item of high value to the customer may be prioritized over an item that provides medium value to all categories.

Considerations

While it is necessary to take the amount of work required into account, I would do so as a secondary metric. Anything that is urgent and important should not be skipped for something that is easy but potentially neither urgent nor important. This means that how difficult something is really shouldn’t be a determining factor if the work is important.

The size of work can be addressed in refinement and better cheaper solutions can be identified at the feature and story level. It makes sense if two themes are equally valuable to have an idea of the amount of work required but there should still be several unknowns at this point that prevent any real understanding of the scope or cost of the work. Additionally, any dependencies will be taken into account once the refinement work begins. This may cause minor changes to the priority.

The second consideration would be to think about the items in the important but not urgent category. These are items that can be scheduled for a later time but if they keep getting pushed back by new themes that are falling into the Urgent and Important category, I would suggest being more strict about what is urgent. You don’t want to indefinitely avoid themes categorized as important because new urgent things come up. A theme should be big enough and general enough to not be pushed out of priority so easily. If this were happening often, I would look for a way to better qualify urgent work.

Planning the Roadmap

The next step for building the roadmap is to place the themes onto a Gantt chart or other visual space that can show themes that will be worked on in the upcoming cycles. At this high-level, it makes sense to plan by quarters as opposed to planning by sprints. The work still isn’t refined enough to know the scope or specifics of any initiative. All that we know so far is that we have a prioritized to-do list of major initiatives that will move our company toward its goals. Now the work involves breaking up and refining each theme into epics, features, and stories.

When planning a roadmap, I also think it is wise to only plan one or two major initiatives into each quarter depending on the realistic velocity of the teams responsible for doing the work. Planning more initiatives means more time spent switching between different goals and more urgency in refining initiatives that may not be picked up for several months.

There is still a lot of work to be done to refine themes but at this point, I at least have an idea of the priority of a large backlog of initiatives and I can roll existing backlog items up into the initiatives or get rid of them entirely. I also have an understanding of the value of doing each item as well as the knowledge that all of the prioritized work contributes to major company objectives.

As each theme’s work gets further refined, I will start to determine key results for each initiative and objective measurements for each key result. I will work with customers, business, and technology stakeholders to better understand the features and acceptance criteria that define success for each theme. I’ll also be working with engineering to determine how each feature is built and work to regularly check plans against customer and business expectations.

Last, my main goal is to create a plan based on limited knowledge. I am mostly trying to take complex and ambiguous ideas and apply a framework that can help me separate good ideas from bad and better ideas from good ones while moving the company toward success in achieving its business goals. Any of the above frameworks could be adjusted or changed to find what works for the team and the business.

This is the first part in a series of responses for a case study for a Product Manager interview. This article focuses on organizing a roadmap. Part 2 covers grooming a ticket backlog to align work with the product roadmap.