What You're Actually Paying For When You Hire Product Insight

If you're reading this, you're probably trying to figure out whether we're worth the money. That's a fair question to ask out loud, and most firms make you guess at the answer. We'd rather just tell you.

The honest version takes a minute, because the number on the invoice is not the most useful number in this conversation. The useful number is the one attached to the decision the invoice is informing. Once you can see both, the math becomes pretty simple, and so does the question of whether to call us.

The decision you're already making, even if you haven't named it

Here's what's usually happening when a company starts thinking about hiring us. There's a build, an automation push, or a transformation on the table. There's a team excited about it, a budget being scoped, vendors being lined up. The energy is on execution. The conversation in the room is some version of how do we do this well.

The conversation that isn't happening, usually, is: should we be doing this at all, in this form, in this order? That question gets answered by default, by whoever framed the brief first. It rarely gets revisited, because once a program is named and funded, the team has every reason to defend the scope. And almost no permission to challenge the premise.

This is the chair we're hired to sit in. Not the execution chair. The one earlier, before the brief is locked, when the decision is still genuinely fluid. The chair where someone holds the customer reality, the technology reality, and the manufacturing reality at the same time, and is allowed to say "this isn't the right thing to build" if that turns out to be true.

Most companies don't fill that chair. Engineers are excellent at can we build it. Industrial designers are excellent at will people use it. Strategists are excellent at should we build it. All three are necessary. None of them is paid to ask whether you're solving the right problem in the first place. That's the gap we fill, and it's the only gap we fill. That position is the whole reason the math works the way it does.

What it looks like when the chair is empty

When nobody sits in that chair, the failure mode is consistent, and it's seldom a technology failure.

The clearest public example of this is a multi-billion-dollar robotic warehouse buildout launched by a major retail player to compete with dominant sector rivals. The technology was real. The automation vendor was capable. The flaw was upstream of both: the operating model had been proven in a foreign market where density and logistics worked fundamentally differently, and the structural reasons it wouldn't translate were visible before the contracts were signed. The deployment became a massive capital write-down. Not because anyone failed to execute. Because nobody was paid to challenge the premise.

That pattern is everywhere in hardware, and it has a structural cause worth naming. The move-fast-and-break-things instinct that works in software does not survive contact with physical systems, where a failed test is not a patch but a fleet of machines that already exist. And once a program is funded and staffed, the team is allowed to iterate the engineering but rarely allowed to iterate the requirements. So a great answer gets scaled to the wrong question, expensively, with real conviction from people doing their jobs well.

That is the cost the invoice is actually competing with. Not what you'll spend on us. What you'll spend executing a decision nobody pressure-tested.

The math, once you can see both numbers

Now the ratio is easy. The decisions we get hired to inform are usually in the millions or tens of millions of dollars, sometimes more. Our fee against that decision typically lands well under one percent. You are paying a small fraction to de-risk the rest. That's the trade. Not "consultants are expensive." A fraction of a percent to make sure the other ninety-nine-plus is going to the right place.

The return on getting it right is rarely "we shaved twenty percent off the budget." It's usually stranger and larger than that. One client was on track to spend heavily over five years on a solution that would generate a meaningful return. We pushed back: spend a quarter of that, accept a return that looks smaller on paper, and put the other three quarters to work earning that same return again on the next program, and the one after that. One line item shows a smaller number. The balance sheet as a whole earns several times more. That's the kind of move that's only available if someone is in the room before the original number gets locked.

The simplest version is payback. A deployment we worked on cost in the low five figures and saved thirty minutes of operator time per unit per day. The first version paid for itself inside a year. Once we helped cost-reduce the design, payback compressed to under three months. At fleet scale, the same logic stops being a percentage and starts being a multiple. That's what good looks like, and it's only available to a buyer who paid for the upstream thinking instead of skipping it to save money.

What it costs to engage

You deserve real numbers before you ever talk to us, so here they are.

An Audit is the entry point. A focused look at a contained operation, usually a day or two on-site and a week or two of work, ending with a documented current state and a real set of options for what to do next. For a contained scope, this generally runs around $30,000. The Audit is the right call when you've been trying to automate or improve something for a while, the attempts are not landing, and the team is frustrated without a clear reason why.

A Project is for when the problem is defined, and the economics are clear. You need a specific outcome, and the path to get there still has to be designed and de-risked. Depending on how novel the system is and how many process steps it spans, Projects generally run from the high five figures into the low six figures, with genuinely complex multi-system work landing above $200,000. A Project fits when you can name the outcome you need but not yet the right way to reach it.

A Retainer is for the company working a continuous set of decisions across many parts of the operation, where the goal is to keep surfacing and prioritizing the projects worth doing before any of them turn into commitments. A Retainer typically runs around $30,000 per month. The projects that surface out of it are then scoped and run separately as their own engagements, so the retainer keeps the pipeline of decisions moving while individual builds are priced on their own.

Read those as fit-for-purpose, not as a price ladder. The right engagement is the one that matches the decision in front of you. Sometimes that's a single Audit, and we don't see each other again for a year. That's a successful outcome on our end.

What actually moves the price

A few things, in order of impact. How novel the system is, because designing several products to work together as something new involves real iteration, which is slower and more expensive than executing a single, well-defined piece. How many process steps are involved, since a squishier problem definition takes more cycles to make sure the real requirements get captured. How many sites we need to be in, because travel and on-site evaluation scale with locations. And how much original research is needed before anyone can responsibly recommend anything.

What doesn't move it as much as buyers expect is the raw size of the build downstream. On large deployments, our fee approaches a rounding error against the deployment itself, which is exactly why anchoring on our number instead of the decision gets the comparison backwards.

When not to call us

Four situations where we're the wrong call, and we'd rather you know now.

• If the decision is already made and you need execution, use a design firm, a system integrator, or your internal team. We'll just slow you down.
• This is also the case if you already have an integrator locked into a fixed solution, because we'll challenge that engagement and you'll be frustrated with us.
• If the problem is purely upstream strategy with no physical process or system component, use a strategy consultancy. That's not our lane.
• And if you want validation for a direction you've already committed to emotionally, we're the wrong call and an expensive way to hear something you aren't going to act on.

If none of those describe your situation, and you're about to commit real capital against a build, an automation move, or a transformation that touches the customer, the technology, and the operation at once, the conversation is worth having before the money moves. That's the chair we're built to sit in, and the math is the math.