Free Your Product Roadmap and Ditch the Timeline [Mind the Product]

I recently tweeted about timeline roadmaps saying they had to go. It’s something I’ve said in the past on conference stages, webinars, podcasts, Twitter, and elsewhere. I even wrote about it in my Mind the Product blog post, Lean Strategies for Maturing Products. So, when people replied to my tweet with questions I figured a post answering them might be helpful. Here’s what happened, along with my answers to those questions.

It wasn’t my plan to start a big old Tweet thread. On a quiet Sunday, I was checking out Ecosia, a new browser that puts your search-result ad dollars towards planting trees instead of lining Google’s pockets, and I thought it was an honourable cause and worth a switch. I tried a couple of searches while I was testing, including one of my favourites: search for “product roadmap” under the Images tab (whether in Google or Ecosia), and you’ll get a bunch of timelines.

When I saw the results I thought it was worth saying on Twitter what I’ve said before: the timeline roadmap simply has to go (said Twitter thread caught fire!).

As a publication, it’s had thousands of retweets and likes, and more importantly, lots of people coming back with various reactions. Most love this freeing idea of ditching their timeline roadmap, and many have already been doing this for some time. A number of people jumped on the thread with advice and solidarity for those who are about to make the leap.

So what did I do with it all? 280 characters – even when you’ve got lots of tweets in a thread – can be limiting, and plenty of people still had questions. I noticed trends in the sorts of questions that were cropping up, and they aren’t dissimilar from the ones I get when I talk to product people in my day-to-day work. So here’s my FAQ on moving from a timeline roadmap.

Frequently-Asked Product Roadmapping Questions

1. My Roadmap is Fine, why do I Need to Ditch my Timelines?

The biggest reason people stick with the timeline roadmap is due to other stakeholders, like their boss or customers. Interestingly, a few people replied to my tweet in a way that suggested they liked their timeline roadmap and didn’t see a need to change.

It’s a bold assumption that you know exactly what to build, especially months in advance. The best product people aren’t the ones who make assumptions about the future and drive towards them. Instead, they know to surround themselves with experts and to ask the best questions. They know that markets and constraints change and that the best way to take advantage of opportunities is to remain lean with a flexible product roadmap.

A timeline roadmap simply doesn’t leave room for discovery and iteration, and at the end of the day, makes the product person look bad when delivery fails or the wrong product is built.

2. What About Showing Dates That are Absolutely Necessary?

Some folks (rightly) pointed out that there are times when delivery dates really are necessary to hit. How, they asked, is that possible if there’s no timeline in their roadmap?

This is where 280 characters falls short, as there’s a nuance: just because you don’t have a timeline on your product roadmap, doesn’t mean you can’t ever use your roadmap to communicate an important date or milestone.

We all want to be hyper lean and build the right things, at the pace required, with no looming deadlines to cause stress and tech debt. But, we don’t live in that world. Sometimes we do have externally driven, unavoidable, strategically important deadlines. Take GDPR for example. In the run-up to that, I saw many, mostly lean, roadmaps with cards on them with hard, specified dates leading up to it.

The key is this though: just because one item in your roadmap has a date, doesn’t mean you should give everything a due date. A timeline on your product roadmap does just this, and that’s why you need to ditch them. Your roadmap is meant to be a human-readable document that communicates your product strategy. If a key date is part of that strategy, write it down. However, the fewer key dates you commit to, the faster and more flexible you can be. That means you have a better chance to outperform your competition and build a better product.

Ditch your timeline altogether, and avoid date-driven deadlines as much as humanly (and legally!) possible.

3. How do I Show Dependencies on my Roadmap?

I think a lot of the questions about dependencies came from the assumption that a timeline roadmap would allow people to show the stacking of projects. This is shown in a Gantt chart sort of way, communicating a dependency.

But this format isn’t necessary to communicate dependencies. Your roadmap is a strategic communication tool, not a feature release planner. A Gantt chart-style format adds too much fuss and includes the trap of a timeline at the top.

