In today's business landscape, companies must accurately attribute shared costs like cloud and vendor expenses to customers and internal teams. Without attributing shared costs, engineers, product managers, and others will lack accountability and the complete picture of how much their products cost. This is where unit economics and internal rate cards help to manage shared costs by creating a contract among teams providing services to each other. It is effectively enabling budgeting and forecasting.
Companies frequently adopt OpenMeter usage metering and unit cost features to attribute shared costs between customers. This blog post will discuss FinOps practices to manage shared costs effectively, even for upcoming product features and cloud services.
Unit Economics: A Tool for Managing Shared Costs
To effectively attribute shared costs, businesses must establish unit economics. This involves calculating the unit cost and metering the consumption of each consumer to attribute spending accurately.
Consider this example: If your monthly cost for handling 1,000,000 requests is $1,000, the unit cost per request is $0.001. By metering each consumer's usage, we can determine their specific cost. For instance, a customer responsible for 20,000 requests costs $20 monthly. Extending this process across various layers of your business, from business transactions to infrastructure layers, provides a comprehensive view of the cost of all shared resources. This method can be applied to any shared cost, from business transactions and support minutes to cloud resources like compute and storage.
These resources often interlink; for example, a microservice might utilize shared compute resources like Kubernetes nodes and shared databases. Thus, the unit cost of one resource can inform the cost of another, creating a cost tree where the leaf nodes represent direct costs (cloud, vendor, labor) and the root node reflects the aggregated cost of high-level product features or business transactions.
Rate Cards: Contracts Between Teams
Rate cards are an internal static price list of shared resources that can serve as a contract between teams building on top of each other services and business planning with cost.
Rate cards are derived from unit costs but are usually locked down for a period of time. As unit costs can change with usage and costs fluctuate over time, rate cards are static and should be adjusted infrequently, like once a year. This is because rate cards serve as a contract between teams. For example, if a product manager planning a new feature knows it costs $0.02 per month to store a Gigabyte in the database and finds it too expensive to hit their margin goals can decide to:
- Collaborate with engineering to optimize database usage,
- Adjust public pricing,
- Modify data retention policies, etc.
Rate cards transcend departmental boundaries, offering a universal language for discussing costs across engineering, product, marketing, and finance. They encapsulate various operational costs, from the price of a cart checkout to the cost of storing a byte in the database or a single microservice call.
While rate cards are adjusted infrequently, monitoring the variance between the rate card and actual unit costs is vital. Significant discrepancies should prompt a detailed discussion within the team, as they can influence budgeting and strategic decisions.
Budgeting and Forecasting with Shared Resources
Rate cards establish a contractual framework among teams and serve as a common language for cost-based planning and decision-making. They enable finance departments to translate anticipated business growth into revenue and cost projections. Simultaneously, teams can estimate their future expenses, influencing decisions like service re-architecture based on cost forecasts. Businesses can then align these forecasts with broader objectives, such as optimizing checkout costs, reducing technical support load, or enhancing storage efficiency.
Elevating this approach, consider developing an internal cost calculator based on your rate cards, similarly as provided by cloud services or usage-based SaaS pricing models. This enables teams and leaders to proactively estimate their decisions' financial impact.
As Werner Vogels, CTO of AWS, aptly stated in his first law of The Frugal Architect:
“By considering cost implications early and continuously, systems can be designed to balance features, time-to-market, and efficiency. Development can focus on maintaining lean and efficient code. And operations can fine-tune resource usage and spending to maximize profitability.”
