10. Roadmaps and How to Say “No”
“That’s a great idea,” I remember telling a Ph.D. with deep expertise into human interaction who was working at the time in the innovation lab of a huge tech company. “I love it, but how are you going to get it onto the roadmap?”
If you ask enough UX people what it is the product manager has control over that they wish they had more say in, one thing you’ll hear about a lot is the roadmap. For the product manager’s peers and ordinary stakeholders, the roadmap can represent an opaque and even arbitrary lockbox that prevents them from getting the feature or design they want into the product.
Towards the end of this year Rosenfeld Media will be publishing my book Product Management for UX People: From Designing to Thriving in a Product World (you may sign up there to be notified when it is available for order), the culmination of a multiple-year project that has unfolded with the input and support of the Design in Product community.
During the editorial and production process I am sharing early drafts of chapters, and I welcome any feedback here that will strengthen the material.
For the product manager’s upper management, the roadmap often represents a commitment to deliberate specific features on specific dates and a source of angst, disappointment, and constantly reset expectation.
Some of the more common thing you’ll hear about a product roadmap from people in a tech company (including the product managers) are variations of
- “Where is the roadmap?”
- “Is the roadmap up to date?” and
- “Where are we on the roadmap?”
So, a roadmap is obviously a metaphor but for what? What does it actually mean? What’s the car, what’s the road, what’s the destination, and what are the rest stops? Maybe let’s park the car on the shoulder and look this thing over calmly to figure out what exactly a roadmap is trying to tell us.
Defining the Roadmap
The songwriter Mose Allison once wrote “Everybody’s crying mercy, but they don’t know the meaning of the word.” So too, will you hear everyone talking about roadmaps but very few people agreeing on exactly what a roadmap is and what it’s supposed to do.
What is a roadmap?
As the metaphor implies, a roadmap is a plan for the “road” ahead, a map of where you hope to take your product, feature, or line of products. In some ways it’s more like the old “TripTik” that AAA still puts together for you to customize your road trip with just the stretches of highway and surface roads you’ll need to cover to get to your destination.
So what is the destination, in this metaphor? It turns out that is often the source of confusion. Inside a product team, a roadmap helps identify (and build consensus around) what to build now, what to plan for now to build next, and what to plan for next. It provides a way of tracking whether efforts are focused on the most important goals and if adequate progress is being made along the way.
Outside of product teams, most people view a roadmap as a commitment to ship specific features on certain dates in the months and years ahead, but this is a dangerous misconception that causes endless grief for product teams and equally frustrating disappointment for outside stakeholders.
A roadmap is not a launch plan
The biggest problem communicating about roadmaps is inevitably stakeholders interpreting it as a launch plan. If the roadmap suggests that you’ll be adding the new “Post to Tiktok” feature to your cooking app in Q2 and July rolls around without the feature shipping, it’s understandable that people are going to interpret that as a failure and a broken promise.
They may have built launch plans and a marketing campaign around this feature. They will be less likely to trust your predictions and commitments in the future, and they may invest less in supporting your feature launches in the future to minimize risk from a “once burned, twice shy” perspective.
By the way, the solution to this problem is to make actual release and launch plans in collaboration with your sales and marketing teams, and include in it only things you actually can commit to shipping and only when you can commit to real dates. When people treat the product roadmap like a launch plan or complain that it doesn’t look like a gantt chart (see Figure 10.1), give them what they want but just keep clarifying that the project plan to ship a specific feature or set of releases on a schedule is a different artifact from the roadmap.
Feasible horizons: Now, Next, Later
A launch plan is anchored to fixed dates with dependencies running backwards along a critical path. Wearing a project management hat you can drive a team toward a launch, trim where needed to keep on track, detect and resolve problems in time, or negotiate new dates with sufficient advance warning when reality intervenes versus your best-laid plans.
A roadmap, by contrast, is a forward-looking document used to prioritize (primarily) near and medium term efforts. It is best structured into three rough time frames that can be viewed as a receding horizon getting less sharp as it gets further away: Now, Next, and Later (see Figure 10.2).
Now
Ideas in the Now bucket are (as you might have guessed already) things that your team is actively working on currently. This tends to mean things your developers are working on, code your are writing, things you are trying to ship (as opposed to ideas you are still just “noodling” with).
Next
Items in the Next bucket are on deck, as we say in baseball. They are the things we hope to work on next, once the things were are working on now are done. Ah ha, you say! No ideas is ever done! True, but the ideas in these buckets are expressed in achievable chunks and a specific product or feature may be the subject of an ongoing series of ideas.
Developers are usually not actively working on (or preparing to work on) the items in the Next bucket except occasionally to provide some technical ballast to planning and ideation sessions, but product managers, UX designers, and stakeholders generally are working on these ideas or their precursors, so that by the time there is room in the Now bucket they are ready to work on directly.
Later
Things in the Later bucket are important ideas that the team is building toward, but they are too speculative at this time, or too dependent on executing not just the Now items but some of the Next items as well, and so it’s not really worth anyone’s time to research, design, or architect these items, beyond capturing the idea as accurately as we can at this time, for when there is room in the Next bucket to really start digging in.
Product strategy
OK, none of this sounds like rocket science so far, you may be thinking, but what goes into each column? Or maybe you’re not asking yourself because you think you already know and the answer is “features” but that’s not it.
A product roadmap is not a list of features.
Features (or bug fixes, or experiments, or any other changes you ship to your codebase) are (tentative) solutions. They are the results of your research and design and development work and what you learn after releasing a feature feeds back into your research in the endless build, measure, learn cycle.
So it’s a mistake to jump right to features and start dropping them onto a plan. Not only does it lock you into specific solutions before you’ve done the work, it also sets concrete expectations with stakeholders leading them back down the path of hearing your roadmap as a release plan.
So what do you put in the roadmap? Outcomes, organized into themes, laddering up to company objectives.
Outcomes
You don’t put features in your roadmap, you put outcomes. Results. Things you want to happen, such as:
- Double retention
- Increase customer satisfaction by 50%
- Support user requests for more ways to collaborate with each other
- Improve performance
- Reengage with formerly active users
There might be any number of strategies for achieving the outcomes listed (made up) above, and any strategy might suggest a number of tactics worth trying. One of these tactics might be a feature that you might design, build, and ship, but there’s no need to lock yourself into a specific narrow potential solution now. It’s better to describe what the successful outcome you want looks like and then the work of the team is to figure out how to get there.
Organized into themes
To avoid having to sift through a completely random bucket of outcomes, and as a way of recognizing that goals and initiatives often require an ongoing series of efforts that will span multiple quarters, defining a set of themes to organize and associate outcomes helps keep things aligned, balanced, and legible.
It may be tempting to structure roadmap items in terms of the specific product area or functionality they relate to, but “signup,” “sharing,” and “profile management” aren’t themes. They are segments of your product. There’s nothing wrong with tracking this metadata and even indexing or sorting on it, but it’s not the right way to organize your roadmap by default.
Themes tend to cluster around related goals — such as user growth, retention, revenue targets, network effects, behavioral patterns, and other — defined in your product strategy with the aim of fulfilling your business strategy (or, if you are in a non-business sector, your organization’s overarching strategy).
Laddering up to company objectives
This nesting of strategy is key to product alignment. The organization has goals: long term goals, goals for this year, goals for this quarter or half. The product team within the organization therefore owns some of the responsibility for helping the org achieve those goals.
If you’re in a product-centered org, then the product team may be driving most of the overall strategy!
At the leadership level, the head of product coordinates with the rest of the executive team to negotiate commitments the product team can make to the org as a whole in order to fulfill larger objectives. Many tech companies use OKRs (objective and key results) as a framing device for:
- articulating clear objectives (basically the same as goals or outcomes) and
- identifying key results that are measurable and can either confirm or falsify whether the goal was achieved, or in the case of goals that can be achieved in whole or in part, measure to what extent the goal was achieved
- aligning OKRs up and down an organization so that the objectives of any given team fulfill the key results of the team or leader they report to, all the way up (and down) the chain
Owning the roadmap, or part of it
If you are the head of product (congratulations!) then you probably own the whole roadmap. If you’re anyone else in the product org, then you probably own just a piece of it. (If you’re junior enough, you may nor actually own any of it, but you will at least be included in discussions about plans for the part of the product you are currently working on).
For example, a large product organization might have:
- A product portfolio consisting of several lines of products, owned by a Chief Product Officer
- A line of products, owned by a VP of Product
- A specific product in a line of products owned by a Product Director
- A major piece of functionality (onboarding, administration, core experience, etc.) owned by a Group Product Manager
- A feature owned by a Product Manager
- A backlog owned by a Product Owner
More often than not, outside of enterprise tech companies, you will not have so many levels of articulation and ownership, but the conceptual gradations exist at any scale.
In such larger organizations, the demand for product operations (or “product ops”) starts to grow to manage the orchestration of multiple lines of business all trying to make use of the same product and development resources, and this alone can become a complex part of the roadmap planning process.
So let’s say that you do own at least some piece of the roadmap; that you are thinking in time horizons of now, next, and later; you’re aligned with your team on the major themes in your product strategy, and you’ve got a nice big backlog of great ideas for how to achieve important outcomes across all those themes.
How do you determine which idea goes in which bucket? This is a matter of prioritization, something that you are responsible for driving and achieving alignment on across all stakeholder even if you are not empowered to simply make all the tough calls yourself directly.
Converting the wishes and ideas of an org into a clear, usable roadmap is a fundamental responsibility of the product team and it doesn’t ever come easy.
Prioritization
Products are more than just a bundle of features and bug fixes, and roadmaps are more than just a giant wishlist.
The product practice sits at the nexus of every input into, and every stakeholder of, the customer experience that represents your company’s brand. Product people shoulder the difficult but critical responsibility of weighing the opportunities (and risks) and forging a consensus that moves the team forward and helps deliver valuable outcomes.
There will always be a surplus of great ideas, new problems, ongoing unaddressed issues, deep-pocketed partners, eager sales efforts, business fads, and competitive setbacks.
There will always be too many good ideas to do them all at once, without even getting into the opportunity costs involved in each or the fact that many good ideas are mutually incompatible.
For example, you can’t have two top priorities. You can have any number of important things that you think matter but only one of them can be the top priority (and if not, then you have zero top priorities, not two).
Weighing these priorities, wishes, good ideas, problems, etc. against each other is a fundamental product practice that takes place at every level of the business. Whoever speaks for product in the C-suite will ultimately decide what the entire product org or effort focuses on, what gets funded, who gets hired, headcount, and so on.
Product leadership needs to address and respond to the business strategy through a product roadmap and operational plan. Product practitioners need to make hard choices about what to ship, what to work on next, the order of the backlog, the priority of bugs, and so on.
Prioritization methods
It’s important to tackle prioritization in a systematic way. There is no one single ideal prioritization method or process or exercise that will suit every occasion and context, but there are always too many good ideas to go around, that stakeholders with varying degree of insight and claim over outcomes all need to be understood, respected, and addressed, and that a transparent open process for weighing and evaluating priorities works best.
The most common prioritization methods involve weighing the effort to execute an idea against the potential impact of doing so. In its simplest form, all ideas can be rated as high or low effort and then high or low impact. This enables a first-order rough sort. High impact, low effort things go first! Low impact, high effort things happen never. The other two categories then require more careful orchestration to balance the longer-term and larger efforts that may yield profoundly good results against the drumbeat of relatively trivial or tactical tasks that are easy to do but won’t in and of themselves “move the needle.”
Impact vs Effort
The next level of sophistication for that process is to use t-shirt sizes for estimates (small, medium, and large or S, M, L) which gives you another point on each scale. Most commonly a large surface such as a wall is cleared to enable an X and Y axis with Y (vertical) for impact and X (horizontal) for effort. The same logic applies at all of these scales: the stuff in furthest in the high impact/low effort corner comes first, and it’s the diagonal in the middle that requires the most scrutiny.
For more complex decisions, frameworks such as RICE (reach, impact, confidence, and effort). This model keeps the concept of effort and impact from the simple one above but also give you a variable to scope the reach of the idea (is it going to impact all of your customers all the time? new users? a subset of existing users? etc.) as well a variable to capture how confident the estimate (or the consensus of the group) is, relative to other ideas.
This latter factor helps address the subjectivity of a quasi-algebraic scoring model such as RICE, but ironically does so by introducing an additional subjective variable.
Important vs Urgent
Impact vs. effort builds on the concept of the Eisenhower matrix, Eisenhower matrix is a two-by-two grid that divides tasks, projects, or goals first by whether they are urgent or not, and then by whether they are important or not. The great advantage of this analysis is that it prevents you for confusing urgency for importance (and vice versa).
It is far too easy for any of us at any level of an organization to become reactive to urgent interruptions, emergencies, crisis, deadlines, launch dates, publicity schedules, quarterly reports, and so on. It is not possible to avoid urgent priorities and of course most urgent things need to be addressed, but not everything that’s urgent is important, and not every urgent thing needs to be handled at the highest level.
More critically, there are many important things that are not urgent in the sense that they are not due immediately and they are not blocking anything right now but being postponed, but the great risk is that these things never get addressed (or, more likely, only ever get addressed when they become urgent, generally by way of catching on fire).
This analysis reminds us to plan and schedule longer term and slower-burning matters so that they come to fruition when they are needed and we escape the “take a crisis number” method of planning that is more akin to a panic attack than a sustainable execution process.
The Eisenhower matrix (Figure 10.3) reminds you to do those things that are urgent and important immediately, and decide when important things that are not urgent need to happen (schedule them). It tells you to delegate the things that are urgent but not important to us directly, and to delete (forget about) the things that are neither urgent nor important enough to ever be worthy of your attention.
This sort of analysis helps with broad sorting of goals and ideas into priorities and helps minimize wasted effort and falling into reactivity, but it’s not really granular enough for most roadmap prioritization needs.
OK, so back to Impact vs Effort
Another two-by-two grid (or “magic square” as some business consultants seem to want to call them) compares impact vs. effort. This is the bedrock tradeoff that lies at the core of most product decisions, and requires you to think things through along these lines:
- How much value are you likely to derive from doing this thing?
- How much work will it take for the team to pull it off.
- What are the opportunity costs of doing this thing and therefore not having time to do that thing?
Plot impact vs. effort helps clarify these points. Sometimes, particularly when facilitating workshop-type sessions with a large group of stakeholders, it makes sense to use a cartesian plot (x- and y-axes) and actually rank each item against both scales (see Figure 10.4).
Generally, though, you don’t need to focus on assessing precise relative effort or impact estimates between pairs of ideas so much as roughly sorting them into four buckets by defining the impact and effort of each item as either “high” or “low” and then placing them in the quadrant that corresponds to that intersection (see Figure 10.5).
Once you sort your ideas into these buckets, then — as with the Eisenhower matrix — you can take a different tack with each of the four categories (see figure 10.6).
- Definitely do high-impact, low-effort things. They should be the “no brainers” at the top of your list.
- Meanwhile, review the ideas that would be high impact but would require much effort. You can’t do all of these things but you should invest effort in some of them (as with the non-urgent but still important items in the Eisenhower matrix).
- Just maintain basic quality control through housekeeping, fixing and tackling low-effort low-impact items when convenient.
- Immediately delete and spend no more brainpower or cycles on things that would require high effort without promising anything more thaa low impact.
Figure 10.7 shows some ideas sorted into an impact vs. effort matrix for an imaginary product.
Note: When estimating effort, another useful rough sort is called T-shirt sizes (typically meaning small, medium, and large, usually abbreviated to S, M, and L, but sometimes extended with things like XS, XL, XXL, and so on — which kind of defeats the purpose if you ask me, and you kind of did but reading this note.) This method is great when planning a sprint, but in a two-by-two matrix, medium impact or medium effort items still have to be forced into a small or large bucket, even if you want to show them hugging the edge.
So. Many. Frameworks
If you start digging into prioritization frameworks, you are going to discover quickly that there are an infinitude of them. Many of them are good! It helps to be conversant with multiple approaches partly so that you have a toolkit that you can adapt to different types of prioritization scenarios (what should the squad work on next sprint? what should the team build next quarter? what are the product goals for the second half of the year?), and partly so that you can adapt to the prevailing methods when joining an existing team.
From the Trenches
Matt LeMay says “I like to think of all of these as communication frameworks. The framework won’t help ou make a perfect decision, but it will help you communicate how you made a necessarily imperfect decision.”
Andrea Saez of ProdPad’s “What is the best framework to prioritize what to work on next?” published at Product Manager HQ offers a great overview of prioritization methods and how to know which approach to use when. She boils her advice down thusly:
Prioritization is not a linear process, and happens at different stages of development.
Start with your objectives, find problems to solve, and run discovery to better understand how different items may give you the desired outcome.
Frameworks help you understand and visualize information, foster conversations and discussions. They are not there to make decisions for you.
A great next step beyond simple impact vs. effort, for example, is the RICE framework, which also brings into account two further dimensions, “reach” (R) and “confidence.” (C).
- Reach means the potential audience impact of the idea (similar to the traffic dimension of the experimental pipeline prioritization engine discussed in Chapter 6. Considering this can help you calibrate ideas against each other (since big impact with a smaller audience may not actually be bigger than a smaller impact with a bigger audience).
- Confidence is a percentage used to challenge how sure you are about your assessments of the potential reach, impact, and effort. It gives more credit to ideas supported by evidence.
Populating and maintaining the roadmap
OK, but what happened to the roadmap, you may be wondering. Well, the end result of all that prioritization, remember, is to place ideas within time horizons to figure out what to work on now, what to prepare to work on next, and what to keep an on for later (see Figure 10.8).
As a product manager, you’re really recommending what should go on the product roadmap and where. When you (or your team) presents the roadmap to leadership, it needs to obtain their buy-in, or you’ll be sent “back to the drawing board” to try again. So the roadmap is also a proposal or a position in an argument.
When there is no roadmap
If you are making the first roadmap, congratulations! You have a blank slate. You’ll need to gather input from all your sources and signals, assess them, prioritize them, obtain buy-in, and then communicate the plan to all stakeholders. So, mission accomplished? Not quite
Keep a roadmap fresh
There is a tendency to make a roadmap and then set it on a shelf and only refer to it when the quarter ends or when the board is demanding and update, but this defeats the purpose of planning anything. Instead, you need to revisit the roadmap (or your bit of it) on regular cadences:
- On a monthly basis (if not each sprint) review the current workload of your team against the roadmap and make sure that the top commitments are getting attention. If the team is getting pulled into things that are not in the plan, escalate this to the attention of your boss. This does not mean refusing to do unplanned work (which would hardly be “agile”) but making sure that the roadmap doesn’t drift away from reality and become useless. Instead, any gap between planned work and actual is new information to be fed back in to the discussion and used to reset expectations and make intentional choices about new tradeoffs.
- Each quarter revisit the roadmap with all stakeholders, review what got done, what has moved from Next to Now, what has moved from Later to Next, and what new ideas need to be tracked for Later.
Managing Expectations
As hard as you try to communicate that a roadmap deal with a series of time horizons that necessarily get more vague and speculative the further out you go, and no matter how carefully you build and present your roadmap in ways that don’t give the impression your are sharing a gantt chart delineating a project plan culminating in a launch or series of releases, there is no way to avoid the expectation that your team is going to ship certain promised features or solutions or fixes by committed deadlines.
Thematic roadmaps don’t get you out of obligations.
They can help frame the conversation, though. When you present a roadmap covering timeframes called Now, Next, and Later, and a stakeholder points to an item in the Next bucket and asks you when you expect the team to get to that, what do you say?
One thing you can do is map the horizons to approximate chunks of time. What has worked for me is this:
- Now is this quarter, a roughly 1–3 month period depending on where we are in the quarter.
- Next is the six month period following the current quarter. The items in that bucket will likely come to fruition in that period but it’s impossible to be more specific. (So at this point the plan covers roughly 7–9 months).
- Later is the nine month period that takes us out to about a year and a half from the start of the current quarter. It’s pretty much impossible to make plans further out than 18 months, and the items you’ve parked in the second half of that timeframe are necessarily broad and subject to revision every time you reevaluate your roadmap.
Beyond that, the best way to manage the expectations of the people looking to your roadmap as the best insight into what to expect from your team is to present roadmap updates and status reports to the larger organization on a regular basis, at least once a quarter and more frequently for the teams directly adjacent to your own.
Epilogue to the Break Even story
If you want to know things went at our startup once we hit break even, well that story hasn’t finished although my part of it has come to an end. We really faced three paths there at the end, as described in Chapter 8, “Getting the Money”:
- Where we’re going there are no roads: break even business as a platform for experimentation
- The band is just fantastic: doubling down on the value in the core service and paid version of it
- Go for broke: looking for breakthrough, game-changing, market-making opportunities
We started down path number two with a roadmap geared toward tightening up our offering, continuing to optimize our signup flow and subscription service, improving a scaling the paid service tier, and ultimately making enterprise deals with health and insurance providers better positioned to underwrite emotional support and gain the benefits of broader services than point-of-same consumer transactions could ever accomplish.
Along the way, a shiny government innovation contract presented itself and tempted the business onto path three, searching for another radical breakthrough.
Sadly, around the time I left that approach had fizzled out, and I fear there might have been a missed opportunity to scale the initial sucess, but the good news is that this has likely forced the current leadership to focus again on path no. 2, which still to my mind represents a winner.
The art of saying No
The hardest part of being the person who has to establish priorities is protecting them once the rubber meets the road. There will be an endless supply of requests — heartfelt, sincere requests — for a dispensation to add just one more special new thing to the roadmap. There will also be demands from people with more power from you. And there will be endless “suggestions” from folks who you need to work with but whose ideas you are not willing (or able) to put ahead of your real priorities.
From the Trenches
As a counterpoint, Matt LeMay points out a danger is this negative framing: “I see PMs fall in love with saying ‘no’ and miss out on critical information. From my point of view, the goal is to ask ‘why’ before you say ‘yes’ or ‘no.’ Whenever an exec comes to you with a new idea or somebody tries to override something, there’s a reason behind that and it’s your job to understand that reason.”
Fielding and addressing these cross-pressures is demanding, especially when you’re not the boss, and even a chief product officer must stand naked (metaphorically speaking) and defend priorities against a CEO or a board when whoever signs their paychecks demands due consideration for a fresh idea (even if that idea did come from a recent Harvard Business Review article the CEO’s first class seatmate summarized for them on the flight home from Cabo).
Who will you have to say No to?
At various times you may have to find a way to say No to any of a wide range of potential stakeholders, including:
- Customers
- Partners
- Advisors
- Sales, Business Development, Partners, and Customer Success
- Marketing
- Engineers
- UX Designers (sorry!)
- and, of course the CEO
And you can’t blow these people off. You don’t need to capitulate and let them disrupt your best-laid plans (most of the time) but you do need to give them the time of day.
Who does have a say?
Ellen Chisa, a product leader and currently entrepreneur-in-residence at (get VC name) likes to note that there are four main inputs that contribute to your roadmap to varying degrees at different stages of product development (link to https://vimeo.com/222453375 for reference):
- The product vision
- Feedback from users
- What the data is telling you
- Ideas that come from the rest of the team (bandwidth permitting)
That first slice in some scenarios are the “CEO features” but in an empowered product team, they are arising out of product strategy. Still, there is usually a CEO or equivalent in the picture and there is no shame in accepting that they have a legitimate right to drive at least some portion of the roadmap, as the person ultimately responsible for the well being of the enterprise and the execution of its strategy.
Nonetheless, saying no to the Boss is still part of the job, as unpleasant as it may be in reality, and when the time comes for you to make the presentation, ideally you’ll have practiced letting lower-level stakeholders down easy any number of times, to hone your tactics.
Most of the time, the key to saying No is not to negate the value of the request or the significance of it for the requester. In fact, the best approach is something like this:
- Thank the stakeholder for offering their advice.
- Ask questions about the suggestion: what problem is it intended to solve or opportunity is it intended to exploit? what is the expected outcome of delivering this feature or ideas? What are the risk of not doing it? Were other ways to address this situation considered?
- Offer to research and explore the problem space further
- Review the current top priorities in the Now bucket and how they connect to company strategy, objective, and key results.
- Ask which of the commitments that have already been presented, argued for, and which have obtained buy-in should be set aside to pursue this new potential priority. Remind that these changes will need to be reviewed and reevaluated by all stakeholders.
- Ask for data to justify this priority and have your own data ready to make the case for the priorities you already fought for and won.
- And, finally, if overpowered and forced to elevate an unwanted priority, be sure to define success metrics, measure the impact, and report back eventually both on the eventual outcome of the novel idea as well as the impact of dropping the priorities that had to be cut to make room.
By the way, sometimes the ideas the boss makes you do is a good one and they were right. It’s all part of the job.
When the Brass Wants Aha!
If you’ve gone down the road of a thematic, outcome oriented roadmap with increasing time frames and have successfully avoided being forced to produce a list of features and ship dates under the heading “roadmap” you’ll likely find that a product such as ProdPad is ideally suited to this approach. (It’s no coincidence: one of their founders, Janna Bastow, has championed this model and influenced a generation of product managers in this direction.)
But this is not going to change the fact that your stakeholders will still (quite reasonably) want to know when new things are going to ship, and the executive types are quite likely to find ProdPad’s presentation options somewhat hard to follow. The more complex your product portfolio, and the more strongly they are hoping for something like a gantt chart, the more likely you may find yourself pressured into adopting (or at least “evaluating”) another roadmap product, Aha (Figure 10.9).
Aha is powerful and provides many more dimensions of complexity than ProdPad does. Their model of products, projects, epics, and so on may not map perfectly to your product taxonomy, but it is fairly malleable and can be adapted to fit many complex environments.
It also offers the ability to maintain entirely separate views of your roadmap so that you can make something with strong presentation values for a marketing department slide deck or a sales presentation and at the same time have an internal version of the roadmap that “lets it all hang out,” included internal maintenance, technical debt, and other unglamorous priorities, and provides more working detail.
Ultimately, you need to be agnostic about tools and able to ply your trade with whatever kit prevails in your current shop. When you’re the boss or building your own product org, you can own the exciting task of selection which product operations tools will unleash the awesome potential of your team.
A Day in the Life of a SaaS PM
Ian Johnson, Principal/director of product at Flow Commerce Inc.
What industry do you work in? E-commerce
How mature (or how long established) is the organization you work for? 4 years, 70 people
Share anything else that might help describe the environment in which you practice product management: SaaS products B2B
How do you start your workday? Checking emails and Slack channels
How do you spend most of the morning? Either reading up on key industry reports, customer data or potentially responding to ad hoc requests.
How does the morning end? Daily stand-up
When do you take a lunch break, and what do you have for lunch? About 12:30 and have pre planned meal
What do you do first in the afternoon? Meetings with stakeholders
How do you handle “firedrills” or other unplanned work? Assess severity and then address based on the context
How do you spend the bulk of the afternoon? In meetings
What do you do at the end of the workday? Wrap up with focused work for a period of 1–2 hours
Do you work in the evening? Almost always
Key Insights
- A roadmap communicates what goals the product team is working on now and planning to work on in the future.
- A roadmap is not a launch plan
- Roadmaps are best managed in three time horizons: Now, Next, and Later
- Roadmaps should focus on desired outcomes organized by themes, and not laundry lists of wishlist features and pet peeves
- A product roadmap communicates the product strategy, which is itself an expression of the organization’s larger strategy.
- You may own an entire roadmap or just a tiny part of one
- Roadmap planning requires rigorous, systematic prioritization of ideas that may come from vision, users, data, and colleagues.
- You’ll need to make a case for your priorities and obtain buy-in for your roadmap.
- Roadmaps require constant care and feeding, and you need to keep stakeholders abreast of updates and changes as priorities evolve and external circumstances change.
- Practice saying No.
- The boss may still overrule you.
- It can be useful at times to be able to show your roadmap in multiple ways depending on who’s asking.
—
You can sign up to be notified when Product Management for UX People is available for order at Rosenfeld Media.
