Roadmaps

What is a roadmap?

A product roadmap is a plan of action for how a product or solution will evolve. It helps the product team to determine what they should be working on and when. It's more or less a prioritized list of features and projects.

Open

What roadmaps usually look like

Why do we usually want Roadmaps?

1. It helps us make sure we work on the highest-value thing first.

2. It helps run the business, it's a plan that indicates when we'll be able to launch key capabilities or features.

3. Share it with customers and give them insights into when they can expect what

There are all justified reasons. Yet, typical roadmaps are the root cause of most waste and failed efforts in product organizations.

Problems with Roadmaps

We have been there ourselves before, and there are a ton of resources you can find out there that describe the problems inherent to roadmaps:

• It leads to very poor business results.

  • Because just not all our product ideas are going to work out.

  • Many ideas usually need multiple iterations to get to the point where they deliver expected business value.

• We don’t build software to ship features, we do it to solve problems and get the jobs of our customers done.

• A roadmap itself isn’t of value. The value is in the conversations you can have around it, once you use it to outline your assumptions.

• It causes unnecessary pressure for everybody on the team because if you have to be honest, how often do things work out exactly as you planned? Deadlines mean pressure, pressure means shortcuts, and shortcuts result in friction that will slow you down in the long run.

• We are still an early-stage company so context tends to change quite quickly. You can’t do that if you have a roadmap of features for the next 6-12 months.

To conclude, the most important problem with Roadmaps is that no matter how many disclaimers you put on it, people will interpret it as a commitment. And that’s the crux as you're now committed to building and delivering something, even when it doesn't solve the underlying problem.

The problem with commitments

Uncertainty

We don’t have a crystal ball. Say we have features A, B, and C we want to build. We don’t know if A is going to work out as planned, and what that would mean for B. We don’t know if we’ll have a eureka in the bathtub one day, and new idea X will suddenly feel much more important than B or C. Or we might start building out B, only to realize that it’s not what we want or it’s harder than we thought and want to bail on it.

In short, we don’t know enough to make good on any promises. Roadmaps are predictions and assumptions. But we can’t predict the future. Priorities change. Shit happens. And we have to adjust.

Expectations

Leadership might be ok with changing course, but what about everyone who saw the roadmap and was eagerly awaiting feature C? What about the conversations with customers where someone in the company assured them to just hold tight because C is coming? Despite our best intentions, if we say we’re going to do something, it’s going to be hard to back out of that, both internally and externally.

Guilt

Have you ever looked at a long list of things you said were you going to do but haven’t gotten around to yet? How does that list make you feel?

The realities of life and uncertainty show us that 100% of the things on the roadmap are not going to happen on time the way we imagine. Meanwhile, the world is not going to stop and wait for us to finish the old list.

New ideas are constantly coming up. New requests and new problems constantly arise. If we hold ourselves completely to the roadmap, we’ll have to say no to new important things we want to do. And if we interrupt the roadmap to do those new important things, we’ll have to push back other things we promised. And that won’t feel good.

The alternative

The value a Roadmap brings is still valid so the alternative still needs to account for:

1. Making sure we work on the highest-business-value items first.

2. It should help with planning and making date-based commitments.

3. Giving customers insights into what to expect.

Make sure we work on the highest-business-value items first and should help with planning

This is what our Strategic context and https://awellhealth.atlassian.net/wiki/spaces/AH/pages/3503980690 helps us to do and we believe this should aid our teams to figure out what are the most important problems to solve next and what are the best ways to solve these problems.

Making date-based commitments

There can, of course, be cases where we will get a specific question like “Do you integrate with platform X, and before we buy, can you tell us if and when you will be integrated with it”? That’s a pretty reasonable question as that integration might be table stakes for them to use our product.

Whether or not we would want to fulfill such a request would be a strategic decision first. However, the timing question can be treated as https://awellhealth.atlassian.net/wiki/spaces/AH/pages/3509682222.

Give customers insights into what to expect

It’s not unusual for a customer to ask us what our roadmap is because we understand that customers are making a significant bet on Awell. They are not only buying the Awell of today but also the Awell of the future so it’s a reasonable ask from them to know in what direction we are heading and whether that aligns with the direction they are taking.

Based on , we know what the problems are with a feature-based roadmap so what else can we do? Instead, we can share the (3-5y out), (a couple of months out), and (what we know will be coming).

Sell the vision and the product you have today, not the roadmap.

The key difference is that neither vision nor strategy focuses on the “how” or the features we will deliver. It focuses on the direction the company is taking in the long term and what problems we are planning to solve short-to mid-term to get to that vision.

FAQ

Q: Can we ever run into a situation where an important customer needs something specific to keep using Awell? This is a problem not only Awell has, but actually a lot of start-ups.
A:

• Yes, that’s why we have

• But, we should be aware that chasing or capitulating to customer-specific requests has a risk to end badly.

• Until a certain point, working with early adopters and leaning more toward fulfilling customer-specific requests is okay. At that point, building our product with these early adopters will give us so many learnings and insights which we don’t want to miss out on.

How can we manage customer expectations when they are asking for a 1-year roadmap as a way to determine contract renewal?

• We should keep in mind that we want to build software that can help all healthcare organizations, not that one client. We want to make an impact on many lives of care providers & patients and we cannot do that by focusing on one customer only.

• Money should never come with influence or power. It’s a lot easier to do the right thing for the many when you don’t fear displeasing a few super customers could spell trouble.

Resources

• Marty Cagan - INSPIRED: How to Create Tech Products Customers Love – 2nd Edition