Presales and solutioning fundamentals

They convert a customer's business problem into a technical answer that can be believed, priced and delivered, before any money has changed hands. In practice that is four things: running the technical half of discovery, shaping a solution that fits the customer's constraints rather than the ideal one, sizing and defending an estimate that delivery will have to live inside, and being the person in the room whose technical statements the customer treats as true. The deliverable is not a diagram, it is credibility — a buyer who believes the approach and a delivery organisation that believes the number. The cost of the role is that you are measured on a commercial outcome you only partly control, and the temptation that comes with it is to win by promising, which is the single behaviour the role exists to resist.

The presales architect optimises for a decision, the delivery architect for an outcome, and that changes almost everything downstream. Presales works with twenty per cent of the information, on a deadline set by the customer's procurement calendar, and produces artefacts intended to persuade as well as to be correct; delivery works with the real system, discovers that assumption six was wrong, and lives with it for two years. Presales is rewarded for breadth and for speed of judgement — being roughly right about eleven things quickly — while delivery is rewarded for depth and for being exactly right about the thing in front of them. The failure mode of each is instructive: a presales architect who never delivers drifts into optimism nobody corrects, and a delivery architect doing presales over-designs and prices the deal out of contention.

Candidates describe presales as "supporting sales", which tells an interviewer nothing about when they are pulled in or what they own at each point.

The first box is the one worth arguing about. Sales qualifies the lead commercially and often calls the architect in only when a demo is needed, by which point the customer has already been told what the solution looks like and your job has quietly become ratifying it. The stronger arrangement is technical involvement from the first discovery conversation, and the argument that wins it internally is not fairness but rework: late involvement is where unpriceable commitments get made.

The bid or no-bid gate is the stage most candidates omit entirely, and its absence is what produces the pathology of a team that pursues everything. It is also the one stage where the architect's opinion should be able to stop the deal, because the technical feasibility judgement is not one the sales lead can make.

The negotiation stage is where deals are actually lost after being won. Scope moves in procurement — a must-have appears, a date shortens, a rate card is squeezed — and if the architect is not present, each change is accepted without being repriced. The discipline is that every redline goes back through the estimate, even when the answer is that it costs nothing.

Handover is the last box because it is treated as the last box, which is the problem. The architect who signs the promise should be accountable to the team inheriting it for at least the first month, and being able to say so unprompted separates a presales candidate from a demo operator.

In the gap between what will win this quarter and what will be deliverable next year, and it is structural rather than personal. The sales lead is compensated on signed revenue in a period, so a commitment that creates trouble in month eight is nearly free to them and expensive to you; you are the person whose name is on the technical claim and who will be quoted back in a delivery review. It shows up as pressure to say yes to a roadmap item, to soften an assumption, to remove a caveat that "makes us look weak", or to shave a number to hit a price point. The functional relationship handles this by separating roles explicitly: the sales lead owns the commercial position and the customer relationship, the architect owns what is technically true, and neither overrules the other in front of the customer.

The solution architect, and the answer matters because the ownership is usually left ambiguous until something goes wrong. Ambiguity here has a predictable resolution — when a delivery review asks who committed to a three-month migration, the sales lead points at the solution document and the architect's name is on it. So the practical stance is that no technical statement leaves the building unless you would defend it in a delivery post-mortem, and anything you are unsure of becomes an assumption with a condition attached rather than a softened sentence. The corollary is authority: if you own the promise you need the right to refuse a claim, and a presales function without that right is a proposal-writing service that will be blamed for outcomes it could not shape.

Visibility, and specifically a named delivery representative who has read the estimate and the assumptions before anyone signs. What you owe them concretely is the sizing basis rather than the total, the assumptions the number depends on, the risks you accepted knowingly, and an honest statement of what was not investigated. The reason to do it before signature rather than after is that afterwards it is information and beforehand it is a veto — delivery can say the integration effort is understated while the price is still movable. The cost is real: involving delivery slows the bid and sometimes raises the number out of contention. The alternative cost is worse, because a team handed a deal they consider unwinnable delivers it as though it were unwinnable.

By replacing refusal with pricing, because "no" makes you the obstacle and a price makes it a decision. The move is to convert each demanded yes into a conditional one — yes, with these two assumptions, at this cost, delivered in phase two — so the sales lead can still take something positive to the customer and the commitment stays bounded. Where the request is genuinely impossible, say so once, in writing, in plain language, with the reason, and offer the nearest thing that is true. What settles the pattern over time is being right in public: an architect whose caveats turn out to have mattered gets listened to, and one who caveats everything indiscriminately is routed around within two quarters.