Building a 0-1 Product ~ Engineer's POV
Starting from scratch to build a brand-new product is an exciting journey filled with learning and challenges. When you’re part of a team that’s creating something entirely new, your role can morph daily.
Since the time I started working as an Engineer at HackerRank, I have had the chance to work on multiple 0-1 products, some of which we stopped due to lack of Product Market Fit (PMF) and some we continue iterating on.
Here’s a glimpse into the life of a developer in a 0-1 product environment.
1. Understanding user feedback and iterating
The heart of any successful product is its users. When building from scratch, understanding the user feedback directly can help in interpreting what the users truly need. One of the habits that I have developed is to regularly go through the support tickets and the user feedback via in-product channels to get a better sense of how the product needs to be tweaked.
As engineers, this loop of user feedback and iteration often helps in refining vague ideas into features that can help solve problems with clarity and purpose.
2. Balancing Quality with Velocity
There’s always a tug-of-war between perfecting a feature and moving fast to release new ones. Finding that balance—knowing when to prioritize what—is crucial for momentum.
3. High Learning Curve
In the world of building new products from scratch, you learn a lot, and fast. One big plus is that you get to take care of whole features by yourself. For example, if you learn about a new way to organize your code or a new technology or design pattern, you can try it out in one of your features.
As this feature grows—by getting updates, connecting with other parts of the product, or being used by other developers—you get feedback that's more useful than reading lots of blogs about it. This real-world experience helps you learn better and keeps things interesting.
4. Becoming a Product Engineer
As you develop in this role, you begin to see beyond the code. You start to understand how each line of code you write impacts user experience and business goals. There needs to be a shift in perception—from a pure coder to a product thinker. Keeping the users in mind during development can get us very far.
5. Scalable Tech Design
In the early stages of product development, it’s important to design architectures that can scale. As a developer, you can closely with the product manager and designer to discuss the long-term vision for each feature. This collaboration helps in grasping not just what the feature needs to do now, but how it might need to evolve in the future. One of the things to keep in mind is to aim to understand the right user experience and iterate backward from there for technical feasibility.
Start with a simple technological framework—it keeps the initial development swift and manageable. However, this simplicity must be balanced with scalability. By designing systems that are easy to modify and expand, you ensure that the product can quickly adapt to new requirements or user feedback without extensive rework.
This foresight in tech design not only speeds up iteration cycles but also supports robust growth as the product scales.
6. Wearing Multiple Hats
In a small team, you’re not just coding. You might also be handling customer support, and doing data analysis for product metrics. You get to be a part of the product discussions to first hand understand the idea and fundamentals behind the feature you will be building.
Each hat you wear provides a unique perspective on what the product needs and how it’s being received, making you a more versatile and empathetic engineer.
7. Embracing the chaos and ambiguity
Not everything will be structured, and that’s okay. Embracing the chaos, finding joy in unpredictability, and adapting quickly are part of the excitement. In the world of 0-1 products, the "end state" is a moving target. This can be disorienting but also liberating, as it fosters continuous innovation and improvement.
Finally, comfort with ambiguity is perhaps your greatest ally. Not knowing the exact path or the outcome encourages creativity and resilience.
8. Dealing with Tech Debt
As Engineers, Tech Debt is usually where all of us are excited to go deep into the problem and convert the debt to wealth. One of the things that I have learned is when building a product that is still in the early stages of finding a Product Market Fit (PMF), tech debt only becomes a real problem when it starts affecting our users or slows down our velocity to iterate fast and achieve PMF.
9. High Feature Churn
In the early stages, what you build today might be scrapped tomorrow. High feature churn is common as the team pivots and adapts to the market. It’s all about staying flexible and not getting too attached to any single element of the product.
The code that you write today might become a tech debt tomorrow.
To conclude, the journey of building something new is as rewarding as the destination itself, filled with continuous learning and adaptation.