Technical discovery: keep sales honest and scope clear

Why discovery turns into free consulting

Discovery calls usually go wrong for one reason: both sides want certainty before they have enough facts.

The seller wants to build trust, so the conversation slides into live problem-solving. That feels helpful in the moment. It also teaches the buyer to expect architecture advice, tool recommendations, and rough plans before anyone has checked the real limits.

The buyer often pushes the call the same way. They want a timeline, a budget range, and a read on risk right away. If nobody slows the pace, the discussion jumps from "what are you trying to fix?" to "should we use microservices, AI agents, or no-code?" That is design work, even if nobody calls it that.

The drift usually starts in familiar ways:

• Someone asks for numbers before the team understands the current system.
• A technical lead tries to prove expertise by offering specific fixes on the spot.
• One pain point turns into a plan for the whole product.
• Nobody says what the call is actually for.

That is how technical discovery becomes free consulting. The team gives away real thinking, then ends the call with fuzzy scope, hidden risks, and notes that say almost nothing beyond "needs integration" or "AI may help."

Senior technical people see this all the time, especially in early sales conversations. Smart people hate dead air, so they fill it by solving. That habit is expensive. It burns senior time and creates false confidence, because fast answers sound solid even when the facts are thin.

Good discovery does not mean being vague or withholding useful questions. It means keeping the session focused on risk, constraints, and the next decision. If the call stays there, you still build trust, but you do not do unpaid design work.

What a discovery call should produce

A good discovery call should end with a few clear outputs, not a half-built solution. If the buyer leaves with pages of design advice, the call went too far. If they leave with nothing concrete, it was just a chat.

Start with one plain sentence that defines the problem. Make it specific enough that someone outside the meeting could understand the job. "We need a customer portal" is too loose. "We need customers to place repeat orders online instead of calling support" is much better.

Then capture the risks that could delay delivery or drive up cost. Some are technical, like old systems that do not connect cleanly. Others are business risks, like missing product ownership or a launch date that cannot move. This is where discovery earns its keep. It turns vague worry into a short list people can act on.

You also need the hard limits. A small team, a fixed deadline, a strict budget, or a required tool can rule out entire approaches before anyone starts sketching screens or drawing architecture.

By the end of the session, you should have four things:

• one sentence that defines the problem
• a short list of delivery risks
• the limits the team cannot change
• one or two decisions the buyer must make next

Those decisions matter most. The buyer may need to choose between a faster launch with fewer features and a broader scope with a later date. They may need to decide whether the current team can build the project or whether they need outside help.

That is enough for one session. Clear problem, real risks, fixed limits, and a decision. Once you go further, you are usually doing free consulting.

Set the boundary before the call

Most discovery calls go off track before anyone speaks. The invite is vague, the buyer expects answers, and the team hopes to sort it out live. That is how discovery turns into unpaid solution design.

A short agenda prevents a lot of this. Send it before the meeting, even if it is just a few lines in the calendar invite:

• confirm the business goal
• list known constraints
• identify the main risks
• agree on the next decision

That framing changes the tone. You are there to map risk, not to sketch the full system, price every feature, or solve edge cases on the spot.

Set the time limit early and keep it firm. Forty-five minutes is usually enough. Once people know the call has a hard stop, they are less likely to wander into detailed design debates that belong in a paid workshop or a later scoping phase.

It also helps to name the boundary in the first minute. Say that the session will cover risks, constraints, owners, and next steps. Say that you will not design the whole solution live. Serious buyers usually respect that because it makes the process clearer, not colder.

Before the call, ask who can speak for budget, scope, and timing. If those people are missing, the meeting often turns into speculation. One person wants speed, another wants a lower budget, and nobody can make a decision. You do not need a large buying committee. You do need someone who can say yes, no, or not now.

Ask for basic facts in advance if the buyer has them. A rough feature list, current tools, user count, deadlines, and known technical issues are enough to start. If they send nothing, that tells you something too: keep the session high level.

Run the conversation in a clear order

A discovery call needs structure. Without it, the loudest problem takes over and the meeting turns into unpaid design work.

A simple sequence works well:

1. Start with the purpose and the stop time.
2. Confirm who feels the pain and who can approve the next step.
3. Map the current state before talking about fixes.
4. Move into constraints and risk.
5. Close with a decision, an owner, and a date.

The opening sets the tone. A line like this is enough: "We have 45 minutes. By the end, we should know the problem, the limits, and whether a deeper paid discovery makes sense." It keeps the session focused and makes the boundary clear.

