Recently, I gave a presentation to a group of founders about our workflow in handling feature requests. I share these slides, and my thoughts, to give you a behind-the-scenes at a small start up working on a b2b SaaS product.
I enjoy helping other founders where I can, so when I was asked by the newly created Fusion Founders program to speak to their first cohort, I jumped at the chance.
I have spoken at the program a few times in the last few weeks on various topics, however I thought I would create this talk into an article, perhaps helping another founder, with their own thoughts around feature requests and the workflow in handling them.
I have kept the slides as is, and removed a number of the slides which I explain in the text anyway, so wouldn’t make much sense (there is a link to the full slide deck at the bottom of this article).
So, without further ado, here goes…
I opened my presentation by suggesting that adding every single feature suggested from any stakeholder is tantamount to craziness.
You’ll be adding features only one customer will ever use, you’ll be so preoccupied with reactive work you’ll have no roadmap or time for anything else. The resulting end product will be bloated with features and complex choices the customer won’t know how to use it.
The above slide is really important to understand. Having a product mission or vision allows you to hold up the feature against this benchmark, and see if it holds true to your value.
Our mission is to create a powerful system, that encouraged deep engagement between leaders and their teams, yet keep it all wrapped up in a simple to use system. I know it can be a tall order, but it’s certainly achievable.
Say for example, a feature request comes in for something that will make the overall customer experience more complex. It’s important to weigh up the benefits of the new feature with the downside of having more complex software.
So there are three stakeholder groups that bring us feature requests. They are all equally as important for the development of our product. They are;
- Customers
- Free trial users
- Us (the team behind 6Q)
The reason I say all equally important, is that although our paying customers have shown a commitment to us by handing over their money, it’s often the free trial users who are churning away because we don’t have a feature they really need that are a focus area for our growth, and features from us is the overall larger picture roadmap of where we want 6Q to head.
So how do we find out what these users are wanting? We have automated on-boarding emails, which are typically fairly low response rate when we ask about feedback, however I augment this by spending time every week sending personal, direct emails to all the recent free trial sign-ups, asking how they are finding 6Q.
A tricky part is managing these stakeholders and the requests that come in, which all naturally need to be answered personally by myself or one of the team.
We receive feature requests by email, telephone, tweets, direct messages and blog comments. The first thing we do is record them centrally (more on that in a moment).
What I find invaluable is to discover why churning trial users (those that didn’t upgrade), didn’t upgrade. If it’s a feature or something they require, is it possible of us to add it?
We are huge fans of Trello, the Kanban process board software. Everyone in the team is able to review the board at any time, and add comments or checklists.
The way this works, is when a feature request is received, the first thing we do is check to see if it hasn’t been requested before. If it has, we’ll add a vote to that card, and this helps prioritise it over other requests.
If it is a new feature request, we will add it to the first column (Features requested), and then as decisions are made, and work is done, this card gradually (or swiftly) moves its way across the board.
On our board, we use five card lists, being
- Features requested
- Backlog (The Future)
- Backlog (To Do)
- Doing
- Done
Each of these columns mean something. Features requested is where everything starts. Once it is agreed that this feature is likely to be needed, it either gets shifted to ‘Backlog (The Future)’ which is another way of saying ‘Approved, but not immediate’ or ‘Backlog (To Do)’ which is where all the cards which are about to get worked on, live.
When it reaches this column, we prioritise it based on importance to the customer or us, the rough estimation of time it may take to create and other features already in the queue.
Once it’s time to start work on it, it gets moved to ‘Doing’ and at this stage, someone is now actively creating it. When the work is finished, we move it over to ‘Done’ and eventually it gets archived from there.
This is a closer view of one of our Trello cards.
We use the ABC Analysis method to prioritise, using a scale from A+ through to C-, which changes over time. In this example, the feature above is marked as a B+
We allocate developers or team members to work on it, we set a rough deadline (as you can see, this one is past due) and try to give as much context. This card has an attachment Word document which has further explanation into this feature, and what screens and code it will impact.
The checklist is a small subset of tasks that need to be completed, in order to get the new feature working.
To illustrate that it’s usually not a trvial exercise to just whip up a feature over a few hours, there is a fair amount of peripheral work potentially involved. We utilise a development to staging to production server environment, so we test everything, big or small, at least three times.
Then there’s developer documentation, potentially UI changes, in which case we will need to run it past one of the design team, or have the designer work on tidying it up, if required.
If it is a reasonably large change, we may need to also make changes to our support knowledge base, change the wording and images on some of our on boarding emails and potentially even add it to our ‘sales site’.
Once a larger feature is in production (live) we may then also decide to promote it.
We start by emailing our current customers and our current free trial users, given that they will likely notice this feature when they next log in to their dashboard.
We may then also contact recently expired free trial users, particularly if they were the ones who originally requested this feature and potentially we would also write a blog post and share this on social media (we are currently on Twitter and LinkedIn).
The above is an example of an email that we may send existing customers or free trial users. We have these all segmented nicely in customer.io which makes sending personalised emails a breeze.
I can’t speak highly enough of customer.io – if you need automated triggered emails, I encourage you to check their service out.
If this new feature is something we feel may be an item that helps people decide to use 6Q, we may also write a blog post about it. The blog post shown in the slide above can be seen over here.
I feel it’s important to make mention of these larger features, one for the hope this may convert more of our free trial users, but also to illustrate that we’re constantly refining and working on the system, overall.
In Summary
So, that’s my take on how we handle feature requests in a SaaS environment, and how we as a small start-up team handle them whilst creating Australian software for the world. It’s likely not perfect and may even go against everything that your team does, however it’s how we currently work.
