One of the knottiest problems to untangle in the product development lifecycle is that of the product roadmap. Used correctly it can be a valuable tool for communication with stakeholders, and simultaneously an opportunity to allow a product team the autonomy to focus on value and problem-solving. Used incorrectly, the product roadmap can single-handedly impede rapid development, fast feedback loops, and the ability to really get to the heart of what your customers need.

The issue with the product roadmap is that it’s often only seen by high-level stakeholders involved with your product; and these are most likely the members of your organisation who are least familiar with the idea of agile, iterative software development. As such, the likelihood of a roadmap turning into a high-level, long term waterfall project document is unfortunately high. In these instances, development crews find themselves presented with a fully-formed, fully-specced feature (naturally, without the functional spec because we work *agile* here!), and are asked to implement it. In worse cases, these fully formed features that are thrown to a feature crew don’t even come with a rationale or justification behind them. The team is asked to build what they’re told, and they set about building what they’re told. Collaborative, no?

In the instances where this is the case, it’s the people most involved with the grass-roots of your product (and the people most likely to provide real innovation) that end up stifled. Think about it; a software developer spends every hour of his working day with your product – they knows its’ ins and outs, the backlog of technical debt that’s been accrued, the areas that desperately need improvement, and indeed could be improved quickly, if only the chance was afforded. They’re probably also keenly interested in the feedback received from the user base (if they’re not, they shouldn’t be working for you), and eager to explore opportunities to improve the product based on what the users of their (yes, *their* product) think. Developing a product roadmap which looks way into the future and demand a ready-defined feature from a dev team, not a problem to solve, cuts off this potential value at it’s neck.

By its’ very definition, a roadmap is a series of directions or steps, outlined and designed to allow you to reach a predetermined endgoal. And, as such, by its very definition a ‘roadmap’ is constrictive, inherently waterfall; development teams faithfully complete each task as outlined, and (if the business is very lucky), the end goal may be reached, eventually. Alternatively, the roadmap will continue to expand forever, a never ending nightmare car journey with that relative you really dislike.

This is an output-centric focus, and outcomes are unfortunately forgotten – because we’re on to the next shiny feature on the roadmap, and there’s no time ‘scheduled in’ for looking back (or worse, even when there is that time is 6 months later when it’s way too late). In cases where this happens, an agile approach is restricted to only be practiced ticket to ticket – and the real value-add which comes from company-wide adoption of this model is lost.

Sound like waterfall? Unfortunately, this is all too often the case in organisations getting to grips with the idea of agile, and indeed the idea of product development. Some of the biggest companies in the marketplace who work ‘agile’ are sat arbitrarily t-shirt sizing features for a product roadmap (“only a rough estimate, we know we don’t have all the detail yet!”) two years out from development. And these will, inevitably, be the companies who are rendered obsolete by the businesses who have clocked onto the idea that this is inherently flawed. Luckily, a simple shift in perspective can change all of this, and for the better.

Got a problem?

Problem-focused roadmaps are an ideal way for spanning this gap. Don’t get me wrong, none of us live in a world where hard and fast business needs don’t come flying down the pipeline to disrupt well-laid plans (and frankly if I was saying that there’s a product methodology that should be followed blindly irrespective of the circumstances, then I’ve been drinking the KoolAid too) – but these should most definitely be the exception, rather than the norm.

Building a culture where stakeholders can present you with a problem, rather than a ready-made solution or a feature to build, is the first step. Asking ‘why?’ at every available opportunity helps, too. The issue here is discipline – present a series of stakeholders with what is ostensibly a giant Gannt chart stretching wayyy out into the distance, with a whole heap of blank space at the end, will result in that blank space being filled very, very quickly with features, with little to no means to prioritise or justify why. The problem is that everybody has their own idea of what would be beneficial to build – and that initial process of identifying the problem statement is done upfront, by one person, quite regularly with no context as to why other than opinion. Encouraging a mindset where a problem remains a problem. until a collaborative effort defines a solution, is key.

Additionally, asking a stakeholder why they need something, what value it’s going to add, and for who, allows you to effectively weigh that up against everything else you want to build – and more importantly gives you a level playing field on which to push back. If every problem can be measured against the same set of relative criteria, then you have a common base of understanding from which you can clearly explain whether something will get resolved or not, and why something doesn’t necessarily need to be solved this very second.

Further down the line, too, this switch in perspective allows you to achieve real outcomes for your product – you have a problem, so when do you know you’ve solved it for your users? This provides an additional level of autonomy for your stakeholders as well – giving them a results-driven understanding of when a piece of work may be ‘complete’, not just a timeline from when what they’ve asked for will be ‘done’. This flexibility allows everyone to focus on continuous improvement, and allows all your key stakeholders to micro-prioritise their features and become mini-evangelists for value, not just ‘stuff’; nothing need ever be ‘completed’, and everything built is always a propsect for additional iteration. If your stakeholder can’t give you a definition of success, then chances are you don’t want to be building what they’re asking for in the first place.

On the flipside of this, a problem-driven roadmap also allows your development team to really get creative; giving a team a problem to solve opens up this additional avenue of value add, and allows this wealth of product knowledge to be applied in the most beneficial way for your end user – it encourages collaboration across the entire team (not just between developers), and the rationale for why we’d want to solve the problem is clear and simple, outlining succinctly from the off.

So, the product roadmap – a blessing or a curse? Used correctly, it’s a brilliant tool for collaboration no matter the size of the team or the user base – and it’s an instant mechanism for championing value above ‘stuff’. Used incorrectly? Well, the article title kinda says it all.