Tl;dr: A simple mental model for CTOs to think commercially about product decisions. Any coding should either increase revenue, increase retention, or increase the revenue customers pay you.
I had a call with a senior CTO. He was lamenting on the difficulties of the job:
- The CEO and other execs expect a CTO to not only manage but to do
- What KPIs to focus on are not always clear
- The skills to be a great coder and manager are very different
- Spending time managing people doesn’t always feel like you are accomplishing anything yourself
- Apple are masters of simplicity. Making things as simple as possible and not coding anything beyond what is needed is really hard
- Allocating resources to features can be a difficult call to make
Interestingly, he tracked the time spent coding every week and his happiness. The weeks he coded he was happier at the end of the week!
The core problem is that the role of a CTO is not to code (unless you just started and that title should really be lead engineer) but to make decisions, and everyone on the team needs to understand that. Yes, not everyone is clear on what tech people at different levels are meant to do (not that I am an expert either, ha!).
Something I struggle with myself, is I’m great at consulting others, but not myself. I can either do or critique. Without keeping a level of abstraction between those that do and those that figure out what to do, it’s hard to have perspective.
As a dev you can get into coding an API. You’re told you just need to call a birth date, but you see you can add in all sorts of other data ‘just in case’ so why not add it? People like to have more data fields, right? You keep coding and eventually focus on what you’re doing and not the outcome you’re solving for.
I always say to myself “Alex, what are you solving for? What are you solving for?” to focus myself on what my actual goal is. If the goal of what your action is not clear, you can’t do just what is done. I’d certainly benefit having someone to question why I am doing what I am doing.
I ended up reframing his role in an organisation to being responsible for creating a product that customers pay for.
I then explained that there were only three goals that he had for coding anything new, or improving anything existing:
- Increase customers
- Increase retention
- Increase revenue from existing customers
Let me walk you through these.
If you want to grow, then naturally you want to add new customers. How does your coding lead to increasing customers? Have marketing identified that potential customers use a competitor because they have features that you don’t have? If so what are they and what are the critical ones in priority?
You will only add new features if you believe that will help you convert more customers for your current target segment.
He mentioned that they focused on one segment of an industry but were looking to add another. Ta da, you believe that you can increase customers by adding a new niche, so what do those customers specifically need in order to adopt your product? That is what your team needs to build to enable marketing to go out and get them.
Always remember that customers want a quarter-inch hole, not a quarter-inch drill.
The best and cheapest customers are the ones that you already have. Higher retention leads to high valuations. There are other ways to illustrate this, but let’s just agree that retention is good.
The graph below plots net retention against EV/Revenue ratio for 21 SaaS companies in the SEG SaaS Index. Higher net retention is good.
As a CTO why do you care about this? There are many reasons why a customer will leave a SaaS product (Budget for example), but the product itself is going to be one of the key reasons. If they don’t like the product you have built and they find a better option, they will leave so long as the switching costs are low.
A strategic priority for any startup should be to balance time allocated to improving product and adding new features.
To speak to the choir, think about technical debt. As a nerd and a perfectionist you may want to allocate time to cleaning code because it’s driving you bonkers! But that’s not a commercial rationale!
You decide to clear debt because it will increase retention of your customers.
Of course there is the logic of being able to potentially ship features faster, but I don’t want to get into the weeds too much.
Increase revenue from existing customers
Land and expand means that you get a customer and then try to get them to hand over as much money as is possible.
You are going to do that by:
- Increasing seats through more usage
- Releasing more paid features they pay for
Your role isn’t to increase usage as that’s really the sales team, or product marketing team’s job.
Is what you’re planning on building the ideal thing to increase how much your customers will pay you?
Your job is to have perspective
Everyone will have ideas of what should be built. Marketing may say that customers want integrations and the CEO may pop in and drop his latest hair brained plan… As you know, you can’t build everything, and you can have 2 or fast, cheap, and good.
The person in the startup that actually knows how long something will take to build is you (or those in your team). Not all product additions will lead to the same outcomes and of course it is hard to quantify benefits! What you can quantify is time to ship though. Why spend 6 months and 4 devs on something that yields 5 points of benefit, when 2 devs can ship something in 2 man hours that also yields 5 benefit points?
The best CTOs get the commercials of what they are doing. By understanding the commercial outcomes they are seeking to deliver they can have insightful discussions with management about the roadmap and better communicate down the line what the devs are solving for. In my experience many if not most good devs are well balanced people. They may not have studied business, but they get the basics because they are smart and like, read stuff. If you can explain why they are doing what they are doing the devs can think for themselves what they should and should not spend time coding. And you can always check in to ensure they aren’t over baking anything with that understanding or what you are solving for.
When considering what you are doing as a CTO don’t go straight into you head and let the cogs run on how this fits into your architecture. Stop. Question the logic of it to yourself with these questions:
- Will this increase revenue?
- Will this increase retention?
- Will this increase revenue from our customers?
If the answer is no, then what is the specific reason you are doing something? You can also just ask “increase revenue, increase retention, or increase share of wallet from our customers?” and but the ball in their court.
I doubt this framework will end up being taught at HBS, but it’s a really easy to remember mental model to aid you to get out of your tech head and start thinking about everything as a commercial decision.
I came up with this on the call, so welcome your thoughts! Let me know in the comments.
Get in the game
Free tools and resources like this shipped to you as they happen.