Preface
I am currently exploring low-cost entrepreneurship methods, which is also a major advantage for professionals in the computer science field. With just a computer, a server, and a registered domain name, you can build an MVP to test the waters and validate the key hypotheses of a project.
Of course, my best friend and I had also been exploring the path of side-project development before, but it didn’t lead us to financial freedom or the peak of life as we had dreamed. There are also many abandoned projects on GitHub, which goes to show that while it is easy to launch a project with full enthusiasm, how to sustain its development and survive is the biggest challenge.
Of course, back in my student days when time was “infinite” and the cost of trial and error was “infinitely small”, I could adopt Linus’s “Just For Fun” spirit (also the title of his autobiography, Just for Fun) to handle everything by myself from scratch—initializing codebases and databases, drawing frontend UI, designing interactions, as well as creating presentation slides, promotional videos, manual binding, and competition pitches—enjoying the chuunibyou-style hot-blooded manga plot of dominating a national competition all by oneself.
However, after graduating and becoming a corporate wage slave, time and energy seem to become limited. This is why managing time, energy, and even attention should be placed on an equal footing with financial management. Starting a project from scratch now feels like a form of “cyber self-consolation”, but isn’t using market-validated technologies also a good thing? How many side projects have died in the womb because their MVPs were delayed indefinitely? How many projects fell apart with “the venture half-finished and the budget spent”? Therefore, systematically studying entrepreneurship courses helps save non-renewable resources like time and energy while preserving your principal capital.
This is a note-style blog post. As the saying goes, “the palest ink is better than the best memory.” Since I tend to forget things right after reading them, taking frequent notes is much better. I will intersperse my own insights throughout the notes using annotations, though some parts are relatively brief. Part of the content copyright belongs to “Yitang”, a startup bootcamp packed with practical knowledge.
What Are You Actually Creating When Building a Startup?
Drive business with hypotheses — “What is the [key hypothesis] of your business, channel, or product?” Don’t just look at surface-level business data, product forms, or user reviews; advance your business around hypotheses. A hypothesis represents all the key conditions your business model relies on to hold true. If all key conditions are validated, your business can basically run successfully. But if even one condition fails, it will be hard for the business to continue, at which point you need to consider pivoting or even quitting. A key hypothesis is the hypothesis with the highest risk and the greatest importance to your startup among all hypotheses.
Therefore, you must work hard to identify these very few key hypotheses and then validate your business around them. Among these deconstructed key hypotheses, which ones have already been validated by others? Which remaining ones carry the highest risk? (For example, the two most important key hypotheses for opening a store are product selection and customer acquisition.)
Coming up with an idea is cheap because thousands of people might have the same idea, but the key hypotheses behind it are worth a fortune.
In work, when judging whether an innovative project is feasible: if there are prior similar examples or the tech stack is familiar, you can directly estimate upstream and downstream workload hours. If the project has no precedent at all, you need to analyze what its core points are, and then use key technologies to quickly validate whether a minimal version can run.
Managing innovative projects means saving multiple lives for yourself: premortem analysis (think about where the project might die, what the fatal points are, and how to avoid dying at maximum scale with minimal cost) + prepare for failure before anticipating victory.
The Three-Pronged Strategy for Key Hypotheses
First addition, then subtraction, and finally fast validation.
First Addition
First addition: Break down the business into a set of hypotheses, extracting all elements of the entire business in a few sentences or on a single page.
Deconstruct a project into a series of independent judgments that are extremely critical, decisive for success or failure, logically complete, mutually dependent, and capable of guiding decision-making.
2
Break it down into two of the most fundamental hypotheses — Value Hypothesis and Growth Hypothesis.
Value Hypothesis: Does the thing you provide actually have value for consumers, and will people pay for it? Or can one of your stores be profitable in the long run?
Growth Hypothesis: If your business has value, can it be rapidly replicated, rapidly expanded, and rapidly spread so that everyone starts using it?
In short: Do not prematurely scale an unvalidated business model.
5
Five Milestones — Demand (A problem worth solving) → Solution (Does it truly satisfy user needs and pain points?) → Business Model (Is revenue really greater than cost? Is the solution sustainable in the long run?) → Growth (Can your model be rapidly replicated to get more people using your product and capture market share?) → Moats (Can you defend your competitive advantage, or even future advantage, and become an industry giant?)
These must be anticipated globally and executed with focus. At the start of entrepreneurship, you must have global thinking in mind and anticipate the future. When fighting a battle, put your key focus on the link that really matters right now, and execute with laser focus.
9
Any business model can be broken down into 9 key parts.
Then Subtraction
Then subtraction: Select the key priorities from them; don’t try to tackle everything at once.
Principle 1: Prerequisite hypotheses first (do them in order)
Principle 2: Validate a single hypothesis at a time (the higher the risk, the smaller the steps)
Principle 3: High-risk hypotheses first (the longer you delay, the greater the loss; validate at the lowest cost)
Fast Validation: When facing the selected key hypotheses, you need to know how to validate quickly, and how to complete 100% of the work with a 10% investment.
I created a bunch of efficiency tools on the side at work. What colleague problems the created tools solved, how to promote them, and how to iterate on them are all questions tool developers need to answer.
If you want to experience the above workflow, you can build an efficiency tool targeted at a real problem within your company or team. Promote it for everyone to use, keep iterating on it, and extend the tool’s lifespan as much as possible.
Cheat Sheet for Extracting Key Hypotheses
- Your judgment of the business (this is the foundation)
- Discussion with the founding team (where everyone feels uncertain/lacks confidence)
- Advice from fellow entrepreneurs in the network (especially pitfalls and complaints)
- Advice from investors (experience / complaints)
- Advice from senior FAs (experience / complaints)
- Post-mortem causes of historical failed projects (worth studying in depth)
- Focus points of competitors in the same track (what benchmark businesses are validating)
This really looks so much like a tech refactoring project workflow:
First judge by yourself whether it can be done
Tech review to see if there are any pitfalls
Check whether similar projects were done before, and consult senior experts who have done them
How budget administrators view estimated resources (especially when introducing extra middleware)
Have similar projects experienced delays? (especially painful projects requiring consistency like data migration or tech stack migration)
What is the design proposal from the same company or peer companies? Can it be used directly? What problems did they solve? How effective was it?
Once you clarify the above points, the project is probably not far from success—bet on getting a 3.75 performance rating (just kidding)!
Efficiently Answering Key Hypotheses
Entrepreneurship ≠ Building a product
Entrepreneurship = Validating key hypotheses
- Some are industry common sense, no need to validate (the industry has benchmark empirical values)
- Some have already been validated by competitors (if you can burn other people’s money, don’t burn your own)
- For the remaining few that industry common sense and competitors cannot answer, start running experiments yourself (run in small fast steps, low-cost trial and error)
Book Recommendations
Must-read guides for entrepreneurship: The Lean Startup, Zero to One, Business Model Generation, The Four Steps to the Epiphany
Extra bonus read: Buffett’s Moats
Not being able to predict the future doesn’t mean giving up on planning altogether. — Andy Grove
