{"id":380,"date":"2015-12-30T13:43:38","date_gmt":"2015-12-30T13:43:38","guid":{"rendered":"http:\/\/www.scrummable.com\/?p=380"},"modified":"2017-06-16T10:15:02","modified_gmt":"2017-06-16T09:15:02","slug":"fk-you-i-wont-do-what-you-tell-me-the-perils-of-the-product-roadmap","status":"publish","type":"post","link":"http:\/\/scrummable.com\/fk-you-i-wont-do-what-you-tell-me-the-perils-of-the-product-roadmap\/","title":{"rendered":"F**k you I won\u2019t do what you tell me: the perils of the product roadmap"},"content":{"rendered":"

Who likes following orders? Better yet, who likes following orders blindly?<\/div>\n

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.<\/p>\n

The issue with the product roadmap is that it\u2019s 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\u2019t even come with a rationale or justification behind them. The team is asked to build what they\u2019re told, and they set about building what they\u2019re told. Collaborative, no?<\/p>\n

\"Because<\/p>\n

In the instances where this is the case, it\u2019s 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\u2019 ins and outs, the backlog of technical debt that\u2019s been accrued, the areas that desperately need improvement, and indeed could be improved quickly, if only the chance was afforded. They\u2019re probably also keenly interested in the feedback received from the user base (if they\u2019re not, they shouldn\u2019t 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\u2019s neck.<\/p>\n

By its\u2019 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 \u2018roadmap\u2019 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.<\/p>\n

\"rebecca\"<\/a><\/p>\n

This is an output-centric focus, and outcomes are unfortunately forgotten – because we\u2019re on to the next shiny feature on the roadmap, and there\u2019s no time \u2018scheduled in\u2019 for looking back (or worse, even when there is that time is 6 months later when it\u2019s 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.<\/p>\n

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 \u2018agile\u2019 are sat arbitrarily t-shirt sizing features for a product roadmap (\u201conly a rough estimate, we know we don\u2019t have all the detail yet!\u201d) 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.<\/p>\n

Got a problem?<\/strong><\/p>\n

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

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 \u2018why?\u2019 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.<\/p>\n

Additionally, asking a stakeholder why they need something, what value it\u2019s 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\u2019t necessarily need to be solved this very second.<\/p>\n

\"Fix<\/a><\/p>\n

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\u2019ve 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 \u2018complete\u2019, not just a timeline from when what they\u2019ve asked for will be \u2018done\u2019. 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 \u2018completed\u2019, and everything built is always a propsect\u00a0for additional iteration. If your stakeholder can\u2019t give you a definition of success, then chances are you don\u2019t want to be building what they\u2019re asking for in the first place.<\/p>\n

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\u2019d want to solve the problem is clear and simple, outlining succinctly from the off.<\/p>\n

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

\"Fuck<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Who likes following orders? Better yet, who likes following orders blindly? 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 […]<\/p>\n","protected":false},"author":4,"featured_media":588,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,6,7],"tags":[],"_links":{"self":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/380"}],"collection":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/comments?post=380"}],"version-history":[{"count":0,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/380\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media\/588"}],"wp:attachment":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media?parent=380"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/categories?post=380"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/tags?post=380"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}