In a prior life as a CTO, when you asked one of the best engineers on my team if he could build something, his typical answer was “it’s just typing.” He knew what to do; it just took time. But is that what he should be doing?
Now as a VC, I help early-stage startups create their version of the future. The best startup teams consistently focus on the known unknowns, which is a mountain you know you have to climb, but you haven’t yet found the path. Sadly, many teams do the easy stuff and don’t maniacally focus on the hard parts.
First, a startup begins with need a small group of users have. You envision a product that might solve it, and build many versions of the idea until that small group can’t live without it. That’s your first Known Unknown. You know what you think they want; then you have to prove it. It’s all that matters. Hopefully, you’ve raised enough seed capital to iterate enough times to figure it out.
Not all companies should raise venture capital, but if you chose to swallow the red pill, your next job is to find scaleable repeatable ways to grow. Depending on the type of product you’re building, you need figure a version of this path before you raise your Series A. Anyone can google massive numbers to put on a top-down TAM slide. The hard part is the bottoms-up plan, outlining how you take on a large market, one bite at a time. If you’ve had time to test that go-to-market already, you’re only asking VCs for fuel to put on an existing fire, which is remarkably easier. Annotate the graph and tell the story.
Why do many teams struggle with this? It ultimately starts with the company culture you build. An engineers job is not to write code. Most tech interviews test how well they write code (even though I think that’s broken), but the only job is to improve the product for your users. Importantly, the founders and the most talented people in the room must be focused only on the Known Unknowns. If a problem has moved from a Known Unknown to a Known Known, where you understand the what and the how… it’s also a great time to hire new people to do it.
What I often hear from CEOs is that “my CTO thinks we need to rebuild the backend so it’s scaleable.” The reality is that if you haven’t yet solved for the product’s scaleable and repeatable growth, you don’t know what the backend needs to be. If you’ve hired people that care more about the programming languages/frameworks and not the KPIs of your product, you’ll constantly have this internal battle. Remind them that writing software is the easy part. Building a company that scales isn’t.