Dark magic

Scoping an MVP is a delicate balance that can make or break a company. We’ve all seen projects where overspending on an overly ambitious MVP drained resources and led to failure. On the flip side, we’ve also seen projects and opportunities slip away because the MVP was not interesting enough and later on someone else nails it - It was a good idea after all… In my 15+ years of making projects, and co-creating with many different people, I’ve encountered these challenges time and again, and I’ve had my share failures and successes.

I’ll be sharing my experiences and war stories to hopefully help some of you navigate this tricky terrain.

Is it worth it?

MVP, for me has to answer just one question: “Is this worth my time?” And I should spend as little resources as possible to answer this question. The goal is to be able to show enough to a few clients/users (or investors at times) so that they can feel what the product could be, understand it and validate that the features I think are important are actually important. Users should use 100% of the MVP features naturally and ask for a few more. That would mean success. If there are features they don’t really use, means I am biased to do things I like or the idea needs work. Either way, I need to rethink what’s really the point of the product that attracts the users.

Futureproofing

Scaling, stability, clean code, “cool” features are not important and I don’t spend any time at all on it, of course with experience things just come out clean naturally and if you have developed your workflow over time to automate scalability, then you can have a scalable and clean solution at MVP stage which happens most of the times these days for me. But I don’t really put any extra time on scalability. If it can handle 10 or 20 users, that’s just fine.

What should be there?

An easy heuristic would be: If Im telling someone about the product for the first time, how many features do I really need to mention (and which) until they really start listening (spark of interest). Those are the product features that I need to add. And I need to add them just well enough so that people understand it and try it and I can tell the story. The less features I need to tell a story the better I can focus on really delivering that promise of quality and usefulness, even if the MVP itself doesn’t fully solve the problem yet. It’s all about people beliving your promise that the tool will rock their lives.

Amazing but discardable

It should be absolutely fine to throw away the MVP and start from scratch after a successful MVP run. It’s always much easier to re-write then it is to write. And when you already have the confidence and the backing of your users, peers and investors, and you have your critical features figured out, you can really focus on bringing that product to the spotlight and getting ready for success.

That time when we took it to the extreme

Here’s a very illustrative example from way back when. In 2009 I was part of a an art project that required the creation of an iPhone app (iPhones and apps were really a new thing back then) it was an insanely technically challenging app that relied heavily on very specific UX design, and we had almost no time for it.

We had to recreate the iPhone maps app but add turn by turn navigation (iPhone didn’t do that back then) and add extra instructions that would make people get lost and interact with other people at every turn on the way and still get to their destination in the end (although it could take quite a while).

We had little more then 3 weeks to do this (production team of 2, only me coding) and we needed the app to be user tested extensively and the extra instructions designed to perfection. It seemed almost impossible…

My colleague at the time (and business partner for many years after that) Rui Guerra, had the brilliant insight that the first prototype needed to be out for testing in a few hours after the first meeting. He was right. We did it by running to buy notebooks and pens, drawing rough maps and instructions on every page and sending everyone in the lab out to the street pretending that the notebooks were a phone. This proved critical and all the most important design decisions were done by extensively using those notebooks for two weeks while I struggled my way through developing the first working version of the app.

The app grew from silly, to incredibly interesting by iterating on those notebooks, and MVP was actually reached before the first broken version of the app was built.

When I got the app to finally work, we already knew exactly how to design the instructions so they would be fun for our users and, not only, we managed to make the deadline, the project was a success. You could argue that it wasn’t an MVP, just a prototype, but I am sure that if the app wouldn’t have woked, we would have just designed and printed really fancy notebooks and still make the project successful. The notebooks definitely answered the question “Is this worth my time?” and without that, we would have given up.

Hope this helps anyone, and wish you all great success.