CULINARY STRATEGY & MENU ENGINEERING

MENU DEVELOPMENT

A menu is not a list of dishes. It is a financial document, an operational plan, and a brand statement — all on one page. I work with restaurants and hotel F&B programs to build menus that perform: dishes that are correctly priced, operationally executable, and coherent with the concept they represent.

SERVICE COMPONENTS

CONCEPT ALIGNMENT

Every dish on the menu should be answerable to the same question: does this belong here? I audit existing menus — or build new ones from the ground up — against the concept's identity, target guest, and competitive positioning.

MENU ENGINEERING

Profitability and popularity are not the same metric. Using a structured engineering framework, I identify which items are carrying the menu and which are costing more than they return.

SEASONAL CALIBRATION

I build seasonal rotation logic into every program — not as an afterthought, but as a structural discipline.

PRICING STRATEGY

Pricing is psychology as much as arithmetic. I develop pricing structures that protect margin without signaling the wrong things to the guest.

RECIPE DEVELOPMENT & COSTING

I develop recipes with full cost breakdowns, yield calculations, and mise en place specifications ready for kitchen implementation.

WHO THIS IS FOR

Hotel restaurants transitioning concepts or repositioning
Independent restaurants with menus that have grown without strategy
New openings building a culinary program from scratch
F&B directors who need an outside perspective before a seasonal reset

THE MENU IS WHERE CULINARY VISION AND FINANCIAL DISCIPLINE MEET. I MAKE SURE BOTH SHOW UP.

REQUEST AN ADVISORY REVIEW

FREQUENTLY ASKED QUESTIONS

What is menu engineering, and how is it different from menu design?

Menu design concerns layout, typography, and sequence: how the menu looks and reads. Menu engineering concerns economics: what each item contributes in margin, how often it sells, and what the combination of the two does to the operation's profitability. Every item falls somewhere on that grid. High-margin items that sell well should be protected and positioned. High-margin items that sell poorly need repositioning or better description. Popular items with thin margin need reworked specifications, portioning, or price. Low-performing items on both axes should usually be removed. The discipline is that decisions follow contribution margin per item and actual mix data, not the chef's preference or the owner's attachment to a dish.

How often should a restaurant menu be updated?

Structural review once or twice a year; tactical calibration far more often. A full rebuild, meaning rewriting the architecture of the menu, its categories, and its price ladder, is disruptive and should not be done casually. But item-level review against sales mix and cost movement should happen monthly, and seasonal calibration two to four times a year depending on the concept and the market. Hotel restaurants with multiple dayparts and banquet obligations usually work on a longer structural cycle and a shorter tactical one. The failure mode I see most often is the opposite of change fatigue: a menu that has not been costed in two years while every input on it has moved.

What food cost percentage should a menu target?

The honest answer is that the percentage is an outcome, not a target, and fixating on it produces bad decisions. What matters is contribution margin in dollars against the cover count and the labor required to produce the dish. A thirty-eight percent item that sells constantly and takes ninety seconds to plate can be more valuable than a twenty-four percent item that sells rarely and consumes a station. That said, useful ranges exist: most full-service concepts operate between twenty-eight and thirty-five percent, steak and seafood-driven menus run higher by design, and hotel breakfast operations behave differently again. The number to watch is variance. A food cost that swings four points week to week signals a systems problem, not a menu problem.

How do you price a menu without losing guests?

By pricing against value perception and competitive position rather than a uniform multiplier applied to cost. A blanket markup produces items that are indefensibly expensive next to items that are quietly unprofitable. The work is to build a price ladder of entry, core, and anchor items within each category, so the menu guides the guest toward the items you want to sell while making the range feel coherent. Price sensitivity is not uniform across a menu: guests hold sharp reference prices for familiar items and almost none for composed or signature dishes. Increases are also sequenced rather than applied at once, and paired with visible changes to plate, portion, or presentation so the guest receives something in exchange.

How many items should a menu have?

