You probably know the common phrase “release early, release often”. When it comes to developing software, people won’t stop recalling that sentence. Since we think that the phrase is quite generic, I’d like to show you how we interpret that programming paradigm and why handling features requests from customers plays an important role.
Generally speaking this software development philosophy emphasises the importance of early and frequent releases.
Tight feedback loops between developers, testers and customers are key here. It’s kind of a contrast to the traditional way of releasing software within lengthy sprints (My gosh, do you remember those times as well?).
Basically we – at Usersnap – try to live up to that philosophy through establishing an open-minded culture in the way we work. Not taking things for granted and considering different viewpoints from everybody involved, helps you to get there.
Here’s how we interpret the “release early, release often” paradigm:
However, following the paradigm won’t stop you from failing with your product/startup. Prepare yourself getting harsh or non-qualitative feedback from your users. There are lots of things which can go wrong by asking the wrong questions or simply asking the wrong people.
In order to keep our product sprints as fast and productive as possible, we follow the “jobs to be done” framework. Conventional marketing techniques teach us to segment and frame customers by attributes – like age, race, demographics, etc.
The jobs-to-be-done framework in contrast evaluates the circumstances which arise in someone’s life. People make product decisions because they face a problem in their life which they would like to solve. The product itself is bought, because of that job.
So first things first: Find answers to the following questions:
As the “release early, release often” paradigm suggests to keep loops between sprints tight and your users and customers close, we try to offer as many touch points with our customers as possible in order to collect as much qualitative feedback as possible.
Here’s how we try to do that. I really put the “try” here because I think there’s a lot of potential left.
We do send out a couple of emails after someone signs up for a trial. On the one hand we try to learn more about our on boarding users in order to understand their workflows and work better.
On the other hand, we want our users to get to know us better. It’s probably like a blind date if someone signs up for a new service, since she/he do not know what to expect.
Email marketing is a great way to build up a relationship,, since it provides you and your users the freedom to choose with whom you’d like to interact and with whom you simply don’t. And yes: we do send out some automated emails. But sending automated emails, doesn’t keep you from making them emotional and appealing.
We recommend you to:
We track the activity of our customer, meaning how “actively they are using our tool”. In our definition, a user is an active user, if he has created more than 3 screenshots or bug reports with our tool, or if she/he has logged into her/his project dashboard more than 3 times.
Our CPO Josef jumps on a skype call with active customers on a regular basis asking specific questions about how users think about certain features.
He doesn’t ask simple questions like “How do you like FEATURE X?”. He builds up his questionnaire following the principles of Outcome-Driven Innovations developed by Anthony W. Ulwick.
Especially making use of the opportunity algorithm helps us tremendously in the way we gather information, ask your daily/weekly/monthly active users and prioritize new features.
We’ll get back to the opportunity algorithm and how we ask our active users soon in an own article.
Happy customers are probably the most valuable thing we strive for. Working on features which customers requested is one way to make them more happy (of course there are other ways too 😉 ).
By releasing so-called “invisible features”, we deploy new features only for a certain segment of users. Whether you call it “soft release” or releasing invisible features, it basically means that we add certain new features to our product, which are only visible to certain user segments and invisible for everybody else.
We believe that adding invisible features gives us the possibility to keep the feedback loop with our users tight. Getting first-hand feedback from those customer segments gives us the opportunity to build better product features for everybody else.
If you’d ask me how that workflow looks like, I’d probably draw you something like this:
The jobs-to-be-done framework and the “release early, release often” paradigm will help you to boost your product updates tremendously – if well executed. By including comprehensive customer feedback and releasing invisible product features we try to keep the product sprints tight. However, we definitely know that there’s still a lot of room for improvements.
Are you making use of any of the mentioned frameworks? If so, what’s your experience with this? Or are you using any other helpful technique for working on new product features?
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.
What’s the point of launching a great feature if no one notices? The real magic…
Ever wonder how some companies make product updates feel like the highlight of your day? …
Picture this: You’re in the middle of a hectic workday, balancing strategic decisions with daily…
Ever wish customer feedback came with subtitles? With the right feedback analytics tools, you can…
Survey design is the backbone of effective data collection, enabling businesses, product managers and researchers…
Wondering how to master Jira’s vast capabilities for strategic project/product success? Epics are the key…