This is the story of how Feature Upvote came into existence. As with so many business stories, we began by wanting to find a solution to a problem that was really bugging us. We ended up creating a solution that other people wanted – so much they’d pay us for it.
We started off trying to solve a problem that our company had
Back in the day
In the early 2000s we were running a successful software company called Barbary Software. Our consumer software product was getting a lot of feature requests. In some ways this was great. We learnt a lot from these requests, and were able to build a better product as a result.
However, as the product user base grew, so too did the number of feature requests. These reqeusts came through support, from user research conversations and from social media. We were beginning to struggle with the quantity of feature requests.
We’re a small team. We didn’t have an enormous support team to track feature requests. So we started thinking about how we could be more organised. First up: the spreadsheet.
Using a spreadsheet for feature tracking
As a bootstrapped company, we didn’t want to spend a lot of money on software that wasn’t vital. So trying to organise feature requests with a spreadsheet seemed like a good idea. Spreadsheets are free and we knew how to use them.
Each time we got a repeat suggestion we then added a vote. Pretty soon, we started to get a fairly clear idea of which suggestions were most popular.
However, we ran into a few problems fairly quickly:
- We found it hard to update the document fast enough when we had so many other demands on our time
- We needed to always double-check that we hadn’t already got a feature suggestion to which we should add a vote
- Our customers didn’t know about our hard work. As far as they were concerned, their requests were going into an email black hole, never to return.
This is where most customers thought their feature requests ended up
As well as failing to update the document, we also had to spend extra time reassuring customers that “yes, we do care about your feedback”.
After a few months trying to use a spreadsheet we decided to look for a better solution. Spreadsheets were free, but they weren’t the solution we needed.
Trying Get Satisfaction to centralise feedback
Get Satisfaction helps you build an online user community. It seemed like a good way to centralise feedback and get customers involved in the product. We even thought that customers might start answering the questions of other customers.
For a while, this kind of online community building worked well. We got nearly 150 user suggestions in a year, which averaged at about 3 per week. We even saw some instances of customers answering the questions of other customers. Result!
However, after a few years people stopped contributing. We talked to other people who ran software companies. They reported that around the same time the usage of their product forums really dropped off.
We eventually closed our Get Satisfaction board and looked around for something better.
Trying Jira for feature requests as well as bugs
We then tried to use an issue tracking tool instead. We tried FogBugz, then Jira.
A customer feature request in Jira
Jira was okay for tracking which requests we had, but it had some problems:
- We couldn’t track how many people were asking for a particular feature. The Jira voting feature just didn’t work, as it only allowed one vote per internal team member.
- There wasn’t public visibility
- The feature requests were intermingled with bug reports and internal tasks
We concluded Jira wasn’t a good fit for managing feature requests, even though we still use it for bug tracking and project management.
We should make our feature requests public
We decided we would make our feature requests public. We had experimented with a public community forum with Get Satisfaction, which had worked for a while. We wanted to fix the problems that stopped the community forum from working for us and be public again.
It seemed like the right solution for us:
- Our customers would know we cared about their feedback and see we were implementing it
- They could enter their own feature requests and vote, saving us a ton of work
- Vocal customers could get a better sense of what everyone else wanted, which should help moderate their expectations
- Customers generally expect greater ease of use and transparency
We had one niggle: won’t our competitors see what we’re working on and pinch our ideas? We quickly got over this. If our competitor’s growth strategy was to be a pale imitation of us then they were going to fail pretty fast.
At this stage, we had a brief look at two options that we could use for public feature request tracking: Trello and UserVoice.
Considering Trello and UserVoice for feature request tracking
We already knew Trello was a great project management tool, but we hadn’t really considered it for feature tracking. Trello had written about how you could use it for feature tracking though, so we decided to look into this option.
We realised fairly quickly it wasn’t for us. Why?
- The board looked complicated once you added a lot of feature suggestions.
- It wasn’t clear to users how they could easily contribute
- Users would have to have a Trello account to make a suggestion or vote which would result in less feedback
Trello seemed better for showing a public roadmap than for collecting and prioritising ideas
In the end, we decided to use Trello for implementing already-agreed upon actions and collecting research that didn’t require prioritisation. That’s what we did, at least before we moved to Notion which does a better job of offering you a coherent workspace.
So, no to Trello.
Another option we looked at was UserVoice, which sounded suitable. We went to their site – when they were still openly showing their prices – and saw they charged $500 per month. That would dwarf even our server hosting bill. We wanted something like UserVoice but without such a high price tag.
We certainly didn’t seem to be the only ones looking for an affordable feature tracking solution.
I can’t tell you the number of times I’d go visit User Voice thinking I’d need to bite the bullet and signup, but their pricing was absurd for anything but huge companies
- Quoted by the founder of a software company
Let’s build our own feature tracking solution
Around this time everyone in our small team was on vacation for a week, apart from our founder Steve.
He used the quiet time to sketch out a possible in-house tool for tracking feature requests. When the team was back, he showed us the sketches and asked if we thought we should build it - not just for our use, but for other companies to use too.
“Yes!” was the response. So we asked some other software companies if they would use such a product. Some said no, some said maybe, and some - with great enthusiasm – said “Most definitely”.
Our own Feature Upvote board and suggestion form
Fast forward a few years
Feature Upvote is now a successful product.
Our customers range from construction giants and major banks to community theatres and educational companies. They are located in 30+ countries around the world, speak different languages, and work in different ways.
What they all have in common is a desire to organise feature requests in the simplest way possible and to surface the best ideas.
Although occasionally tempted to move upstream and add many new features, we’ve resisted.
What we like about Feature Upvote is its simplicity. We looked at similar solutions, but they were much more complicated than they needed to be.
Sitebulb, desktop website crawler
Ready to give Feature Upvote a try?
- Public facing or private boards
- Custom domain as standard
- Able to add comments, status updates and tags
- Available in 12+ languages
- Works on any device