There’s only one thing that will get you anywhere in the tough world of product (and no, it’s not cool swag). The thing you need is real product vision.
Because here is what’s happening to your team: A product enters a new market and sees some success. Then more products follow, making the space more competitive. That sparks a tendency to hunker down on whatever’s working, but not to really innovate.
Instead of breaking ground in the industry at large, you (or your stakeholders) ask:
- What are our competitors doing?
- What features are our customers asking for?
- What can we do that is incrementally better to keep them from running off to the competitor?
And so, quarter to quarter and sprint to sprint, you start to think smaller.
Hit The Road Running
Breakthrough products don’t come from thinking small. They don’t come from the fear of losing ground, either. They come from thinking big and responding to change better than everyone else.
A great product arises from asking the question: “What’s the best way to solve this problem?”
Agile product roadmapping helps you answer that question in safe, controlled iterations. From your vision, you set goals. From your goals, you define desired outcomes. Then you launch a series of experiments in sprints to meet those outcomes. If you meet them, you move onwards. If you don’t? Take a coffee break, then pivot.
Thinking both big and small: It’s what elastic, vision-driven product teams are doing differently. It’s what belongs on your product roadmap, and it’s what agile roadmapping is all about.
The following ideas will help you plan your next product roadmap for top-to-bottom clarity.
What’s An Agile Product Roadmap?
An agile product roadmap revolves around desired goals and outcomes, instead of features or timelines.
With an agile roadmap, you can communicate both your big picture narrative—that pie-in-the-sky vision—and the series of steps you anticipate will help you meet that vision over time. The steps matter, but they also don’t.
Technology will change, new and unexpected markets will open up, business will boom or suddenly drop, and all of these changes will affect what you’re able to build both in the short- and long-term. You can’t exactly know what you’re going to build ahead of time, but you can plan for how you’re going to respond to change in order to keep on track with your innovative vision.
An agile roadmap helps you communicate your priorities in clear “what problems are we trying to solve?” terms for everyone you work with.
You don’t need to know exactly what you’re working on ahead of time. It’s fine to have a fuzzy idea of what’s way out in the future and prioritize what’s coming up now.
Agile Product Roadmap - In A Nutshell
Using an agile product framework, you can focus your organization around a repeatable, collaborative process that gives you some awesome team perks:
- You focus on the best way to solve the problem rather than plan features first and work backwards.
- You are super customer-centric. It helps you think about what you’re building, why you’re building it, and for whom.
- By listing what teams are involved, everyone at your company becomes responsible for pulling their weight to meet that outcome (not just product or engineering).
- You can also collaborate with everyone to build up good ideas and get buy-in.
With agile roadmapping, you’re working your way from problem to solution, not reverse-outfitting a feature to solve the problem.
The Theme Is #Winning
So you have this big, inspirational vision, but you also have dozens (and possibly hundreds) of tasks that bog down your backlog each week—some mundane and others impossibly large. Themes are a sort of filter between the two, and they help you determine what actually makes it to your product roadmap.
Filtering tasks through themes that adhere to the topline goal is a step that ensures you’re only working on items within the roadmap scope. It also helps you control what makes it to your developer backlog in Trello, so only items you’ve cleared as on-vision make it to the team’s sprint.
In a nutshell, some solid wins come from applying themes to your upcoming work:
- Consolidate similar ideas: Duplicate and similar tickets can make it look like there’s more in your backlog than there actually is. Themes will help unearth their similarities.
- Understand the problem behind incomplete tickets: Tasks left in the backlog sprint after sprint are usually a symptom of a larger issue. Use theme fit for direction, then dig in to find the root of the problem.
- Tie customer feedback to product backlog: What are customers saying? What are the big problems? What are they struggling with? Feedback can clue you into ways to better ways to solve a problem.
- Get your team involved via team votes/collaboration: Getting your team involved when a task is sitting in the dev backlog slows things down immensely. This should happen before a task is pushed out for a sprint, so it’s very clear what a task looks like.
- You fill out product specs: How much time and effort is needed? What is the business case for building out this product?
Themes are the building block for agile product roadmap. After all, you need to figure out what you’re building next and why.
You can also use them to start assembling ideas for big ideas you might want to tackle in the future, even if you’re not quite sure what that may look like yet. Drop a theme into the Future column so you can communicate what’s on your radar. You can collect feedback, ideas, and start forming an inspiration backlog with the help of a theme to stay on track.
Keeping Projects Flexible
Before diving into agile development, it’s important to remember that capital “A” Agile doesn’t work for everyone.
I once worked with a team that had a dedicated scrummaster hired in to set up 'by the book' agile scrum, and he was super strict about following the process. However, the company didn't have a clear product vision, and the roadmap was done away with in order to allow agile to work its magic.
The result: I've never seen a team work so quickly and get so much out the door—and yet still build all of the wrong stuff.
Agile with a capital “A” isn’t as flexible as you might need it to be. If you go by the Agile Manifesto, you only actually plan one sprint at a time and maintain the rest as a prioritized backlog. (Mind The Product’s Martin Eriksson has called the original manifesto “dogmatic,” even.)
That’s why I recommend “agile” with a little “a.” It’s based on the original manifesto, but you can bend it to your team’s messy reality.
What does this look like? Typically, we see people planning out two or three sprints in detail, each representing about a two-week duration. Sprints further out in time are still up for grabs. If you learn something after Sprint 1, maybe it means that your original plans for Sprint 4 need to change quite drastically.
Flexible agile also allows for larger, known projects to be worked on in iterations, even if the end goals are fixed.
We use a Kanban board similar to this:
The goal is to push features live as you go so they can start adding value to the product and have that feedback loop going into your next sprint. Shipping quickly helps estimate the scope and define what you build in your next iteration. Sidestep the large timeline with a ton of features, and you’ll worry less about how long that might take.
Wrong moves realistically happen pretty often Shipping something that falls flat or it doesn’t go as you expected it to is actually a daily reality for product teams.
Agile roadmapping is a perfect buffer against those “oops” moments:
- X didn’t work? Modify for the next sprint.
- Y didn’t work? Now you know and you can modify your product strategy.
When your product roadmap is agile, it gives your entire organization the ability to shift focus and still keep everyone aligned towards the same goals.
As long as you communicate the direction you’re taking your product, your team will always be on track.