Buy what we have today, not what we might have tomorrow

I got into a bit of a debate on Twitter about product roadmaps (ie, what we’re going to be adding to our accounting software product over the coming week, months and years). I thought rather than trying to explain (justify?) myself in 140 characters I should write a blog post instead.

Some background

Dennis Howlett wrote a blog post that mentioned KashFlow and contained the sentence

[Potential customers] may not get everything they want [from the software] but are willing to buy into a vision

I then tweeted that “we don’t sell a vision. We sell what we have today. Hence u rarely see us talking up what we’re going to do, only what we’ve done”

There was more back and forth on Twitter and also a thoughtful blog post from Adrian Pearson.

The Issues

There are actually two issues here. 1) Should we try to sell our product based on what it might do tomorrow and 2) Should we publicly list our development plans for the product?

The first issue is easily dealt with in my eyes. Just turn the question around and ask it from the potential customers perspective: Should you buy a product that doesn’t do what you need it to do today, but might do it tomorrow? The answer has to be no. Come back tomorrow, if it  does what you need, then buy it – but not before.

The fact is, KashFlow is a mature product compared to the vast majority of other SaaS accounting apps. There’s a big enough market that will (and do) buy it as it stands today, not based on some sort of vision for the future.

The second issue is much less black and white. I know plenty of reasons why a company should publish a road map, but let me count just some of the reasons why we don’t.

The Reasoning

1) Loss of agility If there’s a big (or even medium-sized) deal to be had (ie, lots of new customers or revenue) and we need to act quickly to be able to do any required development then I need to be able to commit 100% of my development resources to it straight away if it’s justifiable. I don’t want my hands tied with prior commitments.

2)Delight, not underwhelm If you’re told for months that the software will soon make you a coffee when you wake up in the morning, then when it eventually does your reaction is more likely to be “about time, they’ve been talking about it for months”. Contrast that with the delight if you weren’t expecting/waiting for it to make you that coffee.

3) Commercial Sensitivities There are often things going on that you can’t or don’t want to talk about publicly – often due to non-disclosure agreements and so on. Some of the decisions you have to make regarding product development are informed by that. If you are asked to publicly explain why X is on your roadmap but Y isn’t, how do you respond to that if you can’t reveal all?

4) Competitors Apparently there are around 50 SaaS accounting apps in the UK alone now. A couple in particular try to mirror virtually everything we do from press releases, to on-site SEO. Why give them a heads up of what we’re doing product-wise in the future?

5) Disappointed  Customers Even if we don’t actively try to sell based on the “vision”, if we have a published road map some people will buy the product based on what’s listed there in (rightful) expectation of us delivering on our promise (small print about “subject to change” won’t help). If we don’t deliver then the new customer would be pissed off. I don’t want to piss off customers.

If an existing customer asks “when will you be adding x?”, and we know we are planning on adding it soon, maybe even in the next 3 months, the answers we give is “It’s something we’re hoping to add, but it’s not going to be in the immediate future”. We don’t want to disappoint existing customers by not living up to their expectations.

Apparently my approach is bonkers and I’ve “got a lot to learn”. No doubt.
But I have a lot of respect for the others in the asylum with me, all of them.