What to build, what to buy, what to stop.

For a platform: where the roadmap goes, what open really costs when interoperability stops being optional, and the point where a recommendation engine becomes a decision engine and the liability moves with it.

For an owner: what to standardize and what to leave alone, what a system is genuinely going to change about the operation, and which capability is worth owning rather than renting.

Same question from two chairs. Neither side answers it well without knowing how the other one thinks.

What you actually sell, in the words a buyer uses.

Most positioning problems are not messaging problems. They are a company describing its product from the inside while a buyer compares three options from the outside. I have written the description and I have sat on the other side reading it, which is a short way of saying I know where the gap usually opens.

This one is mostly for platform companies. Owners who are pitching an internal program have the same problem with a smaller budget.

Telling the difference between what the demo showed and what you are buying.

I have built the demo. I have also sat through it as the buyer and signed for what came after. Both are useful, and the second one is why I know which parts are load-bearing.

For a platform, the same knowledge runs backwards: what your evaluation actually proves, and what a serious buyer is going to test that your demo does not cover.

Getting it out the door with the organization intact.

For a platform, that is shipping a roadmap when engineering, sales, and services all want a different quarter. For an owner, it is going live without the operation absorbing the cost quietly for two years.

Advice that ships is a different discipline from advice that persuades, and most failures in this category are execution failures dressed as strategy disagreements.

Where automated recommendations took decisions that used to carry a signature.

For an owner, that means finding out which decisions moved and putting a name on each one. It is a short exercise with real consequences and it is not a technology project.

For a platform, it is the same question pointed the other way: where your product moved a decision, whether your contract language holds, and what a customer's counsel is going to ask about it.

Thirty-six years produces a long list of things I have been handed. If your problem does not fit the five above, describe it anyway.

I do not implement systems, resell software, or take vendor referral fees. There is no product behind any of this, and that is the point. An advisor with something to sell is answering a different question than the one you asked.

I also do not run long engagements. If the work cannot be scoped in a conversation and delivered in weeks rather than quarters, I am probably not the right person for it.