Then sort out roles. Ask who deals with the problem every day, who will use the result, and who can approve budget or timing. Those are often different people. If a founder wants a new AI workflow but the operations lead owns the current process, both views matter. One feels the pressure. The other knows where the work actually breaks.

When solution talk appears too early, park it. Do it politely and out loud. If someone asks, "Should we rebuild this in Next.js or add automation first?" note it down and move on. You need the limits first. Otherwise, you are guessing, and guesses sound a lot like free consulting.

The middle of the call should feel practical, not flashy. Ask what systems already exist, what data is messy, which deadline cannot move, and what failure would cost the business. Those questions reveal more than a long wish list ever will.

Finish with a short recap that names the next decision. For example: "Anna will send the current workflow by Thursday. Ben will confirm the budget range. We will decide next Tuesday whether to scope a paid architecture session." That is enough. Clear owners and dates keep the conversation honest.

Questions that expose real risk

A good discovery call should expose pressure, not prove how smart the seller is. If the room stays at the level of features and wish lists, you miss the reasons a project might stall, run over budget, or die after one meeting.

The best questions are usually plain. They are direct, and they force people to talk about pain, timing, limits, and trade-offs.

A few examples:

• "What fails today, and how often?" You want specifics, not a vague complaint like "the system is slow." Maybe payments fail twice a week, reports take four hours, or a manual step adds 20 minutes to every order.
• "What date matters, and what happens if you miss it?" A deadline tied to a contract renewal, investor update, hiring plan, or busy season is real. A date with no consequence usually moves.
• "What are you stuck with?" That might be an old ERP, a vendor contract, a compliance rule, a customer promise, or an internal team that only supports one stack.
• "What budget range would you actually approve this quarter?" If nobody can name a range, the project may still be a thought experiment.
• "What would make you say no right now?" This saves time fast. Sometimes the real blocker is headcount, internal politics, security review, or a spending freeze.

The point is not to corner anyone. The point is to find the limits early, before people start sketching a full solution. When a founder says, "We need an AI assistant in six weeks," the useful follow-up is usually about data access, legal review, and who will own the result inside the company.

These answers also tell you whether the work fits this quarter at all. A good technical lead should be able to say, "This is blocked by procurement" or "Your real problem is bad source data," instead of pretending a build plan will solve everything.

If the client cannot name the problem, the deadline, the constraint, and the budget range, you are not scoping a project yet. You are still testing whether a project exists.

Capture decisions, not design work

A technical discovery call should leave you with a record of choices, risks, and unknowns. It should not leave you with a free system design.

Write notes in plain language as you talk. If a buyer says, "We need customer data in one place," write that need down first. Do not translate it into a stack, a diagram, or a full build plan on the spot.

One simple habit keeps the call honest. Split your notes into three buckets:

• facts: what the team already knows, uses, or must keep
• guesses: assumptions that still need proof
• open questions: gaps that block a clean estimate or recommendation

This structure stops a common problem. People hear a few details, then jump straight into solution mode. Ten minutes later, they are sketching databases, services, and workflows nobody agreed to pay for.

At this stage, trade-offs matter more than drawings. If the buyer accepts a slower launch to lower cost, write that down. If they want fast delivery and can live with manual steps for a month, record that too. Those choices shape scope far better than a polished architecture diagram.

Deep architecture work is separate work. If the buyer wants migration planning, vendor selection, or a detailed rollout plan, say so clearly and move it into a paid scoping phase. That protects your time and gives the buyer something more useful than improvised advice.

After the call, turn your notes into a short decision memo. Keep it tight: the goal, the known constraints, the accepted trade-offs, the open questions, and the next decision with an owner. One or two pages is usually enough.

That memo does two things. It shows the buyer you listened, and it keeps both sides anchored to what the call was actually for.

A simple startup example

A SaaS founder wants an AI feature live in six weeks for a customer demo. The idea sounds simple: use past support tickets, let a model suggest replies, and show the draft to the support team before anything goes out. On a sales call, that can turn into free consulting very quickly. People start talking about prompts, model choice, and interface details before they check whether the idea can work at all.

A better discovery call stays narrow. The team starts with the risks that could kill the project early. They ask where the data comes from, what customer data the model can use, and who will review bad suggestions. They also check support volume. Ten AI drafts a day is easy to review. A thousand is a staffing problem.

