Menu Engineering: Which Dishes Actually Earn

What menu engineering is, and who built the matrix

Menu engineering — the joint analysis of dish popularity and contribution margin, used to decide what to keep, reprice, reposition or remove.

The method is not ours and it is not new. It was built by Michael L. Kasavana and Donald I. Smith at the Michigan State University School of Hospitality Business around 1982, and published the same year as Menu Engineering: A Practical Guide to Menu Analysis (Okemos, MI: Hospitality Publications, 1982) — the imprint is independently confirmed by the bibliography of a peer-reviewed study: "Kasavana, M. L., Smith, D. I. (1982). Menu engineering: A practical guide to menu analysis (1st ed.). Okemos, MI: Hospitality Publications" (DETUROPE vol. 14 iss. 1, 2022, pp. 111–127). Kasavana himself restated the attribution and the definitions in The Power of Menu Engineering — Part One, AHLEI, 08.04.2025: the term "refers to a specific restaurant menu analysis initially developed by Michael L. Kasavana and Donald I. Smith at the Michigan State University School of Hospitality Business (circa 1982)".

What the method attacks is stated in the same article in one sentence: "Perhaps the oldest misconception in food service management is that food cost is directly related to profitability." A restaurant does not deposit percentages. It deposits money.

What this page adds is the arithmetic in full — where every axis value comes from, where the two dividing lines come from, and which of your own decisions silently moves a dish from one quadrant to another. The costing of a single portion is not repeated here: that is food cost percentage and plate cost, and the difference between the recipe's cost and the cost you actually incurred is theoretical versus actual food cost. Menu engineering takes plate cost as an input and works on what happens after it.

The two axes, and which number goes on which one

Say it out loud before drawing anything, because reversing the axes is the commonest way to ruin the exercise:

• the horizontal axis is popularity — the share of units this dish took inside its own menu category, a dimensionless share;
• the vertical axis is contribution margin per portion, in cash — złoty, euro, whatever your till counts, and never a percentage.

Contribution margin (CM) per dish — menu price minus plate cost, in currency, for one portion.

Menu mix (MM) share — units sold of one dish divided by total units sold in the same menu category.

Two things follow immediately. First, the categories matter: a starter and a main course are not comparable, because a starter cannot win a share contest against a dish every guest orders. The matrix is computed inside a category — starters against starters, mains against mains, desserts against desserts. Second, both axis values are relative to your own menu. There is no external benchmark for either axis, and this page prints none: the lines are drawn from your own averages, which is exactly what makes the method honest rather than a borrowed number.

The three inputs, and where each one actually lives

Kasavana's article names three data elements: covers sold, menu mix, and contribution margin. In a working restaurant those come from three different places, and mixing up which is which is where the exercise usually stalls.

The period must be identical for all three. A menu mix from March against prices from May produces a matrix that describes no restaurant that has ever existed. If your till exports items but your recipe cards live in a spreadsheet nobody has opened since the last supplier change, the matrix is not blocked — but the vertical axis will be wrong by exactly the amount the cards are stale, and you will act on it. Pulling those two sources into one place is what analytics and dashboards are for; the point of doing it once is that the matrix stops being an annual project.

The horizontal axis: menu mix share and the popularity index

MM share % = Units of dish ÷ Total units in category × 100

• Units of dish — portions of this dish sold in the period, in units;
• Total units in category — portions of all dishes in the same menu category, same period, in units;
• units divided by units is a dimensionless share, and multiplying by 100 reads it as a percentage.

Raw shares are hard to read across categories, because a category with four dishes and a category with twenty behave differently. The method normalises them:

Popularity index = MM share % ÷ (100 ÷ Number of dishes in category)

• MM share % — the share above, in percent;
• Number of dishes in category — how many dishes competed for those units;
• 100 ÷ Number of dishes is the expected equal share, also in percent, so percent divided by percent gives a dimensionless index.

An index of 1.00 means the dish sells exactly like an average position in its category. An index of 2.00 means it sells twice as often as an average position.

