Janna Bastow 5 Ways to Avoid Building a Useless Product Roadmap

1. 5 WAYS TO AVOID MAKING A USELESS ROADMAP Janna Bastow – Co-founder, ProdPad @simplybastow
2. WHAT IS A ROADMAP? An artefact that communicates the direction you’ll be going in order to fulfil the product vision.
3. FOR (target customer) WHO (statement of need or opportunity) THE (product name) IS A (product category) THAT (key benefit, reason to buy) UNLIKE (primary competitive alternative) PRODUCT VISION
4. DON’T HAVE a product vision?
5. Don’t go solo Team Exercise: The Product Tree Free PDF download at: www.prodpad.com/product- tree
6. Team Exercise: The Product Tree Free PDF download at: www.prodpad.com/product- tree
7. THE ROADMAP The GAN TT The UP AND TO The CHOOSE YOUR OWN The DO ALL THE The ROADSID E ROADMA
8. ROADMAP ESSENTIALS • Time horizons • Scope • Strategic Initiatives • Product areas/components • Sometimes: • Multiple products • Specific features Time horizons Scope Product Areas STRATEGIC Initiatives
9. DATES “I love deadlines. I love the whoosing noise they make as they go by.” - Douglas Adams
10. RELEASE PLAN vs ROADMAP
11. a little FLEXIBILITY is good for your roadmap
12. Make more than one version Internal initiatives Public initiatives High level Detail DEV, operations, QA Customer Support Product Marketing
13. CEO & Execs DEV, operations, QA Sales & Marketing General Public Trusted customers Development partners Internal initiatives Public initiatives High level Detail Customer Support Product Marketing
14. CEO & Execs DEV, operations, QA Customer Support Product Marketing Sales & Marketing General Public Trusted customers Development partners Internal initiatives Public initiatives High level Detail Forget about the COMPETITION
15. To avoid a useless roadmap: • Start with PRODUCT VISION • Don’t fret about the FORMAT • Drop the DATES • Make different VERSIONS • Show your CUSTOMERS and forget your COMPETITION Thanks! Drop me a line any time: janna@prodpad.com @simplybastow Build your own roadmap: www.prodpad.com Check out our conference: www.mtpcon.com

Editor's Notes

Well, I'd call it an artefact
that outlines the direction you'll be taking
in order to fulfil your product vision.

That's all nice and simple,
though it definitely leaves it open for interpretation.

However, I'd argue that the most important thing,
underpinning your entire roadmapping strategy,
IS your product vision.

After all, if you don't know where you want to be,
you're either as far as you'll ever get already,
or will end up somewhere completely unexpected.
So that’s the first way you’ll screw up your roadmap, is by not having a product vision.

------------------------------------

Your vision statement could be formatted in a bunch of ways,
but a reliable but rudimentary format I've often seen work
looks something like this. It should outline what it is you’re aspiring to build, to solve which major problem and for whom, and how you’re going to stand out in the market and from the competition. Feel free to riff on this format, but it’s here to get you started with some of the key questions you need to ask.
Don't have your vision nailed down? Stop right there. Get it down and get buy in.

Got it? Okay, let's look at roadmap formats:
2) Don’t go solo.

As with everything you do when wearing your product manager hat, you'll need to spend most of your time just communicating and helping the team collaborate. A roadmap isn't something that you write up quietly at your desk and then present your final version.

Instead, it needs to come from what you've heard the team talk about, and each draft should be aired out so you get the feedback you need.

There's a bunch of tactics you can use to build this out. One exercise that I particularly like is the 'Product Tree'. The goal of the product tree is to get your team talking about your product vision and the steps you'll need to get there, while making it clear that they can't just have all the things tomorrow. Plus it's a whole lot of fun.

The concept is that you think of your product's future in terms of a growing tree. Go to Staples and have a large outline of a tree printed. Make sure there's room on the paper for 'growth' both above and below. Then stock up on post-its (you can even get nifty leaf shaped ones for effect) and markers, and get your whole team (or at least representatives from each area) in a room.

Have them write out key features or areas they each think the product needs to tackle, and work with them to get the post-its up on the tree. The trunk represents what you have now, your core product. The branches indicate various product components or development streams. Each new initiative or feature that's added needs to be considered in terms of order - the notes closest to the trunk should happen first, and other features can get built out on top of them over time. The roots are where your development and architecture teams get their say. A rule of thumb is that, just like roots that need to extend further and further down to support a bigger and bigger tree. It gives the rest of your team an understanding that they can't just slap on new features or leaves, without respecting the time that your devs will need to put into supporting it. With the shape of the tree, they can also see when once area gets out of hand, and might require a bit of pruning.

You can use any old tree clipart, or download a copy of the product tree outline here.

I've played this Product Tree game in startups and with big corps, and the outcome is always a refreshed team who really understands where the product might be going next. Very importantly, if gives a sense of the wider

picture involved in the product development process, and forces people to think about what you can realistically tackle in the Current term, the Near term, and the Future.

Based on the layout of your final tree, you can start drafting out or updating your roadmap.
2) Don’t go solo.

As with everything you do when wearing your product manager hat, you'll need to spend most of your time just communicating and helping the team collaborate. A roadmap isn't something that you write up quietly at your desk and then present your final version.

Instead, it needs to come from what you've heard the team talk about, and each draft should be aired out so you get the feedback you need.

There's a bunch of tactics you can use to build this out. One exercise that I particularly like is the 'Product Tree'. The goal of the product tree is to get your team talking about your product vision and the steps you'll need to get there, while making it clear that they can't just have all the things tomorrow. Plus it's a whole lot of fun.

