Menu Engineering for Restaurants: Which dishes make your money and which don't.

Menu engineering is the process of analysing every item on your menu in two key ways: how popular it is, and how much gross profit it actually generates. Most operators know roughly which dishes sell well. Far fewer know which ones are making them money.

The framework uses a four-quadrant matrix to classify every item as a Star (high popularity, high margin), Plowhorse (high popularity, low margin), Puzzle (high margin, low popularity), or Dog (low on both). Once you can see your menu that way, the decisions become obvious.

Done properly, menu engineering can shift your food cost percentage by 3–5 percentage points without changing a single item or raising a single price, because it shows you exactly which dishes to promote, reprice, improve, or remove.

There is nothing like the buzz of a busy service. The chef is excited because two key dishes are flying out. Tables are ordering them all night. The floor team loves selling them. Meanwhile, somewhere in the back office, the owner is doing the maths and realising that one of those dishes might actually be costing the business money every time it leaves the kitchen.

That gap, between what sells and what actually makes money, is what menu engineering is designed to close.

In most hospitality businesses, the people who pick the dishes and the people who check the margins are having separate conversations. Chefs think in terms of what they love and what sells. Operators also want the sales, but they rightly worry about what a dish costs. Menu engineering is the process that connects those two conversations, and turns a menu from a list of what the kitchen makes into a tool used to consistently improve performance and profitability.

This guide covers the full framework: the four-quadrant matrix, how to calculate menu item profitability, the steps to build your own analysis, why most operators get it wrong, and why the whole thing depends on accurate recipe costing.

What is menu engineering for a restaurant?

Menu engineering is the systematic analysis of every item on your menu by two variables: how often it sells (popularity) and how much gross profit it generates per serve (profitability). By plotting every item on a simple matrix, operators can see at a glance which dishes are making money, which are popular but under-priced, which are profitable but underselling, and which should be rethought or removed.

The framework was developed in the 1980s by Michael Kasavana and Donald Smith at Michigan State University and has been used by restaurants worldwide ever since. In practice it is less of a theoretical exercise and more of a straightforward analysis that any operator can run so long as they have accurate recipes and pricing and a few weeks of sales figures.

The reason menu engineering matters is that most menus aren't designed to maximise gross profit. They are designed around what the kitchen can produce, what the chef wants to cook, and what customers have historically ordered. None of those inputs necessarily aligns with what generates the most profit per cover. Menu engineering is how you bring those inputs into alignment.

The difference between menu engineering and menu design is worth being clear about: menu design is about how the physical or digital menu looks and what it directs customer attention towards. Menu engineering is about the profitability and popularity analysis that determines which items should be getting that attention in the first place. They inform each other, but they are not the same exercise.

What are the four categories in the menu engineering matrix?

The menu engineering matrix classifies every menu item into one of four quadrants, based on whether it sits above or below your menu average on two measures: popularity (units sold as a percentage of total covers) and profitability (or margin per serve, the menu price minus the food cost).

Stars — high popularity, high margin.

Stars are the dishes your business depends on. They sell consistently, they generate strong margin on every serve, and they anchor the menu's profitability. Protect your stars! Keep the recipe tight, maintain the quality, and don't change them without careful thought. Feature them prominently on the menu and make sure your floor team knows to sell them. The job with a Star isn't to improve it, it's to make sure nothing erodes what makes it work.

Plowhorses — high popularity, low contribution margin.

Plowhorses fill covers but don't generate enough margin. They're popular because they're priced accessibly or because they've become a habit for regular customers. The opportunity with a Plowhorse is to either raise the price modestly (popularity means customers are likely to absorb a small increase), reduce the food cost by adjusting portion or recipe, or both. Handled carefully, a Plowhorse can become a Star. The conversation with the kitchen is sometimes uncomfortable, but the financial upside is almost always worth it.

Puzzles — low popularity, high contribution margin.

Puzzles make strong margin every time they sell, but not enough people order them. The fix might be the dish itself, but it's often worth looking at how it's positioned. Renaming a Puzzle with more descriptive language, moving it to a prime position on the menu, or training your floor team to recommend it as a suggestion can move a Puzzle into the Star quadrant without changing a recipe or a price.