The vertical axis: contribution margin in cash

CM per dish = Menu price − Plate cost

• Menu price — the price the guest pays for one portion, net of VAT, in PLN;
• Plate cost — the cost of everything that goes out on that plate for one portion, corrected for yield, in PLN;
• currency minus currency is currency, which is the whole point.

Kasavana's article is specific about what plate cost should contain: food cost including wasted product and product loss, incremental labour for in-house preparation and plating, condiments, and packaging where there is any. Delivery orders therefore do not share a matrix with dine-in, because packaging and platform economics change the plate cost and the price at the same time — that is covered separately in what actually stays with you on an online order.

The second cash number you need is what a dish brought in over the whole period:

Total CM of dish = CM per dish × Units sold

• CM per dish — contribution margin of one portion, in PLN per unit;
• Units sold — portions sold in the period, in units;
• PLN per unit times units is PLN.

This is the number the matrix does not show directly, and the one you will keep coming back to. A dish can sit in the strongest quadrant and still be a rounding error in your month.

Where to draw the two lines, and why a plain average lies

The quadrant boundaries are the whole method, and they are set by your own menu — not by any published norm. There is no official statistic anywhere that says what a good contribution margin per portion is, and this page does not invent one.

The horizontal line: weighted, not plain

Category weighted CM = Σ (CM per dish × Units) ÷ Σ Units

• Σ (CM per dish × Units) — total contribution the category produced, in PLN;
• Σ Units — total portions the category sold, in units;
• PLN divided by units is PLN per portion, which is the same unit as the axis. The line is therefore drawn in the right dimension.

A plain average of the CM column — add up the margins, divide by the number of dishes — is a different number, and it is the wrong one. It gives a dish sold twenty times the same vote as a dish sold four hundred times. The weighted figure answers the question the axis is actually asking: does this dish contribute more or less than the average portion that leaves my kitchen?

This is not an improvement on the method; it is the method. Kasavana writes the contribution-margin rule as "Menu CM / Number of items sold" and works it through on a menu whose total contribution of 3 444.80 dollars over 1 000 items sold gives an average of 3.44 dollars (Kasavana, The Power of Menu Engineering — Part Two, AHLEI, 14.05.2025). Total contribution over total units — the weighted figure, every time.

The vertical line: the method's own seventy percent rule

It carries none of your data at all. Drawing the line there is identical to drawing it at a popularity index of 1.00, and it splits the category near the middle by construction.

The method does not draw it there.

Shifting the line below the equal share is deliberate: it lets the "popular" half also catch dishes selling somewhat under average, rather than only those above it. Note what this coefficient is, though — a setting of the method, not a measured property of your restaurant and not an official norm. Whatever value you use, write it down next to the matrix. A dish moved to another quadrant because someone quietly changed the line is the single easiest way to lose trust in the whole exercise.

One category, five dishes: the matrix computed end to end

The figures below are round teaching numbers, invented for the arithmetic and describing no real restaurant. Substitute your own till export and your own recipe cards; the mechanics are what matters.

The two lines, computed from the table and nothing else

• weighted contribution per portion: 28 420 PLN ÷ 1 000 units = 28.42 PLN;
• expected equal share: 100 % ÷ 5 dishes = 20 %; at the method's seventy percent rule the popularity line sits at 20 × 0.70 = 14 %.

Reading the quadrants off those two lines: A is above both — a star. B sells most of all and contributes 18 PLN a plate, below the line — a plowhorse.

D is below both — a dog. E is above the margin line at 29 PLN and far below the popularity line — a puzzle.

Two readings worth more than the labels

Two things in that table are worth more than the classification itself.

Swap the weighted margin line for a plain average of the CM column (36 + 18 + 48 + 18 + 29, divided by 5, which is 29.80 PLN) and E drops out of the puzzle quadrant into the dog quadrant on 1.38 PLN of arithmetic convention. Neither dish changed. This is why the boundaries are stated, not assumed.