In this case, the legal risk is manageable. The company can keep the feature internal at first, so agents review every draft before it reaches a customer. That removes a lot of risk. The support volume also looks manageable because the team already has a review step in its workflow.

The blocker is testing. The founder has a large pile of old tickets, but none are labeled. No one marked which reply solved the issue, which answer caused more back-and-forth, or which cases needed escalation. Without that, the team cannot test the feature in a serious way. They can build a demo, but they cannot tell whether it helps.

That finding changes the next step. Instead of promising a full build in six weeks, the team proposes a paid spike with a small, clear goal:

• pull a sample of real tickets
• create simple labels for good and bad responses
• run a few model tests against that sample
• measure review time and error rate

After that, the founder can make a real decision. If the sample produces clean results, the build moves forward with tighter scope and a better timeline. If the data is too messy, the company fixes that first instead of paying for a feature built on guesses.

That is the line you want. The founder pays for clarity, not for a half-designed system hidden inside a sales call.

Mistakes that blur the line

Discovery slips when the seller starts acting like a solution architect for free. The point is to reduce uncertainty, not hand over a mini plan before the buyer commits to a paid next step.

The first mistake is giving estimates too early. A buyer asks, "How long will this take?" and the pressure to answer feels real. But if you still do not understand the current workflow, data issues, approvals, integrations, or team limits, any number will sound firmer than it should. People remember the number, not the caveat.

Another mistake is letting one loud feature control the whole call. A founder may focus on an AI chatbot, a dashboard, or a mobile app because it sounds exciting. Meanwhile, the real problem may be slower order handling, messy internal handoffs, or poor reporting. If you follow the loudest topic instead of the business pain, the session turns into idea shopping.

The line also gets blurry when you solve edge cases before confirming the basics. If nobody has agreed on the main user, the core workflow, or what success looks like, a deep discussion about rare exceptions is wasted effort. It feels smart in the moment. It does not help anyone decide.

A few warning signs usually mean the call is slipping:

• You start sketching solutions for cases nobody confirmed matter.
• The buyer asks for another "quick session" with more people, but no paid work exists yet.
• You leave with homework, while the buyer leaves with no clear choice.
• The conversation gets more detailed, but not more certain.

The easiest mistake to miss is ending without naming the buyer's next decision. Every discovery call should close with a simple choice such as paid discovery, a small audit, a proposal based on stated assumptions, or no fit. That protects both sides.

A quick end-of-call checklist

A discovery call can feel busy and still end in a fog. Before everyone leaves, both sides should know what problem matters most, which constraints are real, and whether the conversation stayed inside the line between scoping and unpaid solution work.

Use five quick checks before you wrap up:

• Name the biggest risk in plain words. If you cannot say it in one sentence, the call is still too vague.
• Confirm budget and timing. You do not need a perfect number, but you do need a range and a target date.
• State what is outside this phase. That might include mobile apps, custom reporting, third-party integrations, or a full rebuild.
• Agree on the next decision. Not the next meeting - the next decision.
• Stop when design work starts. Once the call moves into diagrams, sprint plans, schema details, or tool-by-tool choices, discovery is over.

A simple test helps here. If the founder leaves knowing the next business choice, the session worked. If they leave with a half-built technical plan and no agreement on scope, budget, or ownership, the boundary slipped.

What to do next

Send a short summary within one business day. Wait longer, and people fill the gaps with their own version of the call. Scope drifts fast when nobody writes down the decision.

Keep the follow-up short. Include the decision that was made, or the single decision still pending, the main risks and constraints behind it, and the next step with an owner and a date.

If nobody can point to one clear decision, do not fix that with another free call. Book a paid scoping step instead. That is usually the right move when risk still feels high, the team disagrees on priorities, or the architecture options would change the budget in a serious way.

Paid scoping works best when it answers one business question at a time. "Can we ship on the current stack in eight weeks?" is a real scoping question. "Can you tell us the best way to build everything?" is open-ended consulting, and it will eat time fast.

Keep the next step tied to a decision, not extra advice. If the team needs estimates, review the assumptions behind them. If they need an architecture call, compare two realistic options and pick one. If they need a delivery plan, define the first milestone and what must be true before work starts.

Some teams also need an outside technical view before they commit. In cases like that, Oleg Sotnikov at oleg.is can review scope, delivery risk, and architecture fit as a fractional CTO or startup advisor. That kind of help makes sense when founders need senior technical judgment without hiring a full-time CTO.

A good discovery call does not end with more talking. It ends with a written decision and a smaller, clearer next move.