“If you are not embarrassed by the first version of your product, you’ve launched too late.”
– Reid Hoffman, Founder, LinkedIn
Here’s the scenario: You started with a great idea, partnered with an excellent tech founder, and got $1M in funding so you could get the first release out the door. Part of your new-found funding went to hiring 3 Engineers. As the weeks of product development pass, you review the usability, demo it for prospects, and get feedback on how to make it better. The Engineers are working long hours to complete the first useful release for beta. When you review the usability with the Advisory Board or prospects, you get lots and lots of feedback about what works and what doesn’t, and you’re making changes—often daily.
One night you wake up and wonder, “Will we be tweaking this product forever? Will it ever get out the door so we can close some sales?” It’s time to have the conversation about what is “good enough” to ship. That means it’s time to revisit the original set of product requirements—the ones you and your team agreed needed to be implemented to ship the product. Go back to work with the team to completely scrub the bare minimum of what needs to be in the first version. Everyone will have opinions about what needs to be in the product when you ship. Justifications for including requirements may sound something like these:
“We won’t be able to reach one of our vertical market targets.”
“We’ll have a product that will only scale to 1M requests/timeframe and we need 10M.”
“Beta users hate the UI.”
During the scrub remember to ask, “What’s the cost of not implementing this functionality? Will we be able to add this functionality later without re-architecting the product?” Asking these questions lets you and the team make an informed business decision about minimal viable functionality. And at the end of your discussion, remember to reassure the team this sort of dialogue is healthy because it helps the company stay focused by prioritizing functionality into the releases on your road map—and ultimately drives your success.
A few years ago I had a great team that was working endless hours on a new workflow product. We started with requirements that were loosely defined and easily interpreted differently by each member of the team. Our usability expert seemed to re-interpret the same requirement each week, for example, but with the honest intent off making the product better. When it became clear we weren’t going to meet our functional complete date, I called the Engineers, PM, and QA together. As we scrubbed the requirements, we realized we were going to deliver 60% of what we originally thought was needed, but we still had very useful product. We finalized our definition by doing an in-scope/out-of-scope as a team for the rest of the company. And although it was a difficult conversation for the team to have, we delivered the first version—and got first mover advantage. So in the end, our 60%-ready first release actually turned out to be “good enough.”