Presales solution engineering is the technical half of a sale: designing, demonstrating and pricing an answer to a customer's business problem before anyone has bought anything. It is engineering under commercial constraint, and the deliverable is being believed by the buyer and by your own delivery team.
High demand22 min readSolution Engineer / Sales Engineer, Presales Consultant, Presales Solution Architect, Specialist or Overlay Solution Engineer, Principal Solution Engineer / Solution Engineering ManagerUpdated 2026-07-27
Assumes you know: Enough engineering depth to design a system and be cross-examined on it, Willingness to speak, unrehearsed, in front of people who can say no
Overview
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.
Mode
What it is for
The characteristic failure
Discovery
Find the funded problem and the decision process
Leaving with a feature list and no idea who signs
Demo
Make the answer credible in twenty minutes
Showing everything the product does
Proposal
Make it defensible without you in the room
Prose that quietly became a contractual promise
POC
Retire the doubts that block the deal
Free delivery work with no definition of done
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.
Now practise it
21 interview questions in Presales & Solutioning, each with the rubric the interviewer is scoring against.
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.
Subsection
What it is for
Discovery & Qualification
Finding the funded problem and the decision process
Solution Design & Proposals
Turning findings into a defensible written answer
RFP & RFI Response
Working a formal bid under time pressure
Demos & POCs
Proving it live, and defining what proof means
Estimation & Commercials
Effort, staffing, licensing, TCO and margin
Objection & Competitor Handling
Hostile questions and real gaps
Presales Scenarios
Role-plays as they actually run
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.
Loading diagram…
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.
Term
What it means
Why it matters technically
Champion
Someone inside the account who wants you to win and will spend capital on it
Without one, your proposal is read by nobody in the room where it is decided
Economic buyer
The person who can release the money
Often never met by the solution engineer, which is a risk worth naming
Compelling event
A dated reason the customer must act - a contract expiry, a regulation, a migration
No compelling event usually means no close, whatever the enthusiasm
Decision criteria
The stated basis on which they will choose
Your job is often to influence these before they are written down
Decision process
Who approves, in what order, and how long each step takes
Determines whether the date in the forecast is fiction
Qualification
The judgement that an opportunity is worth pursuing
The one call that is yours as much as the account executive's
POC exit criteria
Written conditions that define success before work begins
The only defence against a proof of concept becoming free delivery
TCO
Total cost of ownership across licence, infrastructure, people and change
The number a CFO asks about, and the one demos never address
Statement of work
The contractual description of what will be delivered
Your assumptions end up here, in language you did not choose
Assumption
A stated condition on which the estimate depends
The single most valuable thing you write, and the first thing cut for brevity
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.
Loading diagram…
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 objection
A weak response
A response that holds
Your competitor does this natively
Disparage the competitor
"They do, and it is genuinely better if that is your main workflow. Here is where the difference stops mattering, and you should test both."
It will not scale to our volume
Quote a marketing figure
"What is your peak, measured rather than projected? Let me show you what we run at that shape and where the first bottleneck appears."
Your product cannot do X
Promise the roadmap
"It cannot today. There are two ways round it and both have a cost. Which of them is tolerable is your call, not mine."
This is too expensive
Discount immediately
"Against what alternative? If we compare against the cost of the current process, I would want to include the four staff doing manual reconciliation."
We tried something like this and it failed
Distance yourself from it
"What specifically failed? If it was adoption rather than technology, nothing I show you today changes that and we should talk about it."
Your security posture is unclear
Send the standard pack
"Which control are you actually worried about? I would rather answer that one properly than send you sixty pages."
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.