Like any SaaS organization, CloudZero cares about our COGS, margin, and unit cost. As you can imagine, we have a fair amount of insight into how those numbers are changing every day thanks to being “customer zero” on our cloud cost intelligence platform.
Talking with other companies, I often find that the best organizations understand that measuring the cost implications of new products and features once you’ve deployed them can be too late.
However, any good engineering leader is also wary of slowing down the pace of innovation by adding more processes. I believe that at CloudZero we’ve found a good balance that allows us to understand risks around cloud costs during our product discovery process in a lightweight manner and wanted to share what has been working for us.
How Product Development And Discovery Works At CloudZero
In the CloudZero product and engineering group, we are organized around empowered product teams.
Small groups of highly capable engineers are paired with a knowledgeable product manager and an experienced UX person and then empowered to serve customers, in a way that meets the needs of the business.
These teams have ownership of a portion of the CloudZero platform and ensure that it continues to deliver the intended outcomes for our customers as well as picking up new customer objectives each quarter from the product leadership team.
In our process, those new objectives are focused on customer outcomes — not specific features — so the team goes through a discovery process to ideate, validate, and control risks before the much more expensive implementation phase commences.
This discovery phase of the product development process is led by what we refer to as the triad.
The triad is composed of three representatives from the product team, the product manager, the UX person, and a single engineer. The triad’s responsibility is to discover a path to the desired outcome for our customers.
Achieving that uses a variety of tools, but the outcome, if successful, is a solution that controls for all of the classical types of risks that you find when building software (business viability and value risk, technical feasibility risk, and usability risks.)
How Risks To Our Margins Are Tracked In The Discovery Process
We’ve found that this discovery process is a perfect vehicle to understand and control risks around profitability when it comes to new features.
In practice, the engineering member of the triad is tasked with the first pass. Since this individual is responsible for the technical feasibility risk of the discovery process, they must understand the technology approach we’ll use to achieve the desired customer objectives and outcomes.
During this process, they explicitly list any areas where the technology solution suggested will incur significant cost overhead.
When talking about cost risks, we find it helpful to talk about cost impact in the terms of unit costs.
At this point in product development, it can be difficult to know for sure how successful a new feature will be, so by instead talking about the cost impact of delivering a single unit, outcome, or servicing a single customer in this objective, the entire triad can more easily understand the cost risk.
Of course, having good insight into your current cloud costs and unit economics helps model new changes much more quickly.
Once the engineering member of the triad has listed the unit cost associated with the suggested technology solution (or costs across a few different solutions we’re considering), we move that risk over to the list of business viability risks.
The product manager member of the triad is responsible for understanding and addressing any business viability risks. The product manager is now responsible for working with others across the company (primarily the sales and marketing teams) to ensure that this solution can be cost-effective for the company given our new understanding of unit cost around delivering this objective.
This process is rarely linear for areas that have significant unit cost implications, but it’s still lightweight enough to quickly understand if we can deliver these outcomes in a cost-effective manner long before we start writing any code.
Since product discovery is all about understanding risks as cheaply as possible, we find that we better understand these implications long before a team has to write any code — giving the product teams great confidence that their implementations will serve our customers in a way that both delights them but also meet the needs of our business.
How To Get Started
The above lays out what works for our team. It’s resulted in incredibly empowered teams and fewer COGS surprises as we grow our platform quickly. If you want to get started, I’d suggest you figure out how these key things can fit into your culture and process:
- How can you empower your product team and engineering teams to discuss cost implications before they ever start development of a new product or feature?
- How can you lower the costs of those discussions by arming both of those groups with rich and easy to understand cost information about your current cloud architecture?
Achieving both of those outcomes in your own product development process will invariably allow you to have more profitable SaaS platforms without sacrificing customer delight or the pace of innovation.
If cost awareness is new to your engineering team, I’d also suggest you look into tools or training that will help your team get started. Of course, if you’d like assistance getting started with empowering your product teams with cloud cost intelligence and the ability to make better cost decisions in the product discovery phase, we’d love to talk to you.