Presales & Solutioning

What this area actually covers

Presales — variously called solution engineering, sales engineering or presales consulting — is the technical work done before a contract exists. A prospective customer has a problem and, usually, a budget. Your job is to establish what the problem really is, decide what your product or your firm would build to solve it, prove the parts genuinely in doubt, write down what it costs and what it depends on, and defend all of that in front of the people who will pay for it and the people who will operate it afterwards.

The work divides into four modes that reward different skills, and interviews probe each separately. Discovery is investigative: you are diagnosing, and also deciding whether this is a real opportunity. Demonstration is performative and unforgiving — live software, live questions, no retakes. The proposal is written engineering, read by strangers including procurement and legal. A proof of concept is an experiment designed to remove one named reason not to buy.

Treat it as a genuine engineering discipline, because the design decisions are real and the constraints are hard: an existing identity provider, data residency rules, the operating team's actual skills, a fixed-price contract model. Adjacent things get wrongly bundled in. Marketing and technical evangelism are one-to-many with no named deal attached. Post-sale solution architecture inherits your promise and is accountable for delivering it. And sales itself owns the number, the negotiation and the relationship, none of which are yours.

The seven areas underneath

The subsections follow a deal rather than a syllabus, because that is the order in which the skills are used and the order in which an interview loop will test them. The last two are the ones candidates most often arrive unprepared for.

Discovery & Qualification covers running a first call, the qualification frameworks used to decide whether an opportunity is real, and the harder skill of mapping a stated business pain onto a technical capability without leaping to your product. It comes first because everything downstream is wasted if it is wrong, and because the interview will almost certainly include a discovery role-play. Expect question construction, listening ratios, and how to establish who signs without asking a question that sounds like an audit.

Solution Design & Proposals is the written engineering: turning what you learned into an architecture the customer's own people will scrutinise, choosing a reference pattern, and writing the narrative that carries a non-technical reader from problem to answer. It exists separately because writing under commercial constraint is a distinct craft — every sentence may end up quoted in a contract schedule, and the ones that are vague are the ones that hurt.

RFP & RFI Response deals with formal bids: deconstructing a requirements matrix, deciding whether to respond at all, building compliance answers at volume, threading win themes through hundreds of boxes, and managing the whole thing against a deadline that will not move. It has its own area because the work is structurally different from a conversational sale and because a large part of the public-sector and enterprise services market runs this way.

Demos & POCs covers demonstration storytelling, handling a live failure without losing the room, and defining proof-of-concept success criteria in writing before any work starts. It is separated out because these are the two most visible moments in a deal and the two where an unprepared solution engineer does the most damage: a demo that shows everything convinces nobody, and a POC without exit criteria becomes unpaid delivery.

Estimation & Commercials is effort estimation, staffing and delivery models, licensing structures, total cost of ownership and enough margin awareness to know when a deal is bad for your own firm. It exists as its own subsection because it is where presales is most often weak and most often caught: an estimate is the point at which your technical judgement becomes somebody else's budget.

Objection & Competitor Handling covers answering a hostile technical objection, positioning against a competitor without disparaging them, and the much harder skill of conceding a genuine gap in a way that increases rather than destroys trust. It is separate because the technique is counterintuitive and because interviewers test it directly by playing the sceptic.

Presales Scenarios puts you in the room: a CTO who has decided you are overselling, a timeline that cannot be met, a feature you do not have, a bid you are losing and can still learn from. It sits last because scenarios combine everything before them, and because presales loops are unusually scenario-heavy.

Where it sits in a real business

Follow one deal. An account executive owns the forecast and pulls you in to run discovery, and your first output is not a solution but a judgement about whether the opportunity is real. If it is, you demonstrate, answer the security questionnaire, scope a POC if the customer needs proof, and write the solution and estimate that becomes the priced proposal. Legal turns your words into contract schedules. If you win, a delivery team then lives for a year inside assumptions you wrote in week three.

sequenceDiagram
    participant A as Account executive
    participant S as Solution engineer
    participant C as Customer team
    participant L as Legal and procurement
    participant D as Delivery
    A->>S: Qualified opportunity, run discovery
    S->>C: Discovery sessions and current-state review
    C-->>S: Constraints, existing estate, the real deadline
    S->>A: Judgement on whether this is winnable and worth it
    S->>C: Demo and a POC with written exit criteria
    S->>L: Solution, assumptions and estimate
    L-->>C: Priced proposal and contract schedules
    C-->>D: Signature, and a year inside your assumptions

