{"id":6824,"date":"2022-04-22T21:50:28","date_gmt":"2022-04-22T13:50:28","guid":{"rendered":"https:\/\/slash.bravefactor.com\/?post_type=resources&p=6824"},"modified":"2024-01-30T16:31:01","modified_gmt":"2024-01-30T08:31:01","slug":"become-relevant-within-3-product-versions","status":"publish","type":"resources","link":"https:\/\/slash.co\/articles\/become-relevant-within-3-product-versions\/","title":{"rendered":"Become relevant within 3 product versions"},"content":{"rendered":"

The lean startup movement and rapid prototyping practices that have flooded the market, advocate for \u201cgetting out of the building\u201d and rapid user testing.<\/span><\/p>\n

But when you start building your first production-ready release (\u2018V1\u2019), how much should you build? And how should you think about your roadmap after V1?<\/span><\/p>\n

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.<\/span><\/p>\n

Three product versions to stay relevant<\/h2>\n

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\u2019s dig in!<\/span><\/p>\n

Version 1, deliver value to your first \u201c100\u201d users<\/h3>\n

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.<\/span><\/p>\n

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

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.\u00a0<\/span><\/p>\n

We advocate to keep v1 focused and \u201csmall enough\u201d, ideally at ~500 development days. In the event you\u2019re building a product that needs to be embedded in a more mature enterprise environment, there could be other considerations.<\/span><\/p>\n

Why 500 development days? We find that it\u2019s 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.<\/span><\/p>\n

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:<\/span><\/p>\n