“I’m okay with sharing the roadmap… as long as clients and sales people know that the roadmap is a plan and not a commitment.” – Steve Johnson
As a Product Manager, I like this quote for obvious reasons, but recently came to think that while the roadmap should be flexible, there should be some commitment to stakeholders on something. Aside from gaining trust and assuring them, this gives some direction to the product.
Pretty fundamental you’d think, but I had a good reminder about it yesterday.
As the outcome of a feature-request discussion, a stakeholder prepared a document which stated two features as a PM priority (I’m glad we communicate on the working level first). I was worried that it would give the impression IT would only focus on those two features.
(Yes, during the meeting those two features were highlighted as key articles in the roadmap, but after additional thought, I had my concerns because: firstly, they required integration with other systems, which could add ongoing development and testing overhead. Since there were plans for construct changes in our system, we should consider whether to work those first. Secondly, the stakeholder might interpret all other work not directly contributing to this feature as being poor prioritisation, when they were still important developments. Especially since the two features were large and would take time to plan.)
The “aha!” moment for me was remembering what those two features were for.
It can be easy to fall into either one of two extremes: (1) a somewhat waterfall approach – planning big features/changes a year or more out based on yesteryear’s requirements, each feature planned to the day of launch regardless of the changing environment, (2) an agile team without time constraints and without direction, simply working on the next feature request or bug fix.
From my limited experience, stakeholders enjoy the first approach more. Not many like change or uncertainty, preferring gantt charts and deadlines set out, for the next few years even (hey, I was once in that seat). This can be seriously limiting in software, and puts a lot of overhead on the PM to carve out estimates, constantly revise them when something crops up or a feature is no longer useful, and to be an expert communicator and pacifier for stakeholders. Time that could be better spent elsewhere, like finding out user needs and monitoring the changing landscape.
On the other hand, throwing out the plan under the guise of “agile development” is just as dangerous <insert headless chicken .gif here>. Without underlying principles or guiding light, you risk prioritising features that don’t meet the critical business or user needs, developers don’t see where their work is heading to etc. Thus, there needs to be an understanding of why, to have some guiding goals, to keep a product strategy or vision.
I think this is the true advantage of agile development – flexibility that helps you achieve your goals more effectively (since you learn from users and adapt along the way), efficiently (if something is found to be ineffective it can be removed from the roadmap) and possibly faster (incremental development). So, prioritise the goals, not just the features.
My interim plan is to communicate and agree with the stakeholders, in order of rigidity from “inflexible” to “flexible”:
- goals (maybe defined in user stories)
- short-term roadmap (features/fixes for the next 3 releases, some degree of flexibility but a firmer promise with deadlines)
- longer-term roadmap (features/fixes currently planned but with flexibility on implementation dates)
The risk and challenge then would be managing the longer-term roadmap – how do I ensure that these features get enough of my time for planning so they don’t just get pushed back? I’ll also need some KPIs, because perhaps we can achieve the same results without having to implement them. Perhaps I can wrap all of this up with a Product Manifesto/Strategy document (no, not those 3,000 word essays).
Phew. A longer post than usual, but a good workout for me. I credit some articles from mindtheproduct on prioritisation and roadmapping, as well as Marty Cagan’s writing on Product Manifesto (and check out the Product Strategy stuff too).