Second, the biggest seller is not the biggest earner. B sold 400 portions and brought 7 200 PLN. C sold 160 — two and a half times fewer — and brought 7 680 PLN. If you only ever look at the sales ranking on your till, C is a marginal dish you might cut and B is untouchable. The cash says otherwise.

Stars: the one thing you must not do to them

A star sells often and contributes well. The correct action is almost entirely negative: protect the recipe, protect the portion, protect the position on the card, and leave the price alone unless the plate cost forces you.

The single thing you must not do to a star is quietly shrink it. It is a star because guests order it repeatedly, which means they know what it looks like when it arrives. Shaving the portion or swapping an ingredient for a cheaper one lifts the margin on paper and moves the dish toward the plowhorse quadrant in reality, because the popularity axis falls. If the plate cost of a star genuinely rises — the supplier moved, the yield changed — raising the price is usually the safer response, and you will see the outcome on the popularity axis at the next recalculation.

A star is also the right place to test a price increase, precisely because you have enough units for the change to be readable. A dish selling twenty times a month tells you nothing about elasticity; a dish selling three hundred times does.

Plowhorses: lifting margin without touching the price

A plowhorse is popular and contributes below the line. It is doing real work — it draws people in and holds the mix together — so removing it is rarely the answer. The order of attack runs from the invisible to the visible:

1. Re-cost the plate. The card may be older than the last three supplier price lists. This is the cheapest fix and it changes nothing the guest can see.
2. Fix the yield. A purchased kilogram is not a plated kilogram; trim, cooking loss and over-portioning all land in plate cost without appearing on any invoice. The mechanics belong to theoretical versus actual food cost.
3. Change the accompaniment, not the hero. The garnish, the side, the sauce quantity — these carry cost and rarely carry the reason the dish is popular.
4. Reprice, last. A plowhorse is popular at its current price, and that price is part of why it is popular.

There is a fifth move that is not on that list and is often better than all of them: sell something alongside it. If a plowhorse reliably comes with a drink or a dessert, its contribution as an order is not its contribution as a dish — see the arithmetic under dogs below, which applies here too.

Puzzles: three tests before you delete anything

A puzzle earns well per plate and barely sells. Before removing it, run three tests, in this order, because they cost nothing and they answer different questions.

1. Is it visible? Position on the card and description carry a large part of the answer. Kasavana's article puts placement, description, layout and typography inside the method itself, not beside it. A dish at the bottom of a long column is not competing on merit.
2. Is it understood? A name that does not say what arrives, or a description that lists ingredients rather than the dish, converts badly regardless of quality. Rewriting the description is free.
3. Is it reachable? Is it available at the times its buyers come, does the team mention it, does it survive the kitchen's own capacity at peak? A dish that gets 86'd every Friday cannot accumulate popularity.

Only when all three have been tried and the index has not moved does removal become the right call. And even then, check the total contribution first: a puzzle with a high CM and a low count is a small amount of money, and removing it frees a line on the card that a better dish can use — which is a real gain, just not the one people usually claim.

Dogs: when a losing dish stays on the card on purpose

A dog sells rarely and contributes little. The default action is removal, and for most dogs the default is right: it occupies a line on the card, a slot in the prep list, and stock that ties up cash.

The exception is real and it has arithmetic. A dish can carry a thin or even negative margin and still pay for itself by dragging profitable items onto the same ticket. That claim has to be measured, not assumed:

Order contribution = CM of the anchor dish + Σ (CM of attached item × Attachment rate)

• CM of the anchor dish — contribution of the dish under suspicion, in PLN per order;
• CM of attached item — contribution of the item that arrives with it, in PLN per unit;
• Attachment rate — units of that item per one order of the anchor dish, dimensionless;
• PLN plus PLN per unit times units per order is PLN per order.

With round teaching figures: an anchor dish contributing −2 PLN, an attachment rate of 0.8 drinks per order, and 12 PLN of contribution per drink gives 0.8 × 12 = 9.60 PLN attached, and −2 + 9.60 = 7.60 PLN per order. The dish loses money and the order does not. Turn it around and you get the test worth writing down: at 12 PLN per drink, the attachment rate that merely covers the 2 PLN loss is 2 ÷ 12 = 0.167. Below that, the story is not true.

