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 which one to develop next?

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. But 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, including free ones like Google analytics to 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 I record the sessions with a screenshare recording tool. I often use Skype with the Call Recorder app 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 clients 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 screenshare lead 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’sfirst 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, so 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 feedbac, such as telephone calls (a great and often underexploited method), in-app messaging services, emails, surveys, questionnaire’s 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 effect your company will influence your decision greatly too. For instance, it may be that many of your customers use a particular 3rd party platform and 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 certain 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 develop this feature, will it cost you time where you could have been developing something else that would’ve made a bigger impact?

Ensure Features 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 all of the new features 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. And 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 development resource 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 on 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 are aware of a real user requirement that your developers are not aware of. Perhaps you’re sales team are hearing objections that 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, add colour coordinated labels to your cards to indicate priority and assign users responsible for logging the feature request.


View the Demo Trello Board

Consider Opportunity Cost Associated with Each Feature

Once you develop a feature for your product it can be tricky to take it out. It can be a waste of time and resource 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

Whilst you have a place to consolidate all of your feature requests and associated information it’s still the customer voice that drives your decisions. You’ll be reminded by users which feature requests are a priority by listening to the sources you have 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.