Image of Mike McDerment
Mike McDerment, co-founder of FreshBooks, just wrote an interesting post stemming from many requests in the FreshBooks customer forums for some indication of a product development roadmap. Mike wrote of his justifications for keep the product development roadmap close to their chests. Broadly his reasons were;
- Commitments weigh you down, make you less nimble and lessen your ability to react to unseen threats or opportunities
- A roadmap is an excellent resource for your competitors – not disclosing it keeps them on their toes
- Customers will always want the next feature (or the one after) – Mike contends that publishing a roadmap can in fact delay purchasing decisions
- Focus on your proven track record – not what you promise
- Delight your customers – under-promise and over-deliver
What Mike says makes perfect sense, kind of. But like every argument there is a compelling counter argument;
- Commitments focus the business on what it needs to do and inform the workflow process. They also minimise the temptation to go off on tangents not directly in keeping with the business direction
- Sure competitors can see your roadmap and possibly gain an advantage from it but delivery is key. Having a clear roadmap focuses the mind and makes it more likely that you’ll execute successfully
- Customers want to see that you’re thinking of the future – they’re more likely to go with a vendor that they can see has a clear direction and is moving in a way that is aligned with their needs
- At every level; funding, staffing, customer acquisition – people will want to know where you’re heading – a product roadmap is part of this information
- You can advise your customers of your roadmap and still over deliver. A roadmap is a bare minimum – you can still deliver more than your roadmap says
I agree with not giving too much away. We struggle with customers wanting to know what’s coming up vs not committing unless we need to make changes. It’s a hard balance, and all software co’s have this prob.
We just give a few feature promises to users (and commit to them) and keep others up our sleeve…
Which aligns nicely with my points – give your customers a broad product roadmap, deliver early wherever possible, and keep some nice features up your sleeve to roll out and delight the punters.
I think the question you need to ask yourself is do you want to be Steve Jobs (ie don’t tell anyone what you’re up to – though admittedly leaks happen sometimes) or Bill Gates (of Longhorn/Vista fame).
Both approaches work…it’s up to you to decide which one works for you.
You’re right Mike – horses for courses. And your strategy obviously works well for you guys.
Cheers for the comment
Counter-arguments 1 and 2 apply only if there is no roadmap at all. The solution is to have a roadmap but not reveal it outside the company.
I find a product roadmap keeps our development team focused and honest about what we are going to deliver to our customers. Sometimes it is hard to differentiate between a direction, a trend or a whim, and it helps to go back to a ‘stone tablet’ with your original promises on it.
But at times, it can be the veritable albatross around your neck too…
You should have a public roadmap*.
*Public to your team and invested parties. Competitors, and other negative interests must be kept out. There should be a space where your team can know and discuss about what’s up, without worrying about who will read and what will be revealed.