The attachment rate has to come from your own tickets — which items actually appear on the same bill — and not from a belief about what guests do. That is a query against your own sales history, which is what a decision engine and scheduled reports exist to run repeatedly rather than once.

Cash, not food cost percentage: what "cut the high food cost items" actually cuts

This is where menu engineering earns its keep, and it is visible directly in the table above.

On the food cost axis they are indistinguishable. On the cash axis they are twelve PLN apart. A ranking by food cost percentage cannot see the difference at all, because it is a ratio and it discards the size of the number it is a ratio of.

Push it further with two dishes and round figures.

To replace one sale of the second dish you would need 44 ÷ 21 = 2.10 sales of the first — and you would need the guests to show up for them.

Kasavana states the same trap plainly: items highest in gross profit "typically are higher priced menu items that almost always fall within the higher end of the food cost percentage scale", and promoting the low-food-cost items "often results in a lower average check and lower gross profit".

None of this makes food cost percentage useless. It is the right tool for a different question — how much of your sales goes to product, tracked over time, on which food cost percentage is the page. It is simply the wrong axis for choosing between two dishes, and what is left at the very bottom after everything else is restaurant profit margin. Three questions, three indicators, and menu engineering answers only the middle one.

Dishes that only sell inside a set

Lunch sets, tasting menus and event packages break the matrix in a specific way: the till records one line at one price, but the kitchen produced two or three dishes, and each of those dishes also exists on the à la carte card with its own price and its own popularity. Ignore the sets and both axes go wrong — the components look less popular than they are, and their margin looks better than it is.

The set has its own contribution, which is straightforward:

Set CM = Set price − Σ Plate cost of components

• Set price — what the guest pays for the set, net of VAT, in PLN;
• Σ Plate cost of components — the plate costs of every dish inside it, in PLN;
• currency minus currency is currency.

To put the components back on the matrix, the set price has to be split between them, and the defensible split is by their à la carte prices:

Component allocated price = Set price × (Component à la carte price ÷ Σ à la carte prices of all components)

• Set price — the set price, in PLN;
• Component à la carte price — that dish's own price on the card, in PLN;
• Σ à la carte prices — those prices added up, in PLN;
• PLN times a dimensionless ratio is PLN, and the allocations add back to exactly the set price.

Round teaching figures: a set at 60 PLN containing a soup priced 18 PLN à la carte and a main priced 52 PLN. The prices sum to 70, so the soup takes 60 × 18 ÷ 70 = 15.43 PLN and the main takes 60 × 52 ÷ 70 = 44.57 PLN — 60.00 PLN exactly. With plate costs of 5 and 21 PLN, the components contribute 10.43 and 23.57 PLN, and their sum is 34.00 PLN, which equals 60 − 26. The split moved the money between components; it did not create or destroy any.

Their units, meanwhile, count once each in their own categories. Event and banquet menus follow the same logic but with a different cost base again, which is why quoting an event from the first phone call is treated as its own workflow.

GUS cuts gastronomy revenue four ways, and the finest cut is a voivodeship, not a dish

There is a fair question hiding behind this whole page: if the matrix has no external benchmark, does official statistics offer one? It does not, and it is worth seeing exactly how far off it is.

Poland's statistical office publishes gastronomy revenue once a year in its internal-market series.

Two things about that figure before anyone divides by it: it covers all entities, not just larger firms, and the publication's own definition states the figure is reported together with VAT. It is therefore not a net-sales denominator.

The same publication slices that revenue four ways, and all four have to be named or this page's claim stops being exact.

If you cook in Warsaw, that last cut is the nearest official figure that touches your own market at all: close to a third of the revenue booked by Poland's larger gastronomy firms sits in Mazovia. Worth knowing about the market you compete in. It is not a target for anything on your menu, and it cannot become one.