The concept is that you think of your product's future in terms of a growing tree. Go to Staples and have a large outline of a tree printed. Make sure there's room on the paper for 'growth' both above and below. Then stock up on post-its (you can even get nifty leaf shaped ones for effect) and markers, and get your whole team (or at least representatives from each area) in a room.

Have them write out key features or areas they each think the product needs to tackle, and work with them to get the post-its up on the tree. The trunk represents what you have now, your core product. The branches indicate various product components or development streams. Each new initiative or feature that's added needs to be considered in terms of order - the notes closest to the trunk should happen first, and other features can get built out on top of them over time. The roots are where your development and architecture teams get their say. A rule of thumb is that, just like roots that need to extend further and further down to support a bigger and bigger tree. It gives the rest of your team an understanding that they can't just slap on new features or leaves, without respecting the time that your devs will need to put into supporting it. With the shape of the tree, they can also see when once area gets out of hand, and might require a bit of pruning.

You can use any old tree clipart, or download a copy of the product tree outline here.

I've played this Product Tree game in startups and with big corps, and the outcome is always a refreshed team who really understands where the product might be going next. Very importantly, if gives a sense of the wider

picture involved in the product development process, and forces people to think about what you can realistically tackle in the Current term, the Near term, and the Future.

Based on the layout of your final tree, you can start drafting out or updating your roadmap.
These things can come in all different shapes and sizes.
You've got your Gantt.
Your up and to the right
Your choose your own adventure
Your Do all the things
and even the roadmap roadmap.

This is one of the areas that people get caught up in the most. I prefer something simple,
so that the message doesn't get drowned out
by the format.
I prefer something simple,
so that the message doesn't get drowned out
by the format.

Typically, your roadmap will contain the following info:
Time horizons, to give a broad sense of how you'll progress over time.
Scope, a simple sentence or two to describe the projects you plan to tackle en route.
Strategic initiatives, and product areas or components, to give context around the problems you’ll solve

And depending on your audience,
you'll sometimes include more than one product in the same view, or if going more detailed, you might include notes on which features are going to be tackled with each initiative.

----------------------

So here's my roadmap again, with each of these elements in place.
You'll notice that it doesn't include dates -- that's on purpose!

This is because of the nature of the roadmap.
Depending on the size and maturity of your company,
your roadmap will stretch out anything from a year to 5 years from now.
If you're looking, let's say, 2 years into the future,
you have no idea what's going to be happening that far down the line.
You don't even know how big your team will be,
let alone how fast you'll be able to deliver.

And so if you slap some Q3 label on your roadmap,
no matter what sort of massive caveat you include at the top,
someone's going to call you out on it.

So leave the dates off.
I should clarify the difference between two different documents:
The release plan, and your roadmap.

A release plan is a project management document
that outlines the next few weeks or months at most,
usually.

It includes key release dates and detailed scope on what will be included.
It's put together as a result of working closely with your dev team
to sign off on the product specs,
provide detailed development estimates,
and map it based on your resources and other constraints.

This document is helpful for anyone
directly involved in the product development process,
or who needs to see clear dates on what's happening next.

However, the release plan is just a short term document.

The roadmap, on the other hand,
is a much broader document.
Having a roadmap without dates
allows you to change the conversation.

Instead of it being a myopic discussion about
what month each feature is going to be delivered,
it gives you refreshing flexibility
to talk about the direction of the roadmap
and the vision that you're heading towards.

Once you drop dates on your roadmap,
you'll be able to stop worrying about
exactly when each feature will be delivered,
and instead talk about what order
you should be tackling each,
so as to provide the most value.
I'm a firm believer that you should be transparent about what's on your roadmap.

But that doesn't mean you have to bare *all*.

Don't be afraid to have multiple versions of your roadmap.
After all, different stakeholders should be treated
and communicated to differently.

-------------------------------------------

You’ll want to differentiate your roadmap based on high level vs detailed versions, and whether you show internal or public initiatives.

-------------------------------------------

Some, like your developers, your QA team, product marketing, support, ops and delivery teams - this is your inner circle and can generally be trusted.

Show them more detail in your roadmap, and include them on internal-only initiatives.
Likewise with the management team and CEO. You can trust them to see the whole roadmap,
though you might want to spare them the nitty-gritty details
and show them a high level version of your roadmap,
particularly if you're working with a whole portfolio of products.

At this level, you're showing off how you're going to solve key problems
and add value at each step towards that product vision.
--------------------------------------
For your sales and marketing teams,
include the key areas you're planning on tackling,
showing them that there are indeed interesting things on the horizon.
---------------------------------------
Save your public initiatives for development partners, trusted customers and the public.
Now of course, this leaves you wide open to the competition, right?

But really, is there anything on your public-facing roadmap
that they wouldn't be able to see from reading your company blog,
or picking up the phone and bending the ear of one of your sales or support reps during a demo?

Unless you're Apple and you rely on massive buzz around mysterious product launches,
having your roadmap public will do more good than harm.

Your competition is too busy building out their own product to both copying yours,
so get yours out there to show off how you're going to keep rocking.

Janna Bastow 5 Ways to Avoid Building a Useless Product Roadmap

You are reading a preview.

Check these out next

Janna Bastow 5 Ways to Avoid Building a Useless Product Roadmap

More Related Content

Viewers also liked (7)

More from Business of Software Conference (20)

Recently uploaded (20)

Janna Bastow 5 Ways to Avoid Building a Useless Product Roadmap

Editor's Notes