In our recent post I’ve shown you how we interpret and live up to the “release early, release often” paradigm of software development. In this post I’m going to show you how we handle feature requests and implement new product features. Everything backed by customer feedback.
Managing a newly launched product and thinking about the vision and roadmap of your product isn’t that easy.
And sometimes talking with colleagues, friends and your first users will make you even more doubtful about certain new features and your road map. This will probably make you stop collecting information & feedback. Please, don’t stop gathering information.
We think: The more information you have, the less risky it is.
Asking customers about the job which needs to be done
Continuously ask yourself (and others too) about the problem which your product is solving. Ask for that problem. And verify the solution you’re offering through customer interviews. Here’s how we conduct our customer interview.
Our product team basically handles the product roadmap with a so-called feature matrix. To be honest, it isn’t that complicated as it may sound. The feature matrix at Usersnap is a google spreadsheet which looks like this:
The feature matrix includes every new feature we or any customer or user like to see in our future product. Yes, any user. If a user tells us about certain feature requests we put that in the feature matrix.
We give the request an expressive name (=desired outcome) and a short description (what the feature is about).
We then basically have 3 columns which are important for prioritizing new features. These are:
- Importance: how important is a future feature for our (future) users
- Satisfaction: are your customers satisfied with certain features / use cases
- Amount: How many users will be affected by this new feature
Having drafted a first version of the feature matrix, we then start adding questions and potential interview partners to the matrix.
Again, another Google spreadsheet helps us to track down importance and satisfaction on various features through skype interviews with our customers. The matrix looks like this:
Those questions which we then ask customers are not generic questions like “What do you think about feature X?” or “Would you like to see feature Y in Usersnap?”. We rather ask if people are working with certain features and for what use cases they are being used.
Outcome driven innovation & opportunity algorithm
We basically prioritize our features by calculating the opportunity of each new feature. We therefore use the opportunity algorithm developed by Anthony W. Ulwick. Ulwick’s outcome driven innovation framework helps us a lot to focus on the truly important product features. The algorithm basically includes the following parameters:
- Importance (of a new features)
- Satisfaction (of the user with certain features)
- Opportunity (which can be gained through implementing certain features)
Therefore the calculation looks like this:
This algorithm basically measures and ranks new features and product updates regarding their innovation opportunity.
Standard analysis look at the difference between the importance and the satisfaction. Ulwick, however, gives twice as much weight to the importance than to the satisfaction. The higher the opportunity score of a certain feature, the more priority we put on implementing this feature. And those features are the ones on which we are working.
Since resources are a limited good (especially in startups), we focus on the features with the biggest opportunity score. This opportunity algorithm won’t prevent you from failing or working on the “wrong” features, but it will give you a clear outline on what’s important and what’s not.
What’s your way for working on product features and which to focus on?
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.