About Me
Blog
Projects

The Minimum Viable Release

  • Note: Transferred from Ghost Blog on July 21 when cleaning up Digital Ocean droplets

  • Disclaimer: This is an attempt to name and put in writing a simple concept I use when working on web software projects. It is not intended to be "Revolutionary new way of getting work done™". The reason I'm writing it so that I can point to something when new team members ask "What's a Minimum Viable Release", and as a resource I can send friends when this comes up in conversation. It works best on small teams, where team members have T-shaped skillsets, and where the project lead is part time.

  • Work expands so as to fill the time available for its completion.

  • – Parkinson's Law

  • When working on short term (daily or bi-weekly) cycles, particularly on large projects, it can be easy to lose sight of the bigger picture. The list of improvements that can be made to a product or feature is potentially infinite, but the customer feedback loop doesn't start until something is pushed to production and put in users' hands. The Minimum Viable Release is used to ensure that short term work planning doesn't become untethered from the bigger picture, and to ensure your team is getting something into users' hands as quickly as possible.

  • The Process

    • Identify the Goals

    • Set the Work Themes

    • Identify what's in and what's out

    • Set a deadline

    • Identify The Goal/s

    • Are you launching a product, validating a hypothesis, trying to raise money, or win a new contract? Everything else is downstream of this, so spend some time on it and try to be as explicit as possible.

    • Set the Work Themes

    • Themes serve two purposes:

      • Each theme is a prompt when planning – it's much easier to identify potential improvement areas with a trigger word like "Mobile Web" than with a project title. I've found the process of identifying what remains to be completed to be more thorough when starting with themes.

      • Delegation – this is optional but highly recommended. If you have engineers or designers who can do more than just translate specs to designs/code, delegating themes allow you to change how you assign work – rather than one person attempting to collect every possible task across the project and assign it, individual team members can identify their own tasks, based on their owned themes.

    • There are no rules for what constitutes a theme. In fact, the reason for using the word "Theme" here is to allow for flexibility. Themes from a recent project of mine fell under  screens (E.g.'Ideas Section') , Personas (E.g. 'User Features'), and UX areas ('Mobile Web'). If you're familiar with MECE, themes don't need to be Mutually Exclusive, but should be Collectively Exhaustive. Tasks can and will span multiple themes. If your team communication is regular and fluid enough this shouldn't be an issue.

  • What's in and What's out

    • This is the most important step. Something I've seen happen often is that a designer will be commissioned to design a new product or feature, and those designs will then be handed to a team to implement. Armed with goals and themes, it's very likely that your first MVR can omit 20% to 30% of what's in the designs.

  • Set a Deadline

    • The deadline is the thing that ensures you actually ship something. Ideally this is the date when you push your work to public users, but for projects where the polish and finish is important at launch, this can be the date you demo to clients or internal users.

    • It's important that the team knows what the deadline is, and that it's regularly referenced once the work is underway. It's equally important that there are no negative consequences for missing it. This whole format (broad overlapping themes with individual owners) rests on the presence of trust, and good, regular communication within the team. If you're going to be strict with your deadline, your team will rightly expect you to be strict with your scope.  The purpose here is to incentivise collective action toward a goal, not to "keep your team in line".

  • What does this look like?

    • The tool doesn't matter a huge amount, but I'm using airtable to manage a current client project and it's working very well. We have a table called tasks, a table called releases, and a table called themes. Here's what it looks like:

    • The "Notes" field of our first release in the releases table!The "Themes" table which lets us see what's still to be done

  • Website Page