Building a minimum viable product (MVP) is one of the first things you do as a startup. You’ve found a problem, you’ve found a small set of early adopters and now its time to pull them in. But it is also something you do continuously. Be it as a founder, first developer or tenth, you should always be looking towards what is the next MVP. This is hard. You joined/started a tech startup to build cool shit or be technically challenged. You are going to be challenged, just not as expected. Every piece of code you write you need to expect to throw away next week. Why? Well customers don’t give a shit about you and your beautiful code, they care about product and whether it is solving their problem.
Decide what your customers most value
So how do you design your MVP? Again, it’s hard. Most often it’s not technically challenging but it is hard because you need to decide what features are most important. It is hard because you have to prioritise what is done now and what can wait. It is hard because you have to go through the mass of qualitative and quantitive data that you’ve amassed through various conversations and analytics. You need to decide what your customers most value. And once you’ve done that. You have to build it the quickest, scrappiest way you can.
Don’t be afraid to be a consultant
Let me tell you what we did at Hubble. Here is our original landing page:
It took us about 30 seconds to decide on colours, fonts, design and we got something up as quickly as possible. It blowed. But it was designed to describe the value proposition and encourage people to signup. It did that good enough. We tracked bounce rate and signups and spammed this across various Facebook groups, email lists and personal networks. Once they were signed up, we became a consultancy. Don’t be afraid to be a consultant, especially if you are building a marketplace. Often this is called the concierge MVP. With our first few signups, we contacted everyone individually and asked them about their office needs. We then went out, on the phone, and found them an office. For us, the concierge MVP worked. We understood the true pain our customers had, we had a fantastic set of evangelists for what we did (our now testimonials on the current landing page) and we knew what to build next.
Make every release an MVP
What did we build next? Another MVP. Never abandon that idea. Every release you do should be a minimum viable product. This doesn’t mean it has to be a pile of shit (it’s got to be viable remember). It just means that shouldn’t be spending overly long developing features that you don’t know will make a difference. At Hubble we haven’t yet been going a year yet but often we get lots of compliments about our platform. I’m still embarrassed by it. There are too many bugs, the design patterns are all over the place and the UX…well, could be better. But I’ve learnt that is how it should be. Reid Hoffman once said, “If you are not embarrassed by the first version of your product, you’ve launched too late” and he is completely right. At the end of the day getting it out there is paramount. Done is better than perfect.
Don’t get hung up on the tech roadmap
Finally, a lot of people will want to hear about your tech roadmap. I’m not saying abandon this idea. It’s a good idea to have one. But it is like a business plan. Most likely you’ll tear up it next month (or week), or at least you should. Again this means…drum roll please…don’t spend a lot of time on it. What you build next week is almost always predicated on what your customers did last week. The only benefit I see of a tech roadmap is that it provides a vision for your team and an element of accountability, which is important. Day to day though, what are you doing in your next 2-week sprint? Building an MVP.
