Product Strategy, Materials and the Cost of a Decision

A Product Vision states a direction of change. A Product Strategy decides how the organization will get there under real constraints — which customers it will serve first, which problems it will refuse to solve, and how it intends to win against alternatives. Vision points; strategy commits.

Consider a fictional streaming product called Northline. Its vision is to give families immediate access to relevant regional stories on any connected device. That vision alone says nothing about how Northline competes with services that already have larger catalogues and larger budgets.

Northline’s strategy narrows the vision into a bet: serve a specific regional audience through a curated, locally produced catalogue, rather than compete on the sheer volume of global content. It deliberately trades reach for relevance and a lower cost of content acquisition.

A strategy is therefore as much about what a product will not do as about what it will. Northline will not license international blockbusters, will not attempt every device profile in its first year, and will not chase every geography a global competitor already owns.

This is the strategy the rest of the chapter tests against reality — because a strategy that cannot be produced, operated and paid for is not yet a strategy. It is a preference.

People buy a product because it improves their life or their business more than the alternatives available to them. That comparison is never made in isolation — it is always made against whatever else the customer could choose instead, including doing nothing.

A simple way to hold this in mind is a value equation: a product’s value equals its benefits, rational and emotional, relative to its price, judged against competitors. A product that improves this ratio faster than its competitors tends to keep the customers it has and attract new ones.

Value = (Rational Benefit + Emotional Benefit) ÷ Price — relative to the competitive set

For Northline, the rational benefit is straightforward: content a household cannot easily find on a larger, more generic platform. The emotional benefit is closer to identity — seeing a region’s own stories told on its own terms. Neither benefit matters if the price, in money or in friction, erases the advantage.

A product strategy therefore has two levers, not one: grow the benefits customers actually notice, or shrink the cost of delivering them. Improving both at once — better content, cheaper delivery — is what turns a narrow regional bet into a durable margin rather than a one-time novelty.

This is the same value wedge that reshaped the smartphone market in 2007, when a new entrant stopped competing on battery life and messaging speed and instead removed the unmet friction of using the internet from a phone at all. The lesson was never the device — it was where the value gap had been hiding.

Every product competes on a shortlist of dimensions: features, usability, performance, durability, reliability, serviceability, conformance and aesthetics. Not every dimension matters equally to every customer, and treating all eight as equally important is itself a strategic mistake.

A regional streaming product like Northline gains little by competing with a global catalogue on raw feature count. Its real contest is on usability — how fast a household finds something worth watching — and on reliability — whether the stream that starts on a Tuesday evening keeps playing.

Durability and serviceability, dimensions that matter enormously for a physical product, barely register for a streaming service; conformance to a regional content rating system, by contrast, may matter more to Northline’s audience than to a global competitor’s.

This is the same idea introduced earlier as tolerance, applied one level up: a strategy does not just set a tolerance for each dimension, it first decides which dimensions deserve a tolerance at all. Tightening a dimension customers barely notice is the strategic equivalent of over-specifying a bolt no one will ever inspect.

Deciding which two or three dimensions to compete on — and which the product can afford to be merely adequate at — is one of the clearest outputs a product strategy can produce.

A product strategy produces two distinct documents, and conflating them is a common source of confusion. The roadmap is the what — the sequence of product bets the organization has chosen to make. The product development lifecycle strategy is the how — the goals and initiatives that determine whether the organization can actually deliver that sequence.

The lifecycle strategy itself has three parts: effectiveness goals, which describe the outcomes the roadmap should produce; efficiency goals, which describe what it should cost in time and resources to produce them; and the initiatives needed to close the gap between current and target performance on both.

For Northline, an effectiveness goal already exists in this chapter: weekly hours of content successfully reproduced by active households. An efficiency goal exists too: the cost per successfully streamed hour. A roadmap without both is just a list of features; goals without a roadmap are just aspirations.

