You’ve probably seen a pricing change ripple through a product and wondered why usage spiked or stalled. I’ve had that moment too, especially when we rolled out tier changes and the analytics plot looked nothing like our forecast. The root cause was simple: we were treating “demand” as a vague idea instead of a measurable relationship. When you translate demand into a function and a schedule, you get a structured way to reason about how price and other variables move quantity. That’s not just economics theory; it’s a model you can simulate, test, and communicate across teams.
I’ll walk you through what a demand function is, what a demand schedule is, and how both relate to real-world decision-making. I’ll use straightforward analogies, show how to build a demand schedule from data, and point out common mistakes I’ve seen in product, pricing, and marketplace contexts. By the end, you should be able to define demand clearly, express it formally, and use it in a way that supports better decisions.
Demand as a Relationship, Not a Guess
When I talk about demand in a technical setting, I define it as the quantity of a commodity or service a customer is willing and able to purchase at different prices during a specific time period. That phrasing matters. It includes four anchors you can’t ignore:
- Quantity of the commodity
- Willingness to buy
- Ability to buy
- Price of the commodity
- A stated time period
Think about it like system throughput under load: it’s not enough to say the system is “fast.” You need a throughput number at a known concurrency and a defined time window. Demand is the same kind of measurable relationship. You specify a time period and observe how quantity changes when price (and other factors) shift.
Two views matter:
- Individual demand: the quantity one consumer is willing and able to buy at each possible price during a time period.
- Market demand: the total quantity all consumers are willing and able to buy at each possible price during the same time period.
This distinction is a big deal in product analytics. An individual demand curve is how a single customer behaves; market demand is how the whole population behaves. You should not mix the two when making forecasts.
The Demand Function: A Precise Model
The demand function expresses the relationship between quantity demanded and the variables that shape it. I treat it like a dependency graph in code: quantity depends on price, income, tastes, and related goods. When any of those inputs change, output changes.
Individual Demand Function
For one consumer, the demand function can be written as:
Dx = f(Px, Pr, Y, T, F)
Where:
- Dx: demand for commodity x
- Px: price of commodity x
- Pr: prices of related goods (substitutes or complements)
- Y: income of the consumer
- T: tastes and preferences
- F: expectation of future price changes
I like to map this to a product pricing scenario. Suppose you run a subscription service:
- Px is your subscription price
- Pr is the price of a competing service or a complementary add-on
- Y is the user’s disposable income
- T captures preferences, such as a user’s preference for a specific brand or feature
- F captures expectations, like a rumored price hike next month
If price goes up, demand usually goes down. If a competitor drops their price (a related good), demand for your product could fall. If user income rises or preferences shift toward your product, demand could rise. All of those are encoded in the function.
Market Demand Function
For the entire market, you add more variables:
Dx = f(Px, Pr, Y, T, F, Po, S, D)
Where the new terms are:
- Po: size and composition of the population
- S: season and weather
- D: distribution of income
In a marketplace context, population size is your active user base. Season could be holiday demand, and income distribution explains why a price change affects different segments in different ways. I’ve seen this in practice with B2C products: a price rise might not reduce demand in high-income segments but could collapse demand in lower-income segments, making the aggregate response look nonlinear.
Why This Function Matters
A function forces you to be explicit. It’s the difference between saying “demand is strong” and saying “demand is strong because price is low, income is rising, and substitutes are expensive.” That specificity is what you need when deciding pricing, forecasting revenue, or planning inventory.
The Demand Schedule: A Concrete Table
A demand schedule is the simplest way to make demand observable. It’s just a table showing how much quantity is demanded at different prices during a given time period. I like it because it turns abstract relationships into something you can share with stakeholders who don’t want equations.
Individual Demand Schedule
An individual demand schedule shows how one buyer’s quantity changes as price changes. Here’s a clear example:
Quantity Demanded (units)
—
20
21
22
23
24
25This schedule reflects a common pattern: lower price leads to higher quantity demanded. It doesn’t imply “always,” but it reflects typical behavior.
Market Demand Schedule
Market demand is just the horizontal sum of all individual demands at each price. If you have two consumers, A and B, you add their quantities at each price level:
A’s Demand
Market Demand
—
—
20
42
21
44
22
46
23
48
24
50
25
52This is how you build aggregate demand for a product segment. If you’re in a product role, you can generate a market schedule by summing quantities across cohorts or regions.
The Table Is the Product
I treat the demand schedule as an artifact I can share. It’s hard to argue with a table that shows price and quantity side by side. If a team disagrees with the numbers, that’s great — now you have a clear surface to debate assumptions.
From Theory to Implementation: A Simple Demand Model
Sometimes I build a demand schedule directly from a demand function. Here’s a Python example that uses a linear demand function for illustration. It’s intentionally simple, but complete and runnable.
import pandas as pd
A simple linear demand function: Q = a - bP
a = base demand, b = sensitivity to price
def demandquantity(price, basedemand=60, price_sensitivity=2):
# Non-obvious logic: demand cannot be negative
return max(0, basedemand - pricesensitivity * price)
prices = list(range(5, 16)) # 5 to 15
quantities = [demand_quantity(p) for p in prices]
schedule = pd.DataFrame({
"Price": prices,
"Quantity": quantities
})
print(schedule)
This code produces a demand schedule from a function. In real work, I replace the linear function with a calibrated model based on historical data. But the pattern is the same: define a function, then sample it across prices to create a schedule.
If you work in JavaScript, the same idea is straightforward:
function demandQuantity(price, baseDemand = 60, priceSensitivity = 2) {
// Demand cannot be negative
return Math.max(0, baseDemand - priceSensitivity * price);
}
const prices = Array.from({ length: 11 }, (_, i) => i + 5);
const schedule = prices.map((price) => ({
price,
quantity: demandQuantity(price)
}));
console.table(schedule);
The critical point is not the language. It’s the workflow: define the relationship, then convert it into a table you can use for discussion and decision-making.
How Demand Function and Schedule Work Together
I like to think of the function as the “API” and the schedule as the “response payload.” The function is the model; the schedule is the output at specific price points. The function gives you a continuous relationship. The schedule gives you discrete, practical reference points.
Here’s a simple analogy I use with teams:
- Demand function is like a formula in a spreadsheet.
- Demand schedule is the filled-in sheet at a few selected rows.
They are two views of the same reality. If your function is wrong, your schedule will be wrong. If your schedule is noisy or sparse, your function might be overfitted. You need both to cross-check each other.
Common Mistakes I See in Practice
I’ve seen teams make the same errors, especially when they jump straight into pricing changes. Here are the ones I watch for.
1) Ignoring Time Period
Demand is always tied to a time period. I’ve seen teams compare weekly demand to monthly demand and draw the wrong conclusions. If your time window changes, your demand schedule changes even if prices don’t.
2) Mixing Individual and Market Demand
An individual demand schedule might show a steep response to price changes, but market demand might be flatter because other consumers are less sensitive. You should not use individual behavior to predict total market demand unless you account for segmentation.
3) Treating Preferences as Constant
Preferences shift. Product launches, social trends, or competitor improvements can move demand without any price change. If you don’t capture this, your demand function will lie to you.
4) Ignoring Related Goods
A substitute can gut demand even if your price stays the same. A complement can boost demand. For example, an API product might see higher demand when cloud storage prices drop because storage and API usage are complementary.
5) Assuming Linearity
Demand often isn’t linear. At low prices, demand might saturate. At high prices, demand can collapse quickly. I usually start with linear models for clarity, then test for nonlinear patterns with real data.
When to Use a Demand Function vs a Schedule
If you need a quick, explainable artifact, use a schedule. If you need to simulate scenarios or do sensitivity analysis, use a function. In practice, I often create both.
Here’s how I decide:
- Use a demand schedule when you need to communicate price impacts to a product team or executive group.
- Use a demand function when you need to forecast or run simulations under different assumptions.
If you want a full decision workflow, start with a function, generate a schedule, and then validate with real-world experiments.
Real-World Scenarios and Edge Cases
Scenario 1: Subscription Price Change
I once worked on a subscription service where price rose 15%. Our demand schedule predicted a 10% drop in quantity. We were wrong because we ignored expectations: users expected a new feature release with the price change, and demand did not fall as much as predicted. The missing variable was F (expectations). That single variable can flip your forecast.
Scenario 2: Seasonal Demand Spikes
A scheduling product for schools had dramatic demand spikes before each semester. Without including seasonality, the demand function predicted steady growth. The schedule showed a surge only at specific times. Adding season and time period fixed the model.
Scenario 3: Segment Differences
In a marketplace, low-income segments were highly price sensitive, while high-income segments were stable. The aggregate demand schedule was misleading because it averaged two very different behaviors. I now build separate demand schedules by segment and then sum them.
A Practical Modeling Pattern I Recommend
When I build demand models, I follow a short pattern that keeps me honest:
1) Define the time period explicitly (weekly, monthly, quarterly).
2) Identify the key inputs: price, related goods, income, preferences, expectations.
3) Start with a simple function (linear or log-linear).
4) Generate a demand schedule for a set of prices you care about.
5) Validate the schedule against historical data or experiments.
6) Refine the function based on observed gaps.
This pattern helps you avoid being overly confident in the first model and pushes you toward a useful, testable artifact.
Traditional vs Modern Approaches (When You’re a Developer)
If you’re coming from a data or engineering background, it helps to think about how traditional economics modeling compares to modern product analytics. I use this table when explaining it to teams.
Traditional
—
Small surveys or simplified assumptions
Closed-form functions, often linear
Demand schedule tables
Slow, periodic
I don’t recommend abandoning the simple demand function. I recommend starting with it, then layering more data and modeling where it clearly improves accuracy.
Performance and Practical Constraints
In product environments, I care about performance constraints in two ways:
- Data freshness: A demand schedule built on stale data is like a cache with an expired TTL. I aim for weekly updates in fast-moving markets and monthly updates in stable ones.
- Computation cost: If you model demand with heavy ML pipelines, you need to account for training time and monitoring. In practice, a simple function plus a scheduled refresh is usually enough for planning.
If you’re building tools around demand modeling, you can typically generate a new schedule in milliseconds for simple functions, and in seconds for model-based pipelines. The key is to keep the loop tight enough that teams actually use the results.
When Not to Use These Tools
There are times when a demand function or schedule won’t help you:
- If your market is unstable and user behavior changes daily, a static schedule is noise.
- If you don’t have any data or reliable estimates, a function will be a guess disguised as math.
- If your product has network effects, demand can rise as price rises because perceived value changes. Standard functions may fail unless you add those effects explicitly.
In those cases, I recommend experiments and qualitative data before investing in a model.
A Short Example with Realistic Numbers
Suppose you sell a productivity app with a monthly price P. Based on prior experiments, you estimate a demand function:
Q = 1200 – 40P
If you consider prices from $10 to $20, you can build a demand schedule. At $10, Q = 800; at $20, Q = 400. That gives you a clean, readable table. If you also know that a competing app is launching a $12 tier, you can treat that as a related good and adjust the function to reflect competitive pressure.
The point is not to claim a perfect number, but to provide a transparent, testable framework for decision-making.
How to Communicate This to Stakeholders
I’ve learned that demand modeling falls flat if you dump equations on non-technical teams. I use a layered approach:
1) Start with the demand schedule table.
2) Explain the function in plain terms.
3) Show how changing a variable shifts the schedule.
This approach gets buy-in because it gives teams something concrete, then shows the machinery behind it.
Key Takeaways and Next Steps
If you only remember one thing, remember this: demand is a relationship, not a number. A demand function makes that relationship explicit. A demand schedule makes it visible and shareable. Together they give you a way to reason about pricing, inventory, and product strategy with more precision and fewer assumptions.
Here’s how I suggest you apply this right away:
- Pick a single product or feature and define the time window you care about.
- Write a basic demand function with price as the primary variable, then add one or two more factors you know matter.
- Generate a demand schedule at the price points you’re actually considering.
- Compare the schedule against real data or a small experiment, then adjust the function.
That workflow is manageable even for small teams, and it keeps your decisions grounded in observable behavior. I’ve seen it save months of guesswork and make pricing conversations far more productive. If you want, I can help you build a demand schedule from your own data or design a small experiment to calibrate your function.