The arrow to look at is the fourth, because it points backwards. The solution engineer's first real deliverable is a judgement returned to the account executive, not an artefact given to the customer, and it is the only point in the sequence where withdrawing is cheap. Everything after it accumulates cost and commitment; a deal that should have been disqualified in week two consumes two months of two people's time and usually loses anyway.

That handover at the end is why the role has teeth. You are the last person who can say "we cannot do that for that money in that time" while saying it is still cheap; after signature the same sentence costs a change request, a margin write-down or a reference customer. Presales is structurally the honesty checkpoint between a sales forecast and an engineering commitment, which is why it needs someone who can be told no by their own account executive and hold the line anyway.

Who does this work

In product companies the title is solution engineer or sales engineer, aligned to one or two account executives or a territory and measured on the same quota they are. In services firms it is presales consultant or presales solution architect, and the work is bid-shaped: RFPs, estimates, delivery models, rate cards. Overlay SEs are pulled across a region for one deep area; above both tracks sit principal SEs on the hardest deals and SE managers running a team's capacity.

A representative day holds two customer calls that do not go as planned, an hour repairing a demo environment someone else reset overnight, a spreadsheet of two hundred RFP questions, a call with product management about whether a roadmap item can be committed in writing, and half an hour convincing an account executive that a deal they like is not qualified. The depth in any single hour is lower than in an engineering role; the number of systems you touch in a month is far higher.

Compensation is the structural difference from every engineering job. Pay splits between base salary and a variable component tied to quota attainment — commonly somewhere between a 90/10 and a 70/30 split, depending on company and seniority — so part of your income depends on customer decisions you do not control, on cycles of six to eighteen months. What that changes is incentive. At quarter end there is real pressure to overstate what the product does, and the professional skill of the role is being the person who does not, because technical credibility is the only asset you have and it is spent permanently.

The relationship with the account executive deserves its own paragraph, because it determines how good the job feels. A good pairing is a genuine division of labour: they own the commercial relationship, the forecast and the negotiation, and they defer to you on what is technically true. A bad one treats you as a resource to be scheduled, expects you to say yes in front of the customer and argue afterwards, and quietly blames the product when a deal is lost. You cannot choose your pairing, but you can notice which one you are in within a fortnight, and it is a fair thing to ask about in an interview.

The vocabulary of a deal

Presales is conducted in a commercial vocabulary that engineers find opaque, and being fluent in it is a large part of being taken seriously on the sales side. Most of these words denote something specific, and using one loosely is noticeable.

Two rows repay attention. A compelling event is the difference between a deal and a conversation, and asking for it directly — what happens if you do nothing this year — is the most useful discovery question there is. And assumptions are the mechanism by which an honest estimate survives contact with procurement: an estimate without them is a promise, and an estimate with them is a conditional promise you can defend when a condition turns out to be false.

Demand, adoption and how that is changing

Presales exists wherever software or services are too complex, too expensive or too regulated to buy without a conversation, and that condition has strengthened at the top of the market while weakening at the bottom. Product-led growth genuinely removed presales from simple products: a free tier and good documentation replaced the demo call. Enterprise buying meanwhile got harder — security review, data residency, procurement scrutiny, integration into estates nobody documented — so deals that still need a technical seller need a better one.

Two forces push demand up. Buyers burned by platform programmes that failed after signature now want to interrogate the architecture before committing, which is presales work by definition. And AI products are being sold into organisations that cannot yet evaluate them, where the gap between demo and production behaviour is wide enough that vendors cannot close without someone technical in the room.

Two push down. Presales sits in the sales cost line, so cost-cutting stretches the SE-to-AE ratio rather than protecting it, and the routine work — first-line RFP answers, standard security questionnaires, generic demo builds — is being automated, which removes junior tasks rather than senior ones and narrows the entry route. The field is in real demand for people with both depth and presence, and harder to enter than it was.

The narrowing entry route has a practical consequence worth stating. The traditional way in was to be junior, answer questionnaires, build demo environments and learn the product by osmosis over a year. Where that work has been automated, the remaining roles assume you arrive with technical depth from somewhere else, which in practice means the common route in is now sideways from engineering, consulting or delivery rather than upward from a support or graduate scheme.

What makes it hard

You must be trusted by three parties whose interests conflict, with authority over none. The customer trusts you only if you will say your product does not do something. Delivery trusts you only if nothing you sell arrives as an impossible commitment. Your account executive needs you to advance deals rather than kill them. Every serious presales decision trades among those three, and you have only credibility to spend.

