MINIMUM VIABILITY FRACTAL

November 18th, 2022

Minimum Viability is fractal. It applies to everything I can think of, but the best way of introducing it is through the lens of the tech industry. The most celebrated incarnation of this concept is the Minimum Viable Product. This is at the heart of tech start-ups that seek to move fast, ship early and iterate. This little equation: ship early, fast and iterate, is touted as an effective recipe for success. Pre-launch, the aim is to build the minimum viable product - the simplest version of an idea that can be delivered to potential customers to test for product-market fit. All this means is - is the idea good? Can it make money? Are there actual real people who appreciate this idea?Once those questions are answered, the minimum viable product is either abandoned for a new one based on a different idea, or it is improved upon, iterated in response to user feedback and, ideally, turned into a stronger product.

However, the Minimum Viable Product is an expression of a fractal process. Meaning simply: the minimum viable product is an event that is produced by a cascade of similar smaller events that have the same phenotype.

Let’s rewind the process of a Minimum Viable Product particularly as it applies to tech. Where does it start? A programmer, naturally. But let’s go back even further. Where does a person start when the aim is to become a programmer?

This’ll likely make the most sense to programmers who have already got through this process, but I’ll do my best to try and make it excessiblef to the non-programmer…

Think about it. How would you begin to learn the art of programming? Or how did you begin learning?

There are a select few who can simply research, read and study without actually doing, form a fully informative picture, and then begin. But these people are not the norm - they are outliers and inso being, they don’t apply to the minimum viability fractal.

Generally a person seeking to break into programming will do a few courses, perhaps a Javascript course, perhaps a Python course, maybe C++ course. Whatever, it doesn’t matter. What ends up happening though is that these courses prove to be fairly useless. Sure some functions and class structures have been learned, but always at the end of such courses the question arises: what do I actually.. DO with all this stuff?

This approach vector is.. well I believe the technical term is ass-backwards. It is putting the cart ahead of the horse. It’s learning how to make cadmium paint without realizing it’s the sky you should be painting. Or put another way:

The only real way to learn programming is to try and build something. Some application, some idea, some tool or toy. Something you can dream up. This vision becomes the north star of one’s learning compass, and the process becomes much simpler, albeit a bit more challenging. Instead of the comfort of pursuing a 30 lesson course with a definitive beginning, process and end, the task is now radically different. The question is refined to this: what is the minimum viable action I can take to bring this vision to life? Perhaps a familiarity with some of the coding languages is helpful, but this can be done with some googling and reading some high level descriptions. That’s actually the main skill of a programmer: Googling. Because as Chris Pines one said: Programming isn’t about what you know, it’s about what you can figure out. And I don’t believe Pines meant this in an exclusively high-level way. He didn’t mean: you figure out how to code and then you know how to code. What I believe he meant is, coding is the process of continually figuring it out.

At least this has been my experience. The way to build a product is the same as the way to learn how to code: simply concentrate on figuring out the next smallest viable step required to make your idea come to life. This creates efficiency in multiple ways. Instead of arming one’s self with a broad set of techniques and knowledge, the majority of which is useless for getting started, a novice with programming can start hopping the stepping stones of building a product by learning only what is necessary for those steps.

Each step in the process is it’s own version of the minimum viable product. Each step is a minimum viable action. A good programmer is a good learner, and a good learner figures out how to search broadly, quickly in order to narrow down a set of possible solutions and paths to explore. This is precisely how the actual process of a programmer’s workflow looks like. A problem arises, and that problem is converted into a question. That question is googled and the most promising results are opened up in new tabs on the browser. The programmer than quickly clicks through those tabs, scrolls and scans, assessing for answers that seem to address the specific problem at hand most closely.

There is so much useful stuff out there to learn, but all of it must be regarded as noise. Yes, perhaps one day it will prove useful, but it will become so because it’s the solution to the topic and problem at hand. But at any given moment the signal of learning is dictated by what is needed to proceed with building the product. At each stage in the game the builder is searching for the fastest and most efficient way to make the current goal a functional reality. It doesn’t matter if it’s perfect so long as it works. If one day it breaks, or causes problems, then that is the day that further investigation is needed. Deep dives are only required when the functional solution is actually that deep. Otherwise, good enough is the name of the game. If it works, then that’s good enough to move on to the next step.

When enough of these steps are taken, a minimum viable product eventually emerges, and it’s launched. It’s emergence is a kind of phase change that is highly noticeable - something that emerges from the process already described, but the event itself is no different from the events that lead to it’s creation. The minimum viable product is the product of minimum viable steps in a process that extends beyond launch. Iteration is just another word for the same event described previously. Learning is the experience of iterating on knowledge that does or does not already exist. Product iteration is taking small viable steps to improve what does or does not already exist. That later part - product iteration is taking small viable steps to improve what does not already exist is the process taken before a product is launched. The former proceeds after launch. But there is not difference, Minimum viability is always the guiding force that pushes and pulls the compass needle. Minimum viability is at the heart of every tiny action, be it while building a feature, debugging, or designing. But it also represents the entire project at every stage of iteration. Each iteration ideally represents the next smallest viable step for the evolution of that project.

Fractal viability is defined by minimizing the distance between each step in the process. This is the equation for product development, but it’s also the equation for learning. Product development and learning are both additive in the same exact way. Countless tiny realizations eventually lead to functional knowledge and eventually expertise, just as countless tiny developments of a product eventually lead to minimum viable product and eventually to a monopolistic domination of a market niche if the same process of small iterative developments is continued.

At each level of resolution the equation for progress is the same:

Take the next smallest step.