Dogs — low popularity, low contribution margin.

Dogs are a drag on your business — they should be removed from the menu unless there is a specific operational or brand reason to keep them. A Dog takes up real estate on your menu, adds complexity to the kitchen, and generates little revenue or margin. The most common reason restaurants keep Dogs is habit. A regular who orders one specific dish keeps it alive, even as it costs the business on every other cover. Be honest about Dogs.

I'll be honest, one of our earliest restaurants kept a chicken and mushroom risotto on the menu for years longer than it should have, because I used to order it 2–3 per week for lunch. I didn't think it was much of a big deal, but the reality was it was stopping our kitchen team having the space to try something new that could have turned into our next star.

The strategic framework is simple: Protect Stars. Improve Plowhorses. Promote Puzzles. Remove Dogs.

How do you calculate menu item profitability?

Menu item profitability is calculated using margin — the gross profit a dish generates per serve, before labour and overhead.

Contribution margin = Menu price (ex. GST) minus food cost per serve

So a dish priced at $30 excluding GST, with a food cost of $9 per serve, has a contribution margin of $21.

To place that item correctly in the matrix, you also need its food cost percentage:

Food cost % = (Food cost ÷ Menu price) × 100

$9 ÷ $30 × 100 = 30%

‍

A food cost percentage below your menu target (typically 28–32% for food in a full-service venue in Australia, or 25–28% for quick-service) indicates the item is contributing well on margin. Above that target, it's a candidate for the Plowhorse or Dog quadrant.

The key data you need for every item:

• Menu price (excluding GST)
• Accurate recipes
• Food cost per serve (the cost of all ingredients in the recipe at current purchase prices)
• Menu sales for the period

That last point is where most operators hit problems. Calculating food cost per serve requires knowing the actual cost of every ingredient at the price you are currently paying, not the price you were paying when the recipe was written. If your recipes haven't been updated since your last supplier price review, your food cost data is out of date — and an item you think is a Star might already be a Plowhorse without you knowing it.

How do you build a menu engineering analysis step by step?

Here is the practical process for running a menu engineering analysis on your current menu.

Step 1: Pull your sales data. Export a sales report for the period you want to analyse. Four to eight weeks gives a reliable picture of normal trading patterns. You need item-level sales counts for every menu item.

Step 2: Update your recipe costs. For every item on the menu, calculate the food cost per serve using current ingredient prices from your most recent invoices. If you have recipe management software, this should update automatically when purchase prices are entered. If you are working from spreadsheets, update them now before running the analysis. Using stale or old purchase costs will produce inaccurate category placements — the most common and most costly mistake in menu engineering.

Step 3: Calculate contribution margin per item. Menu price (ex. GST) minus food cost per serve = contribution margin. Do this for every item.

Step 4: Calculate each item's popularity score. Divide each item's unit sales by total item sales across the period, expressed as a percentage. The menu average is the dividing line between high popularity and low popularity.

Step 5: Calculate your average contribution margin. Add all items' contribution margins together and divide by the number of items. This is the midpoint for the profitability axis.

Step 6: Plot the matrix. Items above the popularity midpoint and above the margin midpoint = Stars. Above popularity, below margin = Plowhorses. Below popularity, above margin = Puzzles. Below both = Dogs.

Step 7: Make decisions by category. Stars: protect and feature. Plowhorses: reprice, reduce cost, or both. Puzzles: reposition and promote. Dogs: consider removal or rework.

Step 8: Implement and track. Make the changes, run the same analysis in six to eight weeks, and check whether Plowhorses have moved toward Star territory and Dogs have been cleared. Menu engineering is a cycle, not a one-off exercise.

What mistakes do most restaurants make with menu engineering?

The most common failure in menu engineering isn't the analysis, it's the info going into it.

Menu engineering only produces accurate results when your recipe costs reflect what you are currently paying for ingredients. Most operators know what they paid for beef at the start of the year. Fewer know that the price has moved twice since then, and the recipe in their system still reflects the original figure.

