If you’re experiencing growth it can be a great position to be in. However, as new challenges mount, things can get even tougher than they were during those exciting startup days. Whilst the number of paying customers grows, so does feedback, suggestions and feature requests. At this point, you may receive so many feature requests you begin wondering how to proceed with your future SaaS feature development? In this article, we’re suggesting 8 points to consider for your next feature development.
I don’t believe there is one correct way of doing this, but I’d like to suggest a general method and approach. Developing your product is an art form that requires analysis, critical thinking and sound judgement based on market influences. It’s hard to develop a system for doing this. Here I’ll try to outline a general process that may help you achieve this more effectively.
Observe User Behaviour
If you’re not doing so already, it’s important to start tracking the behaviour of your users. You may find some insights that highlight usability issues, problematic user journeys or missing features that users haven’t mentioned to you. You’ll find many tools to track behaviour. These include free ones like Google analytics or more purpose-built platforms like kissmetrics.
Also, try observing user behaviour by arranging screencast sessions and shadowing. Gain permission from your users before doing so. I like to arrange sessions with users where they perform predetermined tasks within the software and we record the sessions with a screen share recording tool. I often use Zoom and change the settings to record automatically, or Screen Recorder from Screencast-o-Matic.
The screen capture above was taken from a screencast I held with a user who was having problems using a client’s app. In this particular instance, the user had several tasks she wanted to complete as well as an outline of the challenges she was having. This user was happy to spend 30 minutes on the call demonstrating the problems she was having with the platform. The screen share led to direct improvements we then made to the interface. Valuable calls like this one can make a big difference. Be sure to observe the screencast carefully as user behaviour here will give you many things to look out for.
Track and Understand Your Metrics
One clear thing to be sure of is that you are basing your decisions on sound metrics. You need a foundation of evidence on how your users actually behave and use your product, because customer feedback is not a reliable indicator of actual user behaviour. Whilst you should take note of what users say they want, it may not be accurate.
Gather Feedback From Your Users
What’s the best way to find out what your users want? Ask them!
A great question to ask is simply “What feature is X missing?”. A good time to ask this question is just after your user’s first period of utilisation, i.e. a free trial or end of first subscription period after sign up. This question gets your user thinking and may draw to mind the first impression they had using your product.
There are other ways to do this too, you may find one that best suits you. But make sure you try asking users at different times in the customer life cycle and in different ways. This is because the answer they provide may vary depending on the context. Furthermore, what users say they want and what will actually work best for them may be different. Therefore, record everything they say and review the data in context with your other sources.
Don’t neglect to try a number of methods for gathering feedback. These may be telephone calls (a great and often underexploited method), in-app messaging services, emails, surveys, questionnaires and user focus groups.
If you are seeking in-depth feedback you may even wish to incentivise users to give up some of their time in a brief chat with you. See the email below that asks for a 10 minute Skype or Google Hangout chat in exchange for a $10 Amazon voucher. It’s worth asking… You may receive invaluable knowledge, not only about your platform but about your customers too. Here’s an example email on how to do this.
Consider External Market Factors
What’s happening in the market and how it will affect your company will influence your decision greatly too. For instance, it may be that many of your customers use a particular 3rd party platform. So it becomes important for your users to connect to it. In this instance, you might prioritise interfacing with this platform over other feature requests.
Another example may be that other features are provided in abundance for free in the marketplace. In this instance perhaps it’s not worth the investment and resource to build it. This may lead you to refocus your efforts on other more unique offerings within your platform.
Of course, market timing plays a key role too. Is it the right time to introduce product feature x? What is the cost assessment? If you introduce this SaaS feature development, will it cost you time? Instead, should you have been developing something else that would’ve made a bigger impact?
Ensure SaaS Feature Development Support Your Company Vision
I once consulted with a company that had developed many conflicting features based on the requests of a range of different customers. Whilst initially this enabled them to serve a diverse range of users, eventually the company lost their way and struggled to market themselves. The problem was that the new SaaS feature development diluted their product to the point that it didn’t obviously serve one type of audience anymore.
How clear is your company vision? If you have a clearly defined vision that you need to stick to, you can also evaluate whether certain feature requests will take your business off course in the long term. This can save you from making the short term decisions that turn out to be problems for your product later on.
Estimate Resource Required to Implement
Whilst the amount of work needed shouldn’t determine whether you build this feature it certainly influences it. You may wait for a suitable time when you have the available resource to allocate to the larger yet high priority feature requests. What about two features deemed to have the same level of priority yet one represents a highly resource-intensive development process and the other a much lesser resource? Perhaps this would lend weight to the argument that you develop the lesser resource-intensive feature to build more value into the app faster.
Using t-shirt sizes is a quick and dirty method used to estimate the development resources required to get a task done. At this stage you only need a rudimentary indication and this method enables you to quantify the comparative resource required to develop each feature. You could use a range of 6 sizes including XS, S, M, L, XL, XXL, assigning a size to each feature request to enable you to discuss this easily, assessing the relative resource requirement of one feature compared with another.
Consult and Listen to Your Team
It’s important to involve your team in product updates for a variety of reasons. Depending on the size of your team and the divide in job roles, some of your team may have valuable insight into what customers value. How well is this information communicated throughout your business? Perhaps the customer support team is aware of a real user requirement that your developers are not aware of. Perhaps your sales team is hearing objections related to a missing feature and this information has not yet been disseminated throughout your team. Ensure you’ve set up some system for sharing valuable knowledge throughout your company.
Furthermore, you’ll want to ensure team buy-in. Does your decision on the next feature motivate your team? If not, it could be a slow uphill battle getting it developed and released. If your team understand why the feature is important, know where the need came from and where involved in the process you may increase development efficiency and improve team morale.
Use a Repository for Feature Requests
All you need is a simple place to store feature requests and track where they came from and the level of priority you associate with each one. There are several platforms and tools for doing this (see wantoo.io, enduserfeedback.com or openvoyce.com) but in my opinion, Trello is a perfectly adequate place to store all of this information.
A system for your board helps to share information with everyone involved. You can do this by creating lists to categorise feature requests, adding colour coordinated labels to your cards to indicate priority and assigning users responsible for logging the feature request.
Consider Opportunity Cost Associated with Each SaaS Feature Development
Once you develop a feature for your product it can be tricky to take it out. It can be a waste of time and resources spent developing a feature that wasn’t of a high-level priority. Furthermore, users may have gotten into the habit of using it. For these reasons, it’s healthy to take a bias towards inaction. This prevents you from making bad decisions and pushes absolutely essential features to the top of your product development pipeline.
Let Users Be Your Memory
The customer voice drives your decisions. Users will remind you which feature requests are a priority via their feedback. This feedback will come to you by listening to the sources you’ve set up to receive their feedback. Ensure that the data you learn is being fed into your Trello board or feature request repository so that they accurately reflect the priority as indicated by your users.
Need a hand?
If you need help developing features, please reach out to us at UserActive.io to book a no-obligation call to discuss your UI/UX challenges with a SaaS expert. We’ll offer advice on your current situation, provide a steer for your project and see if we’re a good fit to help. You can also book here.
