Product Development Roadmap Definition:

A good way to think of a software development roadmap is to imagine a high-level, visual representation of any important milestones and objectives in product development. Then, the overall goals and directions can be communicated to stakeholders and teams with a flexible priority order in mind.

Roadmaps are made at the beginning of a project and should be frequently amended, reviewed, and updated as the project progresses - this really fits in line with an agile mindset and allows for iterative development from stage one! Following guidelines in software development can help teams and partners to stay on track and keep with the goal.

As we pride ourselves on being an extension of our partners, a roadmap is definitely a great place to start to hit those milestones!

These types of pre-planning can include the following elements:

• Overall goals or objectives;
• Key milestones or deliverables
• Timelines and deadlines;
• Overview of phases;
• Information on budget and resources.

Gantt charts, timelines, and flowcharts are examples of roadmaps but do not function the same way or fit into the ‘ideal roadmap’.

To get all philosophical, there can be a lot of ways of defining and conceptualising a roadmap (they can actually be totally subjective!). Many people have different ideas about the “definition debate”!

In the book ‘Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty’, Roadmaps are categorised in several ways, including but not limited to (we won’t bore you with all the specifications!):

• As a tool for product development and management,
• To set direction and goals, and align teams,
• As uncertain - a constant in product development.

For this piece, we caught up with our Product Owner expert Eddie Harrison to talk about how roadmaps can be looked at as well as give examples of some “yays and nays” when it comes to roadmap planning.

Roadmaps - the debate:

When we spoke to Eddie he highlighted the usefulness of product roadmaps:

"While there is a healthy debate in the community about what is and isn't a roadmap, I believe that regardless of definition they are a vital tool for indicating your current intent and achieving alignment across the business on your priority.

A great roadmap sets the direction for now, and gives an indication of the future, but it should be adaptable to allow quick reaction to new challenges and opportunities. For me, a roadmap is not a delivery plan filled with timelines, but can happily exist alongside one - the main aim is to clearly set the priority."

Now, Next, Later Roadmap:

The “Now, Next, Later” Roadmap was initially introduced by Janna Barstow due to her frustrations with deadline-focused timeline roadmaps.

Barstow invented this concept so that product teams could focus on discovery and learning based on current data - this means teams avoid ticking off tasks on a to-do list and not iteratively focusing on the goal!

The “Now” phase focuses on things currently being worked on and are due soon; the “Next” phase includes things that have been agreed on but have not yet been started; this is always subject to change also! Finally, “Later” includes items identified as important and valuable but might not be ready to be started!

This kind of roadmap can be seen as preferable to more linear options because it’s agile and flexible and promotes continuous improvement, development and communication between teams! It is a less overwhelming roadmap model because it focuses the team on what is essential RIGHT NOW and means there is no obsession over what may or may not happen in the product’s future. Again, this links us back to embracing the uncertainty of a product’s journey along the roadmap.

Why Product Roadmaps Fail:

Sometimes things just don’t go to plan, whether that be in day-to-day life or, more specifically, in product development! There can be many reasons why your product roadmap might not work out how you envisioned; here are a few:

• The roadmap might not be aligned with the client’s goals;
• Communication and collaboration might be poor between stakeholders, or they may not have read or agreed on the roadmap;
• People and team allocation aren’t up to scratch;
• Direction and priority of tasks and goals aren’t first and foremost;
• Reassessment and readjustment of goals based on the market just aren’t happening;
• Timelines might be unrealistic or optimistic;
• There may be too many tasks and too much information on the roadmap;
• It might be too linear and rigid, not allowing for agile and flexible change;
• Interdepartmental teams (such as sales and marketing) may not be asked for input, or dependencies on other teams/products/services etc., might not have been considered.

Product development roadmaps may also fail due to something called a “buildtrap”. A buildtrap can be summarised as building feature after feature without looking at whether that feature is really adding value to your customers/the business. The impact should be measured, and this should feed back into your roadmap (which is why they can change so often with new learnings!)

Mindera and Roadmaps:

With Mindera’s unique culture and way of working, we know our teams are proud of the work they do from conception to completion!

Our product roadmaps are an extension of our culture and our motto - “we craft software with people we love”. Our expert teams are super proud of their work and have the know-how to solve problems, come up with solutions, and propose initiatives that will work along every step of your product’s roadmap! Every client is unique with their own set ways of working - we recognise this along the whole product journey!

Want to partner with people who know their roadmaps? Get in touch!