Eli Weinstock-Herman

Planning a Product Roadmap in a Small SaaS

November 20, 2021 ▪ Head of Engineering Tips posts ▪ 25 min read
"I need a roadmap to present on the call in a couple weeks"

When there isn't a product team and we need a product roadmap, it's not unusual for the head of engineering (director, VP, whatever) to get the request.

"This is really important, will we be able to do it this year?"

There's a lot of advice out there. Some better for consumer apps, some better for dedicated product teams, a lot for hyper-scaling startups. I'm not an expert, but I have been that director, VP, and so on that wants to do a great job and has to figure it out on the fly.

"We told [new client] we will have [major feature] by June?"

If that's you too, hopefully this will help.

From Prep to Prioritize to Roadmap to Delivery

This is a collection of things that have worked well for me and some of the better links I saved for rainy days.

Before we jump into reading the internet, I like to start with an outline so I don't skip "obvious" things. Here's where my thinking has evolved to:

Major Stages:

  • Identify the goals: what is different once we have the roadmap
  • Organization Context: How much time do we have, how much change do we bite off during the roadmap process
  • Identify people: the stakeholders and communications methods/timing
  • Orient: The Business Vision, long-term strategies, current location, and other key locations on the "map"
  • Opportunities: Collect raw material for the roadmap
  • Evaluate: Relative or absolute measures for Opportunities
  • Draft the Roadmap: Synthesizing a path
  • Deliver and Plan to Iterate: Communicating, executing, learning

Writing down an outline and what I find along the way helps me address them all. Later it helps me challenge ideas I come up with, ensuring they align with my goals and don't just seem goo din the moment.

1. Identify the Goals for making this Roadmap

First up: Why are we creating a roadmap?

What was the trigger or reason for developing it? There's a lot of different ways a roadmap can be developed, presented, and communicated. We want to stack the deck by selecting options that will be the most helpful for our particular needs and audience.

  1. Who asked for it? And what was their reason?
  2. What is going to be different once our company has a Product Roadmap?
  3. Is there a particular deliverable in mind?

Many flavors of roadmap