This is why a credible product strategy cannot be written by the product team alone, sealed, and handed to engineering and finance afterward. The roadmap and the lifecycle strategy have to be negotiated together, because a roadmap that ignores delivery cost is not a strategy — it is the upper-left quadrant from the decision quadrant below, unexamined.

Every product portfolio decision reduces to one of three moves: improve what already exists, build something new, or rationalize — retire what no longer earns its cost.

An improvement should differentiate the product from competitors, drive better customer value, or open a new use case or segment. A new product should change the game, help sell more of the current lineup, or fill a real hole in the portfolio, not a hypothetical one.

Rationalization is the least comfortable of the three, and the most often skipped. Retiring a low-value feature or an underused content tier frees the budget and attention a genuinely new bet requires — the same sunk-cost trap the decision quadrant below was built to expose.

For Northline, this might mean retiring a device profile with negligible usage, improving discovery for its core regional catalogue rather than chasing catalogue size, and building exactly one new capability — localized recommendations — that a global competitor has no strategic reason to build first.

An engineer may confirm that a chair can be fabricated from a specific steel section. A software architect may demonstrate that a platform can process the expected transactions. Neither answer establishes whether customers want the product, whether the organization can produce it consistently, or whether its economics will remain sustainable after launch.

The familiar design-thinking model evaluates innovation through desirability, feasibility and viability. Desirability asks whether the solution matters to people. Feasibility examines whether it can be produced with the available technology and capabilities. Viability considers whether it can survive economically.

For products intended to live beyond their first release, a fourth lens is necessary: operability. Operability asks whether the product can be supplied, monitored, repaired, supported and eventually retired without destroying the value it was designed to create.

These questions are connected. A desirable product may be impossible to manufacture at the expected price. A technically feasible platform may require operating costs greater than the revenue it generates. A profitable first release may accumulate maintenance obligations that make each later improvement slower and more expensive.

Feasibility is therefore not a gate crossed once. It is a condition examined again as the product, its market and its production system change.

Before calculating detailed costs, the team needs to decide which product assumptions deserve investment. A simple decision quadrant can compare expected value with total delivery difficulty.

Expected value includes customer benefit, strategic contribution and economic potential. Difficulty includes cost, time, technical uncertainty, dependencies and operational risk. The quadrant is not a mathematical proof of viability — its purpose is to expose the relationship between benefit and effort.

An idea in the upper-left combines high expected value with low difficulty and is a strong candidate for validation. An idea in the upper-right may still be valuable, but the team should divide it, investigate its largest uncertainties, or search for another way to produce the result.

The lower-right area deserves particular attention. Organizations often continue funding expensive, low-value features because work has already begun; the quadrant makes visible what sunk-cost reasoning attempts to hide.

The position of an idea changes as evidence appears. Research may raise its expected value, a prototype may reduce technical uncertainty, and a supplier quotation or a load test may reveal that the original production model is not viable. The diagram is a living decision instrument, not a ceremonial workshop artifact.

Once a product hypothesis deserves further exploration, its cost must be decomposed. A first model can use six families: development, production, operation, storage, maintenance and retirement.

These categories apply to both physical and digital products. The objects inside them change, but their economic function remains surprisingly similar — a fact the table below makes explicit.

This decomposition matters because early estimates frequently include development and omit the rest of the product’s life. A prototype can demonstrate that a concept works; it rarely demonstrates what it will cost to keep working for five years.

In a physical product, material cost appears tangible — wood, steel, leather, adhesives and finishes can be measured, weighed and quoted. Yet purchase price is only the beginning.

Material selection also affects waste, machining time, energy consumption, defect rates, packaging, transportation and maintenance. If one hundred dollars of material produces only eighty dollars of usable output after cutting and defects, the product does not have a material cost of one hundred.

C_{usable material} = C_{purchased material} ÷ yield

At an 80% yield, one hundred dollars of purchased material becomes an effective usable-material cost of 125 dollars.

A designer can change this relationship before purchasing negotiations begin. Reducing the number of parts, changing a cutting pattern, standardizing a section, or designing several components from the same stock may save more than a small supplier discount.