The live component is what people underestimate. In a discovery call or whiteboard session you reason in public about an estate you first heard about forty minutes ago, questioned by a specialist who knows their corner far better than you, with money attached. "I do not know, I will come back on Thursday" is the correct answer and is genuinely hard to say in a room that is evaluating you; bluffing once and being caught costs the deal.

Breadth cuts both ways. You hold enough identity, data modelling, integration, security, cloud cost and operational practice to be credible across all of it, which means you are almost never the most knowledgeable person present. Experience is not substitutable here: knowing which stated requirement will turn out not to matter, and which throwaway remark sinks the project in month eight, comes only from having been wrong about it before. The feedback loop is poor too, because deals close and fail for reasons you never see, and judging yourself on process quality rather than outcomes is harder when part of your pay is judged on outcomes.

There is also a grind that nobody mentions in the recruitment pitch. A formal bid can arrive as several hundred requirement lines with a two-week deadline, half of them ambiguous, several of them written by a competitor to exclude you, and all of them requiring an answer that is simultaneously accurate, non-committal and persuasive. Doing that well is genuinely skilled work and doing it at volume is exhausting, and a candidate who has only ever imagined the whiteboard sessions is in for a surprise. Ask in an interview what proportion of the team's time goes into formal responses, because the answer varies enormously between product companies and services firms.

Qualification, and the discipline of walking away

The judgement that separates experienced solution engineers from enthusiastic ones is knowing when not to invest. Every hour spent on an unwinnable deal is an hour not spent on a winnable one, and the account executive's incentive to keep a large logo in the forecast is not always aligned with that arithmetic.

flowchart TD
    A[Opportunity arrives] --> B{Is there a dated reason to act}
    B -->|No| C[Nurture, do not staff it]
    B -->|Yes| D{Can we meet the stated criteria without a heroic exception}
    D -->|No| E[Decline or ask to reshape the criteria]
    D -->|Yes| F{Do we have a champion who will spend capital}
    F -->|No| G[Invest only in finding one]
    F -->|Yes| H[Qualified, staff the solution work]

The gate people skip is the middle one. It is tempting to answer "can we meet the criteria" with a technically true yes that depends on an unreleased feature, a services workaround or an exception nobody has approved, and that yes is how undeliverable deals get sold. The professional version of the answer names the dependency out loud and asks whether it is acceptable, which either qualifies the deal properly or ends it cheaply.

The other thing to notice is that two of the exits are not rejections. Nurture and champion-building are legitimate investments at a much lower cost than full solutioning, and being able to describe that distinction is what makes a disqualification recommendation acceptable to an account executive rather than insulting.

The demo, and why most of them fail

Demonstration is the most visible skill in the role and the one most commonly done backwards. The instinct is to show the product; the requirement is to show the customer their own problem being solved. A demo that covers everything proves the product is broad and proves nothing about whether it helps them.

A DEMO THAT WORKS, IN FOUR MOVES

  1. Say back what you heard, in their words, and get agreement.
     "Last week you told me a failed claim validation sits in a queue
      for an average of three days because nobody owns it, and that
      is what is driving your complaint volume. Is that still right?"
     If they correct you, that correction is worth more than the demo.

  2. Show the end state first, for sixty seconds.
     The resolved claim, the empty queue, the dashboard a supervisor
     would look at. Buyers decide whether to pay attention here.

  3. Show only the path that gets there. Three screens, not eleven.
     Narrate in their vocabulary - claim handler, not user record.
     When something adjacent is interesting, say you will come back
     to it, and write it down where they can see you writing it.

  4. Close by naming what you did not show, including a gap.
     "I have not shown you the bulk reassignment flow because it
      works differently from how you described yours, and I would
      rather walk through that properly with your team on Thursday."

WHAT KILLS ONE

  - Starting with an architecture slide. Nobody bought anything
    because of a box diagram in minute two.
  - Answering an unasked question at length, which reads as evasion
    of the one that was asked.
  - Recovering from a live failure by apologising for ninety seconds.
    The recovery is one sentence and then a move to the next point.

The fourth move is the counterintuitive one and the reason experienced buyers trust some vendors and not others. Volunteering a gap costs you very little because they will find it anyway, and it converts everything else you said from a sales claim into a report. In an interview role-play, the candidate who names a limitation unprompted almost always scores above the one who does not.

Objections, and how to concede a gap

Objection handling is the skill that most distinguishes a presales interview performance, partly because it is the one candidates cannot bluff and partly because interviewers can generate objections indefinitely. The underlying rule is that an objection is a question about risk, and the only two acceptable responses are an honest answer and an honest admission.