Some goals I've had at this stage include:

  1. Align product development to a few key goals with maximum business and customer impact
  2. Align the team towards a common point on the horizon, enabling more autonomy for day-to-day decisions
  3. Confirm for prospects that we are building that one missing thing they need so they'll sign a check
  4. Show the impact of sales promises against our ability to make other business progress over the next X months
  5. Provide input to a key executive (because they're going to tell people what's on "our roadmap" even if we don't have one)
  6. Help the organization move from very short-term or chaotic planning (1 month or less) to longer timeframes with greater payoffs

So, first step, figure out what people expect, but also what your goal is. We don't want to add too much scope, but it could be valuable to include both the triggering goal and one that helps us mature our approach later.

2. Organizational Context

Next, how much we have time we have and what's possible within the current organization.

Some things to consider:

  • Whether there's a provided target (The CEO asked to have a roadmap by next week)
  • How much organizational change we want to drive while building the roadmap

For the first item, I've almost always had external time pressure. In the few cases that I didn't, I chose to timebox it myself si I could finish the first iteration and start learning for the next one.

Which is where the second piece comes in: how the organization thinks about roadmaps (solutions, outcomes vs outputs), the practice it's had at qualitative vs quantitative methods, whether there's a solid culture of experimentation and continuous improvement, etc.

In short: How firm/mature are our practices and how much appetite is there to try new methods or types of goals.

So, two to-dos:

  1. If you don't have an external date, pick one yourself
  2. As you consider processes and tools (and communicate to validate), aim for small improvements unless risking a giant learning step directly supports the external request

I'll talk more to tools in #6, but you'll also want to return to these questions in #4 (Orientation) and #5 (Opportunities) as well.

3. Identify the People

Everything we do is going to require communication and collaboration. If we build a roadmap and no one knows about it, it won't meet the goals (communication). If we build it, but don't involve key people at the right time, they may grab the wheel or we may have to backtrack to fix a flawed assumption. If people know a roadmap is coming, but don't know what the status is, we create anxiety that leads to constant interruptions or stress.

A little bit of planning will help us include and inform people, with less effort than winging it along the way.

Identifying who needs to be involved

Our plan should identify:

  • People or groups that care about the activity or outcome of the process
  • Types of information they care about
  • When they will care about it

This will let us put together a few key communications methods and reminders for maximum effect.

Level of interest

At a certain level, almost everyone will want to be involved in every step. There are a couple tools we can use to narrow in on what level of responsibility others have in this process, which can help us identify whether they're part of the decision-making, receive personalized communications, or need additional one-on-one selling of points before they're shared broadly.

Two tools you could choose from include:

For example, if the CEO and VP of Sales are the drivers for the roadmap, and we know we'll have time to augment the opportunity list from our backlog with some idea sessions with those two and the dev team, we might create a matrix like this:

Communications Matrix Example

Alternatively, using the Power/Interest grid could help you determine which folks need more personal one-on-one time versus a rhythm of steady updates.

Communications Methods

With a sense for who needs to be involved and what level of responsibility, we can put together a plan for how we are going to communicate information.

This includes pushing information to people, interactive decision-making, but also ensuring they don't have to come to us for every question or feel like they're being left out.

  1. Where do people go if they have a question?
  2. Where can people see the status on demand?
  3. When can they expect the next update (and how)?
  4. How will they know about these?

Lean heavily on where people live today.

If they're mostly in slack and you have a company wiki, then our plan could be:

  1. A dedicated slack channel and a summary page in the wiki
  2. A weekly status update in the wiki: what has changed, what is coming next
  3. A Slack message each week with: a couple points from the status, a link/reminder for the wiki
  4. Link to the wiki in the slack room topic, link to the slack from the wiki
  5. Explicit note in the wiki to ask questions in the wiki and how quickly you'll get to them on average

If it's a meeting and email culture, then we could swap "slack" with "weekly all company email", etc.

Conventions and a steady rhythm of information can cut down on background anxiety in the organization. This frees up time to make progress and reduces the incidence of folks (accidentally) undermining the process.

Reminders

Last bit: it's useful to have reminders to create and publish these regular communications. This could be a recurring calendar invite, a weekly todo item on your todo list, a recurring slack reminder, etc.

Just having a consistent rhythm of information will reduce a lot of question. Some folks won't even read it after the first few, but will feel more confident that they're not being left in the dark (and it's great when someone throws that "killer" question out in a meeting and half the attendees are ready with the answer instead of us having to address it).

Customers and Prospects

Don't forget to include customers and prospects in the list. The last stage of the roadmap is delivery, and generally that will include sharing some level of detail with the outside world. It may be worth identifying who will be accountable for that communications strategy well in advance, and we'll touch more on that in the Delivery section.

4. Orientation

If the Product Roadmap is the plan for the product over time, the Vision is the eventual destination, and Goals are areas of interest or milestones we intend to visit along the way.

Orientation: finding where we are and where we intend to go

We can collect or synthesize these items in advance to make decisions about the Roadmap Process and as content in later steps. For more adhoc or quick prioritization methods, we can calibrate folks to the same understanding of "value" when evaluating features. For more analytical processes, these can serve (or help uncover) objectives to score against. They can be used to defuse long discussions on low-value pet ideas, or raise up ideas that haven't received enough interest.

Identify artifacts like this to help define where we are and where we intend to go:

  1. Business Vision and Principles: The long-term impact of the business, the constraints we place on ourselves along the way
  2. Business Mission and Goals: The current purpose of the organization, how it serves its customers, and defined business goals
  3. Product Vision and Principles: The product-level vision and principles that align with #1 and #2
  4. Product Mission and Goals: The product-level mission and goals that align with #1 and #2, in support of #3
  5. Customers and Users: Who are served by #1 and #3 in that future state? Who are served by #2 and #4 now and in the near future?
  6. Where are we now?: Artifacts that explain our product as it exists now

Different companies will have fewer or greater of these, in less and more defined states.

In small, B2B SaaS companies with a single Product we likely won't see separation between Product and Business vision, goals, etc.

We don't have a Business/Product Vision, Principles, Mission, Goals

Broadly speaking, the CEO is the one responsible for these artifacts. If you don't know where these are, here's some methods I've used in the past.

  1. Look for internal slidedecks: recent presentations to a board, the executive team, or for funding
  2. Look for external slidedecks: high-level sales decks or business development decks for partners
  3. Draft off marketing: Positioning statements, user segmentation, brand research: who are we representing ourselves as?
  4. Listen to sales calls by executives: What do we say about our reason for being? What do we say about future direction?
  5. Ask 😉
  6. Interview executives

Ultimately what we're looking for is answers to these questions:

  • What is the long-term impact we want to have, on what industry or segments of people, in what manner?

The less well defined it is, the stronger a confirmation we'll want before moving to later stages.

Motion is not Progress unless we've moved towards a goal

One tactic I've used for this in the past, when it comes to approval and agreement, is something along the lines of:

Hi __,

I'm putting together the agenda for the Product Roadmap prioritization meeting in 3 weeks. As part of that meeting, I've included the statements below to help us start everyone off on the same page about the broad goals we're working towards.

Are there any changes we should make, or more ideal versions I should use instead?

Product Vision: ...

...other bits that are most important...

Confirming this before later steps is extremely valuable. I've seen several prioritization meetings veer completely off course because we didn't start with a common understanding, or we thought we had one but found out the CEO didn't agree with it.

I can't tell you how little or how much to gather in your situation. I aim to capture at least the commonly understood version of this, plus aspects that seem particularly meaningful (things that have bugged the CEO for a long time, things that have driven discussion on potential big initiatives, etc.).

Identifying Customers and Users

The customers and users should be central to your product.

This can be a volatile topic.

In some of my past companies we have had a clear consensus on who the users and customers are. In others, we've had folks that were adamant about "supporting everyone" so that we didn't limit our future customer base.

Users, the journeys or jobs they're attempting to do, and where they find value can be extremely valuable for setting context in the first case, but a massive distraction for the second.

My advice is to build awareness of where folks stand as you go. Then use that information to decide how much to highlight or avoid user segmentation during the roadmap process.

Unearthing existing information:

Here are some of the places I've found this information in the past:

  1. Well-defined personas or segmentation in an internal wiki, shared folder, or slidedeck :)
  2. Internal Slidedecks: slides for a board, the executive team, past roadmaps, etc. can uncover common labels and terminology
  3. Internal tooling: the CRM, support system, and developer ticket system may have categorized labels or tags
  4. Draft off of Marketing: Marketing may have research-based segmentation on users and customers
  5. Draft off of Sales: Sales may have defined labels/personas for sales qualification, to target for inclusion on calls, for specific tactics

We're looking for information to help focus discussions and common terms to use or avoid, due to the company-specific connotations.

Highly Valuable Artifacts

One last round of artifacts to look for are ones that describe how the customer works, the job they are trying to do, and why our product is more valuable to them than excel (excel is almost always our real #1 competitor).

These can provide context for features, helping us show that one is advancing a particular sore spot, or that it's well off in a new direction from anything that's proven valuable so far.

They may even unlock additional options when we get to prioritization and roadmap options.

Here are some I've found useful in the past:

  • Value Proposition: What do we see as the core of why people buy our product
  • User Workflows: What are the key workflows or processes in the application that the user's value
  • User Journeys or Journey Map: What are the jobs users are using the system for, and the major steps of those journeys

Some resources:

When you find artifacts like this, the one caution I'd raise is to make sure they are still seen as valuable within the company before using them. I've worked in organizations that tried things once, failed to get the promised value, and cast doubt on any later thing that was associated with them. You can still use some of the context in these cases, but be cautious.

5. Opportunities

Raw material for the roadmap, at this stage, is probably one of the easier elements. In the shorter term, I find we're usually starting out using what we already have. Over the longer term, we can get into user research and tooling to provide sales and success folk to mine insights, but that's a separate post.

There's two aspects to this, one harder than the other:

  1. What do we put on the roadmap
  2. Where do we collect raw material to synthesize those

What do we put on the roadmap?

The first question, for me, tends to be harder. Are we roadmapping pre-defined solutions (features) or prospective goals to invest in finding a solution for?

I've run into the first one the most. We take a bunch of the really big features, the really costly technical work, and some wild CEO ideas, and build a roadmap that says, "We will build these things". The second is an investment outlook, "We intend to make pain X amazingly better for users", where we expect to invest a certain amount of time and effort to experiment and achieve an outcome.

My preference is to move to the right, and I think this is a better foundation for a company once it scales. You'll have to judge what the current expectations are for a roadmap (back to "Organization Context" above).

(I haven't used ProductPlan. This post talks well to "stuff" vs "outcomes", and the folks they mention are all worth following and doing further reading)

Where do we collect raw material?

Assuming we don't have a user research function, the next variable is how much time we have. For this stage, I think it's really valuable to synthesize a list of the items we think are the major roadmap-able options, but then socialize that around in advance of the prioritization effort. This serves two purposes: (1) we get the oversights included in advance, instead of derailing meetings later, and (2) we find some of our blindspots (an area of value we overlooked, or an insight into a particular executives thinking on what our value is/could be).

Beyond that, unfortunately, I don't have a lot of advice. Seeing patterns and synthesizing 10 odd customer comments into a probably feature or pain point is something I'm pretty good at, without knowing how I do it. There's a lot of whiteboarding, random thoughts while hiking, etc.

Getting the raw material:

  • Review your backlog: there are inevitably big ideas that have gone to there to die, but also some that are recurring topics, and some that have 5 page write-ups
  • Review customer requests: look for big requests that come through from Sales or Success often
  • Review sales calls/notes: what do people ask about when learning about our product?
  • Executive ideas: What big ideas have come through from executives over the past couple years?

This should feed into a synthesized list of roadmappable items.

One last tip that's worked for me: don't filter this list, that's what the prioritization process is for. I've absolutely used the roadmap process before to shine light on something we were very excited about that I "knew" we shouldn't do. The times I've been right, it's cleared distractions that had been floating around for months. The times I've been wrong, it's been a valuable lesson.

6. Evaluate & Prioritize

This is the part that folks were thinking about when they asked for a roadmap.

"All we need to do is get in a room for a couple hours and we can iron out a roadmap" has been a pretty common approach, in my experience. It's generally only worked when we already had a very strong shared understanding of the items above and a small team. In every case where that hasn't been true, it's been a mess.

The big decisions at this point are:

  1. How consensus on prioritization will be reached
  2. Which prioritization method you will use (below)

The information gathering above, plus communications with key stakeholders along the way, will hopefully answer some or all of these.

Consensus methods

The two common ways I've executed prioritization in the past have been:

  1. Synchronous, collaborative meetings
  2. Asynchronous scoring, capped off with a synchronous, collaborative meeting

Or more plainly:

  1. Put everyone in a room for 1, 2, 4 hours, or several meetings, and evaluate every option together using provided context and a selected prioritization method
  2. Assign advance homework (and materials to build shared context), stay on people to complete it, then bring it all together in a collaborative meeting to create consensus

The key elements of both of these are calibrating everyone to the same context and teaching them how to use the method effectively. In my experience, Option #1 tends to be easier as folks are hearing examples and Q&A together. But Option #1 also risks being mind-numbing and indexing heavily towards people with loud voices and the biggest titles.

Your goal shouldn’t be to always make the right decision, it should be to invest the right amount of time in a making a decision relative to its importance

Making good decisions as a Product Manager

Prioritization Method

There are a ton of potential methods for prioritization. I'd advise to start simple and match the method to the current culture and context you've collected. Is your company-decision making more quantitative or qualitative? Inward focused (SMEs) or outward focused (customer input)?

This is an excellent resource on many options, much better than I could summarize in a few paragraphs: 20 Product Prioritization Techniques: A Map and Guided Tour

Prioritization Techniques Periodic Table, career.pm

Any method from this list, used reasonably well, will beat an adhoc process invented on the fly in the meeting. This isn't the time to try and push the team to exercise an area they're weak in, unless you have a lot of prep time available. I'd advise getting the first roadmap done, bank the success, then start learning from it and iterating to take on the next problem.

Over the long term, for product companies, I'd lead towards:

Set Up for Success

At this point, we know what method we're going to use, how we're going to execute to reach consensus, we have the raw ingredients, we have background context into goals and general priorities, and appropriate people have been emailed or included in each of these steps.

The last step before executing is to get everyone to the same starting position.

I like to create an agenda:

  1. What we're doing: we are prioritizing for the purpose of building our forward-looking product roadmap, blah blah
  2. How we're doing it: we're using such-and-such method for collaboration, and such-and-such method to evaluate/prioritize, and I'll walk through an example before we start
  3. Orientation: Where we're going, where we are: reminder on what we're trying to achieve as a company/product, where we are now, and key goals (and goals we already have that we won't be second-guessing during this process)
  4. Prioritization-specific definitions: any dimensions, words, etc. that the method will use that have specific themes, goals, or definitions in the context of our business. It may also include some elements of
  5. Examples: And then walk through a couple examples
  6. Let's do it!

With an agenda, now I can spend some time summarizing all of the earlier information to feed this agenda and calibrate everyone. I can also prepare my list of potential prioritization items, whether that's a prepared JIRA search, an excel sheet, a wiki page, pre-written post-its, etc.

Some small items:

  • I like to ensure the first few items we'll prioritize are easier/clearer, to help us warm up on the prioritization process
  • Items with very questionable value that folks are really excited about tend to get scattered through the middle, to try and reduce the chance that they eat up all the discussion time
  • Getting the group to explicitly classify something as "never" is extremely valuable. Don't leave out items you know you'll never do if they're burning meeting hours or distracting developers.

Execute

And now we should just be able to follow through.

I like to take a lot of notes, have visuals, and follow-up with the results shortly after the meeting.

7. Draft the Roadmap

I prefer to split this out from the individual prioritization and evaluation. The group of people evaluating the individual opportunities may not be the right set to create a cohesive story around a subset of them.

This is also an item I can't provide much guidance on, other than "use your judgement".

From all of the input up to this point, you have to decide:

  1. What level of detail is expected/needed?
  2. Will you design the roadmap or do some of those folks from the first section need to be involved? (likely a subset of the people in the earlier prioritization)
  3. Outputs or Outcomes?
  4. etc.
Completing the roadmap

This is still a very adhoc aspect of the process, for me, because I'm relying on everything I've learned above to try and have the right discussions with smaller or larger amounts of pre-drafted roadmap.

8. Deliver and Plan to Iterate

Like everything, the last step is delivery and follow-through. There's the roadmap, which we now have to start slicing pieces off of to communicate and execute, but also a ton of really great context and decisions we collected along the way. And then there's keeping track of changes in our decisions over the year and getting ahead of the next roadmap planning.

Delivering the roadmap

Here's some things to consider:

  1. Polish up the roadmap and work with executives to present it internally
  2. Deliver on the original goals: whether this is helping prepare a public version, etc.
  3. Create summaries of valuable parts and share or present them internally:
    • The summarized company and product goals (great as a quarterly reminder to the team)
    • The prioritization process that was followed
    • A "What we learned" post or presentation scheduled a few months out
  4. Schedule a retrospective look 3 months out: what have we learned and what changed because of it
  5. Schedule a refresh 3 months out to take into account the items from #4
  6. *Present/share content specific to the development team

* Note: I'm surprised I missed this at the beginning, but make sure you're evaluating how the development team is reacting to "roadmap" throughout the whole process. Even in a mature environment that is aware that arbitrary deadlines are counter-productive, even the hint of something that can be read as a deadline or due date can create high levels of stress and anxiety among the development team, so talk to them regularly.

Final Thought

If I had to bet, I'd bet that your building a one year roadmap, and if there's an expectation from other leaders in the organization it's that you won't build another one until next year.

If I had to make a second bet, you're probably prioritizing "stuff". Feature requests. Solutions. Things to build.

There's flaws and limiting assumptions in both of these. Build the first one, but iterate. My personal experience (and what I've heard from others) is that a 1 year roadmap never makes it the whole year. That's an opportunity to start iterating more frequently.

If folks are opposed to changing the roadmap, then you could limit it to a quarterly review to evaluate successes, identify next items, begin surfacing direction changes that have occurred, etc. You might even use this to start nudging the discussion from "did we ship the items" to "did they achieve the outcomes we wanted".

References

Great articles and resources (a few linked above already):

One last thought:

Share: