When we launched Perch Shop, for the first time we also shared a public roadmap with our customers. I’ve always been reasonably anti-roadmap and in a lot of ways still am. I thought it might be interesting to write about why we’ve not had a roadmap before, why we do have one now and how we went about creating it.
The danger of the failed promise
As soon as we share with customers that we are working on a specific feature two things happen. The first is that we are inundated with “is it nearly done yet” emails, emails that all have to be answered and therefore take time away from developing the feature. The second is potentially more serious, customers start to place expectation on that feature being there and ready for a particular project. They may have quoted for a job on the expectation of that feature being there. If we discover the feature is more complex than first thought, or some other issue comes up we need to deal with first then the feature gets delayed. A customer who is counting on that feature being available then feels let down by us – even if we never promised it to them.
We never want to be in a position where our customers feel let down by us. They use our product to provide services to their clients, we want Perchers to have confidence that when we say something is ready and working, it actually is!
Should customers be voting on your product direction?
One of the big issues of a public roadmap, and in particular things that allow customers to add ideas to the roadmap, is that you can find yourself with a large number of customers demanding a feature that would take your product down a path you do not want to go. Not implementing that feature then raises accusations of not listening to your customers. We are very much driven by customer requests at Perch, however we are also a certain type of product, serving a certain type of need for a CMS. There are things we do not intend to do, even if some of our customers would like us to.
In addition any public place where people can post and vote on requests will be attractive to only a very small subset of customers. We know at Perch that many of our best customers are completely silent unless we actively approach then and ask their opinion. It would be highly unlikely that they would go to a public board and vote on or add features.
The popular tools such as UserVoice and Get Satisfaction don’t help customers demanding a particular feature to realise that the product owner may have a huge amount of data behind the scenes informing their decisions for the product. It looks on the surface as if the demand of a large number of customers are simply being ignored.
Benefits of public Roadmaps
There are of course real benefits to sharing your product direction and feature ideas with customers. A public roadmap means that customers can feel involved and can see where the next few months are heading. They may also be able to add additional use cases or make suggestions around features when they can see what is in development.
In the case of Perch Shop we found ourselves in a different situation than for the core Perch and Runway products. E-commerce opens up a huge number of possible features, none of which have any real impact on the direction of the product. For example there are hundreds of possible payment gateways, lots of options for different kinds of discounts and offers, hundreds of potential integrations. The order in which we tackle any of these is pretty arbitrary. We’ll just tackle those that the most people show interest in. A public roadmap would give us another way to see which things people were most keen on seeing happen first. It was for this reason we began to consider the idea as a possibility.
Implementing our first roadmap
We felt that the popular feature request and voting tools would just create another channel of communication for us to monitor, and the ability for people to add and discuss features would require us to participate there. We’d rather discussion came into our forum so it’s all in one place, and somewhere that we can control. With Perch Shop, what we really wanted was an easy way to gauge interest in the next possible round of features, we needed voting but not really a lot else.
I was on the cusp of building such a tool when I did another search and discovered an article on roadmapping with a public Trello board. We had already used Trello during the Beta, what I hadn’t realised was that it was possible to add voting to a board without opening it up for people to add to and comment. The article does suggest adding comments to the board which would be useful if you don’t already have a place for customers to discuss features – we’re driving that to our forum.
Actually setting up the board took about five minutes, and we were able to quickly populate it with things we already knew people were interested in.
Living with the roadmap
We’re essentially two weeks in but feedback on the board has been positive. It gives people a way to feel they have added their vote for a feature and the information is already proving helpful in our future planning. In terms of payment gateway support I was surprised to see SagePay beat WorldPay for votes, and while we knew that recurring subscriptions was wanted by a few people we can now see it’s a top request and we’ve had lots of input on the use cases people have for that.
A nice thing with Trello is to vote you need a Trello account, so we can see who voted for a feature. We know many of our customers well and so have chatted with people after seeing them vote on a feature, to get some more information. We’re also finding that customers see the roadmap as permission to email us to add something. We’re getting requests for payment gateways specific to certain countries or regions, things we wouldn’t have heard of otherwise.
It’s been a nice balance between sharing what we are thinking of working on, without opening the floodgates to the problems of public roadmaps and user voting. It will be interesting to see how the use of it changes as more people start to develop their Shops on Perch Shop and as we knock the top features off the list in future versions of the product.