The pattern across the right-hand column is that every response either asks a question or concedes something. Neither behaviour is intuitive when you are being challenged in front of a buyer, and both are what make the answers believable. A solution engineer who has never once said "no, we do not do that" is a solution engineer nobody in the room is really listening to.

Conceding a gap well has a shape of its own. Say plainly that the gap exists, say what it costs the customer in their own terms, offer the workaround with its honest price, and then stop — do not immediately bury it under three compensating strengths, because that reads as damage control and undoes the credit you just earned. If a roadmap item genuinely addresses it, describe it as a plan rather than a commitment unless you have written authorisation to do otherwise, since a roadmap promise repeated in a contract negotiation is a problem that lands on somebody else.

Why study it

Study it if you like breadth and you like people. In a year you will see more real architectures, in more industries, with more of their embarrassing history exposed, than a platform engineer sees in five, because customers show you the truth when they want help. You also learn how technical purchases are genuinely made — who decides, what a CFO is really asking about cost, why the best product loses — and that is the raw material of product management, a CTO's office and any consulting career.

Study it too if you are an engineer who has noticed that the technical argument does not always win, and wants to understand why. The commercial layer above engineering is not irrational; it operates on constraints and information engineers rarely see, and a few months of exposure to it changes how you write proposals internally as well as externally.

Do not do it if what you want is depth. If you enjoy owning one system for three years and improving it under load, this will frustrate you continuously, because you leave every problem at the interesting point and hand it on. Do not treat it as an escape from difficult technical work either; the demands move from the compiler to the room. And if being measured on other people's decisions would eat at you, treat the variable pay as a reason not to do this.

If a presales loop is next week, expect a shape unlike an engineering loop: a presentation round where you are given a product and an hour, a discovery role-play graded on your listening ratio rather than your answers, a whiteboard solutioning round, and a commercial conversation about qualification and estimates. Scoring weights heavily towards how you behave when you do not know something, which means the single most valuable thing you can rehearse is saying so cleanly and then saying what you would do to find out.

Your first hour

Do the deletion exercise. Pick a product you genuinely understand, then invent a specific buyer: not "a bank" but "the head of claims operations at a mid-sized motor insurer, 400 staff, on a mainframe-era policy system with a 2019 web front end". Write ten questions you would ask in a first call, in order. Then delete every question whose answer you could get from their website, their annual report or their job adverts. Most people lose seven.

Deleted (findable, or answerable yes/no):
  "Are you on AWS or Azure?"          -> in their engineering job adverts
  "Do you use Kubernetes?"            -> yes/no, and it changes nothing you would do
  "What are your main pain points?"   -> invites a rehearsed answer

Kept (only they can answer, and the answer changes the solution):
  "Walk me through what happens today when a claim comes in and fails validation
   - who touches it, and how long does it sit?"
  "You have lived with this for years. What made this the quarter you decided to
   do something about it?"
  "If this went ahead, who else has to agree, and what would they each need to see?"

Write the survivors on half a page with two lines underneath: why this buyer would choose you, and the single thing you would have to prove to them. That half page is a qualification note, and it is the first real artefact of the job.

If you want a harder second exercise, take the same half page and write the three assumptions your solution would depend on, in the form a statement of work would use — "assumes the existing identity provider supports SAML and that customer staff configure it", not "assumes SSO is fine". Then ask yourself which of the three, if false, would cost the most to discover in month four. That question is essentially the whole discipline in one line.

What this is not

It is not sales support, and treating it that way is how organisations end up with presales teams building decks nobody reads. A solution engineer makes technical judgements and owns them, including the judgement that a deal should not be pursued.

It is not sales either. You do not own the number, the negotiation or the relationship, and an SE who starts closing deals usually stops being trusted as the honest technical voice, which was the whole value.

Nor is it post-sale architecture: the presales architect owns the promise, the delivery architect owns the outcome, and firms that blur the two produce either undeliverable proposals or delivery teams who commit to nothing. Where the same person does both, watch for whether they are given time to hand over properly, because the handover is where undocumented assumptions are lost.

It is not product management, though the two are often confused because both sit between customers and engineering. A PM decides what gets built for everyone; a solution engineer decides what to promise one customer using what exists. The feedback loop between them is real and valuable, and an SE who logs the reasons deals were lost is doing product management a favour that is rarely returned.

And it is not less rigorous than engineering. The rigour moves, from correctness under test to correctness under cross-examination, where the reviewer is a hostile specialist, the review is live, and the artefact you are defending becomes a contract.

Everything you say in presales is eventually read by someone who has to deliver it, so the discipline is not persuasion — it is making commitments narrow enough that they are still true a year later, in front of people who would prefer you were vaguer.