This is a guest post I prepared for Venkatesh Rao's ribbonfarm.com. Go there to join the discussion.

When I first encountered the phrase minimum viable product, I thought to myself here is a term that is ripe for misinterpretation by droves of hyperpragmatic undergrad-aged startup founders with a cheque from Paul Graham and more energy than sense. Admittedly it's an appealing concept even if you don't fall into that category, but it's in my nature to take things apart and play with them.

My understanding of the goal of the minimum viable product is to arrive at something you can sell in as short a period as possible. Its purpose is to get answers to empirical questions that can only come from customers and users, while at the same time getting paid. Awesome idea. Just a couple of questions:

What exactly is viable?

I'm going to use the definition of a viable product as one that you can sell and eventually profit from. It's worth noting that the appeal of software to customers is inextricably connected to, but distinct from desirability, the appeal to users.

One of the first things a user experience designer will point out is that customers and users are not necessarily the same people, such as with enterprise or educational software. For a hosted app vendor, such as where MVP got its 15 minutes, it's the users who are often the customers, primarily paying attention, which I'm told is tantamount to paying money.

Whereas a conventional business has customers first and users second, a software company, especially a Web-based software company, has users first and customers second, due among other things to a protracted period of trying-before-buying — but I'm probably not telling you anything new here, so moving right along.

If users have primacy, then the path to viability is through desirability to have an ongoing relationship with the product, or at least glean substantive value from its output. But the central empirical question that only your users can answer is indeed if they want to use the product, which they can only do by using it. Which makes sense if the product is novel. After all, you can't do market research if the market doesn't exist yet.

Software tends to exhibit the following pattern: there's a pittance of business logic, which is what you're trying to test, surrounded by a profusion of cladding that enables people to put it to work for them. The problem I see here is that just about every programmer I've ever met considers the latter, at best, slightly less important than the former.

While you may not yet know what is desirable to users, you can probably compose a decent list of what is undesirable. I'll get you started: Non-functioning UI elements, alert boxes, dummy text, stack dumps, data loss — just off the top of my head. Unless your target users are patient developers, it might make sense to have your macro-level implementation priorities set by someone who considers the product from the outside in.

What counts as minimum?

In Notes on the Synthesis of Form, Christopher Alexander remarks that while it is fairly easy to get consensus in a group on what constitutes a valid requirement, it is nearly impossible to get people to agree on its priority. In fact, that entire book is all about rescuing the generic design process from the vagaries of human whim, bias and self-consciousness.

This is what originally raised my eyebrows about the MVP: the thought of a room full of developers bickering over what work not to do. Actually, it's more than a thought. It's a compilation of far too many memories.

If the goal of the MVP is to get selling quickly, the fact that you can have a protracted argument about whether or not a particular unit of work is part of the minimum set flies in its face. Often it's faster just to do the work, minimum or not. This isn't just an issue for teams either, unless you are immune to lying awake at night vacillating over whether to work on one aspect of a system or another, or do something else entirely.

This situation is exacerbated by the fact that a programmer is actually an executive. That's right: every line of code you write can be considered your own executive microdecision. While you may be getting told what results are expected, your articulation of the solution is going to be your own. You know this because these decisions can turn out to be business-critical, and because you invariably have the most information about what you are working on. If this wasn't the case, the person who did could probably do a better job, and faster.

If, as an executive, you contravene your own better judgment, especially at the behest of somebody else, ugly things start to happen. You lose trust in your work. You risk becoming cynical or apathetic from consciously proceeding in a way you don't support. Your ability to estimate goes out the window, assuming it was ever there in the first place. And if the endeavour fails, the finger will probably still be pointed at you. But even if it isn't, you knew better but were complicit anyway.

So whatever putatively superfluous effort you value, you're going to want to do it. You'll sneak it in after hours; pull an all-nighter if you have to. If you don't, you're going to obsess about it. If you're a security nut, spend the time to sanitize your inputs or it's going to drive you bonkers. If the database is your thing, you'll kick yourself every day you don't properly normalize it. If you're a stickler for code indentation, stop stewing over it and just fix it. Worrying about whether or not what you're about to do is part of the minimum set is categorically a waste of time. If it's expedient, do it now.

As for behaviour that is desirable to users but not challenging to programmers, at least it's easy. Let's face it: bugs like the order in which buttons appear on a screen get triaged into orbit, so it's easier on everybody just to get them right the first time, or as close to it as possible.

Expedient Desirable Product

There is valuable work you can complete and deliver today that is not part of the minimum set. To confirm its absence from the set or to discuss it with your colleagues would take time, potentially more time than it would take to do the work. To omit it would deprive the product of its value. Rather than argue about it, do the work and capitalize on it.

There is also work which is not on the main program but still valuable: a tool, a document, record-keeping, even tidying your work environment. Again, if you have all the means and the motivation to complete it now, do it now. And if it produces an artifact you can sell, all the better. If you can't sell it but it can augment your colleagues' productivity as well as yours, remember to share it with them.

The question I expect to be asked at this point is how do I deliver a product on a deadline with all these diversions? How do I propose to keep a schedule if I'm constantly going off-task? The answer is I don't.

