Ex-SaaS CEO.
Now your pricing partner.

Five people, maximum. Usually product, sales, finance and the CEO. Add a sixth and the room stops sprinting and starts building consensus. Smaller companies do fine with one or two.

One of those people is the decision maker. Usually the CEO, and if not, someone with the authority to overrule the room. The group brings data and argues. That person calls it.

No voting. Voting is how pricing projects lose three weeks to a detail nobody will remember.

Everyone else in your org is an advisor. They all hold information you need, like why customers churn, where deals stall, what people actually complain about. They supply that. They do not decide.

One warning sign worth knowing: if everyone in the room is comfortable, you are designing by committee. Some friction means real trade-offs are getting made.

That depends on your company more than on the work. Small projects wrap in a month. I commit a minimum of two months of focus to every engagement, and some run longer than that. The variable is how fast your team can make decisions.

That usually means one of three things. You changed price points without changing the structure underneath. The model was right but never made it into the billing system or the sales floor. Or nobody senior owned it and it quietly died. The first is a diagnosis problem, the other two are execution problems.

Across my engagements, the revenue growth from the pricing change one year after launch has averaged 75 times my fee. That counts year one only, so it understates it. A pricing change does not stop paying in year two.

The multiple is not really the point. The point is that my fee is a rounding error against what pricing does when you get it right, and against what it costs you every month you leave it alone.

I have been the CEO making the call, not the advisor recommending it. I have raised prices, watched the churn dashboard the next morning and handled the sales team that thought it was a terrible idea. Most pricing consultants have only ever been in the room for the advice.

You get me for the whole engagement. No partner who sells the work and then hands it to a junior analyst two years out of school. That is the real risk with the large firms, and it is worth asking any of them who will actually do the work before you sign.

I also run at most 1-2 active engagements at a time. This means you get my full attention, but it also means sometimes I cannot start for a few weeks.

The big firms are the right answer if you need six people embedded for six months. I will tell you when that is your situation.

Rarely, and I usually argue against it.

There is a gap between what someone says they would pay and what they actually pay, and it is a big one. Answering a survey costs the respondent nothing. Entering a credit card costs them something. The proof is in the pudding: if customers put their card details in and press pay, your pricing works. If they don't, no amount of research makes up for it.

Research also aims at the price point, which is the least important part of your pricing. Structure is where the money is.

And you already have the signal. Your sales and commercial teams know where you are leaving money on the table and where deals stall on price. That comes from real deals with real budgets.

Early on I ran Van Westendorp myself, looked at the "optimal" price it produced, decided it made no sense and doubled it. Revenue went up close to 100% against what the research recommended.

I write a pricing spec that can be handed off to your engineers. If you want more than that, I can work directly with your dev team to get the pricing and billing shipped.

Traditional SaaS runs at 80% margins, so weak pricing costs you growth you never see. AI costs you cash. The same flat subscription can be 70% margin on one customer and underwater on the next, purely on how much they use. A rep paid on ARR has no reason to check which one they just signed. That is when credit systems, rate limits and fair use policies stop being cosmetic. If you are bolting AI onto an existing product, that is the sharpest version of the problem I work on.