Digital products consume materials too, although they do not remain visible in the final interface. Computing capacity, network transfer, storage, licensed data, third-party APIs and model tokens are transformed into a service — the material simply arrives through a meter rather than a truck.

A tolerance defines how much variation the product can accept and still perform its intended function. In manufacturing it may describe a dimension, an angle, surface roughness, color variation or material strength.

Tighter tolerances normally require more precise equipment, additional inspection, better process control and higher rejection costs. Digital products have tolerances too — maximum response time, acceptable error rate, service availability, recovery time after failure, data freshness, synchronization delay and result accuracy.

A requirement for 99.99% availability is not simply a decimal placed in a document. It can imply redundancy, monitoring, automated recovery, more complex deployments and permanent operational capacity.

A tolerance should come from the consequence experienced by the user. A financial transaction and a film recommendation do not require the same certainty; a medical component and a decorative cover should not carry the same dimensional control.

Applying the strictest tolerance to every part produces an expensive product. Applying no discipline produces an unreliable one. Design consists partly in knowing where precision creates value and where it merely creates cost.

Manufacturing labor can often be connected to observable operations — cutting, bending, welding, sewing, assembling, inspecting. Even there the relationship is not perfectly linear: setup time, batch size, learning, defects and model changes affect the cost per piece.

In digital products the connection between labor and completed units becomes even less direct. Ten developers working for a month do not necessarily produce twice as much valuable software as five — adding people also adds onboarding, communication, integration, review and coordination.

A feature that appears small on the interface may require changes to identity management, data models, cybersecurity controls and several existing integrations. Another may be assembled rapidly from capabilities the organization already owns. Hours worked are an input, not finished pieces.

Software-cost estimation therefore considers functionality, complexity, criticality, technical conditions and risk — not headcount alone. This is one place where an experienced Product Manager creates measurable value: not certainty, but recognition of what a first calculation omits.

Legacy constraints behind the interface, unavailable or poor-quality data, external approvals, security and regulatory work, operational readiness, adoption, migration and the cost of failure — the Product Manager connects technical uncertainty with customer value and economic consequence.

Return to Northline, introduced earlier as a strategy bet on regional relevance over global reach. A vision and a strategy are not yet a business — they still have to survive contact with a cost structure, starting with the metric that will measure whether the bet is working.

Its North Star Metric is not the number of registrations or downloads — neither guarantees customers receive value. A more useful metric is weekly hours of content successfully reproduced by active households.

For Northline, “successfully reproduced” also requires a tolerance: playback must start within the expected time and continue without a failure severe enough to make the viewer abandon it. The metric therefore connects customer experience with technical and economic performance.

These numbers do not represent Netflix or a particular cloud provider — they form a transparent model for understanding cost behavior. The estimated monthly contribution is revenue minus fixed and variable costs: 800,000 minus 660,000, or 140,000 dollars. The cost per successfully streamed hour works out to $0.33.

Now imagine viewing rises to thirty hours per household without a price change. Engagement improves, but variable consumption also increases: an additional million viewing hours costs 120,000 dollars more, so the North Star Metric moves upward while the margin moves downward. This does not mean the metric is wrong — it means a North Star must be accompanied by economic guardrails.

Northline’s first architecture might be intentionally simple — a limited catalogue stored in one cloud region, encoded into a few playback formats, delivered through external services. This may be the fastest, least expensive way to test whether the audience exists.

If the product gains traction, its economic conditions change. More users create more concurrent sessions, a larger catalogue increases storage and encoding, and expansion to new countries adds content rights, regional infrastructure, support complexity and new device profiles.

Large streaming platforms bring content closer to viewers because repeated long-distance delivery is expensive and can damage performance. The specific architecture is not universal — the principle is that as demand becomes observable, the production system can be redesigned around actual patterns rather than initial assumptions.

