Your First 3 Versions: Part 8 of How to Commission a Software Project
Your First 3 Versions is part of the “How to Commission a Software Project” article series.
Your first version
Reid Hoffman, the founder of LinkedIn said “if you’re not embarrassed by the first version of your product, you’ve launched too late.” I love this outlook, but I find myself asking “What is the first version?” Is it best to start with a minimum viable product (MVP) or does it make more sense to put a confident version 1 stamp on your first public effort?
It depends on many factors, but we can cover the possible scenarios by answering a few questions.
- Does your approach to the first version really matter? Plan, build, test, repeat. Iterate until the product feels right and the market is (almost) ready. MVP became a thing because it was a manifestation of being able to move fast and iterate.
- Who are the users? If you are building for a small base of motivated users (internal business users, committed existing customer base, or something similar), MVP is super useful. You can deploy a small feature at a time (early and often) and make people’s lives better.
- Are you riding a trend to ensure product/ market fit? You do not have time to waste, but spend every minute making the first version amazing. Why? Because the advantages you have today are your understanding of the solution, your agility, and a head start. More-than-an-mvp is a better approach. Get it right before showing your hand to the market.
Version 2
By the time you’ve launched your product you should have a realistic plan for version 2 and a general idea of how you will adopt new features. At any moment, you should have a formalized plan including features and a timeline for the next release and a prioritized roadmap for what might happen after the next release.
The strength of the realistic plan is that barring some sort of train wreck, you’ll know exactly where to focus product development efforts. But don’t make it unnecessarily rigid because even if there isn’t a train wreck, you’ll want to tune in to the market, user feedback, and your own gut barometer to make sure v2, v3, and every iteration after are magnificent.
Later versions
It’s also incredibly important to identify a release schedule. Another reminder to be flexible is in order here. If you plan for 2-week feature sprints and a regular release falls during a practically inconvenient time, I give you permission to skip it or alter your existing schedule to accommodate it. That could also happen during a natural business call, a natural business roar, or if there’s just not much to do right now. Use your judgment – you’re smart.
However you’ve answered these questions to help design your first three versions, make sure you create a sustainable plan for future iterations and growth. Users will do unexpected things, customers will demand new features, and you’ll continue to have splendid ideas about how to make your product better and more profitable.
Interested in getting help with software product best practices?