Creating Your Roadmap Is Only Half the Battle. This Is the Other Half (and It Ain’t Glamorous).
What you do after you have your roadmap? How do you move from stories on your roadmap to features that customers can play with?
There’s a lot to think about.
- How do you implement it?
- How do you make sure all of your stakeholders are happy along the way?
- How do you know that your engineering team has the information that they need to build the thing right? And the right thing?
Why do we care about implementation?
If you can implement strategy well, you’re going to be a huge asset to any product team. You’ll become known as the product manager who can take something from just an idea in someone’s head to something that a person can use and play around with, and that can be helpful to a lot of people. You’ll be a finisher. Heck yes.
You have a new roadmap. Now what?
So you’re done with your product strategy meeting. You have your new shiny roadmap. The team is super excited to get to work. The energy in the room is electrifying.
But there’s a little bit of a looming black cloud over your head…
Who’s going to do this? How long is it going take? What do we need? Are there dependencies that we don’t know about? Are there stakeholders who aren’t going to dig some of these ideas?
There’s a lot to think about. The good thing is that you can reduce the overwhelm you’re feeling with three simple steps.
Step One: Define Scope
The first step is to define the scope of each of these stories on your roadmap.
This helps you figure out what is and what is not included in each of these stories.
Say you’re building a drag and drop feature for a landing page generator product. What does drag and drop really mean? It sounds like a silly question, but it’s something that you’re going to have to sit down and think about.
- Does this mean drag and drop on a single page that we have?
- Does it mean drag and drop everywhere throughout the application?
- Does it mean that it has to be accessible?
- Does it have to have certain qualities?
Write down what is and what is not included in each roadmap story.
Step Two: Write Specs
Once you have your scope defined, the next thing is to start writing your specs. So if you’re not familiar with them, specs basically tell everyone why this feature is getting built, what it entails, how we’re going to do it. It’s a big planning document that helps you really think through the feature that you’re about to build.
Your spec is going to include things like user stories (super critical), mock ups and wire frames that you’re going to have to work with your designer on, timelines, dependencies, and so much more. Here’s a bit more on how to write specs.
Now you have your scope and your specs. Let’s chat about the other dreaded “s”…stakeholders!
Step Three: Get Your Stakeholders On Board
This is where things get a little bit squishy and hard to teach… how can you get your stakeholders on the same page and behind the thing that you’re about to build?
It’s tough to do, especially if your stakeholders aren’t exactly on board with a particular idea or maybe someone else’s thing is getting built before theirs and they’re a little ticked off at you because you’re not building their thing.
If this is the case, you need to talk to each of your stakeholders, particularly the ones who are pushing back to really try to get them on board and show them why you’re building it and why this is good for them.
Once you’ve got most of these in place (sometimes stakeholders do come around and sometimes they don’t. You’ll have to push through anyways), it’s time to build.
So once each story has a story, a spec, and the stakeholders are on board, it’s almost as simple (simple, not easy) as handing off everything to your engineering team and then being the go between for your engineering team and the rest of your stakeholders.
Before you know it, your engineering, your team is gonna come back and they’re going to be like, “Hey, here we go, let’s test it, let’s deploy it”.
And then bam! You just went from a line item on a roadmap to something that your customers can touch and use and hopefully get a lot of value out of.
The 3 top product stories from around the web. Every Sunday.
We scour the web looking for the best PM articles for product people at smaller companies. No fluff. Just the good stuff.