Join the community at FinOps X 2025, June 2-5
FinOps Foundation Insights

Cost-Aware Product Decisions

October 16, 2024

Key Insight: FinOps is continuing to shift from managing cost as an operational afterthought to a key consideration in the product design process. Data-driven business conversations about what to build, which features to include, and where to build it are now happening before engineers are handed requirements to start developing. FinOps teams can estimate, monitor, and optimize the unit cost of a product or service from inception to help drive cost-aware product decisions before architecture begins. A proactive approach to cost management at each stage of the software lifecycle results in lower operating costs and better budget adherence than later-stage remediation.


Cost has been an afterthought

At FinOps X in San Diego in 2024, J.R. Storment, Executive Director of the FinOps Foundation, discussed the Evolution of FinOps, where he outlined five key changes happening in the practice. One of these key changes is the shift from cost as an operational afterthought to a key consideration in the product design process. Some in the industry call this change “shifting left”, mirroring a similar movement in the security industry to design and build with application security in mind (1).

FinOps X 2024 Day 1 Keynote: J.R. Storment discusses making cost-aware product decisions.

Not considering realistic cost forecasts, or only considering cost after deployment, can lead to unwelcome outcomes, such as surprisingly high cloud bills, lower than acceptable product margins, and reduced options for cost optimization due to earlier design decisions. Further, attempts to manage cost after deployment can increase the risk of service interruptions when remediating designs in pursuit of cost savings.

Shifting the cost focus

FinOps Practitioners must spend time continuously performing incremental cost optimization for products that are operating in the cloud or other environments they manage, but each phase of the product life cycle offers opportunities to optimize cost. Making decisions without considering cost implies that you lose some levers that could have been pulled to manage overall cost. But if you consider cost in the initial product design, you will end up with a product that meets its budget and operates cost-efficiently (or decide not to proceed with building the product because it is not viable from a cost perspective).

This concept is illustrated by the image below, where cost requirements come in at different stages of the product development lifecycle:

How can organizations design with cost and value in mind?

Designing products to known cost requirements means that cross-functional planning must be done before product design begins, which may come significantly before engineering design. FinOps Practitioners must bring together Leadership, Finance, Product, and Engineering personas to define product success criteria, and clearly establish the balance among the competing goals of low cost, high quality, and fast deployment (the Iron Triangle).

Organizations should consider cost as a part of setting target profitability targets in the initial product design, and pull levers available to them at each phase of the development cycle. In some cases this may result in decisions not to launch a product, or to build or source it in different ways due to the expected cost profile. It is better to identify large discrepancies between forecasted costs and product requirements as early as possible to avoid lost time, money, and productivity when discovered after the fact.

1. Product Design: Estimate the cost and value of the product

Personas involved: Product, Leadership, FinOps Practitioners

In the product design phase, product owners typically turn an idea into an actual product:

Making the business case: cost/benefit analysis

A cost/benefit analysis should be done as part of setting the business requirements. The FinOps team can support cloud architects and product owners to estimate cloud infrastructure cost. The value can be described in terms of direct or indirect revenue, time saving, efficiency, etc. Based on this analysis, the business may decide to proceed, stop the project, or reassess the goals or requirements for the product.

Design to cost/value

Once the business case has been positively validated, the business and user requirements are translated into functional/non-functional requirements. Considering cost as a design parameter helps in maintaining a positive business case throughout the lifecycle so the principle of design to cost/value should be considered. Design to cost means costs are designed into the product as a non-functional requirement. Alternatively, design to value can be considered, which emphasizes the value delivered rather than cost.

Establish unit metrics

A best practice for designing to cost/value is to have a clear view on what success looks like and how to measure this. This is where unit metrics come in; they provide an understanding of how an organization’s cloud spend impacts the value of the organization’s products and services. Having an agreed unit metric from the beginning creates a common understanding of value/cost across all teams (engineering, product, business, finance) and enables data-driven decision-making throughout the product lifecycle.

2. Build: Engineer with cost in mind

Personas involved: Engineering, Product, FinOps Practitioners

Architecture

Based on the product requirements set in the design phase, engineers will design the architecture, selecting components that deliver the required functionality. In this phase, you typically have a series of trade-off decisions that need to be made to balance the competing goals of low cost, high quality, and fast deployment (the Iron Triangle).

Engineering architects will consider questions of workload placement (on-premises, cloud, hybrid), level of technical abstraction (IaaS, PaaS, SaaS), and development architecture (VMs, containers, serverless, etc.). The design to cost/value principle will guide decisions about architecture for each workload.

Additional data can be leveraged, such as resource utilization, to rightsize resources from the beginning. Analyzing legacy architecture also helps in building a roadmap to re-factor or modernize workloads using cloud native services.

