You Don't Need a CTO
Lack of product momentum leads to company failure before and beyond MVP. If you’re struggling with getting your product to market and failing to gain product momentum post-MVP, you’re highly likely to fail and run out of cash.
What does product momentum look like? Product momentum means consistently getting customer and market-validated features out the door, resulting in happier users and customers and increasing revenue.
While context matters, I’m quite opinionated about product delivery, given how frequently a lack of it leads to company failure. This article gives you a set of rules to live by, especially when you’re not sure what you are doing from a technical standpoint.
Remember, you are not a small version of a big company. This is a common error for founders, as they try to replicate big company roles in their early stage startup.
If you see these characteristics in your business, especially pre $1m ARR, you’re in big trouble:
Your pre-seed/seed stage startup already hired a “CTO” when you barely have revenue and product market fit. Essentially, you’re saying you’ve already found the best talent to lead your product and engineering effort a few months in.
If you’re wrong, now what? What if they are good enough as a developer but can’t hire, operate or lead a team? If a developer won’t join your team without the CTO title, they may not understand what they are getting themselves into, and you may be dodging a bullet by passing.The exception may be a co-founder who is a developer and gets the CTO title while you get the CEO role. Otherwise, you don’t need a CTO. You need an intelligent, highly motivated software engineer with the skills to build great software. Consider other titles. Don’t cap your upside.
Your “CTO” or engineer can’t write production-level, high-quality code and needs to hire additional developers to get anything done. A huge red flag. Of course, you may have a great product person, but is that what you need? You should own the product this early. If you’re hiring someone to work on the product, they should be highly technical.
If the person is a co-founder and a great product person but can’t write code, don’t give them the CTO title. Figure out something else. Co-founder and Product Leader works.
You can’t point to any tangible product momentum that delivers highly functional customer value. This is self-explanatory. If you have a developer, you should make product progress weekly. You're in trouble if you can’t see progress in tangible ways weekly.
Clarification: I’m not saying every feature takes a week to get done; progress should be clear and communicable to you as the founder.
You’re running a two-week sprint. The feedback loop for 2-week sprints is too long for an early-stage startup. 99% of pre-traction startups shouldn’t be running 2-week sprints. So you’re getting valuable stuff out twice a month? The founder and developer should go back and forth in sync, building daily and feeling the excitement. Again, context matters, but there are few exceptions to this rule.
Your developer or CTO only “talks tech,” not customers and their experience. A developer should be just as focused on ease of use, business outcomes around revenue, and customer retention when building a product versus the new framework they want to use.
Your development team makes everything complicated. When you know something well, you can explain it simply for the audience to understand and make appropriate decisions. Complicating the technical information you need to make business decisions is a sign your developer doesn’t fully understand what they are doing.
If you continue to struggle with your technical team, technology leader, or CTO to deliver momentum, you have to make a tough decision. You need a change in leadership or team members. I’ve hardly seen a technology team turn around without drastic personnel changes. It’s not what a CEO wants to hear but what is usually required. On multiple occasions, I’ve wasted significant time, resources, and opportunity for growth, hoping an existing technology team or leader will turn things around.
One way to reduce your chance for talent errors is to only hire full-time after a test period, where someone consults with you on a problem, and you can see their ability to get things done before bringing them on full-time. In addition, if you are not a developer, find someone to help you vet candidates or consultants for a role. Give prior experience getting things done a considerable weight in your decision making, not from what the person said, but from real work you can validate.
If you want feedback on your product delivery and technical team structure, join the community to learn from myself, the experts at HVL, and other founders. It’s great to hear from others on a similar journey to see what works and what doesn’t.
Let me know what you thought of this week’s newsletter here or on Twitter.
Great article and insights!