That is the whole point — and the exact version of it is sharper than "nobody has these numbers". Your units-sold count is no secret from the state at all. A Polish fiscal receipt has to name each item so it can be identified unambiguously, print its unit price, and print the quantity together with the total value sold of that item — § 25 ust. 1 pkt 6–8 of the Minister of Finance regulation on cash registers of 29.04.2019, Dz.U. 2019 poz. 816 for registers with an electronic or paper copy, and § 23 ust. 1 pkt 9 lit. a of the technical-criteria regulation of 28.05.2018, Dz.U. 2018 poz. 1206 for the online registers that replaced them. And those online registers report upward: the head of the National Revenue Administration runs the Centralne Repozytorium Kas — a system for receiving and collecting data from cash registers, including the sales data recorded in the statutory sales record — and the registers transmit to it directly, continuously and automatically (Value Added Tax Act, art. 111a ust. 1–3, consolidated text Dz.U. 2025 poz. 775). Item-level unit counts therefore do leave your restaurant, from every online register in Poland.

What does not happen is publication. The same article opens that repository to the finance minister and to the tax and customs-and-fiscal offices, and to nobody outside them (art. 111a ust. 4), and no published statistic comes anywhere near a line on a menu: the most granular official view of Polish gastronomy revenue is a voivodeship, spread across roughly a hundred thousand outlets. The other axis is not collected at all — contribution margin and plate cost are built out of your recipes and your purchase prices, and they exist nowhere outside your own kitchen. Both axes of your matrix are therefore your own data by necessity, not by preference, and for two different reasons: one is gathered by the state and never released, the other is gathered by nobody. A page that tried to derive a dish-level target from public numbers would be inventing it. The same limitation applies one level up, on restaurant profit margin and its missing benchmark.

One usable signal does come out of that breakdown: alcohol and tobacco are resold goods, not production, and they behave differently on both axes. Keep them in their own category on the matrix rather than mixed with food.

Both axes move, at different speeds: what Eurostat price indices show

A matrix is a photograph, and both axes drift. CM = Menu price − Plate cost has an input on each side, and in Poland those two inputs have not moved together at all.

Harmonised annual average rates of change for Poland (Eurostat, prc_hicp_aind, updated 06.02.2026):

These are consumer price indices, not your invoices — they describe the whole Polish market, not your suppliers, and menu prices in the index include everyone's menus. But the pattern is the argument: the gap between what food costs and what menus charge has changed size every year and flipped sign once, in 2023, when food outran menus by 1.8 points. A matrix built on any one year's numbers was describing different arithmetic the following year.

So the honest answer to "how often" is not a calendar interval, and this page will not invent one. Recompute when an input changes:

• a supplier price list arrives that moves plate costs materially;
• you change menu prices, on any dish;
• the seasonal card comes in or goes out;
• a stock count closes and the actual cost turns out to differ from the theoretical one;
• the mix itself shifts — a new dish lands, or an old one starts or stops selling.

Every one of those is an event with a date attached, which is precisely why the recalculation belongs to whatever already holds your sales and your costs rather than to a spreadsheet somebody rebuilds by hand. Restaurants running more than one site hit this first, because five triggers become fifteen — the mechanics of keeping that on one screen are covered in running several locations from one screen, and the forward-looking half of it in forecasting and scenario modelling.

What the matrix does not see

The method is narrow on purpose, and knowing the edges keeps you from over-reading it.

• Kitchen capacity. Two dishes with identical contribution can occupy the same station for two minutes or twelve. At peak, that difference decides your actual output, and it is nowhere on the matrix.
• Shared ingredients. Deleting a dog can strand a product that only that dog used, turning a small margin gain into waste. Check what leaves with it.
• Guest sequence. The matrix scores dishes, not visits. A dish that is the reason a table books at all outscores its own row.
• Fixed costs. Contribution margin covers rent and salaries; it does not include them. A menu that is all stars can still lose money at low volume.
• Price elasticity. The matrix tells you where a dish is now, not what happens when you move its price. Only the next recalculation answers that.
• Data quality. Modifiers sold as open items, voids never recorded, staff meals rung through the till — every one of those distorts an axis, and none of them announce themselves.

