Zero to One — Handbook for Entrepreneurial Engineers
Ever since I was a teenager, my coding adventure has always centered around one question - I have great ideas. How do I turn them into reality? This article aims to give some answers to this question.
But wait… who am I now? And what real experience do I have to share?
I’m an L8 senior principal engineer previously at Meta, Microsoft, and Atlassian. I see myself as an engineer whose specialization isn’t in any particular tech stack, but in taking things from zero to one.
Over the years, I accumulated experience from -
Having built over a hundred side projects. First time I made money was with a SaaS I built in high school over 20 years ago.
Being a founding engineer of Facebook Instant Games, and taking it to a large business with thousands of games and millions of players.
Then started MSN Games at Microsoft, again from zero and turned it into a business.
Recently at Atlassian I helped start a suite of AI products for software developers, from a pitch, to a prototype, to a state-of-the-art AI product portfolio.
Perhaps the most counter-intuitive learning I’ve had from this journey is that you can actually have a startup founder experience while working in large companies. You may not be able to get a $100 million exit, but you’ll never have a month without paycheck, and over time the reward gets close as well.
If that sounds like something you are passionate about as well, this post is for you!
Let’s start with how to find great ideas to work on —
Want good ideas? Go find some problems.
There are countless ways to generate ideas -
Sometimes we see a new technology coming out, and think “what can we do with this”?
Sometimes we find something painful, and think “can I solve this for myself”?
Other times, an apple fell off a tree and the rest was history.
The world is fully of inspirations. More often than not, we don’t need just ideas, we need good ones that are worth our time.
A good idea is one that can succeed. An idea that can succeed is one that can provide value. An idea can provide value when it can solve real problems.
So the fundamental question is — where can we find real problems? If we can find a real problem and identify a viable solution, we have a great idea to work on.
I typically think of problems in the following taxonomy -
User problems — pain points that exist for end users. For example, having to load dishes into a dishwasher and other house chores everyday is a pain for me, and I would pay a reasonable price if a robot can help me get it done.
Ecosystem problems — suppliers who produce parts for a robot may suffer from various challenges, such as high overhead and cost in managing logistics and customer support.
Company problems — let’s say we have a company who’s building those robot. We may have our own problems, such as LLM bills being out of control.
To know what real problems exist, you’d need to find ways to hang out and talk with people who may have those problems. Follow people who vent on twitter and listen to what they have to say; jump into a reddit community and find out what they are complaining about; go to events and talk to people, understand what they are going through and hear their problems from their own mouths.
The way you know you have found real problems is when you can name a few real people who will be eager to hear about a solution whenever you have one. When you have that, you will have much, much better intuition about whether an idea is good vs not. You may also get new ideas during that process.
If you aren’t doing this yet today, I highly recommend starting here.
What can you do today?
In a corporate environment, finding real problems is actually a lot easier than when you are working solo.
Look up your company and teams’ OKRs — every OKR is a problem that the group already collectively identified as a real problem waiting to be solved. If you think any of the problems may have a great solution that’s not being worked on yet, you have a new idea!
When you talk to people, always be curious what problems they are going through. If you’ve heard the same thing from multiple folks, there’s a good chance you just found a real problem.
Building network across teams and organizations. Read other teams’ newsletters and updates to understand what they are doing. I can’t even count how many times a great idea came from seeing “Team A is doing something that can solve Team B’s problem with just a bit more work”.
No big ideas yet? Build skills, credibility, and trust.
It’s absolutely okay if you aren’t always working on “your own idea”. I certainly wasn’t — very often I even deliberately carved out time to contribute to existing projects even when I have an exciting new idea to work on.
That’s because in order to succeed in taking a new idea from zero to one, you need skills, credibility and trust. You should be building these things when you aren’t building a new idea.
Skills
Both hard skills and soft skills are quite important.
Hard skills can be acquired by learning new things you haven’t done before — for a year or two when I was at Microsoft, I wrote more SQL than “real code” in order to run large map-reduce jobs. To be honest that wasn’t the most interesting thing to write, but it wasn’t until a few years later on when I discovered I was the only engineer on my team that could do data analysis fluently, and could constantly use that skill to identify growth opportunity for our new products, that I realized what I gained from those SQL jobs.
You can also build hard skills by strengthening knowledge in a specific domain that has enough depth, such as machine learning. By going deep, you can become an expert that can solve problems in ways others can’t.
Even if you aren’t increasing either breadth or depth, you can still increase your efficiency at doing the same things, which is a hard skill as well. For example, I can debug problems and do performance profiling very efficiently — this was from years of pushing myself “how can I do it faster next time”.
Soft skills on the other hand are often overlooked by us engineers, probably because we can go pretty far without being intentional about them.
But to be an entrepreneurial engineer, I believe soft skills are incredibly important. We need to communicate a lot — to understand different people’s problems, to sell a vision to stakeholders or a solution to customers, or to rally a team towards the same direction.
If you have no idea where to start on soft skills, I’ll give some book recommendations here (I’m not affiliated). These books genuinely changed me as a person.
https://www.amazon.com/Never-Split-Difference-Negotiating-Depended/dp/0062407805 — this book talks about negotiations with terrorists but deeply under the hood it’s about understanding others and using that understanding to guide how you communicate
https://www.amazon.com/Mom-Test-customers-business-everyone/dp/1492180742 — this book gives you the skills you need to get meaningful insights from others, and helps you avoid being misguided by your confirmation bias and noise that comes from others “being nice”
Credibility & trust
Credibility is about establishing that you are capable.
If a random person on the street comes to you and say — “I have a great idea here! Can you give me $10 to help me build it?” How likely would you give them the money, or even listen to their idea, compared to when the exact same pitch comes from a serial-entrepreneur who you know has a track record of building useful things?
By consistently nailing the tasks you work on, you will be establishing invaluable credibility that makes it easy for others to not just believe in your idea, but also believe in your ability to make it happen.
Trust is slightly different — a person can be a well-known expert in their domain, but do you trust them enough to co-found a company together? You probably won’t until you’ve worked with this person for a while and got to know whether they are easy to talk to, if they do what they say, and respect your inputs.
You can build trust by having positive interactions with others — demonstrate that you understand what others care about, help people out, and (maybe surprisingly) even by getting others to help you. One of my previous articles “Building Trust” here dives deep into this topic.
When you aren’t working on a new idea but instead contributing to a large existing project, that’s a great opportunity to build credibility and trust with others, so that when you do have a great idea to work on, it’s easy for you to find support. It also helps increase the chance that others would bring good ideas to you.
Finding time to build things
Now comes the hard part — we all have day jobs. How do we find time to build something new?
When we want to work on a new idea, we must first acknowledge that we’re taking on a risk. We simply won’t know whether an idea will work or not until we spent some time building and testing them in the real world. What we need is just enough resource (time and/or money) to pursue and validate the idea.
There are a grand total of two (legal) ways to get resource -
You can use your own time or money. You would use evenings and weekends, or by quitting your day job and living on money you saved.
You can convince others to give you time or money. For example, attracting investors to fund your startup company.
When in a corporate environment, I generally recommend going with #2, which is significantly easier than in the startup world — you mainly need to align with stakeholders on your prioritization. If everyone agrees that’s the most valuable thing you can work on, you are all good to go. Many tech companies also have dedicated time carved out, such as as hackathons, that give everyone the time needed to get a new idea off the ground.
Going with #1 is a last resort but also a valid option — you don’t need anyone’s permission to use your own time as the resource to do what you think should be done. Build it, show it, and go from there.
However, if you find yourself repeatedly resorting to this option, then there’s a more fundamental misalignment between what you vs your team believe to be important. You need to understand and tackle this disconnection instead of always consuming your own resource and time, which can lead to burnout.
Being scrappy
Regardless of the approach you take, you’ll find it significantly easier when you stay scrappy and use as little resource as possible. Asking to go dark for 3 months is very different from asking for a few days to do a spike.
But how to be scrappy? Mainly 5 things -
Minimize the initial scope. Avoid falling into the trap of assuming your idea will work well and try to build a perfect version of it that can launch straight to a million users worldwide. Instead, ask yourself “what’s the minimum version of a product that can either prove or disprove this idea?” Your prototype probably doesn’t need to support Mac, Windows and a hundred different Linux distributions all at the same time. Who’s the first user you’ll give the product to? Ask what they use and build just that.
Write as little code as possible. What existing building blocks can you pull together to make a functional prototype of the idea? We’re living in a wonderful world full of amazing open source software and ML models. If you find yourself planning to build a complex system even for a prototype that doesn’t have to scale, you should be alarmed and question if you can assemble it more quickly.
Wait, did I say 5 things? Nope, those two plus the meme I grabbed from the Internet should work for now! If you need more, let me know and I’ll iterate on it.
See what I did there?
I just built a thing. Now what?
If you did it right, by now you should be able to name a few people who are waiting to hear about your solution. And it’s time to reach out to those people whose problems you believe your solution will help with, and show them what you have!
What’s important though is to set the right expectations with yourself — this is not the time when you’ll hear people say
What an amazing product! Here take my $299/month lifetime non-refundable subscription fee plus tax!
Remember you probably just spent a few days hacking together a quick prototype. What you really want to get to are —
Do they think this is the right solution to their problems? Why or why not?
How did they use your solution? Does that match what you intended
What key challenges do you need to tackle in order for this to work well?
Iterate!
All of those above are extremely valuable information that’ll help you refine your approach, and get it closer to something useful. If possible, you should iterate on their feedback immediately -
Not “let me put this in the backlog and prioritize in our next sprint planning which happens in two weeks”
But “hold my beer — let me see if I can fix it in the next 15 minutes!”
The reason an extremely fast iteration loop is necessary for zero to one products is that you should generally expect that there are a lot of iterations needed to arrive at something that truly works. The next problem often isn’t visible until the first problem is fixed. The faster you iterate, the more likely you can get to a conclusive state before you run out of resources to continue funding this idea.
And if people did validate it’s the right direction, you will have a lot of concrete insights about how much more resource is needed to deliver a working solution, and what the return will look like once you deliver it — those are the key things you need in order to attract another round of investment to keep it going.
What if no one responds?
Another very possible outcome here is that no one even responded to you (except for a few emoji reactions). This can be demotivating for sure, and some people would simply stop here. But that’s not the entrepreneurial way! As the founder and CEO of your idea, it’s on you to take actions because nothing else will happen until you do.
One more slack message. Throw a calendar invite. Try reaching out to more people in case you were wrong about who had the problems. People are busy, and the world is increasingly distracting. You need to think creatively to stand out from the noise and get a conclusive read on your idea, so that you never walk away without meaningful learnings.
Play as a team
Think about all the products you’ve used today, and see how many of them were built by a solo engineer? The more things I built, the more I saw the power of having a team with diverse skillsets working well towards the same direction.
That said, a dysfunctional team can be counter-productive, and it’s not easy at all to set up a well functioning one. I would not claim to be an expert here — I still make lots of mistakes and not doing nearly enough, but I can share a few learnings that I found useful.
Inviting others early
Generally speaking, we can benefit from looping in potential collaborators as early as possible. Many companies’ co founders met each other before their product was built — including my last company Atlassian’s founders Mike and Scott!
Having a close partner means you always have someone to brainstorm with, many different perspectives for what may work well vs not, and you can hold each other accountable to make progress. More people working together also means you can make progress and deliver more quickly, which helps build traction and momentum for the project.
There are many ways you can do this. Mike sent an email to the entire class and got Scott — as simple as that. In a corporate environment, you can simply share your insights, ideas, progress and results more actively — if they resonated, people will come to you and ask to work together. You should also actively subscribe to what others are building and reach out if you see good opportunities to collaborate.
Value cross-functional expertise
We engineers are a privileged group because we are the only discipline within a tech company that can solo build a new thing that works, all by ourselves.
This privilege would sometimes create a perception that we don’t need other disciplines to build something successful. Granted, there are solo entrepreneurs like https://x.com/levelsio who have indeed been operating mostly alone, the reality is that these are exceptions not the norm.
One of my fondest memory building new things was when I locked myself and a designer in the same room and we said “no one leaves until we have a good working demo”. We would both be at his laptop where he explained to me why the new button shouldn’t be a big red box, and we would both look at my screen when I told him the beautiful animation he put together in 3 minutes would take me hours to optimize.
In a corporate environment, we all have a huge advantage as we’re already surrounded by people who collectively have all the skills needed to take an idea all the way to market. Whether you can leverage this advantage will make a massive difference in your chance of success.
Share ownership and success
I’ve witnessed many times how Founder’s syndrome caused founding members to struggle and ultimately leave the team when the team started to grow.
When you had a great idea and got it off the ground, you often have a particular vision and strong sense of ownership. That is good and necessary, as otherwise you probably wouldn’t even have gotten this far.
Now, one way or another, you have more team members joining you as a result of the success you established. You start getting questions on why your vision is the right one and everyone seems to be picturing something different. You start seeing the team come up with plans that don’t align with your thinking. You start finding yourself constantly correcting others — to varying degree of success — and you feel exhausted.
These are all signs that you need to share ownership with others, instead of controlling it.
Instead of telling everyone what’s the right thing to do, take them through the same journey that allowed you to arrive at the conclusion.
Focus more on communicating the “why” and let people decide the “what” and “how”.
Be open that you might be wrong, and others may have better ideas that can lead to a better outcome, which is what you want.
Be okay with the fact that great things can happen without your involvement. Celebrate others people’s impact and don’t take their credit.
The difference is between being a small part of something big, vs a big part of something small. You want to be the former — it’s a good thing both for yourself and for the group.
Assume full accountability
One downside of having a team is that it dilutes accountability. When a problem rises, you may think “oh someone else will get to it” not realizing that everyone was thinking the same, resulting in problems falling through the cracks.
The solution to this is to assume you have full accountability by default, for every single thing you work on. It’s a mindset that says -
If this thing fails, it’s on me. No matter what.
This is an extremely powerful mindset. When working on things from zero to one, there are often problems that don’t strictly fall under anyone’s predefined responsibility. By adopting this mentality, you are empowering yourself to take actions during ambiguity and do whatever is necessary to keep things moving in the right direction.
The beauty of this mindset is that you don’t need anyone to give you the permission. You don’t need to be given a CEO title, or be the most senior person in the room. You can just assume the accountability on yourself and start taking actions you think are necessary for the project to succeed but not being done, and that’s typically how great leaders emerge.
When should I keep going, and when should I stop?
We often hear the term “fail fast” — prove something doesn’t work and move to to a different idea immediately.
But people also say “dig deeper” — maybe the real solution is just one iteration away. Thomas Edison failed thousands of times before being able to build a light bulb that works.
Well.. that’s pretty confusing — how do we know which case we’re in?
I’m not wise enough to give you a classifier at 100% accuracy. But here are a few things to chew on when you confront the question yourself -
Make a clear distinction between “the problem is not real” vs “the solution doesn’t work” and figure out which case it is. Sometimes we think people have a big problem when they actually don’t care about it that much. If the feedback you are getting suggests that there’s no strong demand for solving the problem, it’s time to go back to the drawing board and try to identify a problem that’s real.
If people confirmed they have the problem, but they are just not happy with the solution you provided, figure out why. Ideally even before you began to solve the problem, you should have studied what solutions were tried in the past, why the problem is still there, so you can learn from them and avoid repeating the same attempt. Once you know why the solution doesn’t work, you can determine whether those factors are within your control or not, and decide next steps accordingly.
Assess whether you have the resource to build a working solution. Sometimes what you discover is that a working solution requires massive upfront investment or different domain expertise that you don’t have. You could either try and get those missing pieces, or move to a smaller, more manageable goal which sometimes can be a stepping stone towards the bigger dream.
Managing the ups and downs
Working on things from zero to one is inherently risky. Most startup companies don’t make it, and the founders get zero (or even negative) financial gains.
The same holds in a corporate environment — we can’t ask for the freedom to work on risky ideas that may or may not generate value, and expect a GE rating regardless of the outcome just because the ideas are cool and you worked hard on them.
You will need to be comfortable with the rollercoaster ride that every entrepreneur will tell you they went through, and learn to manage the risks.
Know the bottom line
You can’t keep founding new startups if your family is starving — plain and simple. You need to regularly align with stakeholders and make sure you are meeting their core expectations and can keep the lights on.
Focus on long term growth
Understand that your performance rating is not the only thing you are gaining from your career. The rating rates your impact over the last 6 months, not you as a person. Even Steve Jobs had some bad performance reviews — so bad that he got removed from the company he founded — but no one today would look back on the story and say Jobs was incompetent.
What’s more important is your personal growth, which unfortunately is not as visible. You can understand it by asking yourself -
What did I accomplish this month that I couldn’t before?
As you acquire and strengthen your skills, trust that you will be making larger impact down the road. Good performance rating and financial gains will come as side effects when that happens, not a leading indicator.
Manage expectations
While entrepreneurs may enjoy the thrill from a rollercoaster ride, investors generally don’t like unpleasant surprises. This is why in every public company’s earnings call, good CEOs will set expectations clearly if they are anticipating anything to go slow next quarter.
The same idea applies when we work on zero to one projects — because how ambiguous things are, different stakeholders may have their own assumptions on how things will go. As the person who are working on the idea, you likely have the most insights about what to expect — make sure to over-communicate, especially any bad news, challenges and risks, so others also know what’s to come and can plan accordingly instead of getting a huge surprise when the results are revealed and it’s miles away their expectations.
Closing thoughts
I hope these experiences can be helpful to you, especially if going from zero to one is your passion as well. Please feel free to share with anyone else who may also find this interesting.
If you would like for me to dive into anything more deeply, or touch on something not covered, please feel free to leave a comment! If you also have thoughts on this topic, please also raise below so others coming to this page can see too.
Thanks for reading — until next time!