{"id":2889,"date":"2015-04-28T09:21:22","date_gmt":"2015-04-28T07:21:22","guid":{"rendered":"https:\/\/usersnap.com\/?p=2889"},"modified":"2025-08-29T19:09:15","modified_gmt":"2025-08-29T17:09:15","slug":"release-early-release-often-paradigm-interpretation","status":"publish","type":"post","link":"https:\/\/usersnap.com\/blog\/release-early-release-often-paradigm-interpretation\/","title":{"rendered":"How to live up to the \u201cRelease early, release often\u201d paradigm"},"content":{"rendered":"\n

You probably know the common phrase \u201crelease early, release often<\/strong>\u201d. When it comes to developing software, people won\u2019t stop recalling that sentence. Since we think that the phrase is quite generic, I\u2019d like to show you how we interpret that programming paradigm<\/strong> and why handling features requests from customers plays an important role.
<\/p>\n\n\n\n\n\n\n

Try Usersnap for User Feedback<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n

What we think \u201crelease early, release often\u201d means.<\/h2>\n\n\n\n

Generally speaking this software development philosophy emphasises the importance of early and frequent releases<\/strong>.<\/p>\n\n\n\n

Tight feedback loops between developers, testers and customers are key here. It\u2019s kind of a contrast to the traditional way of releasing software within lengthy sprints (My gosh, do you remember those times as well?).<\/p>\n\n\n\n

Basically we – at Usersnap – try to live up to that philosophy through establishing an open-minded culture<\/strong> in the way we work. Not taking things for granted and considering different viewpoints from everybody involved, helps you to get there.<\/p>\n\n\n\n

Here\u2019s how we interpret the \u201crelease early, release often\u201d paradigm:<\/p>\n\n\n

\n
\"release-early-release-often-interpretation\"<\/figure>\n<\/div>\n\n\n

\u201cRelease early, release often\u201d doesn\u2019t prevent you from failing<\/h2>\n\n\n\n

However, following the paradigm won\u2019t 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<\/strong> by asking the wrong questions or simply asking the wrong people.<\/p>\n\n\n\n

Find your \u201cjobs to be done\u201d<\/h2>\n\n\n\n

In order to keep our product sprints as fast and productive as possible, we follow the \u201cjobs to be done\u201d framework<\/strong>. Conventional marketing techniques teach us to segment and frame customers by attributes – like age, race, demographics, etc.<\/p>\n\n\n\n

The jobs-to-be-done framework in contrast evaluates the circumstances which arise in someone\u2019s 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.<\/p>\n\n\n\n

So first things first: Find answers to the following questions:<\/b><\/p>\n\n\n\n