Product Development April 8, 2020

The zero customer heuristic

Chris McCormick @chr15m

When you're building some MVP or SLC it's tempting to over-think technical choices early on. It's tempting to build in all kinds of features and infrastructure.

"People might want a PDF," you think to yourself, "so I'll also build and deploy a PDF rendering server!"

"I'll need a way to measure everything my ten million customers are doing at scale so I'll deploy this elastically scaling mega analytics doodad framework server and hook it up to every user action in my app!"

cricket chirp gif

It's much easier to imagine new features than it is to actually build them. Before you know it there is a vapourware castle shimmering on the horizon.

I've found a useful thought pattern to combat this type of over-engineering. For every technical question just think to yourself:

What will my zero customers think of this?

When you are building the first version of something there are literally zero users. Unless it is the core function of the thing you are building, making a PDF rendering server or deploying a giga-scale analytics system is not what you should be doing. Your zero users don't care about those things! Getting even one person to actually use your thing and tell you if it's good or not is what you should be doing.

Let's protect the most scarce resource of all: our own time. At the start of the project let's make a bee-line towards shipping the best possible implementation of the core function of the software so we can find out if its useful and good.

  1. 3

    I love the concept of core user, core problem, core feature, figuring out 1 one but an 10x feature and nothing else

  2. 2

    I can't deny I struggle with two things; 1.) reducing the MVP to the least number of features, and 2.) a desire to release bug-free code.

    1. 1

      On bug free code I have a slightly controversial point of view. Writing code with less bugs can be achieved but it requires discipline and avoiding certain bug-prone programming patterns (e.g. mutating state willy-nilly, certain async patterns). Fortunately there are languages and tools which can drastically reduce the number of defects in code over other languages and tools, because the discipline is baked into the language/tooling itself, and so you don't have to actually be as self-disciplined.

      I am a ClojureScript user and for me this language is the pinnacle of this. I came to it late in my programming career but it has completely changed the game for me. Because of ClojureScript I can build stuff much faster than before and with fewer defects.

    2. 1

      On reducing the number of features, what I find helps tremendously is to keep two lists. First is the list of "absolutely must haves", the critical features, and the second list is "as soon as I ship I'll implement this". Maintain these lists and be ruthless about moving things from the first list to the second. If you can ship a simple, lovable product without implementing something, put it on the second list.

      When you think of a new feature it seems super important because you are excited about it, and so you put it on the "must haves" list straight away. That's totally ok. Over time as you review the lists you will find a lot of things can migrate from "must have" to "post-ship" as your excitement for them is tempered by the passage of time.

  3. 2

    Seems like a good methodology. :)
    It's also similar to some principals shared in the Lean Startup book from Eric Ries.

    From my experience it is good practice to create simple clean features and ship it to market as soon as possible. Then iterate over it after costumer feedback.

    Cheers and Good luck for your project.

  4. 1

    This is awesome. I will re-read this often on my way to MVP launch. Thanks!

  5. 1

    Ha! Cool!