If the Recommendation Came Before the Questions, It's Not Advisory

Forrester's 2024 B2B Buying Study found that 74% of business buyers feel that salespeople focus too much on pitching their own product and not enough on understanding the buyer's problem. That number has been climbing steadily since Forrester started tracking it. The sales industry knows this is a problem. The behavior persists because it works often enough to be profitable — even though it doesn't work well enough to be advisory.

In The Problem with Generic Tech Recommendations, I flagged a specific red flag: a recommendation that arrives before a diagnosis. If a specific product name appears before there's been a meaningful conversation about your current environment, your constraints, your team, and what's actually causing the problem — that's not consulting. That's a sales motion with consultative language wrapped around it.

What advisory actually looks like

Real advisory follows the same structure as any honest diagnostic process. A doctor doesn't prescribe before examining. An attorney doesn't recommend a strategy before reviewing the facts. An engineer doesn't spec a solution before understanding the requirements. The pattern is universal across every field where the advisor's credibility depends on getting the answer right rather than getting an answer fast.

In technology advisory, the diagnostic phase has specific components. At minimum, a credible advisor needs to understand your current tech stack and what the proposed tool must integrate with, your infrastructure and hosting environment, your budget including total cost of ownership, your team's capabilities and working style, where your business is going — not just where it is now — and what's actually causing the pain you're trying to resolve.

That conversation takes time. It requires questions the advisor can't answer from a website visit or a LinkedIn profile. It produces information that changes the recommendation. If the recommendation doesn't change based on what the advisor learns, the discovery phase was theater.

How sales motions disguise themselves as advisory

The language of consultative selling has become sophisticated enough that the line between genuine advisory and structured sales can be difficult to spot from the inside. A few patterns to watch for:

• The conclusion precedes the discovery. The vendor asks questions, but the questions are structured to confirm a pre-selected recommendation rather than to explore the problem space. "How are you currently handling X?" followed immediately by "Because our platform solves exactly that" isn't discovery — it's a leading question with a predetermined destination. Genuine discovery produces surprise. If the advisor is never surprised by your answers, they aren't listening for new information.
• The demo arrives before the diagnosis is complete. A product demonstration is a presentation of capability. It's useful — after the problem has been defined and the constraints understood. A demo in the first meeting, before the advisor has a meaningful picture of your environment, is a pitch. The timing is the signal. Discovery first, then options, then demonstrations of the options that survived the constraint analysis. Any other sequence is selling.
• The scope of inquiry is suspiciously narrow. If the questions focus only on the problem their product solves and don't explore adjacent systems, team dynamics, process maturity, or organizational direction — the advisory frame is superficial. A genuine evaluation of whether a tool fits your environment requires understanding the environment. Questions limited to the tool's feature set are product qualification questions, not advisory questions.
• Alternatives are mentioned but not explored. Some vendors will reference competitors early in the conversation — "you may have also looked at Platform X" — as a credibility signal. But if the conversation never genuinely evaluates whether an alternative, or no tool at all, might be the better answer, the mention was positioning, not objectivity.

Why this matters beyond the immediate decision

A recommendation that arrives before a diagnosis doesn't just risk selecting the wrong product. It sets a precedent for the relationship. If the vendor's first interaction with your organization prioritized their solution over your problem, that priority structure is likely to persist through implementation, support, and renewal.

Implementation decisions will favor the vendor's standard approach over your specific needs, because the standard approach is what they've built their delivery model around. Support interactions will route toward product-centric solutions ("have you tried enabling this feature?") rather than problem-centric investigation ("let's look at what's actually happening in your environment"). Renewal conversations will focus on new features and expanded licensing rather than whether the tool is still the right fit for where your business has gone.

The first interaction is diagnostic — not just of the product, but of the vendor. How they approach the initial conversation tells you how they'll approach the relationship. It's a direct expression of the trust equation in B2B.

What to do when you recognize the pattern

Recognizing a sales motion presented as advisory doesn't require confrontation. It requires redirection.

• Ask what they don't know. A useful question in any vendor conversation: "What would you need to understand about our environment before you could make a recommendation?" If the answer is "nothing — based on what you've told me, I'm confident this is the right fit," the diagnosis is incomplete and the confidence is misplaced. If the answer is a substantive list of questions, you're talking to someone who takes the advisory frame seriously.
• Slow down the timeline. Sales motions depend on momentum. "Let me set up a demo for next Tuesday" keeps the process moving toward a decision before the evaluation is complete. Slowing down — "Before we look at any specific product, I want to make sure we've fully mapped the problem" — creates space for actual discovery. How the vendor responds to that request is informative. Advisors welcome it. Salespeople resist it.
• Separate the evaluator from the seller. If the same person who will earn a commission on the sale is also conducting the needs analysis, the incentive structure is worth noting. This doesn't make the analysis automatically biased, but it does mean you should evaluate the quality of the discovery independently — does it feel like they're learning about your environment, or confirming what they already planned to recommend?

The distinction between advisory and sales isn't about intent. Many people in sales roles genuinely want to help their clients find the right solution. The distinction is about process. Advisory follows evidence. Sales follows a pipeline. When the recommendation arrives before the evidence is in, the process is the latter — regardless of how the conversation is framed.

Frequently asked questions

How can I tell if a vendor's discovery process is genuine?

Genuine discovery produces information that changes the recommendation. If the vendor asks detailed questions about your environment, constraints, and goals — and then adjusts their recommendation based on what they learn, including potentially recommending against their own product — the process is real. If the questions are structured to lead toward a predetermined conclusion, the discovery is performative. A useful test: ask whether they've ever recommended a competitor's product or recommended that a prospect not buy anything at all.

Is it always wrong for a vendor to mention their product early in the conversation?

Context matters. A vendor explaining what they do and how their product works is transparent — you know who you're talking to and what they sell. That's different from a vendor positioning their product as the answer to your problem before they understand the problem. The issue isn't mentioning the product. It's concluding the evaluation before conducting it.

What should a proper technology evaluation process look like?

A credible evaluation follows a sequence: define the problem and its root cause, document the current environment and constraints, identify the categories of solutions that could address the problem, evaluate specific options within those categories against your constraints, and then — after all of that — move to demonstrations and proof-of-concept testing. Any process that inverts this sequence, placing the product demonstration before the problem definition, has prioritized speed over fit.