When KashFlow was first available back in 2005 it was a very, very basic invoicing tool. It produced invoices with sequential numbers and you could mark them as either “paid” or “not paid”. Nothing more. This was intentional. We (or “I” as it was then) didn’t want to make assumptions about what businesses wanted from what was to be a fully functional accounting software
We were lucky with our timing. There weren’t any other web-based accounting apps worth mentioning at the time and we weren’t under the level of scrutiny new entrants in this market place are today.
So we took our time and asked our customers to tell us what they wanted added. Once we’d covered the main bases we’d only add new features it if they passed 4 tests:
1) Customers must be asking for it – so not just something we think would be cool to have
2) It mustn’t distract from the simplicity of the software
3) It shouldn’t remove any existing functionality
4) Wherever possible it should be off-and-onable, defaulting to off so as not to confuse or distract customers
Rule 4 can cause a problem as people taking an initial look at the software today can be fooled into thinking it doesn’t have many features when in fact there’s probably no other accounting app, online or offline, with the depth of functionality we now have.
This is why we tell people that if they think it can’t do something they need, they should get in touch with support as it probably does do it.
The result is that we now have an application that’s got lots of features that are of genuine use to small business owners, rather then lots of confusing menus full of jargon and options you never use – the main thing that put me off other programs available when we started.
We’ve kept our approach the same over the years; actively soliciting suggestions and sticking to the rules above. You’ve not let us down. We have a list of great feature requests and we’re constantly improving the software based on those suggestions.
Until relatively recently we’d pick the features we (myself and one other developer) were going to work on and just go for it. This meant we’d get new functionality released very quickly and this kept us ahead of the emerging competition.
Now we have thousands and thousands of customers and a team of developers (they rarely let me touch code these days) we needed to implement a more methodical approach to developing the application. So this is how one of your suggestions goes from initially being received to being live in the software.
The suggestions we receive from you are all logged on a database, nothing is discarded no matter how silly or complicated.
Once every 4 weeks I sit down with the development team and let them know which suggestions I want implemented over the next 4 weeks.
The way I decide what I want them to do is based on how many people are asking for a particular feature and how complex it is. I’d be lying if I said I don’t take into account who’s asking for it too. We have some Partners who spend tens of thousands of pounds a year with us and I’d be silly not to give more weight to their requests than I do to others.
They go away and develop the features on a development server we have in the office. Once they’ve finished, the new features are copied to a separate test server we have here and it’s tested by non-technical end users. Assuming the features work as planned they then go on to the “live” system where you get access to them.
This works really well and means we can still get new features out quickly and regularly.
The down-side is that if you make a suggestion for us, it’s virtually impossible for us to tell you how long it’ll be before it’s available. It may be a great idea and we plan to add it in the next development cycle. But as requests flood in each week, the list changes all the time so your suggestion may get put back if other requests become more popular or more pressing.
An observation. The basic invoicing tool we launched with cost £13.99/month. Since then, despite going from a basic tool to a full accounts package that’s winning awards all over the place, and spending 100’s of thousands of pounds developing the software and infrastructure, we’ve only upped the price once – to £15.99/month. And that was only for new customers. If you joined us back when it was £13.99, that’s what you’re still paying.
![[Post to Twitter]](http://blog.kashflow.com/wp-content/plugins/tweet-this/icons/tt-twitter-micro3.png){kind=icon}
![[Post to Delicious]](http://blog.kashflow.com/wp-content/plugins/tweet-this/icons/tt-delicious-micro3.png){kind=icon}
![[Post to Digg]](http://blog.kashflow.com/wp-content/plugins/tweet-this/icons/tt-digg-micro3.png){kind=icon}
![[Post to StumbleUpon]](http://blog.kashflow.com/wp-content/plugins/tweet-this/icons/tt-su-micro3.png){kind=icon}
Tags: agile, development, sprint, suggestions
This entry was posted on Wednesday, January 13th, 2010 at 12:03 pm and is filed under Programming, Technology, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
This is very similar to the model which we will be using for our eCommerce framework when we re-launch in the near future – so I’m glad to see you’re using this sort of approach and find that it works well.
Have you thought about exposing any of the “internal” information as to what is in the queue, etc to users (e.g via UserVoice or similar)? This is a point which is still very much open for (heated) debate in our camp!
We’ve used a very similar model when adding features and planning new releases. We’ve found with external clients in particular, that they really like the ability to plan and launch new features every month – certainly using Scrum has worked for us in this respect.
How have you found your change of role from developer to Product Owner? Probably like us it’s not a big deal for a small organisation, but it must be difficult sometimes not to roll up your sleeves and get stuck in?
As Matt says, there is mileage in exposing your roadmap to customers using something like UserVoice or Get Satisfaction. It’s a great way to let them know they’re being listened to and keeps the fresh ideas coming!
Another vote for UserVoice
“Tracking ideas for 32,496 organizations.”
There’s even some kind of open source version:
https://uservoice.com/for/opensource
Or, use the KashFlow forum poll feature for more control your end.
These things also help avoid idea duplication, as none of us have any clue if our own ideas are new or already submitted/planned.
“Collaborating with your business users frequently” is one of the critical principle for any successful product development initiative. We follow this in our company on our product development quite a bit. You can collaborate on:
– product roadmap (listening to what your customers want and put them into a prioritized feature list)
– looking at customer support issue log to understand customer pain points
– usability aspects & importance of features from the customer perspective
To answer Pauls’ question on role of developers — we do gunslinger events where we make the developers play the role of end users…that really helps them to take up the real product ownership. Once they realize what they are building, that changes their thought process, approach to development. They start asking questions on what our end users would ask :).
I have also seen products having metrics implemented which tells the feature usage across the product. I think, this is one of the important stuff which helps the product managers to focus on their enhancements.
I wonder if rule #1 will mean you miss some kind of game-changer that leaves everyone else in the dust?
good approach. You can chitchat about it a lot and lose yourself in theoretical discussions etc. but most important is it works.
But if I might suggest the following ? With the app you are talking about two things: data that is already in it (and processed) and data that is not in it and you would like to have processed. Why not for example implement a way to decide yourself what kind of data you want to see in the reports ? Ok, you have one, but that only turns on or of a ledger account. I am talking about the information IN the accounts.
Just buy a nice asp.net webpart, link it and have us have fun with it.
So is for example the projects column not shown when you run general reports. I have of course contacted (btw your fantastic) support team but most of all I was a little surprised that it was not shown.
I am sure that you can agree if I state: if you deploy something, deploy it good.
(ok, it is good, I think I must say: deploy it the best).