Always Have a Real Use Case

On the uses and misuses of "MVPs"

I recently built a project I was pretty proud of.

It was a simple website generator that put together image galleries. For example, if you have a bunch of photos laying around in folders on your computer and you'd like to share them with someone... then rather than trying to file transfer them, you can generate a quick, simple website that showcased them as a personal blog (including free hosting as a github page). No need to sign up for anything.

Nevermind for a moment the narrow target audiences (technically savvy, github-browsing photographers who wanted a minimalist homespun site without being bothered to write html/css). Not only was I proud to have built a cool project that scratched a personal itch, I had done so using the best principles of minimally-viable-products!

After all, it did what it said and solved a narrowly defined problem! Put your photos in a folder, run the script, and out pops your freshly made website.

I ran it, tested it, and showed it worked. As an MVP, it was 'good enough' to release out into the world and do a short humblebrag blog post.

Of course, what defines an MVP is up for debate.

Is it a "minimally deployable product/service", one that can evaluate a hypothesis?

Or a minimal sellable product? Or a minimally usable one?

The MVP mentality is about being able to quickly answer important business questions about allocating time and resources to developing something further.

But depending on what you're testing with, you'll get different answers and feedback. Defining your MVP correctly can mean the difference between complete indifference to your project or someone excited to sign up and continue using it.

As mentioned, my project scratched a personal itch. I had photos laying around. I wanted to run a homespun website instead of signing up for an account with some SaaS company, but not be bothered writing code to do so. I was the perfect customer.

So I used it.

Turns out, what I was proud to proclaim was a 'product' ready for use was anything but.

Turns out, I had built and proven my concept with a very narrow set of assumptions. They held up in a controlled environment (my dev computer + test image set), but the moment I tried it with even my set of real trip photos, nothing worked.

While I had proven the MVP to myself, it was not an MVP to anyone else that might have tried to use it.

If someone else had run my code, they would have a received a bunch of bugs. It would have been met with dismissal or complete indifference – well this didn't work, moving on.

I had to go back and rewrite my code to support nested folders (because who has only one folder of photos at time?), image optimization (because no one will wait for a really huge page to load), support for different filetypes and case sensitive names (because .JPG files are not the only types of image files), and many other "core" features that I would have dismissed from other people with a hand wave that says, "that sounds like an edge case. This works for now, I'll handle your edge case as an improvement at some point".

Of course,  it didn't actually work. The things I thought were edge cases were completely blocking any sort of real world use, meaning that I was never going to get real feedback.

Having fixed the code, I ran it again.

It worked.

Not just technically. It worked to create a website that I was proud to share with my friends to showcase my trip. I ran it on a friend's set of photos and it did the same. It was now usable and evaluatable. There were still a lot of parts that needed improvement, but now I could get real feedback to improve the experience, rather than identifying the numerous ways in how it didn't work.

Every MVP strives to answer important questions about whether or not to continue down a path. But if you define your MVP too narrowly, you'll get the wrong feedback. What I learned is that there's a gulf between what you've made and what people are evaluating. It's not a viable "product" until you can actually use it in the real world.

As they say, that's why you've got to eat your own dog food to know if its any good; most customers and clients will be a silent majority, not giving you the feedback you need to hear.

So until you're your own first client, it's hard to say whether what you've built is minimally viable or even usable.