Engineering Quality, Engineering Trust

All: Medium amount of good pizza.

The launch in that episode was the ill fated “Dunder Mifflin Infinity”, and while the reference in the passage is to the pizza that Michael Scott had ordered, it may as well been referring to the website.

For many reasons, people tend to build all you can eat hot circles of garbage, instead of a medium amount of pretty good pizza.

Minimum Viable Product doesn’t mean shipping hot circles of garbage. The very definition of Viable contains the word ‘successfully’, as in, ‘able to operate successfully’. It’s the minimum threshold of success. The term was invented, in part, to encourage the product owner to release software to the customer earlier, to be able to gather data, avoid over-refinement, and retain enough cash-flow to be able to mount a pivot.

Quality doesn’t mean hyper-refined either. How many startups burned through their cash without an ounce of consumer validation? How many entrepreneurs, out of fear of embarrassment, held back the release of a product? It’s tragic.

There’s a balance here. It’s possible, given a limited amount of cash, to release a medium number of good features, instead of a buffet of all you can eat garbage features.

Assume you worked really hard to generate 100 ideas in a spreadsheet.

Are any of those ideas ugly? Are any of them outright — garbage ideas?

If you’re reading this space you know that some proportion of those ideas are terrible. Some of them, on their own or even in combination with others, are unlikely to produce a viable, or successful, business outcome, in a time horizon that is salient to your given situation. (Which is limited by cash).

Some proportion, if executed to quality, are viable. Some proportion, even if executed to quality, are not.

I think that this is the toughest part for a whole lot of people. To even suggest that some ideas, that some of their own babies are ugly, is really tough. Especially so much of the business pop literature is designed to inoculate founders against accepting critical feedback.

It’s pretty tough to tell what’s viable and what isn’t. Let’s say, out of 100 ideas, 10 are viable and 90 are not. You have enough cash flow to implement 12 of them to a viable standard. The odds of selecting an unviable idea are really high, even with informed judgement. And watching a competitor implement that idea, ‘when I had it first’, produces a tang of regret. Often, there’s a pressure to deny the reality of cash flow, and push to implement all 100. Or to implement 50 of them as garbage.

Well, 50 as garbage is worse than 12 features at quality.

I don’t regard idea generation as the work. It’s really quite easy to generate a huge volume of ideas. The vast majority of which are unoriginal, uninspired, and unwanted by most market segments. “Hey, what if an app could convert a picture into sound, if you wanted that for some reason?” — is an actual Onion Talk.

The real work is in the filtering, synthesis, and combination of the ideas – and then, the hardest work of all, is in the engineering of the combination of those ideas together into something that somebody will hire.

And yet, somehow, there’s the mistaken belief if that you engineer 25 features, you double your odds.

I’ll paraphrase Hinton when it comes to ideas. If you’re convinced that a set of 12 ideas together will make for a viable product, even though everybody says otherwise, you may as well make a go of it and make it good. If you’re right, you succeed. If you fail, well, there wasn’t much hope to begin with in the first place, was there?

A huge hangup I had with TAM, and the uncertainty about S*, was in part the uncertainty of stringing a feature set together and holding the breath. All disruptive sets of ideas are heretical. The vast majority of people would have to have seen that specific set you had in mind and dismissed it out of hand. In part, I believe that it’s Thiel that once said that all startups are conspiracies against the status quo. You have to be kind of crazy that a given set of ideas is going to work.

The combination of the ideas don’t have to be perfect, especially to convince innovators/early-adopters to see the value. They have to have just enough quality to be viable. Given limited cashflow, especially at the start, the selection of the go-forward ideas has to be right. There has to be quality.

I don’t see how you get to quality on very limited cashflow, on quantity features.

Putting together a group where the engineers trust the business to value quality, and where the business trusts the engineers to deliver it, is the real trick.

It’s really tough, from the engineering side, to work quality into tight deadlines.

It’s really tough, from the business side, to watch cash flow fall.

If it was easy, everybody would do it.

This is where great alpha supporters are invaluable. If you get a group of truth tellers early, you can iterate through some of the most embarrassing prototypes early. Getting that data and making decisions if there’s a line to push harder on, or if you got a combination of ideas that are just terrible and never going to work. If you trust your Alphas, great things happen. Quality gets worked in as validation accumulates. And quality is worked into the timeline, not discarded as a set of garbage ideas are thrust into the product.

This is where great data, great people, and great trust can come together.

That’s the real engineering work.