Below is my protocol for developing projects.

Definition: A protocol can be defined as procedure of conduct and if done well creates an affordance for reproducability, which creates an affordance for evaluation, improvement, and growth.

This is a live document which I revise. For previous versions and changes see my Personal Devlogs.

0. Aim & Intro

The protocol is iterative and has five states with the aim to counter-act "giving up" when working on large, audacious projects or in other words completing and succeeding at them.

We do that by way of the carrot, i.e. a mechanism that is enjoyable. Concretely we utilize the power of dopamine to trigger our reward system and make us want "more". To release dopamine, we try to create tangible outcomes that move us in the right direction after every few hours of work - that's what this protocol exploits. The other part of the protocol makes sure that these little dopamine hits move us in the right direction and do so efficiently.

1. Planning

The input is the large, audacious project itself or a small subset of it like a component or feature. The output are chunks and the process is one of "breaking things down". For larger inputs this may require hours or days of research and planning, however it is important to not over-work this step as the iterative nature of the protocol acknowledges the impossibility of having all the answers up front. It usually suffices to have a rough overview and start with the most certain aspects, breaking those down into chunks, and moving on to the next step.

2. Chunks

A chunk is a promise for a result that is tangible and can be completed within a few hours. Backend or other “hard to make tangible” chunks should result in tests or evaluations that can be run. The scope of a chunk is only so large that it can power a demo.

3. Demos

A demo is a promise for a result that allows for real "usage" and a feeling of what the experience will be like. One should aim to create one or two demos per week to keep a healthy momentum. The goal with the demo is to see if that part of the product feels "good enough". The scope of a demo is to get as quickly as possible (i.e. with as few and minimally demos as possible) to a self-release (you are adopting the product yourself). If the demo fails to feel "good enough", return to "Chunks" or "Planning" and repeat.

4. Self-Release

A self-release is a promise for a product that you adopt yourself and most likely only you can adopt because in order to achieve the above cadence the functionality will be so restricted that it only works for your setup, workflow, or specifics. The scope of a self-release is to arrive at "strong adoption" as quickly as possible. Strong adoption is characterized by high fidelity, high value, and preferably high usage. Most likely, you will realize that crucial functionality (to arrive at strong adoption) where omitted or that things don't work quite well enough yet and you return to one of the previous stages and repeat until you reach strong adoption at which point you can go to "public release". The idea is, that if you do not adopt a product that was designed for you, it is very likely that others will not adopt it either.

5. Public Release

A public release is a promise for a product that others adopt. Similar to the self-release you want to get to "strong adoption" (aka. "Product-Market-Fit") as quickly as possible - look out for the usual signs like love-like ratio, retention, usage, willigness-to-pay, ... whatever is meaningful for your product type. Most likely, you will have to add more functionality to arrive at strong adoption and you will repeat the previous stages until you get there. Once you have reached "strong adoption" usually some target number on the previous signs, you can return to your initial aim.

Notes

1. As the goal is Public Release we want to think about adoption hurdles and time-to-value from the beginning. These things come with experience.
2. Different types of not-knowing and what to do: https://vaughntan.org/nkapproaches
3. Various risks for (software) development: https://riskfirst.org/thinking/Start

References:

• https://mitchellh.com/writing/building-large-technical-projects
• http://joschu.net/blog/opinionated-guide-ml-research.html