Uncover Technical Decision Criteria Before You Present

A seller prepares a demo for an architecture team without knowing what will count as a good fit. The session looks polished yet misses the decision. Technical teams name many concerns because a system touches many parts of their work. A seller who treats every item as equally important builds a long presentation and learns little about how choice will happen.

Start before you choose a demo path. Ask how the team will compare options and who participates in each part of review. Ask what problem started the evaluation, what current constraint creates urgency, and what a successful change would look like during daily work. Then ask which requirements are nonnegotiable. A nonnegotiable requirement means an option fails when a requirement is absent or unacceptable. A preference deserves attention, yet a team might trade a preference for another benefit.

Use precise follow up questions. An architect who says integration matters has not given you a criterion. Ask which systems need connection, what data moves between them, who owns each system, and what outcome would rule an option out. An answer such as, "Our identity team needs single sign on through our existing method before approval," gives a clearer evaluation path than a broad request for integration.

Ask for tradeoffs without challenging technical judgment. Say, "If two options meet identity needs, what would help you choose between them?" Ask, "Which concern would stop review even if other areas looked strong?" These questions show respect for the team method. They also stop a seller from guessing based on category labels or a past opportunity.

Technical criteria often involve operability, integration, security, team skills, cost, and future fit. Their importance changes by organization and project. A small team might focus on daily administration because no dedicated operations role exists. Another team might place most weight on compatibility with a system already central to its work. Do not infer priority from a familiar customer type.

Here is a fictional practice situation. Mei, a solutions consultant, meets with Ari, an architect, and Noor, an engineering manager. Ari names identity, logging, data movement, day to day administration, budget, and team training. Mei writes every item down. She then asks, "Which of these would end evaluation if an option did not meet your needs?" Ari says identity and logging are hard stops. Noor says data movement must work with their current process, while training is important yet manageable.

Mei asks one more question. "When you say logging, what does an acceptable review look like?" Ari explains their operations team needs to inspect activity using a tool already in use. Mei does not promise compatibility. She asks which events matter most and who should verify an answer. Ari names their operations lead, Ren. A vague word is now a testable question with an owner.

After the meeting, Mei sends a short note in plain language. She lists identity and logging as hard stops, data movement as a required workflow review, and administration, budget, and training as tradeoffs. She asks Ari and Noor to correct order or wording before a demo is scheduled. Written confirmation prevents a later dispute where everyone recalls a different priority.

A decision criterion needs an observable test. "Easy to use" is too broad for an evaluation plan. Ask who performs the work, what task they need to complete, and what would make the experience unacceptable. "A team administrator needs to add a new user during a working session without help from an engineer" gives the team a situation to inspect. The buyer still decides whether a result meets their standard. Your job is to make the test clear.

Do not turn every question into a product pitch. During discovery, your role is to learn the buyer terms before proving fit. If a question exposes a gap in your knowledge, say you will verify rather than fill silence with a claim. Bring an appropriate colleague only when their input helps answer a criterion. An architect will notice when a seller uses experts as a show of force instead of a source of useful detail.

Map people to decisions. An architect might define technical constraints. An operations lead might judge ongoing work. A security person might review risk. A finance partner might assess commercial limits. Do not assume one senior person speaks for everyone. Ask who needs to see each part and what they need to decide. This helps you plan a session around people who own relevant questions rather than invite a crowd to a generic demo.

Criteria change during an evaluation. A team sometimes learns a new dependency after a workshop, or a new participant surfaces a constraint. Treat a revised criterion as information rather than resistance. Ask what changed, who needs to confirm new wording, and whether planned work still answers the question. Update the written list with buyer approval. Quiet changes after a call create confusion.

In the fictional situation, Ren joins a follow up meeting and says operations also needs to know how access changes appear in their existing review process. Mei adds this under logging rather than create a separate vague category. She asks Ren to describe one access change worth testing. Ren chooses a new administrator receiving access during a busy support period. The group agrees this situation belongs in the technical session.

Build each demo segment around a criterion rather than a product tour. Start by repeating the buyer words and confirm purpose. Show enough context for the test. Pause for the owner to inspect what matters. Ask whether the session answered their question, what still needs verification, and who should own next review. A shorter session with clear answers provides better evidence than a long session full of unrelated screens.

Use a simple record for every criterion. Give each row a short name, an owner, an observable test, a priority, and a next date. A row for logging might read: Ren owns review of administrator access events through the existing review process. Demonstration is scheduled for Thursday the 14th. Ari must confirm whether a result meets the team standard by Monday the 18th. This wording separates proof, ownership, and final judgment.

Do not score the buyer criteria for them. A seller scorecard often hides unknowns behind green labels. If identity support needs verification, write verification needed. If Ren has not described the review method, leave the test incomplete. An honest blank directs the next conversation. A confident rating without evidence creates work later.

Compare a test with its decision. Suppose Ari says identity review should occur before logging review. Mei asks why. Ari explains approval from his identity team determines whether a deeper session is worthwhile. Mei moves identity first and leaves logging on the agenda for later. This sequence respects an internal gate without claiming a result before evidence exists.

At the session, Mei opens with Ari's words: identity must work through the existing method before approval. She asks Ari to state the exact question first. After the review, Ari says one configuration detail needs a written answer from his identity owner. Mei records no positive score. She records identity verification pending, Ari as owner, and Friday as the date for his follow up. Ren's access test remains scheduled only after Ari replies.

Before the next meeting, review notes for assumptions. Mark every requirement lacking an owner, a definition of acceptable, or a decision date. Send a brief confirmation note rather than a polished scorecard with your own ratings. In the fictional situation, Mei sends Ari the agenda one day before the session. Ari replies with one change: begin with identity, then test Ren's administrator access situation. Mei updates the agenda, sends Ren the revised order, and asks him to bring the exact review question he wants answered on Thursday.