- A1 Engineering
- Posts
- Decoding the process of crafting new products
Decoding the process of crafting new products
Building new things at warp speed with the right people
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 building 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 -
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F16d8884a-1fdc-4137-bdc3-ff21d504b154_2056x1276.png)
When you consider shipping new features or products, the path to users must be swift and 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.
Reply