Fewer than most operations carry. The constraint is not aesthetic, it is operational: every additional item adds a prep task, a storage requirement, a spoilage risk, a training obligation, and a station complication during service. The correct size is the number your kitchen can execute consistently at peak volume with the brigade you actually employ, not the one you wish you had. In practice, most struggling menus I assess carry twenty to thirty percent more items than the sales mix justifies, with a long tail of dishes contributing almost nothing while consuming disproportionate prep and inventory. Cutting that tail usually improves execution speed, waste, and consistency before a single recipe is reworked.

How do you develop a menu for a hotel restaurant with multiple dayparts?

By designing across dayparts rather than treating them as separate menus that happen to share a kitchen. Breakfast, lunch, dinner, in-room dining, and banquet typically draw from one production kitchen and one prep team, so the leverage comes from shared components: a stock, a sauce, a braise, a dough that appears in several contexts under different presentations. That reduces prep hours, tightens inventory, and improves consistency. Each daypart still needs its own economic logic, because hotel breakfast is often contractually included and behaves nothing like an a la carte dinner. The sequencing question, what the kitchen is producing at four in the morning versus four in the afternoon, usually determines whether the plan is realistic.

What does recipe costing involve, and why do most operations get it wrong?

Proper costing means every recipe carries a yield, a specified portion, and a current price for each component, including the ones people skip: trim loss, cooking loss, oil, garnish, and the sub-recipes buried inside a dish. Most operations get it wrong in three predictable ways. They cost from purchase price rather than yield, which understates true cost on anything trimmed or reduced. They cost once and never revisit, so the numbers drift as markets move. And they cost the plated dish while ignoring the sub-recipes that feed it, which hides cost inside stocks, sauces, and doughs. A costing system is only useful if it is maintained, which is why it is built as a system rather than a spreadsheet delivered once.

Can you develop a menu that works with our existing kitchen and team?

That is the requirement, not a constraint to work around. A menu is a set of instructions to a specific kitchen with specific equipment and a specific brigade, and a menu that ignores either fails in service regardless of how well it reads. Development therefore begins with what the kitchen can actually produce: available equipment and its real capacity at peak, station count and layout, skill level across shifts, prep capacity in the hours available, and storage. Where ambition genuinely exceeds capability, the honest options are to change the dish, invest in equipment or training, or accept inconsistency, and I will say which one applies rather than deliver a menu that only works when the executive chef is personally on the line.

How do you handle seasonal menu changes without disrupting service?

By changing components rather than rebuilding the menu, and by sequencing the rollout. Seasonal calibration should touch a defined portion of the menu while the architecture, the price ladder, and the core signature items stay stable. Each new item needs its recipe, cost, and plate specification finished before it reaches the line, and the team needs to have produced it in a training environment before a guest orders it. Rollout is staged rather than simultaneous: a small group of items at a time, with the previous version running until the new one is executing cleanly. Most seasonal disruption I see is not caused by the new dishes but by the decision to launch fourteen of them on the same Tuesday.

How long does a menu development project take?

Typically six to twelve weeks from first analysis to a stabilized menu in service. The first phase is diagnostic: sales mix, item-level contribution, current costing, kitchen capability, and competitive position. The second is development: concept alignment, item construction, testing, costing, and pricing. The third is implementation, which is where most menu projects fail: training, plate specifications, station adjustments, prep sheets, and support through the first weeks of live service. Compressing the third phase to save time reliably wastes the first two. Timelines run longer for multi-outlet operations and hotel programs with several dayparts, and shorter for a focused calibration of an existing menu.

How do you measure whether a new menu is working?

Against item-level data, not overall impressions. The primary measures are contribution margin per item and per cover, sales mix against forecast, food cost percentage and its week-to-week variance, and average check. Operational measures matter equally: ticket times at peak, waste and spoilage by category, and prep hours required to support the menu. There is also a stabilization curve to respect: a new menu almost always shows elevated waste and slower tickets in the first two weeks as the team builds muscle memory, and judging it in that window produces the wrong conclusion. Meaningful measurement starts around week three and compares against the pre-launch baseline captured during the diagnostic.