At least, I don't in the conventional, Gantt-chart sense. Well-understood deliverables that result from well-trodden processes conform nicely to a schedule, but how much of that are you really doing? Your productivity as a knowledge worker of any kind is predicated on your ability to solve problems, and that can't happen without the right inputs. At the same time, you may experience an eureka moment with a different problem entirely, and it would be wise to capture it while it's hot. Some might call this procrastination, but I prefer to think of it as opportunism.

Besides, the only time you have to worry about being on-task and on schedule is if you have some other kind of obligation to which you've committed. Oh, right.

That Whole Management/Financing Thing

The kind of deal we typically strike in a business endeavour is to produce Result X, such as the archetypal MVP, by Date Y, which is reified by a dollar figure from a departmental budget or a round of funding — a throwback to the methods of manufacturing or construction. This is fine if you have solved the problem already and it only remains to execute it. But software is nearly always novel by definition, which means there are many unknown unknowns and unprecedented decisions that will need to be weighed and executed.

Realizing modern software doesn't normally take big lump sums of cash. The currency of software acquisition and similar novel and complex problems is contiguous blocks of time in which individuals can concentrate — literally fetching disparate pieces of information from all over, organizing them in one place and synthesizing new information from them.

The rub is that information is infungible. You cannot substitute the bit that depicts whether or not I like crème brulée for the one that indicates my preference for sea urchin any more than you can swap those ingredients themselves. Acquiring specific bits of information takes a wildly arbitrary period of time, especially when you don't yet even know you need to acquire them. And to echo the admonitions of Fred Brooks, your Result X won't be achieved until you have the full complement of relevant bits in your possession.

Note however that this is not necessarily a long time, it's arbitrary. Finding a missing clue could take seconds, a lifetime, or never occur. I'm told in the Real World™, however, things need to get done, and that means compromise. But as we saw, how can we tell which compromises are cosmetic and can eventually be buffed out, and which will lie dormant only to cripple the product a year or two later?

And the purpose is what again? Time to market? So you can get a few more days, weeks or months on the front of the product's lifespan in trade for potentially years on the rear? If, at the cost of your health, you went on a coding binge that made EA look civil in order to heroically power-slide into the deadline, you would certainly have something when the dust settles. Why not shed the pretense that something is going to resemble Result X as originally conceived, take your time, and release something else instead?

When we focus too intently on Result X, we become blind to the notion that some piece of the intellectual capital we generate on a daily basis is bound to be within a degree or two of merchantability, which we can handily have ready to ship today, let alone Date Y.

The conventional method of financing and managing software, however, appears to be to say we want Result X by Date Y, here is the money to build it. The problem is that there's no building going on. Once you have concentrated the information relevant to the problem and synthesized a solution you can articulate to sufficient precision, that's it, you're done. The code is written. If there's any part of the method of production shared by manufacturing and construction that software acquisition actually resembles, it's the copious research and planning that happens before the capital is allocated to build.

As an entrepreneur, you could argue that a huge parcel of VC financing is sure to see you to profitability, but the stakes on that bet are pretty high. It'd be harder to convince yourself of that on your Series G round, assuming you hadn't gotten the boot by then. But the task isn't to build a factory or launch a comprehensive marketing campaign or any of the other expensive things you do with big capital investments. We're talking about keeping a small group of people off the street long enough to realize a product that will cover their expenses and then some, and from there they can take care of themselves. Arbitrary indeed, but probably trivial. Once their product works, they can dock with the big-capital mothership for the means to make it scale (i.e. marketing, sales, support).

The micro-VCs have the right idea about the scale of the investment (and concomitant equity stake) but still appear to cast the deal as an all-or-nothing construction project. A profitable business can easily pay somebody to just invent things all day, but I'm not sure how that would translate to equity financing. Patronage 2.0, perhaps? Might be worth a try.

Though if you're contemplating one of these ventures yourself, it's a good chance you already earn a great deal of money relative to your time commitments. You could realistically slash your obligations to sequester as much contiguous time as you can to solve your problem, and keep an eye out for opportunities to cap off old, unfinished problems, or to execute those you've already solved. They may come sooner than you expect.

The Real Enemy is the Vacuum

Software is made of information and uses it as raw material, and we know that information cannot be substituted. A certain quantity of it will indeed have to come from customers and users. Much more of it is available from numerous other sources that do not require promising a product. A surprising amount is lying around close by, in varying degrees of conspicuity.

The most important factor for keeping the pace of a software or indeed any other creative or problem-solving endeavour seems to be to get specific answers as quickly as possible. With that the rationale behind the MVP is clear.

Though we may do our best to facilitate the inbound flow of information, there will invariably be service interruptions. When we are focused and committed to a single objective, this shortfall of information poses a quandary when it comes time to make a decision, in which we either vacillate or commit to a suboptimal solution.

It's hard to say which is more hazardous, no decision or an arbitrary one. I recall a Teddy Roosevelt quote recently co-opted by some Agile evangelist or other: In any moment of decision the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing. Rallying words for the early 20th century, when the keystroke wasn't quite as potent.

When a vacuum forms around one objective, we would do well with the discipline, freedom and support to switch to another. After all, who really cares, honestly, what you work on, as long as you deliver something?

Your customers or users?
Not if you don't promise them anything specific.
Your investors or employers?
Not if you're busy making them rich.
You?
???