Why not write down any dependencies or other important notes about the initiatives outlined on the roadmap? At ProdPad, we link directly to the roadmap card or idea we’re talking about, so the viewer can easily find the reference when needed.

That said, you should try not to overdo it with dependencies. Remember, your product roadmap is a prototype for your strategy. It’s not a detailed, unchangeable plan of what’s to come.

Use the lean format to communicate your assumptions to your stakeholders, and be ready to adjust. Don’t get too tied to all the details you might be tempted to add to your roadmap.

4. But my Boss Expects Timelines?

First of all, figure out why they expect a timeline roadmap. I see a handful of common reasons, each of which needs its own reaction:

Control

This is the worst reason I encounter. There are some people who don’t trust that work is being done unless they see it laid out. They buy into the fallacy that a deadline will encourage everyone to work harder and faster. In reality, it’s exhausting to gun after arbitrary deadlines. What the boss doesn’t know is that it often leads to burn-out and tech debt.

It’s an indication of a poor company culture and can be hard to push back on But if you’re in this situation, try appealing by talking about the risks. This could be accruing tech debt, losing good developers, getting stuck building unvalidated features, and not building the right things.

Investors

Sometimes it’s not the boss who wants to see the timeline, but the timeline roadmap becomes some artifact to show off to investors. It sort of makes sense. If you’re investing a million bucks, you might want to know what you’re getting out of it.

Except that a smart investor knows that they are investing in a great team. A great team knows that it’s not about what they build (because their first assumptions will always be wrong anyway), but about having a good process. A great team knows how to assess problems, propose experiments, and validate solutions, until lots of value is created.

If I were an investor, I would ask the team to show me a record of experimentation and an understanding of their space. I’d then trust the process to generate a product that would serve that space… and profit!

If you’re in this situation, talk about the risk that they are putting their investment in. Point out how high-performing teams build in discovery first, rather than a delivery mindset.

Agency-like Business Model

I see a lot of tension when I meet people who see themselves as product managers but their company requires them to be a project manager. I’ve been there!

This happens a lot, by accident. Companies take on custom or contractually committed work for a client, with an agreed scope and a due date. Suddenly, your roadmap, which could have been full of discovery and experimentation, is rammed with hard due dates. Your business has transformed from a product-led company to an agency.

Now, there’s no shame in making money in an agency model, except that agencies never change the world the way that product companies do. A company takes on a commitment for each client it works for and this is then a chunk taken out of potential discovery of new, tastier problems and solutions. If you’re delivering projects, you need a project manager and a project plan. Sadly, it’s often the product manager who inadvertently gets stuck with this role.

Again, you should appeal to your boss’ business instincts and talk about the risk and downsides of taking on such deals. They may mean sweet money in the short term, but they mean you’ll get surpassed by faster-moving competitors.  If the business wants to be an agency, then your bosses need to price, hire, and plan accordingly. If they want to be a product-led company, they also need to plan accordingly, and that means leaving room for product to lead.

Wants a Release Plan

Sometimes your boss (or your sales manager, marketing manager, or whoever) just wants to know when something in the works is going to come out. If they are talking short term, then it’s a fair question to ask. They are asking about a release plan, not about your product roadmap.

A product roadmap is a strategic document that outlines long term assumptions, your release plan is a separate document altogether, and shouldn’t look like your roadmap. It’s super short-term and only outlines the work that’s been agreed upon, spec’d and planned. It’s there to help the team coordinate delivery. The roadmap helps with discovery, checking assumptions long before you enter any sort of delivery mode, while your release plan is all about delivery mode, once you’ve validated what you’re building.

You can avoid painful moments by keeping these two documents separate. Then your stakeholders aren’t tempted to ask about the next delivery date, which obviously you won’t know yet. You haven’t even validated the right things to do, so you certainly won’t know when you’ll have them done by.

