What even is solution engineering?

In an MSP world, the lines get a little blurry

At some point as an engineer, someone started bringing you into client conversations before the work had even been sold.

Maybe it was framed as “just in case”. Maybe you were there to sanity-check a scope. Maybe you were the one writing the scope. Either way, at some point this stuff became a significant chunk of the job.

That’s presales. And there’s an entire formal role built around it that a lot of MSP engineers don’t get introduced to.

In last weeks post, we touched on what this looks likes in large vendors. The titles vary but the job is roughly the same: be the technical layer between what a client thinks they need and what will actually solve their problem.

Run the discovery that gets underneath the stated requirement. Scope the solution, including the risks. Sit across from a decision-maker and translate the technical answer into something they can act on.

There are entire frameworks that get taught for this. MEDDPICC is one. BANT is another, Sales qualification methodologies that teams use to work out whether a deal is even worth spending time on.

They covers things like identifying the real decision-maker, understanding the client’s actual pain underneath what they’ve described, and figuring out whether there’s genuine budget and appetite to move. Vendors train their presales people on it. There’s certifications, formal training and even commission structures around it.

If you’ve been a senior engineer at a lean MSP for a few years, there’s a solid chance you’ve been doing a version of most of this. Without knowing it had a name, let alone acronyms.

I think this hybrid role is more difficult in MSPs, and rarely well enough defined.

In the formal defined version, presales and delivery are separate functions. The presales engineer scopes the solution and hands it to delivery.

At a lean MSP or reseller, and just like me, you’re often both.

Which means when you’re in the presales conversation, you’re running two streams at once. The client-facing one: understanding the requirement, building the solution, making the case, and winning the deal, and then there’s the delivery track running quietly underneath it. Can we actually support this. Does the team have what they need. What does this look like in 6 months when something breaks at 2am.

That second half is what the formal presales role doesn’t usually have to worry about. It’s the delivery team’s problem. And it’s what I think makes the MSP version more complex. Because every commitment you make, you have to make knowing you’re the one who has to actually deliver it, which means you’re a little more cautious.

If you’re in this position, you’re not just doing a job that happens to include some presales. You’re holding a function that larger organisations split across two roles, and most people in it don’t realise that’s what they’re doing.

Balancing what’s possible to promise against what’s possible to deliver means understanding the client, the scope, the team, and the risk in each.

I’ve never had presales in a job title. Delivery has always been at the top of the job description, presales has always been thrown on top.

Once I recognised I was doing two roles, it got easier to tell which one I was in, and which one I actually enjoyed.

Danny 🤘