…and after the MVP?

You may be familiar with this triangle representation of a “Minimum Viable Product”, or MVP. The idea is that you have a product that contains just enough of all its critical components to be actually sellable, and the pink shaded area represents the amount of work or resources required to bring it to fruition, out of the “full” range of possibilities if budget/resources were not an issue. This diagram is usually presented side-by-side with this one that shows a contrasting “bottom up” approach:

The same amount of resources just fills the bottom layer, giving you lots of functionality but no way of using it, making it unsellable.

That’s where the analogies generally stop. I’ve encountered several misunderstandings of what happens next. Firstly, “the same, but bigger”, where more budget arrives, accompanied by a matching expansion of the spec:

Sure, you get “more” built, but it’s still the same proportion of what you’re aiming for, so it has not really progressed beyond the MVP.

Next we have the “expanded spec”, where the intended implementation is increased, but the MVP implementation stays where it is (i.e. no additional outlay). While management might want the MVP proportion to scale with the spec, of course that doesn’t happen – you have just made your MVP proportionally smaller rather than bigger, likely breaking its “viable” status:

Next up, is “do the same again, because scaleable”!

This is clearly a management disaster, and might be illustrated by jumping straight into a basic project using kubernetes and microservices, or perhaps writing the first page of all the chapters in a book. You will drown in complexity while achieving less than the intended MVP.

The missing image is very simple, I’ve just never seen it actually drawn; it’s this:

Stick to your plan, implement more of it as resources and budget permit. This may involve rebuilding some of the things you did earlier but bigger/better/differently, not just adding. There is another common set of these diagrams that uses a skateboard / scooter / bike / motorbike / car progression analogy that does work a bit better to convey that (e.g. both skateboards and cars have wheels, but skateboard wheels are not good enough for a car). That’s all.

The web developer’s holy vhost trinity

When you’re developing web stuff, working with projects in path names (i.e. not at the top level of a domain) can be difficult (gets in the way of absolute links, rewrite rules etc), so you often need to set up a local apache virtual host, stick an entry in DNS and create an SSL certificate before you can get on with the serious business of doing some real work. This can get to be a drag when you do it a lot, but there is an extremely elegant solution that means you’ll never have to do it again…
Continue reading “The web developer’s holy vhost trinity”