Why CTOs Should Care About Gross Margins, Cost-to-Serve, and Product Management

Why CTOs Should Care About Gross Margins, Cost-to-Serve, and Product Management

We had just started to hit our stride; the revenue engine was humming, and we were getting questions from the Board about how we would grow and scale revenue profitably.  Until then, I hadn’t fully appreciated or understood the impact that decisions made by me and my team had on gross margin.

That was a turning point for me, and there are three critical takeaways from my Krux experience that I now bring to all super{set} companies:

• Cost-to-Serve (CTS) must be a first-class citizen for the CTO and be ingrained into the company’s culture right from day one.
• Product, Engineering, and Platform Engineering (PE) [or DevOps] teams are jointly responsible and accountable for CTS. It is a huge mistake just to hold the PE team accountable for CTS.
• An org structure where Product Management reports to the CTO, especially at a start-up, creates a lot of flexibility and provides leverage in making product decisions related to CTS.

The formula for Gross Margin is simple:

Gross Margin = (100.0 * (Revenue - Cost)) / Revenue

where

• Revenue is what your customers pay you for all the software and services you’ve sold to them
• Cost is what it takes for you to serve those customers (Cost-to-Serve or CTS)

For a SaaS business, gross margin is a great indicator of a company’s financial health. It helps you evaluate whether you can grow and scale your business profitably. The benchmarks for a SaaS start-up depend on the stage, but generally speaking, once you have crossed the $5M ARR mark, you should evaluate your gross margin using the following:

• 80% ? Excellent! Keep doing what you’re doing, and don’t relent!
• 65% - 80% ? You’re doing okay, but improving CTS should be on your 3-month product roadmap
• < 65% ? Fix it! Improving CTS should be on your near-term, urgent product roadmap

While you should always focus on operating your infrastructure in a cost-effective manner, it’s okay to operate at lower gross margins - 45-50% - if your ARR is less than $5M. It’s OK for your gross margins to be even lower if your ARR is lower. At this stage, the board understands that you need to spend more money to stand up cloud infrastructure. Still, you have to be careful about your technical design choices - you don’t want your infrastructure costs to scale linearly with the number of customers!

For us at Krux, two significant factors contributed to CTS:

• Infrastructure (Cloud) Costs: primarily AWS and Fastly (our CDN)
• Compensation (Salary & Bonus) for our integrations & implementation team that helped implement Krux for our customers and built any customer-specific integrations with the ad-tech/mar-tech ecosystem.

As CTO of Krux, I managed five teams: (Application or Product) Engineering, Platform Engineering, Data Science, Product Management, and Integrations & Implementation (I&I). Some folks may find it surprising that Product Management and I&I reported to me. I’d like to say that while this wasn’t a carefully considered decision, in hindsight, this turned out to be one of many things we got right at Krux. This organizational structure has many advantages, but the main one from my perspective was that the buck stopped with me for CTS. My team and I could play offense and defense to improve our gross margin by lowering our CTS as part of our work.

For example, we redesigned the core segment processing algorithm using a two-phase approach, which only required making one pass over the raw user data logs. Similarly, we used Spot instances in our data processing pipelines; we were one of the very early adopters of Spot instances in AWS. On the offensive side, we implemented new self-serve product capabilities that allowed customers to do more for themselves, obviating the need to hire more I&I engineers – and increasing customer volume.

Each choice required us to make trade-offs, but I had more control over outcomes since it was within my team. Of course, we partnered with Sales and Customer Success as needed, but I didn’t have to seek approval from anyone else in the organization to make these decisions. CTS (or improving it) became a product feature, an item on our product roadmap that (a) had strategic value and (b) improved our customer satisfaction.

Another benefit of this organizational structure was that we instilled a culture of frugality when it came to Cloud (AWS) costs across the entire team - Product, Engineering, Data Science, Platform Engineering, and I&I. CTS and gross margin became metrics that everyone on my team - not just Platform Engineering - cared about and were held accountable for. I would beam with pride whenever I overheard things like, “But if we do it this other way, we can solve the problem at a third of the cost. Can we speak to our customers and help them understand the trade-offs?” Often, I see companies where the Platform Engineering (or DevOps) team is left holding the bag for cloud costs. But that is a massive mistake, in my opinion. The engineering team should be held equally, if not more, responsible and accountable for CTS.

CTOs can and should be involved in these decisions. I’ve coined the term “Product-Centric CTO” to describe them. I believe product-centric CTOs can drive growth and success for the companies and teams they lead beyond the purely technical – and they are key to future growth.