Decoding the process of crafting new products
Tags: beginners, programming, productivity, learning
Published: 2024-05-18 12:38:58


The product continuum has 2 discrete parts: 0-1 and 1-n. Differently said, you first need to prove out the need for a product/feature and then you need to scale that product/feature. Both these parts require different strategies. 

Using the 0-1 strategy when you are scaling will lead to unstable and unmaintainable products. Using the 1-n strategy while proving out market fit will cause you to be immeasurably slow. Beyond the development etiquette, there are also the points of setting user expectations. Honing your go to market strategy, identifying what to measure from a user adoption standpoint. All of which differ based on where you are in the continuum. 

*This article predominantly covers going from 0-1  and any exclusion of the 1-n is not due to the lack of applicability to the space but more so because that commentary is reserved for an upcoming article. Lets get back to it.*

When you are going from 0-1, there are only 2 questions you need to answer when you decide how to build something - 

- **Will this introduce a new dimension of risk that could be unmaintainable or immeasurable?**
- **Will this help me get the feature out to the users faster?**

To answer these questions, a high level framework you can apply for a particular decision is - 

![matrix](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5e340oup5ugp60rh12xq.png)

When you consider shipping new features or products, the path to users must be swift and follow the path of least resistance. It must be hyper clear to all involved that any work is vaporware until there is actual validation after the user has it in their hands. There is plenty of time after-the-fact, to correct for architectural decisions, scale considerations and such. Very rarely does one run into scenarios of massive unpreparedness like Instagram faced in its early days, so don’t over-engineer to solve for the million user problem. 

On the other hand, this advice does not eliminate basic practices like foundational testing or instrumentation which you will need to answer no to the risk question above. However, it does provide boundaries to determine how deep you should go in a certain path or how wide you go given the options you are entertaining. 

When you are in the 0-1 phase, the people you need are quite different from the 1-n types. Oftentimes startups are where the need for 0-1 style developers (henceforth referred to as 0-1s) lie although that is not to say that larger enterprises don’t. The incentive structure (motivational rather than financial) and the agency these engineers are given, often determine how successful they are at applying those skills.

Great 0-1s are hard to find but there are some telling signs. Some characteristics include - 

- they love being close to the user problems 
- they love experimenting and tinkering 
- they dislike intense process 
- they can make effective tradeoffs without needing to consult with someone
- they always keep an eye on the landscape for new and exciting ways to incorporate new products into their workflow / products 
- they are quick to demonstrate how things get done without getting caught up in the details 
- they are not easily satisfied with answers and are perennially curious 
- they go looking for trouble without being asked to 
- they have something going on outside of work not related directly to their proficiency - that they are very passionate about (teaching, church, magic etc)
- they move extremely quickly when it comes to delivering something of value
- they prefer show over tell 
- they target effectiveness over efficiency

It’s not all sunshine’s and rainbows with 0-1s. There can be several flags with them as well such as - 

- lack of attention to detail 
- sometimes bypassing best practices like tests and instrumentation or CI/CD
- building things in a silo without telling other people 
- building things highly specific to the case in mind without a tiny bit of forward thinking (this can be a pro in many cases though) 
- disrupting the practices / system for other 1-n developers 
- always chasing the shiny toys which could frustrate other developers 
- not completing projects and moving from one thing to another without closing the loop on things 

The killer hires would be people who not only have the features of both aspects of the continuum but also know when to exercise which muscles. Once you have that, you have set yourself up for having a great engineering team.