How to Look at the Product Roadmap from an Engineering Team’s Viewpoint

Elena Polubochko is Chief Technology Officer at Godel. In a recent virtual client event, she ran a webinar on how to look at a product roadmap from an engineering team’s viewpoint, the challenges it presents and how the «discovery phase» can help overcome these challenges.

Product Vision — Roadmap — Backlog

The Product Vision (what) is the strategic communication tool, overarching each cross-functional team consisting of different roles (e.g., Developer, QA Engineer, DevOps) and describes the purpose of the product. It connects technical details to businesses goals and roadmaps, aligning the whole organisation around it.

The Product Roadmap (why) is a set of features or wish list, describing how the product is likely to grow over the timeframe. The roadmap delivers the expectations of the product delivery, acting as a ‘living document’.

The Product Backlog (how) is the tactical tool, presenting a list of new/existing features, bug fixes, plus a number of details necessary to progress the product.

It is better to take a top-down approach so every decision made on the roadmap will be clearly communicated to the team. This approach will convey the product vision to anyone across the business, ensuring stakeholders are on the same page. It will also make it easier to clearly see your product’s vision and clearly identify priorities.

How do they connect?

The technical information comes from the product backlog, but this is subject to change along the way. The roadmap feeds the backlog, which can be interpreted differently for each person. A different audience requires varying levels of detail, taking into consideration: the timeline, the scope of the roadmap (product vs teams), consolidating the view in the roadmap to get a holistic view and deciding technical objectives.

It’s also important to identify the tooling to build the roadmap. Tooling is designed to assist product managers and project management teams in planning, allowing them to map the strategy and create products that align with the goals.

As an introduction, the team will ask, «What would you want to know?». This allows the engineering team to understand more clearly how they will get to the destination. A release plan takes these details and breaks them down in detail.

It is important to follow-up during the project — asking about the roadmap and checking how the project is progressing. Roadmap visibility helps the teams work autonomously and provides a clearer picture of the future, a better understanding of the strategy and priorities, and makes sure everyone is aligned to the proposed dates versus the real progress.

Mapping out the challenges

When creating the roadmap, aligning the teams to a single plan can present its challenges when working out how to manage the roadmap and backlog. Here is a list of the common challenges:

Not having a roadmap or sharing with the team — If it is not clear what the team is doing, it can bring on feelings of anxiety.

Too complicated — Not everyone will have the same comprehension when it comes to translating technical language, so communicating and clearly stating end-goals will allow all parties to relate it to the work they’re doing.

Focusing on solutions, not problems — When implementing the roadmap, it can be easy to get caught up in the solutions your team plans to build, but it’s important to understand and solve the problems that occur.

No clear distinction between the roadmap and backlog — A lack of details before implementing the roadmap doesn’t set the direction of travel.

A phase of discovery

The discovery phase is about researching and defining the scope of the project. This involves activities such as looking into what a business wants to do it and the benefits, a desire to do further research to solve the problem and to outline the draft plan of the roadmap. Before the discovery phase, it is essential pre-requisites are met to identify and validate the business problem, identify key stakeholders and have the expectations that the discovery phase is clear.

The product owner works with the client stakeholders before planning sessions, refining the backlog for the team and translating it into user stories for the developers, and ensuring product feedback is a two-way street.

During the discovery, the teams analyse the users, the technical landscape and the ways of working. After this, the first draft of the release plan is then created, taking into account the backlog, high level estimates and refined stories for the first stage. It could be a case where the backlog is in place, but it’s not estimated. If the high level of detail is not there, it can bring on feelings of anxiety due to the lack of transparency. It is key to try and implement this to ensure everyone is happy.

Of course, there will always be challenges during the discovery phase, however they should try to be addressed and fixed as soon as possible. Examples of these are:

The pre-requisites aren’t ready.

Struggling to balance the time available.

Getting time with key stakeholders.

Releasing only some of the plan.

Not checking against the roadmap.

Not revisiting it once the project starts.

A key takeaway is that planning creates confidence. We all like to have a plan and the technical roadmap provides the necessary tools for the team to deliver the project. The roadmap is the initial communication tool. Without it, the messages won’t be clear, so it’s important to clearly communicate the key objectives. Lastly, re-visiting the roadmap regularly, whilst understanding that things alter along the way, maintains a clear picture of the future which drives the transparency and alignment for the engineering team.

Webinar questions answered by Elena

«How would you plan a discovery phase when there is a lot of ambiguity about the problem?». We come when the problem is already mapped out and come to find the best solution and release plan.

«How to calculate capacity of the team where in several cases one team is working in parallel to many projects?». Split the capacity of the product, ideally having two streams of work.

«Do you cater for constantly moving timelines? Whilst the roadmap is a working document, continually iterating could cause concern amongst the project team that this isn’t being managed tightly enough?». When we do original estimates, include estimates for high level risks of bumps in the road that could occur. It’s getting the balance of implementing something, getting feedback and knowing what the low-level risks are. There are two sides — deep level analysis with a 3–6-month horizon to flush out minor details, and close daily collaboration — this is how we tackle problems early in the cycle.