Become relevant within 3 product versions • Slash

The lean startup movement and rapid prototyping practices that have flooded the market, advocate for “getting out of the building” and rapid user testing.

But when you start building your first production-ready release (‘v1’), how much should you build? And how should you think about your roadmap after v1?

From our experience designing and building dozens of products at Slash, we use a simple rule of thumb: 3 versions x 500 development days per version.

Each version allows you to validate and master aspects of your digital value proposition in the eyes of your users, and gets you closer to building a relevant product that can grow to achieve its mission. Let’s dig in.

Version 1 = deliver value to your first “100” users

Your first version is really aimed at solving a core problem for 1 user type. This v1 may not be comprehensive and likely cuts corners in many areas, but it should add meaningful value to your chosen user in how it solves their problem.

At Slash, we prefer that v1 is only built if you already have completed user testing of the concept design (e.g low-fi mockups, perhaps some business model) and of the product design (e.g user journeys, UX or UI screens).

Once you have a degree of validation, you can then proceed to prioritize the central unit and core flows of your product, and extract epics, stories and estimates.

We advocate to keep v1 focused and “small enough”, ideally at ~500 development days. In the event you’re building a product that needs to be embedded in a more mature enterprise environment, there could be other considerations.

Why 500 development days? We find that it’s enough work to deliver a (SaaS) product that is meaningful and differentiated, but not too much that you prioritize the development of non-essential features before your users tell you they care about those non-essentials. In some cases, 500 days is just too much or too little. There are no hard rules here, we just see this as a good reference and starting point for discussion.

What does this look like in practice? Say you have a team of 6 developers, 500 days then should amount to ~4 months of work to deliver some core functionality. In the case of a SaaS product this would be:

An end-user interface that delivers a superior customer experience and user flow than what’s out there.
A simple administrative web dashboard or back-office to control some parameters
Some backend functions to process payment, integrate with 1-2 key third-party solutions.

The target outcome of v1 would be that one user persona is engaged and excited about your product, is actively giving you valuable feedback to improve the functionality and user experience, and is ready to wait for v2 when you can deliver them a superior product.

Version 2 = make your first users your biggest fans

Now that you have the feedback from the user, you can start optimizing your product to accommodate all that feedback for version 1. This is the second phase of development, and here the objective is to get the first user persona to be super happy with the product and to promote it, and to gain more users.

The work is done not only with the first user, and you aren’t going to rely purely on their efforts for introducing your product to other people. Over the 500 days that version 2 is going to take to build, you can promote the product yourself to a new segment of users.

The outcome of this is that you will get new feedback and requests for changes – if only because this new segment is not the type of user you initially optimized for.

Version 3 = diversify your fans and get ready to branch out

The scope expands when you get to making version 3 of the product. The continuous improvement and adjustment are for optimization of the product for the next user persona.

What does this process give? The outcome is a model where, with two user personas and some transactions, you are able to go to the next level.

After version 3, you can go to financing from external investors (venture capital, etc.) – or just grow organically.

This is how we usually think about the three versions of the early-stage product.

Our framework of development

Let’s consider an example to see how this works. For instance, one of our startups wanted an MVP and our estimate was that it would take 800 days of work. We told the startup team it was too much, and they could get the MVP in 500 days – not to reduce the work artificially, but because we know that it’s enough to get a version of the product that will give sufficient insight from customers. It does not mean we need to wait for 500 days before testing the product. We can test and feedback very regularly.

The Slash team uses this framework to explain how much time the development takes. It is also a good way to consider our risks.

In short, this is how the process goes:

In approximately 500 days, you solve a core problem for 1 user type, prioritize your product’s core unit and flows, and extract epics, stories, and estimates.
Over the next 500 or so days, you accommodate for the feedback and promote your product to new users.
Once done with that, you expand the scope of users and optimize the product for the next user persona.

The way the framework is used is to set expectations with the clients and with our own startups, to have a rough indication of how long things take. It is really more of a risk management framework, a set of heuristic rules – based on our experience – about what is happening statistically. It is a way to set expectations about the level of investment, time, and effort something requires.