Major public cloud Infrastructure-as-a-Service (IaaS) providers offer design frameworks that include cost as a key pillar with recommendations for best practices. These detailed resources help customers design workloads, and select, configure, and operate cloud services with all of these considerations in mind:

These frameworks can guide engineers to build efficiently in the cloud, making choices among tradeoffs that will align with business goals. Cloud engineers should familiarize themselves with the recommendations from their provider(s) and apply best practices when designing new cloud-native workloads and/or when modernizing workloads on any infrastructure.

Additionally, the FinOps community has developed several resources to help with Architecting for Cloud.

Cloud Cost modeling

In order to get a forecast of cost for a specific workload, a pricing calculator can be used to estimate costs for all components. Although these calculators are comprehensive, they cannot provide 100% accuracy. Calculations are static so they do not reflect actual product data and usage volumes for things like API calls, network traffic, actual storage, or logging data. A Proof of Concept (POC) can be used to understand the true dynamics of a workload and identify the cost drivers of the architecture.

At this phase, the FinOps team can provide both technical and commercial insights and best practices for the components. On the technical side, the FinOps team can leverage lessons learned from optimizing existing applications, workloads, and shared services, such as storage lifecycle policies, caching policies, and using the latest CPU technology, for example. On the commercial side, the FinOps team can help with discount programs and forecasting costs.

3. Operate: Monitor costs continuously after deployment

Personas involved: FinOps Practitioners, Engineering

Design and architecture work will always include some assumptions, but by including unit metrics, cost considerations and value trade-offs from the beginning, you will be able to understand the cost drivers of your service or application when they’re deployed, and discover efficiency opportunities early on. To make sure cost is being tracked, proper governance and policies must be set up. Further, providing granular visibility into cost for key stakeholders helps to build a cost-aware culture.

Governance

Before deploying the resources in the cloud, proper governance and policies need to be clear and agreed upon by all stakeholders. The goal of setting governance and policies early on is to truly understand the dynamics and verify the assumptions you made in the design and build phases. Real-time governance also helps in avoiding waste by setting cost boundaries.

Two critical actions to establish cost governance are establishing proper tagging and setting up anomaly detection. Setting the right tagging strategy goes a long way toward delivering accurate, qualitative data about the cost drivers of your application. Without proper tagging, Engineering teams and Product Owners will not have the necessary insights to identify resources that are candidates for optimization.

Establishing a budget for your application would ideally have been completed in the design phase. Now, you can use automation to detect if costs are trending in a way that will exceed your budget. Anomaly alerts help you remediate potential runaway costs as soon as possible.

Reporting & Analytics

Delivering the right granularity of data to the right stakeholders helps not only with continuous optimization, but also with establishing a cost-aware culture. Without granular data on cost drivers, Engineers are likely unaware of the cost of the resources and service they choose to build and run an application.

FinOps Practitioners can provide the relevant data to do early reviews of the architecture, and make adjustments where needed. Ideally, this data is put “in the path of the engineer” meaning cost estimates are made available to them while coding so they can see the direct impact of cost when committing code in the CI/CD pipeline. This immediate feedback helps Engineers understand that the choices they make have a direct impact on the cost and value of the application they deliver.

Adapting to Changes

Regular architecture reviews are necessary to keep applications optimized as workloads/usage changes. When the FinOps team is involved from the beginning of the application lifecycle, the right data are available to make cost-aware product decisions.

Changes to the pricing of a particular service is one example of an event that can trigger the search for more cost-effective services. Another example is when workloads are “lifted and shifted” from on premises to the cloud. In these instances, historical data can help with right sizing and choosing the right pricing model. From an architectural standpoint, this data can be used to build a business case for optimization and refactoring using cloud components.

Picking the right building blocks for the right architecture becomes more complex as cloud providers add more services and evolve their pricing structures. With visibility into the costs of various technical components, and historical cost and usage data, teams can estimate the cost of new services/offerings based on actual usage data. Since a unit metric has been set from the beginning, it can be used as a baseline to answer the question, “Does a change have a positive effect on the unit cost?”.

Closing

Shifting cost considerations from post deployment to the initial product design phase ensures that cost, quality, and profitability goals are achieved, and that operating costs are well understood and controlled throughout the product life cycle. Further, involving Product and Engineering personas in the cost forecasting from the beginning to help them understand the impact of service choices helps instill a culture of cost-awareness and accountability. Ultimately, cross-functional stakeholders, led by the FinOps team, should establish and track unit metrics from product inception through ongoing operations.

Topics
  • FinOps Foundation Perspectives
Share

Related assets

Shifting FinOps Left in the Development Cycle Unit Economics: Cloud Cost Metrics that Matter to the Business