How to be Lean and Agile AND have a Product Roadmap that does not suck!

When developing a product, a common trap that teams fall into is developing this “Roadmap” thing! To develop one, a lot of teams make this diagram that pretty much looks like a “gantt chart” and it probably makes you mad when you look at it, as long as you want to be “Agile” and do “Experiments” and “Learn” and be “Lean”!

But honest question here! How is it possible to have a the product roadmap looks like the following, and the same thing is communicated to “the business” and all stakeholders and expect everyone on the team not expect them to happen on those dates!

A sample “Roadmap” that some delusional “AGILE” teams use!

PLEASE, IF YOUR ROADMAP LOOKS LIKE ABOVE, BE HONEST TO YOURSELF AND THE TEAM AND NEVER MENTION ANYTHING ABOUT AGILE OR LEAN OR MVP IN YOUR COMPANY!

How is this Agile OR Lean? How do you “know” if the “features” you are building are the right ones and they will be used? where is the learning and experimenting part in all this? what if this is not the right product? are we still just pushing forward because we “know” better than the users?

Unfortunately, product development roadmaps traditionally push you in a direction and this kind of roadmap is neither lean or agile, and still since they look very familiar (they have dates, and promises of features delivered on certain dates) are very easy to be accepted and adopted, and no one will object them in organizations, since everyone is familiar with it! It is the “Gantt Chart” after all!

Because of this above issue, people who want to be lean or agile, many of them have abandoned roadmaps altogether, but at the same time lot of people in the team are nagging that they are missing the “big picture” of the product!

Software Development teams want a document that:

Puts the organization’s plans in a strategic context
Focuses on delivering value to customers and the organization
Embraces learning as part of the product development process
Rallies the organization around a single set of priorities
Gets customers excited about their product direction

At the same time, a product roadmap should not:

Make promises product teams can’t keep
Require a wasteful process of up-front design and estimation
Be conflated with a project plan or a release plan

Now more than ever I see a lot of new generation product development ideas that are lean and agile AND have proper roadmaps, which makes me really excited.

Here is a great thread on Tweeter by Janna Bastow so you know what I am talking about:

How do I check if my roadmap process rocks or sucks?

If you want to know your current Roadmap generation and management process is healthy you can use something similar to the following checklist:

Things to consider developing Product Roadmaps:

If your answer to any of the following questions is “No” or “Not sure”, then you should consider doing them. If your answer to them are “Definitely Yes”, then congratulations, you are doing great stuff!

Focus on Strategic context and Vision

Do you have a clear product vision that most stakeholders can explain?
Do you have measurable business objectives that most stakeholders are aware of?

Focus on customer value proposition

Does your roadmap focus on customer needs?
Are all of the things on the roadmap clearly tied to customer needs and/or business objectives?

Embrace experimenting and learning

Do you update your roadmap regularly, leveraging an evolving process?
Do you allow time in the roadmap to learn whether solutions are working before committing to solving a customer need?

Rally the organization around priorities

Do you use an objective and accepted method of prioritization?
Do you have an established process for achieving alignment with stakeholders?
Do you regularly present and share your roadmap with key stakeholders?

Get customers excited

Do you regularly present and share your roadmap with customers?
Do you seek customer feedback on the roadmap and incorporate it in your process?

If your answer to any of the following questions is “Yes” or “Not sure”, then you should stop doing them. If your answer to them are “Definitely No”, then congratulations, you are not doing stuff that would hurt your team!

Avoid overpromising

Do you have specific features, solutions, fixes, or other deliverables on your roadmap?
Do you have precise or “best-case” dates for things on your roadmap?

Avoid over-designing and over-planning

Do you thoroughly design a solution before putting a customer need or problem on the roadmap?
Do you have project info like resources, milestones, and dependencies embedded in the roadmap?

If you are developing a software product, I recommend getting his User Story Mapping book:

User Story Mapping by: Jeff Patton

If you liked this article, click the👏 below so other people will see it here on Medium.

Let’s be friends on Twitter. Happy Coding :)

Cheer!