Vercel · Strategy · Mid · 45 to 60 minutes

How should Fluid compute bill idle time?

Vercel is a cloud platform that helps developers build, deploy, and run web applications and backend workloads. Answer this product management case and get it graded line by line against a weighted rubric.

product strategy
pricing
technical fluency
analytical judgment
written communication

The situation

You are the PM for Vercel's compute platform. The head of product asks you for a recommendation on whether Fluid compute needs a pricing change before a broader push into AI and long lived backend workloads. Customers are starting to use Fluid compute for AI inference, agents, and MCP servers. These workloads often wait on network calls, model responses, or tools, then wake up for short bursts of work. Some customers say billing based mainly on total runtime makes costs feel unfair and hard to predict, especially when their code is idle for reasons they cannot fully control. Others value simple pricing and do not want a model that is hard to understand or easy to game. You need to propose a pricing strategy for this product area. The decision is urgent because pricing affects adoption, gross margin, positioning against traditional serverless, and how clearly Vercel can explain what Fluid compute is for. The hard part is choosing a billing unit that fits new workload shapes without making the product confusing, technically fragile, or worse for more CPU heavy use cases.

What to produce

Write a 1 to 2 page product strategy memo.

Your answer must

Define the customer problem using at least two workload types, and explain why the issue matters now for Fluid compute.
Compare at least three pricing approaches, including keeping the current model, across customer fairness, revenue impact, simplicity, and technical feasibility.
Recommend one pricing direction and specify the core billing unit, who benefits most, and which workloads may be disadvantaged.
Propose success metrics, leading indicators, and a rollout or experiment plan to validate the recommendation.
Identify key risks, abuse cases, and communication needs, including how the pricing story should connect to what Fluid compute is designed for.

Constraints

The recommendation must apply within Fluid compute, not by launching a separate product.
It cannot rely on customers rewriting their apps or adding custom instrumentation.
Usage must be measurable reliably by Vercel's runtime with low overhead and auditable enough for customer billing.
The model should stay understandable for self serve users, not only enterprise buyers.

Format

Use headings: problem, options, recommendation, risks, metrics, rollout.

How Vercel actually played it

Vercel introduces a pricing model where customers pay CPU rates only while code is actively using CPU, aimed at I/O-bound workloads such as AI inference, agents and MCP servers that sit idle between operations. The post walks from servers to serverless to Fluid compute to explain why idle time should not be billed. A good example of changing the pricing unit to match a new kind of workload.

When workloads change shape, change the billing unit to match.
Do not charge customers for idle time they cannot control.
Connect the pricing change to the product's architecture story.
Name the target workloads so customers know whether it applies to them.

Built from Introducing Active CPU pricing for Fluid compute by Vercel.