The matrix is a decision aid for one question: given what my guests already chose and what my recipes already cost, where should I look first. Answered honestly and recomputed on real triggers, it is the highest-yield hour in restaurant management. Treated as a verdict, it will confidently tell you to delete the dish that fills the room. Where it fits among your other numbers is laid out across the restaurant section, and the plumbing that keeps the inputs current sits in finance and restaurant automation — including the plain question of which numbers an owner actually looks at.

Frequently asked questions

What is menu engineering?

Menu engineering is the joint analysis of how often each dish sells and how much cash margin each sale contributes, used to decide what to keep, reprice, reposition or remove. It was developed by Michael L. Kasavana and Donald I. Smith at Michigan State University around 1982. Every dish is placed on a two-axis grid — popularity horizontally, contribution margin in currency vertically — and each of the four resulting quadrants carries a different action.

What are stars, plowhorses, puzzles and dogs?

They are the four quadrants of the menu engineering matrix, named in the original method. A star sells often and contributes well: protect it. A plowhorse sells often and contributes below average: re-cost the plate and fix the yield before touching the price. A puzzle contributes well and rarely sells: check its visibility, its name and its availability before removing it. A dog does neither: remove it, unless you have measured that it pulls profitable items onto the same ticket.

Should the axis be contribution margin or food cost percentage?

Contribution margin in currency. Food cost percentage is a ratio and discards the size of the number underlying it, so two dishes with identical food cost percentages can contribute very different amounts of cash per plate. Dishes with the highest gross profit are usually the higher-priced ones, which typically sit at the higher end of the food cost percentage scale — so ranking by that percentage systematically favours cheap dishes with thin margins.

How do I set the boundaries between quadrants?

From your own menu, not from any published norm. The margin line is the weighted average contribution per portion: total contribution of the category divided by total units of the category, which gives currency per portion, the same unit as the axis. The popularity line uses the method's own rule — a dish counts as popular when its share reaches seventy percent of the equal share, that is 100 % ÷ number of dishes × 0.70. Both lines are computed from your own sales; the seventy percent is a setting of the method, and it belongs written down next to the matrix.

How often should a restaurant redo menu engineering?

There is no universal interval, and any specific one would be invented. Recompute on events instead: a supplier price list that moves plate costs, any change to menu prices, a seasonal card coming in or out, a stock count that reveals actual costs differing from theoretical, or a visible shift in the sales mix. Polish price data shows why a calendar fails — food and restaurant prices have moved at different annual rates every year, and the gap between them has even changed sign.

What do I do with a popular dish that has a thin margin?

Work from what the guest cannot see toward what they can. Re-cost the plate against current supplier prices, then check the yield, because trim and cooking loss inflate the real cost without appearing on any invoice. Then change the accompaniment rather than the element people order the dish for. Repricing comes last: the dish is popular at its present price, and that price is part of why.

Is it right to remove every dish with a high food cost?

No, and it is one of the more expensive rules in the trade. A dish at 45 % food cost selling for 80 PLN contributes 44 PLN a plate; a dish at 30 % food cost selling for 30 PLN contributes 21 PLN. Cutting the first to protect a percentage removes more than twice the cash per sale, and you would need roughly 2.1 sales of the cheaper dish to replace one of them. Decide on contribution in money, then check the percentage as a separate diagnostic.

How do I handle dishes that only sell as part of a set?

Count the units in their own categories, and split the set price between the components in proportion to their à la carte prices, so the allocations add back to exactly the set price. Then subtract each component's plate cost to get its contribution inside the set. The set as a whole also has its own contribution — set price minus the plate costs of everything in it — and it belongs on the matrix as its own line, since guests choose it as one item.

Bring your own till export and your own recipe cards, and the matrix stops being a workshop exercise and starts being a weekly reading of where your money actually comes from.