Daily, snackable writings and podcasts to spur changes in thinking.
Building a blueprint for a better brain by tinkering with the code.
August 24th, 2020
Startups and entrepreneurs of all kinds seek to get off the ground with a minimum viable product. This is generally the first version of a business product that can actually be released to the public, ideally for money. Many great things have come to market because of the thinking that tends to compliment and enable a minimum viable product. But all too soon, that thinking goes awry, as the product becomes bloated with features and clunky iterations, as companies grow themselves upon the success of that first minimum viable product. How is it that the pressure of necessity and the simplicity that boot-strapping forces is lost once we move beyond that first iteration, and more importantly, how can we maintain the efficiency of the boot-strapper and the survivor?
Similarly, many companies fail to get off the ground in the first place due to the same problem: by concocting elaborate demos that don’t actually do anything. The thinking here is somewhat inside out: instead of making something that is powerful because it simply works in its most simple form, individuals plump up the pomp of their product with flashy theatrics that hint at what might be possible. The insecurity here is searing: why go through all the showy flash and bang if at core there really is something useful? Is it a genuine fear that normal people won’t clue into the potential use of something that actually is useful?
These questions answer themselves. A flashy demo is likely to be hiding something. But a working demo?
A working demo can become that minimum viable product. This is certainly a better allocation of resources. Instead of spending time, energy and money making a flashy demo to simply evoke a fantasy in the minds of others, wouldn’t it be more efficient to actually build the darn thing and see if it works? The success of a demo in the eyes of others inevitably calls for a working version, which simply becomes another step. Why not cut to the chase and build some thing that works?
For those in the business of building, these distinctions might be trivial and uninteresting. What is perhaps lost on a great number of builders is the continued utility of simplicity and how to stick to it. Many builders don’t realize just how simple a thing can be in order to get the feedback we need to move forward. Not only this, we often build in a bloated way that inhibits clear feedback. We can mistake the target of the signal. Only be making simple, clear moves can we be sure that the signal within feedback actually accords with the change we’ve made. This hints not just at a minimum viable product, which harks of only one iteration of a given idea, but all iterations, and a philosophy of building that cuts the fat and makes our path of pivots towards something truly excellent faster, and more efficient.
The concept of a simple operable iteration applies to the 10th version, and the 1000th, along with all iterations in-between and beyond.
Entertain, for a moment, a detour into an analogy comparing a student and a master: at first the student flounders, having no competence of the skill, then, once the student gains proficiency, the expression of this skill explodes. Using the skill becomes an expression more of personal agency than it is an expression of the skill well-used. Think of a junior woodworker, or even a kid with legos who figures out how to put things together and soon enough is pouring loads of effort into huge, sprawling, elaborate projects. Then eventually the student, with time and practice slowly becomes a master of the skill. And what is more evocative of mastery than simplicity? The master of any given skill has distilled very simple fundamentals from enormous amounts of experience. All the fat and bloat has been cut, and what is most often left over is elegance.
The image here evoked of the student and the master, and the bloated progress that links the two isn’t one so much to be applied to the builder, but to the thing being built. All minimum viable products start in the same way that the student gains a simple proficiency. But then the product (and the company) often bloats and bloats and bloats until it breaks. How stereotypical is it for a young company with a fresh influx of money to spend huge sums on fancy office space and cute extras -or rather- extravagances? How can this sort of bloat fail to indicate that something fundamental has shifted within the perspective of the company? Would it be wise to worry about whether or not this shift might effect the way people build?
But we have to attract the best talent? Might be the rallying cry. Perhaps, but does this not say more about the product and how interesting it is… or isn’t? Is not such extravaganza not like the theatrical demo that doesn’t actually work?
Passionate people who are genuinely interested in their work don’t need views of the river or foozeball tables to keep them happy. The work does that.
The simple operable iteration is a perspective about building at every step of the process. It asks: what does the this version look like with everything stripped from it before it ceases to fundamentally work?
The boostrapper asks this question out of necessity.
The master craftsman asks this question out of a hunt for beauty.
Strangely, the beginner and the expert are inextricably linked. Both reach for success from a point of leanness as both are devoid of an interest or access to opulent resource. It’s this pared down focus which creates the simple operable iteration.
donating = loving
If you appreciate the work of Tinkered Thinking, please consider lending support. This platform can only continue and flourish with the support of readers and listeners like you.
Appreciation can be more than a feeling. Toss something in the jar if you find your thinking delightfully tinkered.