When supplier prices change without being updated in your recipe management system, every cost-dependent calculation on your menu drifts. A dish classified as a Star at 28% food cost might actually be running 34%, close to the range where it becomes a Plowhorse. You're still featuring it. Your floor team is still selling it. And every time it goes out, you're making less than you think.

For operators running multiple venues, this compounds quickly. Each venue may be receiving slightly different prices from the same supplier depending on who is placing the order and what was negotiated locally. When you run a group-level menu engineering analysis against old recipe costs, you're averaging across inaccuracies at every site.

The second most common failure is treating the analysis as a one-time project. Menu engineering is a seasonal practice. Ingredient prices move, customer ordering patterns shift with the season, and a dish that was a Star in summer may behave as a Plowhorse in winter when the relevant produce costs peak. Operators who use it most effectively run the analysis at least quarterly, and use a live recipe costing platform that updates whenever a purchase price is entered.

The third failure: acting on the Dogs before the Plowhorses. Removing a Dog feels like progress. Reworking a Plowhorse is harder because it usually involves a conversation with the kitchen about portion, recipe, or pricing. But the margin opportunity in a high-volume Plowhorse almost always exceeds the gain from removing a low-volume Dog. Work the Plowhorses first.

Why do most operators think their bestsellers are their most profitable dishes?

They're not, and this assumption is one of the more expensive mistakes we made when we first started out in hospitality.

Popularity and profitability are different measures. An item can sell in every single service and still cost you money if the margin per serve is below your target. Not cost you money, in that you are spending more to make the item than you are selling it for, but cost you money in the fact those customers could have been purchasing something that contributed more to the bottom line. The Plowhorse category exists because this is so common.

In a full-service restaurant, the Plowhorse problem typically shows up in one of these forms:

A protein-heavy main that's been on the menu for years. It's a crowd favourite, it moves volume, and the price hasn't been raised in 18 months. Input costs went up, you absorbed them, and the contribution margin is now $4 less per serve than it was when you set the price. At 80 covers a night, five nights a week, that's $1,600 a week in margin you're not capturing.

A shared starter that two-thirds of tables order. It's been repriced once in three years. The kitchen has gradually increased the portion size to improve the presentation, meaning the food cost is higher than the recipe card shows. Nobody noticed because everyone was focused on how good the dish looked.

A "value" item designed to bring in groups or lower the average spend threshold. It's priced to be accessible, it sells well, and it occupies kitchen time that could go toward a higher-margin dish.

None of these feel like problems when you're busy. They become visible when you run the numbers.

This is why accurate, current recipe costs are the foundation of menu engineering. An analysis run on old or stale recipe data will tell you your Plowhorses are Stars, your Dogs are Puzzles, and everything is fine. It isn't. The numbers just haven't caught up yet.

How often should you run a menu engineering analysis?

I know you are busy, but ideally run a menu engineering analysis every time you change your menu, and at least once per quarter between menu changes.

In practice, the most important trigger isn't calendar-based, it's price-based. When a key ingredient increases in price, the menu items using that ingredient may shift categories without any change to the physical menu. A beef dish that was a Star at $13/kg might become a Plowhorse at $17/kg. If your recipe costs don't update when the purchase price changes, the shift is invisible until you run a fresh analysis against updated data.

For operators using Loaded, recipe costs update automatically when purchase prices are entered, meaning your contribution margin data is always current. A weekly view of your top-selling items shows any cost drift before it compounds across a full quarter's worth of service.

For operators working from spreadsheets, quarterly is the practical minimum. The risk: by the time you run the analysis, you've spent two months operating with category placements that no longer reflect what's actually happening.

A practical approach that works: schedule a full menu engineering review at the start of each season (four times per year), and manually check the contribution margins on your top 10 selling items monthly. Those are the items where a margin shift will have the greatest financial impact, so they deserve a more frequent check than the rest of the menu.

How does live recipe costing change what's possible with menu engineering?

The manual version of menu engineering — POS export of sales, enter into a spreadsheet, 90 minutes of calculation — has been available to operators for decades. The problem has never been the framework. It's been how manual and painful it is.

Recipe costing requires accurate, current ingredient prices. In a manual system, updating those prices means someone needs to enter each supplier invoice and check it against the recipe. In a busy kitchen with daily deliveries from five or six suppliers, that process usually falls behind. Recipe costs move, the analysis runs on old data, and the categories it produces become less reliable over time.

