Startups Operate at 3 Levels
Startups, and tech companies in general, operate at 3 different levels:
Top level: Business
At this level, you deal with questions like:
Who are the target users? What problems of theirs are you solving? Importantly, what problems are you not solving?
What pitch are you making?
How do you position yourself?
Is the market big enough for your tiny slice of it to be economically viable?
If you’re selling a physical product, are the unit economics viable, or will you be selling a dollar for 90 cents?
Why are you the right founders to take this on? What unfair advantage do you have?
What’s your moat?
Do you have network effects?
Who pays for this, and how? Is it freemium, free only or paid only? Ad-supported? Or do you want to accumulate a user base and let a future acquirer figure out how to make money from your users?
These high-level questions drive everything in the company.
Second level: Product
At this level, the key question is how you plan to address the user needs identified at the business level. What specific product will you build to do so?
What features will it have and, importantly, what features won’t it? For example, if you’re building a notes app, you may say that you don’t offer formatting. Deciding to not offer something is also a decision that narrows down the scope of the product from trying to be all things to all people, which doesn’t work.
At this level, you’d interview users, both to understand their needs and, once you’ve built something, to check if it actually meets their needs.
You should also take a step back and ask how you would know if your product has value. User interviews? Analytics? Are you using funnels to understand where users are dropping off? What metrics will you define to capture whether a given user has gotten value from the product?
How opinionated an approach will you take?
At this level, you sometimes reframe problems to come up with different solutions. If users are asking for a particular feature, what underlying need are they trying to solve, and is there another way of solving it?
At this level, you may pretotype, building fake apps with a hand-drawn UX to explore multiple product ideas much quicker than you possibly could by involving engineers or designers, who do things too well and too slowly for this level.
Are you working on gamechangers and not distractions?
Are you catering to novices or experts? In other words, are you building Microsoft Paint or Photoshop? Either is fine, but not knowing who you’re building for is a recipe for failure.
These are all the things you think of this level. Here you’re laying a concrete product foundation to take care of the users and user needs identified at the top (Business) level.
Bottom level: Engineering
To summarise this bottom level in one sentence, engineering builds the product that needs to be built, as decided one level higher (Product).
At this level, you look at whether the tech is straightforward, like a CRUD app, or if feasibility is a risk to the startup.
Here you can make counter-proposals like “Instead of doing everything you wanted, how about we do this other thing which is similar but will take a week instead of a month?”
At this level, you make hard decisions like the proposed plan requiring years, so what we do instead? It’s easy to daydream about what you want, but engineering is where the rubber hits the road.
Engineers can and should suggest ideas for new features, for example. Engineers are uniquely qualified to identify what’s possible given the technical building blocks, in a bottom-up manner, like Drew Houston asking why you can’t have a folder on your computer that syncs. Till then, folders on your computer stayed on your computer, and cloud services lived in a browser. But Drew asked why you can’t have a folder that’s simultaneously on your computer and in the cloud.
Engineers are not beholden to a domain or business model, and can ask fundamental questions like why can’t any car be a taxi, summoned using an app. A businessperson building a taxi app would have thought within the context of an industry, looking at tech only as implementation, and therefore not have come up with this insight.
So you can see that this three-level grouping doesn’t mean that decisions trickle down from top to bottom. They flow in both directions.
Engineers also make quality / cost tradeoffs like whether a responsive web app is good enough and avoids the need for separate mobile and desktop apps. Or do you need to go one level further and build a native app using Flutter or React Native? Or do you need to go all the way native and build separate iOS and Android apps in Swift and Kotlin?
As for the backend, do you use backend as a service like Firebase? If not, functions as a service, like Google Cloud Functions or AWS Lambda?
Takeaways
Now that we’ve identified these three levels at which a startup operates, what can we learn from this?
First, for a startup to succeed, you need someone who does justice to each of these levels, and not as an afterthought. That’s why single-founder startups typically fail — it’s hard for one person to be skilled at all three levels. Besides, these require different mental gears, which makes them extra hard for one person to them all at the same time.
Second, the leadership team in the company (founders and CxOs) have to be mentally agile and move between all three levels as needed, for a startup to succeed. Even if a person is a native at one level, he should be able to move up or down as needed.
As a counter-example, I recently spoke to a couple of businesspeople who were starting a startup and thinking only at level 1. Their pitch to clients was that instead of using startup A for one service, B for another, C for a third, and D for a fourth, come to us, and we’ll give you A, B, C, and D. This means that their MVP had as much scope as multiple other startups put together. I told them this will take years and cost millions of dollars, and so they need to re-evaluate their strategy, such as by offering some other service E that others are not offering. But they weren’t receptive. One of them asked me, “What if we remove 3(b) from the list of requirements? Will it then get done?” As salespeople, these founders were thinking only at level 1: business.
Conversely, when I started my startup NoctaCam, I initially operated only at the bottom two levels. I didn’t operate enough at the top level — business. If I did, I might have realised that the market for third-party camera app is too small, or that user acquisition is hard for an LTV of a few dollars, which were factors that killed the startup.
Third, if you’re a techie considering joining a startup where you’ll be reporting to or working with a businessperson, tell them some realities about engineering which they wouldn’t like. For example, when I was looking for a job as a CTO, and a CEO would sometimes say, “Things need to be done at the committed time” I counter with “Estimates are guesses. The reason for that is when making an estimate, we don’t know a lot, such as what product we’re building, what features it should have, what form the UX takes, any engineering challenges, etc. So estimates are guesses, not commitments.” When I said this, some businesspeople reacted negatively. We ended up not going ahead, which was good for me. So, if you’re a techie considering joining a startup and working for a businessperson, you don’t want to be perceived as merely an implementation function, a peon who goes and executes what he’s told.
In summary, startups need to operate at these three levels, in order to succeed.