Northline might pre-encode its most-watched titles, place popular assets closer to concentrated audiences, change storage tiers, eliminate low-use formats, cache repeated requests, or scale variable services according to demand.

Cloud autoscaling can align capacity with consumption, but it cannot correct an inefficient unit of work. If every streamed hour uses unnecessary processing, scaling simply automates the multiplication of that cost. Architecture is therefore part of the business model.

Artificial intelligence can reduce the time required for research, coding, content tagging, interface exploration, testing and documentation — and let a team explore more alternatives before selecting one. But faster generation is not the same as proportionally cheaper production.

C_{AI workflow} = C_inference + C_retrieval + C_evaluation + C_retries + C_{human review} + C_operation

A model with a lower price per token may produce a higher cost per successful task if its outputs require more retries or manual correction. A generated component may appear complete while still requiring security review, integration, testing and long-term ownership.

This is why AI-assisted estimates can remain far from reality — the tool may estimate the effort visible in the request while missing the environment the work must survive in.

Cloud providers recommend measuring unit costs — cost per inference, per data point, per completed task — alongside business-value measures, and continuously comparing costs and outcomes as the system and its resource allocation are refined. AI changes the speed of production. It does not remove the obligation to understand production.

An early estimate will be wrong. That does not make it useless — its purpose is not to disguise uncertainty with a precise figure, but to reveal which assumptions could change the investment decision.

A credible estimate begins with a technical baseline, decomposes the work, records assumptions and applies more than one estimating method, then tests sensitivity and risk before comparing the forecast with actual results.

Instead of saying the product will cost $500,000, a team can say: under the current catalogue, device coverage and viewing assumptions, the first release is expected to cost between $450,000 and $650,000, with content preparation and delivery volume as the greatest uncertainty.

The second statement is less comfortable but more useful — it identifies where research, prototyping or negotiation can reduce uncertainty. Different methods can be combined as product knowledge improves.

In physical manufacturing, prototypes and pilot runs reveal actual material yield, assembly time and process defects. Digital products need the equivalent — instrumented releases that measure delivery cost and operational effort, not adoption alone. An MVP that validates demand while ignoring operation validates only half of the product.

Cost visibility should not remain inside a spreadsheet owned only by finance or cloud engineering. Product decisions need a shared catalogue that connects expenditure with design choices.

Every significant cost should identify the product or capability that creates it, its owner, whether it is fixed, variable or step-fixed, the unit that causes it to grow, the evidence behind the estimate, the level of uncertainty, and the date it was last reviewed.

A cloud invoice organized only by technical service is insufficient — it can show that data transfer increased without explaining which customer behavior, feature or market produced it. Product cost management requires allocation by meaningful units: active household, completed order, successful transaction, processed document or resolved request.

FinOps practices formalize this collaboration between product, engineering and finance. The objective is not simply to reduce cloud spending but to connect technology consumption with business value and assign responsibility for both.

Dashboards for forecasting, tagging, allocation, budgets and anomaly detection can support this work, but their value depends entirely on the quality of the product model underneath them. A sophisticated dashboard cannot repair an undefined unit of value.

The Barcelona Chair and Northline appear to belong to different worlds — one transforms steel and leather into a physical object, the other transforms data, infrastructure and content rights into hours of entertainment. Both reveal the same relationship between design and economics.

The Barcelona Chair preserved expensive craftsmanship and found viability through a premium position. Northline cannot solve increasing consumption simply by charging more for every technical inefficiency; it must continually redesign how content is encoded, stored and delivered.

Materials change, suppliers disappear, usage patterns evolve, technology ages, regulations introduce new controls, and growth reveals bottlenecks that were invisible in the prototype. Cost refinement is not evidence that the original product failed — it is part of the product’s development.

The failure occurs when the organization protects the original design after the evidence has changed. A product is not only the object, interface or service the customer experiences; it is also the system capable of producing that experience repeatedly.

The most resilient products are not those whose teams predicted every future cost. They are those designed with enough visibility and adaptability to change when reality arrives. Every cost begins with a decision.