Talk to most product people about timeline roadmaps and there’s a high chance they’ll lightly wince at best and heavily shudder at worst.
Why have timelines received such a bad rep in product management over the years? Probably because in the long term, timeline-based roadmaps can encourage teams to focus on features rather than real sustainable value. They often also fail to reflect the uncertainty of software development.
Here at ustwo, we’ve been working with Joe Wicks and The Body Coach for a year and a half to make the world fitter, healthier and happier. Our work has included designing a new business model, a subscription strategy, a back-end system to support clients with their progress, and a website to communicate Joe’s vision.
After launch we moved into a very different phase of the product life cycle. While timeline thinking served the team in the pre-launch phase, we realised that to create true long term value, we’d need to move away from timelines and towards outcomes.
But this is easier said than done. Transitioning a team and client deeply entrenched in timeline thinking is no easy feat. How do you smoothly move over to the promised land of outcomes when it’s entirely unchartered territory for the team?
I’ve broken down how we transitioned out of a timeline thinking on the Body Coach, and how you can too:
- Identify the problems timelines are causing your team and product
- Communicate these problems to stakeholders
- Revisit your tooling and language, and document decisions around these
- Design robust product goals
- Stakeholders do need some visibility of dates, so build a release plan and milestone calendar with that in mind
Launch mode: a fresh new fitness app
When the team first started working on The Body Coach app, we were in launch mode, working towards fixed timelines. We deliberately worked this way. We identified our Minimum Viable Product (MVP) and bucketed it into one release. Then we adopted a timeline roadmap to build this MVP early in our process and provide some level of certainty to the team (as a digital studio, our clients often have limited time and resources).
After nine months of intensive discovery and build work, we released V1 of The Body Coach iOS app into the wild and it was a great success. We received an amazingly warm reception in Apple’s App Store and the app has since topped the health and fitness chart. But of course, we were only just getting started!
Live mode: a transition period
Shortly after launching, we found ourselves in a very different world than building our initial greenfield product. We’re now live, in the market, with real life users! This means entering the product manager’s coveted land of data aplenty! We have rich qualitative and quantitative feedback such as usage data, a Beta programme, surveys and customer support requests guiding our product decisions.
All of these changes mean we’re now operating in a more complex world; an exciting one, with tons of opportunity, but also more tradeoffs. Iterating on a live product requires a mindset shift. Pre-launch we had to be ruthless in scope, constantly looking for opportunities to trim. Now we must look for the highest value opportunities and try many small things.
Post launch we quickly understood the importance of clear direction that we can communicate across the team. We knew it was urgent to usher the whole team towards an outcome-based approach to solve user problems.
What the heck is an outcome?
In product development, an outcome is a measurable change in customer behavior or business value (these are usually positive and beneficial changes). Adopting an outcome approach means focussing on solving problems and delivering value. Some examples of outcomes we’ve worked on for The Body Coach app are to:
- Help users experience the value of the app early on
- Make it easier for users to shop for the plan
- Help users locate recipes faster
This is different from a feature-driven approach. Features can be thought of as solutions that ladder up to solving an outcome.
So in the case of the examples above, the features we worked on were to:
- Help users experience the value of the app early on → build a free trial experience for our users
- Make it easier for users to shop for the plan → allow users to export a shopping list
- Help users locate recipes faster → build recipe search
There is a time and a place for adopting a feature-first approach. For example, if there is a highly requested feature from your customers, it could very well be worth building (although not always). That being said, it’s still important to be clear on the outcome you want to achieve when building said feature.
Adopting a primarily outcome-based approach is usually a godsend for most teams because it allows them to think critically about the types of solutions that will have the most chances of driving value. The business benefits too, because teams end up working on impactful solutions that will drive towards business goals, rather than getting hung up on how fast they can deliver poorly thought out features they are unsure will have the desired impact.
There are a number of ways that teams can transition to thinking in outcomes, but moving towards this mindset is no small feat; it’s a culture change that requires continued effort.
One way we started to introduce outcomes was by ditching our timeline roadmap.
Why timeline roadmaps continue to haunt product teams
Roadmaps are a common way of expressing product direction to teams. Many product people get up in arms about roadmaps not being timelines. Why? Because we know they are painful, yet they still persist (there are many reasons for this, and you can read more about the different scenarios in Andrea Saez’s excellent post on timeline roadmaps).
A timeline may have served a team early on. But in the case of roadmaps, timelines go very quickly from comforting to tormenting. How can you liberate your team?
To the Promised Land!
As a product team, we were well versed in the value of outcome thinking. We also knew firsthand that a timeline roadmap was no longer serving us and wasn’t sustainable at the stage and scale we were at. Yet, transitioning to an outcome roadmap is easier said than done. Here’s how we did it:
1. We identified the pain it was causing us as a team, and the whole business
First we needed to get clear on why timelines were so detrimental to product development at the current stage of work.
For us, the timeline was leading to the team focusing too much on feature delivery as a measure of success. It was showing us how fast we were moving through the features, but it wasn’t giving us a sense of whether we were working on the right things and delivering value to our customers.
We framed the problem as potentially costing the business money. If the team is spending time and energy working on features we aren’t sure deliver value, this could effectively be like flushing money down the drain. Nobody wants that.
"projects to products"
— John Cutler (@johncutlefish) July 3, 2021
"outputs to outcomes"
"waterfall to agile"
Have been reflecting lately that this is still leading with the Way not the Why.
Explain WHY this will be better for customers, the customers, and the team. Lead with that.
Otherwise... (1/n)
2. Communicate the gains to stakeholders. Over and over!
Introducing change is never easy. It requires a clear goal and strategy to work towards. On our mission to get rid of the timeline, we did the following to “campaign” for an outcome roadmap:
- We documented reasoning in our knowledge hub (Notion) to explain how our timeline was built around outcomes. This allowed us to stay on message, and it meant stakeholders could easily access information.
- We had sessions with team members to help everyone understand the gains of moving towards outcomes. We stopped talking about “features” and instead talked about “outcomes”. We also introduced learning and experiments as key concepts that underpin how we work.
3. Consider whether your tools are serving your roadmap
A good roadmap can be communicated with the most rudimentary of tools. You don’t need fancy software to get your direction across. A spreadsheet can often do the trick.
But make sure to consider whether your team is using tools that bias you towards timelines.
We revisited the tools we were using and opted to use Notion to communicate our roadmap. We love its flexibility and clarity. I’ve written previously about how to design a roadmap that your whole team will understand here.
4. Design robust product goals
Most teams that are outcome-based in their thinking still need to march to the beat of fiscal quarters (or the business year).
Ensure your team can clearly articulate the key metrics you intend to drive in a given quarter (or another given period of time). We use OKRs (Objectives and Key Results) to frame our goals.
5. Build a release plan and milestone calendar
As much as many product people would love to live in a world where dates don’t matter, they do. In our case, The Body Coach team needs to plan for marketing activities and promotions. This includes taking into account the seasonality of operating within the fitness space.
Save yourself some energy: don’t take on battling Western philosophy around linear time! You’ve got places to be, products to build.
Deal with key dates and releases by building:
A key dates calendar
First, discuss with stakeholders whether key dates are in fact truly necessary and not arbitrarily set.
Then, build a key dates calendar to take these dates into account. Make sure you regularly revisit it with the team. This will allow you to effectively plan around these dates. This is how ours looks:
A release plan
Stakeholders do need some reasonable visibility of dates as the product team moves closer to releases. This is where a release plan can help.
Create a separate document that captures your releases. Ours looks like this:
Conclusion
Timeline roadmaps can create waste and enable bad habits that are at odds with product thinking.
If you’re looking to ditch timelines in favour of outcomes, be organised and strategic about how you do it. A good way to start is to adapt your roadmap. Identify the pain of timeline roadmaps, communicate the gains of outcome roadmaps and revisit tools. Make sure to account for real, hard dates by introducing robust product goals, a key dates calendar and a release plan.
Sources & Further reading
- How To Build A Product Roadmap Everyone Understands by Andrea Saez
- Free Your Product Roadmap and Ditch the Timeline by Janna Bastow
- Myth busting: Why date driven roadmaps are not roadmaps by Andrea Saez
- Launch mode vs iterate mode by Paul Adams
- Designing a roadmap that speaks to your whole team
About the writer:
Hilary Johnson is a Product Leader, Advisor and Product Coach currently working on product growth with ustwo and The Body Coach.