Strategic or External Dates

Sometimes there are hard dates that we have to work to. And as much as we’d like to be hyper-lean and not have to bend around constraints, we don’t live in that world.

You should find out if they are absolutely necessary (legal requirements, aligned with the company’s desired business model?) and not a distraction. It’s easy to fall into the trap of becoming more of an agency than a product company, and it happens if you accept too many arbitrary deadline-driven projects.

If you do have the occasional hard date to communicate, you can still ditch your timeline roadmap. A timeline roadmap forces you to show a deadline for everything on it, so instead, use a lean product roadmap. If there’s a date to communicate for one initiative, add that information to that particular card.

Yes, having some regulatory or unmissable date forced upon you means you’re not ever going to be 100% lean. But, don’t let your boss force your hand into another way of working by requiring a timeline roadmap.

Your execs probably don’t care which features are being delivered and when. They just want to know that their teams are putting their best efforts into creating value for the company. A timeline product roadmap has been shown time and time again to be a hindrance in creating value. A lean, discovery mindset and way of working outperforms every time. Show your boss the outcome you’re going for, the value you’ll add and the problems you intend to solve.

And if all else fails, it’s usually easier to ask for forgiveness than permission. Switch to a lean product roadmap next month, and see what sort of reactions you get. It actually works just fine for most product people who try.

5 But my Customers Expect Timelines?

Let’s unpack this one, as there are different types of customer expectations:

Is your roadmap full of features that you’ve committed to clients? Is this in exchange for money, so your company gets paid when you deliver the work? Congratulations, you’re an agency, not a product company. That document you’re looking at isn’t a product roadmap at all, it’s a project plan. Making money this way certainly changes the nature of the business. This is a delivery focused business, which exchanges time worked for money.

I meet a lot of companies who take a blended approach: some, but not all, of the items on their roadmap, are client commitments. I like to point out the trade-off that’s been made. Each client commitment creates an externally-driven obligation to meet an expectation – usually to deliver some combination of scope, quality and time – in exchange for either money or (in the case where the assumption is that the feature is going to get you the sale) a logo to put on your marketing collateral. All well and good, but your team is artificially slowing down its ability to do true customer discovery when it takes marching orders from individual customers. It’s a step away from being lean and from being able to solve potentially more interesting problems for even better customers.

6. I Build Hardware. Is This Even Relevant to me?

Product management for hardware and software products is fundamentally the same,  but they operate at different scales and paces. Hardware is naturally slower, it can’t be manipulated and iterated on as quickly as software. The nature of procurement and manufacturing means it takes longer.

So while a release plan for software might be days or weeks, sometimes the equivalent is many months in hardware, certainly, once you count in the moving parts like shipping components from overseas and lead times on manufacturing. That part is still a release plan, though. The length of it makes it look like a timeline roadmap when it’s not.

This presents a couple of challenges for hardware product people:

1) You need project management skills in the team to pull off a successful launch, even more so than on a software team, due to logistical challenges

2) Discovery needs to be done far in advance because your releases are so long. So you still need a lean roadmap which outlines your obstacles and problems and which helps to articulate your product vision. This document is different from your project release plan. But don’t forget the bonuses of building hardware: you’re creating things of value that are considerably harder to replicate and therefore more defensible from competition, and so the increased challenges are often worthwhile in the end.

It does explain why hardware startups are more risky and often require more upfront investment. It takes longer to experiment and validate assumptions when you’re dealing in the physical world than when you’re contained within a 2D screen. But that’s not to say that continuous discovery is impossible in hardware. I recommend watching Tom Chi’s talk from the Mind the Product conference in 2012 about how he did rapid prototyping on hardware products like Google Glass.

 

The post Free Your Product Roadmap and Ditch the Timeline appeared first on Mind the Product.

Source: Mind the Product https://www.mindtheproduct.com/2019/10/free-your-product-roadmap-and-ditch-the-timeline/