How prioritisation & understanding who feature requests have come from stop you wasting your limited development resources
Image credit: Flickr
If you’re anything like us, your SaaS business will be full of feature requests from customers and internal teams like sales (who want to close more deals), account management (who care about expansion revenue from your existing user base) and support (who just want to keep that important customer happy and successful with your product).
There’s so much value in your feature request & feedback data, but I’ll bet you can’t really do much with it right now; that’s how we certainly felt in our previous SaaS companies. The data is in people’s heads, scattered across spreadsheets so massive it takes your poor product managers many hours (and cups of tea) to unpick each week and to top it all off, that data is also often skewed by input from your most demanding customers.
As a result, important product decisions get made on the loudest voice in the room, incomplete information and gut feeling - all irrespective of real value or effort.
This is a massive pain point for any SaaS business as I’m sure you are aware (!!) and as your company grows, the problem just gets bigger - you get more & more competing and conflicting voices telling you what the product should do.
So who do you listen to? Do you build the feature with the most votes? The things your sales team are convinced are the next big thing? Do you listen to your customers? Which ones? What about your competitors? How do you filter out all those feature requests that don’t align with your company strategy?
Receptive was born out of experiencing these issues first hand. We built the product to answer the big question at the heart of all software companies:
What are the highest-impact things we can work on right now given that we have limited resources - people, time & money
At Receptive, we enable businesses to use those scarce resources wisely.
Currently all of your feedback & feature requests will be an unstructured view of demand. There’s no prioritisation (or you have to prioritise manually which is very time consuming) and as soon as that information arrives, it’s completely stale. It doesn’t reflect that feature requests & feedback from customers and internal teams develop over time, or how people change their mind.
You simply can’t expect priorities not to change. It always amazes me how feedback differs throughout a user’s lifecycle with your product. Having a mechanism to allow for change on a long-term and short-term basis is incredibly powerful.
I mean we’ve all been there…a customer calls and feature X has to be built right now but by the following week, they are fighting their next big issue and have forgotten all about it…or a sales team member has just got off their last exciting call and they’re convinced they’ll close them “if only you build feature Y”. This is what we like to call The Cushion Effect. It’s important to understand how the power of impression can trick you into building the wrong features.
In our business, we gather all of this information centrally. Users can change & prioritise feature requests. Customers are kept updated on product development at the click of a button, management communicate strategy to internal teams and in turn, those teams can understand how their requirements fit into the organisation as a whole, and it’s strategy.
The next big problem we found when building a SaaS product, was that you have different groups all demanding different things from your product and it’s incredibly hard to segment that information. Understanding who is requesting features (and why) is really important in helping build your product roadmap. After all, you can’t just build features your customers will love, you have to build the features that your business needs. Without understanding priorities or who requests are coming from, you will never be able to achieve that.
Generally, you can’t see what matters to your big customers versus your small ones, what paying users need versus free triallers, what the users who have churned were requesting. You can’t see how market and location change the impact of feature requests or what the priorities are for your internal teams…at least not without a heck of a lot of effort rearranging a product backlog in Trello or a group of messy spreadsheets.
When you don’t understanding how your feature requests & feedback are segmented it’s very easy to lose sight of your product strategy. You can end up using your limited resources - people, time and money - building a load of software that nobody wants. The last thing you need is feature bloat. Check out feature requests alone are as useful as a chocolate teapot for more on segmentation and it’s importance in developing a SaaS product.
We can access those insights in one click and it’s revolutionised how we see which feature requests & feedback we should be building into our product roadmap.
The general answer is
What fits best with your company strategy. Getting pulled around by one loud voice, that demanding customer or persuasive investor does not build a good SaaS product. Being able to see the dynamic priorities of different user groups and making informed decisions on where to use your precious resources is key.
For example, if you want to grow your Enterprise client base, you could concentrate on requests from your sales team from their top Enterprise leads combined with feedback from your existing Enterprise users. Or if you need to reduce churn, why not look at the top priorities and feature requests from users who left?
What are the challenges you face in managing your feedback and feature requests? Let me know or book a chat with me.
The Four Laws of Software Economics - great piece from Rich Mirinov on ruthless prioritisation and why your development team will never be big enough
Incredible new SaaS conference announced and we’re very proud to be a sponsor. Check out SaaStock