Recently I had the pleasure of working with Amanda Goetz, Nate Casey, and David Gray of Availendar on creating the first version of their product. Working on a new project is always exciting (and always a little chaotic) - everyone has a pile of ideas they want to see implemented and refined. Naturally, some of those ideas are gems and should be refined and polished; others are well-intended but either unnecessary or not a good match for the over-arching goal of the product.
The first step in turning ideas into something substantial in software is two-fold: one, you need to clarify your vision of what it is you’re trying to make and two, taking these ideas and distilling them into something organized and actionable. Usually we call the result of the latter step there “user stories,” but even if you don’t apply a fancy label to them, it’s important to have prioritized items representing the key things that need to be worked on next.
But worked on, for what purpose, exactly? To reach MVP. The Minimum Viable Product. The shapeshifting unicorn of a startup. For Availendar, as with all of the early-stage companies we partner with, we needed to establish what MVP would be so we knew how to measure progress.
There’s an extra twist to this for your first release, however: you don’t have any users yet. You don’t have much data yet. You have your gut feelings and a pile of assumptions. Some of those will serve you well, others will lead you astray. Your goal when making this first release should be to do as little as needed in order to get your idea in front of users - and then they can tell you if you did things right or not. You don’t want to spend all your capital going in one direction when your customers are going in another.
On Availendar we had the advantage of Amanda’s expertise in the event planning field; Availendar is largely shaped thanks to the pains she and her colleagues feel in the planning industry. We could use her experiences like a lens to focus on our stories. Does this take us closer to presenting a better way to plan events? If not, then it can wait. We need to get the central experience front-and-center, then we can build out around it.
It’s a balancing act - you want a target so you can determine if the stories you’re working on are going to take you closer to your goal. At the same time, you don’t want to nail down specifics too much in case your needs change. Nobody wants their user story list to turn into a codified Requirements Document with hundreds of pages full of “The System Shall.” We were fortunate on Availendar to have Nate and David, both of whom had been entrepreneurs before. They were used to having fluid requirements and were ready to be flexible.
So what’s a team to do? First, talk about your MVP. Mention it constantly. When you’re grooming stories, when you’re doing feature demos, when you’re just chatting about the project in general. If you’re always talking about it, you’re always refining it. On Availendar we were fully distributed with people ranging from Texas to New York to Serbia, so we had daily standups and weekly retrospectives - and when we did, we made sure that we always opened up with a discussion of where we were relative to our MVP. Did we need to change it? If yes, then let’s do it. No reason to kick that can down the road.
Next, always give it a good reality check when you mention it. Do you need to change what your target is? Yes, you very well might. But if you do, make sure what you’re doing is realistic. Do you really need to tie in to 23 different social networks? Do all these search options have to be there for the product to function? Does the admin panel really need that stuff on the dashboard? Sometimes the answer will be yes, yes we do. That’s a key differentiator for us and we need it to establish what we can do. Oftentimes the answer will be no. No, we can do without that. We can get by with a reduced-functionality version of that. We’d rather focus our effort elsewhere.
Never feel bad about saying something is out of scope for MVP. You’re not making a judgement against a person or idea when you do. You’re recognizing that time is precious and that everyone’s effort is better spent elsewhere for now. Have an idea backlog somewhere and use it - those things you’re talking about might be great for implementing in a few months.
Finally, have target dates. As you approach these, evaluate where you are, what you can still do, and what needs to be taken out. This can be stressful sometimes - so use them sparingly and reasonably - but it helps you focus and pare down what you need to do to the core.
After all, isn’t that what you’re trying to do? Focus on the core value you’re offering and do the least necessary to present that to the world and find out how people will use it. It may or may not be the unicorn you were pining after, but it will be the great start you needed.