Editor’s note: we’re currently running a series of posts from our long-term sponsors, focused on use cases and business advice. We hope you find these posts useful and we encourage you to support our sponsors by trying out their products.
Use of hosted software as a service (SaaS) is growing like crazy, and most products are constantly evolving. What is the best strategy for a tech startup: share its product road map (i.e. its development plans) with the outside world, or keep its cards close to the chest?
Product Road Map: Secrecy or Transparency?
Mike McDerment from FreshBooks argues very convincingly for keeping it to yourself:
- Commitments weigh you down (if you promise something and change your mind later)
- Keep your competition guessing
- Purchasing decisions get delayed (as people wait for the next great version)
- Don’t set expectations too high
- You can bank on surprise and delight
I feel strongly that sharing your product road map to gain (and actually use) feedback from your clients is the best product strategy for any rapidly evolving software company.
We have always been fans of the “Agile” development methodology, and when we embarked on developing Wild Apricot back in early 2006, there was no doubt in our mind how to go about it. Instead of trying to design and develop a “perfect” product (which would probably take a year or more), we created a list of “user stories” (product features) and prioritized them according to what we could do in 3 months.
Wild Apricot aims to simplify life for people in associations and non-profits. It replaces five separate pieces of software with one, saving thousands of dollars and countless hours of data re-entry and reconciliation. It automates trivial administration tasks and lets people focus on their cause and passion.
Our first beta release was launched on June 30th, 2006. Feedback started to trickle in right away, and as we started to count accounts in the dozens and then hundreds and then thousands, it really poured in (and keeps pouring!).
Our initial road map was around 80 entries. Our current list is over 400 items, and the cycle never ends:
- Release an update
- Review accumulated feedback from clients, and add or change items in the work queue
- Reprioritize the new list, and pick top items we can fit into our next update
- Several weeks of intensive development, then testing
- Rinse and repeat
(We currently issue product updates every 6 to 7 weeks on average.)
One curious fact is that half of the items on our original list have not been completed, while we have released a couple of hundred other items that our clients requested from us.
This is the ultimate reason behind this strategy: our own team is smart, but the accumulated wisdom of our clients makes our product development much smarter than it would be if we did it on our own.
Let me circle back to Mike McDerment’s points:
1. Commitments weigh you down
Yes, that’s why you have to be very careful about what commitments you make, and about sticking to them. We made our share of mistakes: promising that “This feature would be released in a few months,” and having clients ridicule us for still not having released it after 18 months.
Here is the process we follow:
We maintain a special discussion forum (a wish list): any client can register and post their ideas, or comment and vote on ideas provided by others. Our support team encourages and directs all clients to join the conversation there.
Our product management team constantly monitors this forum and participates and guides the discussion. After each product release, we conduct a thorough review of the wish list. One frequently voiced criticism of using client feedback to guide your research and development is that all of those ideas are too tactical and are not innovative; the fax machine would never have been invented in this fashion, by just collecting feedback for the good old postal service. My answer is that this is where our team adds the most value. Our job is not simply to take one suggestion after another, but instead to look for patterns and commonality and then generate innovative ideas and features that address the feedback, even though it may be in a totally different way than envisioned by the original client.
As an outcome of that, we regularly update the road map discussion forum, which contains the top 60 items that we consider to be pretty well defined and ready to be queued for detailed analysis and development. We do not allow clients to create new entries in this forum, but they can freely comment and rank threads that we have created.
This list of items forms the core of our work queue, which is reviewed and prioritized for each release. Again, the priority assigned to each item is based mainly on its ranking and comments by clients; but here we also have to weigh those rankings and comments against architectural considerations and the long-term vision for the system.
And of course we have to work a number of “unsexy” items into each release to maintain system and data security, ensure reliability, improve system speed, and deal with bugs.
Finally, the feedback loop closes with our weekly product update posts on our blog.
To address the other points Mike brought up:
2. Keep your competition guessing
For us, the competitive edge is in the execution, not the initial ideas, which are a dime a dozen. Plus, of course, customer service, however lame it might sound: this old-fashioned concept still goes a long way towards winning (and losing) clients.
3. Purchase decisions get delayed
Because we have this regular rhythm of new releases, people sign up at a steady pace, and the next update is always around the corner anyway. And if somebody needs a particular feature we do not have yet, I would rather have them wait and get more experience down the road than waste too much time shouting “SIGN UP NOW! SPECIAL OFFER ENDS TODAY!”
4. Don’t set expectations too high
I say, set them high and deliver on your promises.
5. You can bank on surprise and delight
But you lose out on anticipation (also see Andy’s point #2 below).
Let me close by quoting Andy Sernovitz, author of Word of Mouth Marketing (a must-read book, by the way, for any technology marketer: lots of practical advice). He also thinks that product road maps should be shared and makes these points:
- Users will be thrilled to know how the product is going to improve.
- You turn frustration into anticipation.
- Your fans have something to talk about (more word of mouth!).
To close, I do not think there is a single strategy that works for every company and every team. Freshbooks is a very successful company, and we are looking to them in many respects. Our crowd-sourcing strategy works well for us and is a good fit for our team and product. The journey continues. Check out our release history.
What is your experience with crowdsourcing? Any thoughts on product road maps for software companies?
If you’re a non-profit organization wanting to use the Web more effectively, try out the Wild Apricot suite of products and support a RWW sponsor.