When a company hires a fancy management consulting firm to help them “optimize” operations, one of the first things they’ll do is document how things are currently being done. They will interview stakeholders and individual contributors, review documentation, and hold whiteboard-heavy meetings to unpack the current methods being utilized in the company.

After they’re done, they’ll have a (fabulously formatted) series of PowerPoint slides illustrating exactly how the sausage gets made for whichever processes they were directed to unpack and evaluate. Each required step, along with each person or team that contributes, is broken down and displayed for all to see, with lots of numbered items and arrows so everyone can follow along.

This is process mapping, but it doesn’t take an army of MBAs to pull this off, nor should it be reserved for a major strategic overhaul or reorganization. It’s useful in the product development context many of us live and breath every day, including product roadmapping.

Why use process mapping for roadmapping?

If you’re not looking to change how things are done, it might seem like overkill to go through the trouble of mapping out your product roadmapping process. But defining and documenting core business processes has a number of benefits for organizations, regardless of their size or maturity.

“A process map visualizes the ideal process that takes a feature from Idea to Shipped, and puts a stake in the ground about the actions, people, tools, and decisions that should be involved in each phase,” says Ben Blumenfeld of Designer Fund. “There might be exceptions, but all things being equal, it’s the process everyone’s expected to follow.”

There are a few reasons why process mapping is so valuable:

Consistency

A well-defined process ensures that quality control is maintained, regardless of which individual is filling any particular role in the process. Each step is documented (and should therefore be followed), the same tools and data repositories are leveraged, and the output will look the same no matter where (or with whom) it originated.

When there’s only a few people involved in the process and you’re all “old timers” in the organization, there may not be much upside to mapping out how you roadmap. But as the organization grows, it’s important to standardize every repeatable process… and roadmapping is no exception.

Tweet This:
“As the organization grows, it’s important to standardize every repeatable process…and roadmapping is no exception.”

The Basic Design Thinking Approach

If you rely on a fully-mapped process, it is essentially cloned throughout the organization and it becomes a repeatable and shareable process that anyone can follow and understand.

Education

As new people are introduced to the roadmapping process you now have a visual bible to point them to instead of relying on tribal knowledge being passed on via osmosis. Whether you’re onboarding a new product manager or explaining how things work to someone in a different department, a process map is a visual way to provide clarity on how releases are defined from the sea of potential features available.

For those offering up ideas and enhancements, they can know what process their suggestion will go through and check on its status at any point. And if their idea doesn’t make the cut, not only do they know it, but they can revisit it, respin it, and potentially turn it into a winner down the line.

Shareability & scalability

Your product’s not the only thing that should scale as its usage and audience grows. Process mapping helps you codify institutional knowledge so it can easily be used by others.

You might have the best roadmapping process in the world, but if it’s not defined and documented, it’s going to be very difficult to share it with others so they can replicate it.

Gap analysis

One inevitable outcome of any process mapping exercise is uncovering missing parts of the process that aren’t otherwise obvious. When you keep doing what you’ve been doing, it occurs in a largely unexamined context. But there are usually a few areas of improvement that can be made based on organizational changes, evolving product complexities, dependencies and strategic partnerships.

Documenting what’s currently being done and presenting it to others opens up the process to have assumptions challenged and shortfalls addressed. And as new things occur in the overall company environment or specific to a particular product, the roadmap process can be evaluated independent of an actual planning cycle to see what might be modified.

What’s in a roadmap process map?

The end goal for a roadmap process map is essentially a flowchart that maps every step and possible outcome for the ideation, prioritization, and scheduling of product enhancements. It will be a visual document that is light on text and heavy on process and flow.

A roadmap process map will inevitably begin with the inputs, which are a combination of random suggestions and ideas, specific technical and business requirements, and strategic enhancements to the product. These ideas will come from a variety of sources.

Next up is documenting what happens to those inputs:

• Where are they initially stored (JIRAs? Sticky notes? A Google Sheet?)
• Who takes the initial first pass and decides whether they’re worthy of further consideration (and how frequently is this first pass conducted)?
• If they’re rejected, where do they then “live” and how is the person who offered the idea informed of the rejection?
• If they’re not rejected, where are they stored?

Then it’s time to document what happens once the inputs have been pruned down to those meriting future consideration:

• Is additional research conducted at this stage to provide supportive (or unsupportive) data?
• Does a larger group of people discuss and rank them? And if so, who’s included and how often does this occur?
• Where do these approved ideas live?

Prioritization is usually next, so the map should include:

• Who is involved
• How often it occurs
• What factors are considered
• What the prioritization ranking looks like (1 through 5, critical/important/nice-to-have, etc.)
• Where the prioritization results are stored and available

Design, specification, and customer validation can also be included, so there’s a general understanding of when those things happen in the process and who’s responsible (although that might also fall outside of the scope of this process).

Release planning and scheduling would follow, with the process map again including who is responsible, the tools that are used, and the final format of the draft roadmap. From here, the process should cover the roadmap approval process (who signs off and in what forum), how it gets communicated and socialized to other internal stakeholders and customers, and how often the roadmap gets updated (both for scheduling accuracy and for including additional, further-out releases).

Other items should be addressed in the process map wherever they happen to occur, such as:

• When are dependencies researched and identified (and who does that?)?
• When are legal issues considered (and who does that?)?

Your process map should be full of arrows and symbols. To make sure anyone can pick it up and understand the flow, use the standard symbols when possible, such as those for Document, Decision, Database, and Process.

Process mapping isn’t just for roadmapping

Your product management organization can realize the benefits of process mapping in other key areas as well. Quite simply, if you have a process you’re doing on a regular basis, it’s worth mapping it out.

You can obviously break down the roadmap process into smaller, discrete process maps, such as prioritization of individual items or the design approval process. But you can also look at other related business processes that are critical to your product’s success:

• Customer ticket handling—When the support call (or email, or text, or chat) comes in, what happens from there? Most importantly, how do you make sure that the customer’s issue is solved and if it’s something new that product management finds out about it?
• Customer onboarding—What are the steps that should be followed to ensure that every new customer is positioned for success (and “stickiness” is achieved)?
• Customer feedback processing—When a customer has a suggestion, how is it routed to ensure it ends up in the right place? How does the customer know it’s been received, considered, resolved or rejected?
• Product release process—How does marketing and PR spin it? How are customers informed (or warned) about changes (and downtime)? Are the marketing materials, help docs and tutorials updated? How does product, development, QA, and operations align to ensure it goes off without a hitch? When does the post-mortem take place and who’s involved?

Conclusion

“Process” may sound like the antithesis of creative innovation, but it’s what separates an MVP from an enterprise-class scalable solution. “Mapping” may be something you haven’t done since you were trying to get your Orienteering badge in Scouts, but a visual description of exactly what needs to happen when removes any uncertainty from the equation.

Process mapping your roadmapping might be a drag, but once you’ve done it the first time you’ll only have to occasionally tweak it as the situation on the ground evolves. In the meantime, you’ll have a handy chart you can point to the next time someone asks you why they can’t get that new feature they just asked for in the next release… and you’ll finally get to use some of that cool flowchart software!