When a specifically designed hospitality management platform connects your POS sales data, your purchase price history, and your recipe costs in the same system, the analysis reflects reality rather than history. A menu item's contribution margin updates when a new supplier invoice comes in. You can see, at any point, how each dish is performing against your food cost target.

For multi-venue operators, this matters even more. When you're running five venues and each is receiving slightly different prices from the same supplier, a group-level menu analysis is only accurate if the recipe costs at each site reflect the prices that site is actually paying. Without a centralised system connecting purchase prices to recipes across every venue, a group analysis tends to use averaged or estimated figures that mask the variance between sites.

Loaded's recipe costing connects live purchase prices to every recipe across your group. When you run a menu engineering analysis, the food cost figures reflect this week's delivery at each site, not a quarterly average or last year's supplier agreement. For operators who want to use their menu as a profit management tool rather than a design exercise, that's the foundation the whole framework requires.

To see how Loaded's recipe costing and GP reporting work together, book a free 30-minute demo. Just a practical conversation about your menu and your numbers.

Frequently Asked Questions

What is menu engineering in simple terms?

Menu engineering is the process of categorising every item on your menu by two measures: how often it sells, and how much gross profit it generates per serve. Items fall into one of four categories: Stars (sell well, high margin), Plowhorses (sell well, low margin), Puzzles (high margin, sell poorly), and Dogs (low on both). The aim is to protect your Stars, improve your Plowhorses, promote your Puzzles, and remove or rethink your Dogs.

How do you calculate menu item profitability?

Menu item profitability is calculated using contribution margin: menu price (excluding GST) minus food cost per serve. A dish priced at $30 with a $9 food cost has a $21 contribution margin and a 30% food cost percentage. To run a full analysis, you need this figure for every item, combined with unit sales data from your POS.

What are Stars, Plowhorses, Puzzles, and Dogs in menu engineering?

These are the four quadrants of the menu engineering matrix. Stars are high-popularity, high-margin items to protect and feature. Plowhorses are popular but low-margin — reprice or reduce cost. Puzzles are high-margin but underselling — promote and reposition. Dogs are low on both — candidates for removal.

Why does menu engineering fail without accurate recipe costing?

Because menu engineering classifies items based on their food cost per serve. If your recipe costs haven't been updated since ingredient prices last moved, an item's true food cost is higher than your system shows, and its contribution margin is lower than you think. A dish you classify as a Star may already be a Plowhorse. Accurate, real-time recipe costing is the foundation menu engineering requires to produce reliable results.

What is a good food cost percentage for a restaurant in Australia?

Most full-service restaurants in Australia target a food cost percentage of 28–32% of food revenue. Quick-service venues typically aim for 25–28%. These are starting points — venue type, concept, and menu mix all affect the right target for your business. The more useful benchmark is consistency: if your food cost percentage is moving week to week on the same menu without a clear reason, the cause is usually recipe cost drift, yield variance, or portioning issues.

How often should I do a menu engineering analysis?

At minimum, every time you change your menu, and at least quarterly between changes. The most important trigger is a significant ingredient price move: when a key input increases in cost, the items using it may shift categories without any physical menu change. Operators using live recipe costing can run the analysis continuously. Operators on spreadsheets should schedule it quarterly and check their top 10 selling items monthly.

How do I use menu engineering across multiple venues?

Menu engineering across multiple venues requires recipe costs that reflect the actual prices each venue is paying, not a group average. The practical step is centralised recipe management — one master set of recipes that updates when any site's purchase prices change — combined with POS data from every site in a single view. Without centralised recipe management, a group-level analysis tends to mask variance between sites behind averaged figures.

What is the difference between menu engineering and menu design?

Menu design is about how the physical or digital menu looks — layout, typography, imagery, section order, and how it directs the customer's attention. Menu engineering is the profitability and popularity analysis that determines which items should be getting that attention. They are related: menu design can promote a Puzzle into a Star by changing how it's presented. But the analysis that tells you which item deserves that treatment is menu engineering, not design.