This is a quick post on why code and the ability to programme is not important to you – initially – when you are looking at building your MVP. No code in an MVP!
I’m working with a couple of startups at the moment and we ended up having the same conversation in both at the moment. The first is a sports based startup in Los Angeles. I was talking with the CEO when the message came through on slack from the CTO
Backend for the MVP will take about 3 1/2 months
No Programmers does not mean no MVP
There was a long pause and a mutual feeling of – “we really need to start rethinking a lot of things right now”
That was the first.
The second was with Leander when we we were having our weekly meeting working on Lean Card. The actual detail is for a later conversation but basically we were working through ideas for the product road map and what the MVP should look like. Then Leander said
If our unique value proposition is that we offer “awesomely easy business cards” then what we are offering can be described as project management. I don’t need a computer to test that.
So in both cases we ended up sitting down and thinking how the business team could sit down and test all the key hypotheses without a single line of code.
This drive came from a few reasons
- We can do it now
- If it doesn’t work we can change easily
- We don’t waste Dev time or money
MVP for Sales
For the sports startup the key testable hypothesis was whether suppliers would make a commitment which would validate part of the model. The LA sales team already has verbal commitment but we felt it was really important to actually get suppliers signed up to provide traction and real validation.
The idea is then to build some ultra simple sales sites on Facebook – provisionally with Wufoo and stripe and test several different customer segments. That will be done in the next few days and will start giving us some real validation – and just as importantly real life experience of which segments are best and how we need to design the app.
MVP for Operational Processes
For Lean Card the idea was exactly the same. Instead of using a cobbled together tech solution the MVP here was to sample do the process of project managing business card design with family, then friends, then acquaintances, then strangers, so that we could experience what worked and what didn’t. We have a strong idea of what the roadmap should be, but the getting out of the building, totally non scalable process of doing everything manually ourselves is going to make it very clear what is really needed in the first electronic versions and what is not – and maybe even that we need to pivot.
In both cases the net result is to derisk the development process as much as possible. A few months ago I was working with a startup who was looking to persuade people to wear their iphones to stream TV style adverts on public transport. We stuck some iphones to people with sticky tape and started playing Coca Cola dvert using YouTube. Then we send the ‘volunteer’ walking through a busy shopping centre to see what happened. The rest of the team tried to count how many people looked at the screen and how long they looked for. Total failure and an early pivot.
The learning point for this is to forget about the code and brainstorm simple and easy ways that you can start looking for validation of key hypotheses, start testing workflows that are critical to operations and see how customers react.
As someone said to me yesterday
It’s scary going and talking to strangers
Very true, but get out there and do it!
