Raw capture â raw/solution-engineering-advice.md
url: https://maxhalford.github.io/blog/solution-engineering-advice/ date_fetched: 2026-07-05 backfilled: true
I joined Carbonfact as a first employee. In a nutshell, itâs software that takes in raw ERP and PLM data, and spits out environmental reports. I got pulled into many Sales processes and customer onboardings, in addition to building the software. As the company grew, so did my expertise, which made me relevant for selling to and managing big logos. We signed a lot of well-known brands in the fashion industry.
Nowadays I feel more or less comfortable interacting with customers. But I was awful at first. I know because one of the cofounders gave me harsh feedback after a call with our first serious customer. I still remember slamming the lid of my computer when we debriefed. What I perceived as harsh feedback at the time turned out to help me grow quickly.
I used to be a regular data scientist assigned to internal projects. Talking to prospects and customers got me out of my comfort zone. You owe them a service, and they expect you to deliver something. If something goes wrong theyâll go above your head to your founders, at which point you start feeling the heat. It can be quite harsh. But it can also be rewarding when things go well.
Every project is different, but there are tricks of the trade to pick up. I really like Jim Donovanâs Secrets to Optimal Client Service lecture. He gives out 11 pieces of advice:
1. Never use jargon.
2. Pause - slow yourself down.
3. Look for opportunities to give the client advice that is not in your interest.
4. Ask open ended questions.
5. Be positive.
6. Be careful about mixing business with socializing.
7. Be humble.
8. Be available - be responsive.
9. Take a position - tell the client what to do.
10. Control the meeting.
11. Have an agenda, get the client to buy into it, and take notes.
I think this is an excellent starting point. Each piece of advice resonates with my experience. But Jim Donovan is a bigwig at Goldman Sachs, and Iâm just a solution engineer at a small climate startup. I therefore wanted to write down my own advice, based on the battle scars I earned.
There are three phases which I got to experience:
The goals at each phase are not the same. Also, the relationship you nurture with the customer changes when a contract is signed â contracts will do that. Your attitude should also vary according to the level of trust going your way. Therefore, each phase has to be treated differently, and adaptability is key.
I didnât get any bonus when we signed a contract, so my livelihood didnât change whether or not we gained a new customer. That took a lot of the stress away from meeting prospects. But it didnât make me less motivated: I genuinely enjoyed partnering with the Sales team, and convincing prospects we were the right solution for them. I found it rewarding when we turned them into customers.
Regardless, presales is to me the least stressful phase. To make an analogy with relationships, itâs like flirting. Everyone is on their best behavior and the conversation is very polite. This is because nobody owes each other anything â yet. And even if the prospect ends up picking a different solution, thereâs always the option of them coming back to you down the road.
Presales is all about value perception and building trust. The people in front of you are desperate to pick the right solution. Picking the wrong one could cost them their job. Signing with you is a big deal to them. Having empathy for that goes a long way.
Youâll normally partner with a member of your Sales team. This teammate is in charge of figuring out the lay of the land, by mapping the prospectâs organization chart, and identifying the decision makers. If theyâre part of an organized team theyâll follow a framework like MEDDIC. You donât need to concern yourself with this. Your focus should be on convincing the people your Sales buddy succeeds in putting in front of you.
Your Sales buddyâs incentive is financial. They want to sign the deal, almost at any cost. They appreciate having you with them, because you know more about the product than they do. But they are worried you donât have Sales instincts, and can screw the deal by being too honest.
What you should avoid is having your Sales buddy make an impossible promise. Promising something that doesnât exist yet but will/could happen is different from promising something that you know will never happen in the years to come. The latter is lying, the former is overpromising. Lying can secure a short term deal, but everyone loses in the long run.
I perceived part of my job as being the link between the Sales and Tech teams. And I believe keeping that channel open matters a lot. The tech team will take the sales team seriously if the latter keep themselves honest. Itâs all about finding the right balance between the current state of the product, whatâs in the pipe, what the customer wants, and what the Sales team wants to say. I think this is an important part of being a solution engineer.
Thereâs usually some sort of project manager who oversees the process. This person initiated the decision to buy software. Theyâre not C-level, but they might lead a (small) team, and have some internal leverage. This person is your most likely champion, and you wonât manage to convince the rest of the company without one.
Winning them over is the easy part: they kicked off the search, so their reputation is tied to the project succeeding. The hard part is that they donât call the shots on their own. Your real job is to help them convince the decision makers at their company to choose you. The advantage is that theyâre on your side, and can tell you what makes the decision makers tick, what needs to be emphasized, what questions may come up, etc.
In rare cases, the prospectâs alternative isnât another vendor: itâs building the solution themselves. In other words, youâre competing against the prospectâs own engineering team. In that situation, the person youâd hope to turn into a champion may be lukewarm at best, since they may have a stake in the build-it-in-house option. But it doesnât change much. The goal is still to explain the value of what youâre doing.
Your Sales buddy might bring you into a meeting to give a demo. Limiting yourself to the demo is the biggest mistake you can make. Thereâs a good chance the demo wonât wow the prospect. Especially if youâre a startup and your product hasnât fully matured. Giving a demo is a big deal: youâre opening the hood and showing the customer the software theyâre going to buy. Up until now theyâve been admiring the bodywork from the curb; now youâre handing them the keys. The good impression you nurtured so far can go south in the space of one meeting.
In my opinion, the best thing you can do is to get into a conversation as soon as you can. Ideally, by asking open-ended questions, the customer can hint at what theyâre worried about. You should make the demo relevant to their pain points, and avoid showing (cool) features that arenât relevant to them. Also, by letting them talk, you make them feel important. People love to go on and moan about their work. Youâre here to listen, and to get on their good side.
As a technical person, you know a lot about the software youâre selling. In fact, youâre likely the most knowledgeable person in the room â and if youâre not, you need to upskill to become that person. Donât overprepare. The best meetings are those that turn into a conversation, where you have a reassuring answer for each question/concern the prospect throws at you. You need to come off as knowledgeable, calm, and confident. Bear in mind, the prospect is not just signing for software, theyâre also expecting to get professional services to help them use the software. This is your shot to give them a good impression.
Something I like to do is name-dropping, such as:
We worked with brand X, which you may know, and they use the same PLM software. Their data was heterogeneous, but our system is designed for that situation.
Another thing I occasionally do is to undersell the platform:
We implemented this feature a long time ago, itâs a bit old. Weâre planning to revamp it soonish.
In my opinion, the worst thing is demonstrating a feature and expecting the prospect to drool at it. It wonât happen so donât hope for it. Underplaying what youâre showing is a subtle way to say âwe have a high bar, weâre just getting startedâ. Of course, this depends on your audience. Some prospects need everything to be perfect right away, and arenât as trusting. For those you should limit yourself to a short demo on the most polished features, and move the meeting into a conversation. Read the room.
Again, your Sales buddy is nervous because compensation is at stake for them. They donât want you to mess up the deal by opening too many doors. That makes sense. You need to earn their trust before you can take the liberty of moving away from the script.
While itâs beneficial to show off expertise, itâs counterproductive to come off as a geek. The prospect wonât sign for something they donât understand. You need to say smart things in a language they understand. And more importantly, you need to say things that solve their pain points. The prospect is here because they want to tackle something they canât with their internal resources. When you sense youâre going too far into a topic, go back to the initial reasons why theyâre here.
Iâve mostly worked in startup environments. Iâve never been at a place where the product is polished and signing a new customer is a well-oiled process. When youâre at a startup, you feel youâre punching above your weight when selling to enterprise customers.
You wonât be rewarded for always telling the truth. Thatâs not obvious when you come from a technical background. Personally, it took me some time to accept seeing one of my cofounders oversell who we were and what we were building to our prospects. But in a startup, especially in the enterprise SaaS category, faking it till you make it is necessary.
A good metaphor is that the tracks are being laid while the train is moving forward. You have to make the deal move forward â thatâs the train â but all the features the customer wants arenât ready yet â the tracks. But if you trust yourself and your team to build those features eventually, then itâs ok to be a bit dishonest with the customer. There are many situations where the customer will take your word for it and wonât check themselves whether a feature exists.
The prospect has access to the platform you give them access to, and to you as a person. They donât know the vision for your company as well as you do, or what features are next in the pipe. Itâs up to you to share with them the vision for the company. Itâs totally ok to discuss big features that are coming up. In fact, this is a great way to get them excited to work with you.
I understand this section can make me come off as dishonest. Thatâs not my intention. My goal is to satisfy customers. At Carbonfact, I trusted our solution more than I did that of our competitors. If overselling was what it took to get a worried prospect over the line, I felt fine doing it. I was confident theyâd end up better served with us than without.
Pilots are the trickiest situations. The prospect has decided to move onwards, which is a sign theyâre interested in your product. But they are not convinced well enough to sign a full contract. You still have to earn their trust. To continue the dating analogy, this is the first time your date is staying at your place. All the veneer you showed during dates can vanish if youâre sloppy at home.
A key parameter is the duration of the pilot. You want enough time to fulfill what needs demonstrating. But you also donât want it to last too long. The more the pilot drags on, the more the prospect will turn over rocks you donât want them to. Also, the longer you wait to sign a deal, the likelier it is that the prospectâs top management pulls the plug and calls the project off. That happens. If you have the choice, my advice is to keep it short and efficient.
In order to avoid fruitless pilots, be careful not to accept impossible pilots. You donât have that kind of decision-making authority as a solution engineer. Nonetheless you should keep an eye on upcoming pilots in the pipe. Sometimes the Sales team accepts pilots too freely, when in fact a comprehensive demo with the customerâs data can be enough. Pilots are not a piece of cake, so itâs usually better if they can be avoided in the first place.
A pilot should kick off with specifications for the project. These will initially come from the prospect: they are the ones with pain points to solve. However, you should not accept these specifications without reviewing them. Ideally, you should be able to rephrase them, and suggest new ones.
Some pilots succeed because you make such a good impression that any prior doubts seem unfounded. It can go so well that people in the room will wonder why a pilot was needed in the first place. But you have to be prepared for the difficult scenario. Some prospects need to justify internally why theyâre picking you, and they have to back that up with something solid. This can be a list of business and technical criteria that you have to tick.
Your goal early in â and prior to â the pilot is to remove all ambiguity. Whether the prospect likes you or not wonât be relevant when they make the final call. The decision will be made based on the number of criteria you were able to tick during the pilot.
Simply put, each criterion should be measurable. You and the prospect have to be able to determine, without ambiguity, whether a criterion is ticked or not. That may require rephrasing. For instance:
- Measure product environmental footprint
+ Measure GHG footprint for >95% of 2025 production volume
Itâs counter-intuitive, but splitting a criterion into many can be beneficial. Indeed, several clear criteria are easier to tick off than one ambiguous criterion, for example:
- Provide modeling capabilities
+ Provide product level modeling via material country of origin swap
+ Provide company level modeling via material code swap
+ Provide company level modeling via supplier swap
Smaller customers are usually open to having their criteria rephrased. Many of them donât know exactly what they want, so theyâre open to suggestion. In other cases, the criteria might be more rigid. Especially in formal RFPs, where your pilot can be running in parallel with others, and the rules canât be modified. But even in those situations, Iâd encourage you to provide your own interpretation of the criteria.
Iterating over the success criteria can take some time. It will require some back and forth, because each of your propositions can get a rebuttal from the prospect. But it is worth it. Running a pilot with clear success criteria is far less stressful for both parties.
Youâll likely agree on a regular schedule to catch up with the prospect during the pilot. Iâve done this biweekly for six-month pilots, but I find weekly works better if possible. The goal is to keep the prospect engaged. Especially towards the beginning of the pilot, when you rely on the prospectâs technical team to get access to their data, clarify their mysterious business logic, etc.
You have to see the pilot as a race against time. The objective is to tick as many â hopefully all â success criteria before the end of the pilot. Many things can go wrong over the pilotâs duration, and some of these you canât prepare for â sickness, unannounced vacation, etc. But the main danger is to go off track. Surprisingly, the prospect isnât tracking the pilotâs timeline as closely as you are. They have no baseline for how long this stuff should take. If you slip, they might not even notice. Thatâs both a relief and a trap: the schedule is yours to enforce.
You have to prepare catch-up meetings. You canât afford to be on the back foot. The worst thing is to go into a meeting with the prospect without an agenda. It gives room for your prospect to bring their own agenda. They might have many questions that come up from using your software. These questions are probably relevant, but spending time on them can hurt you if youâre late on delivering the pilot. So go over your own agenda before you let the prospect bring theirs up.
Controlling the tempo makes you look professional. Coming into the meeting with a clear list of talking points is reassuring for the prospect. It makes them feel theyâre in safe hands. Indeed, one of their biggest fears is to have to use your software without any support. They donât want to be alone.
You should be proactive. Itâs not nice when a customer spots a bug on their platform before you do. If you spot an issue in their data, then you should surface this. Proactively pointing out issues is a great way to come off as a trustworthy person.
I would say that prospects in pilot phases require more attention than regular customers. Itâs normal to hold a strong tempo. The flipside is that all this time you invest can go down the drain if the pilot is not a success, or if the decision to buy gets rescinded â again, this happens. But thatâs the game.
An implicit goal of the pilot is to give the customer a good impression. Ticking off the success criteria is a must. Anything you can do to impress the prospect beyond their requirements can be beneficial.
You should let the customer know when you did something that took a lot of time. For instance, if you integrated some of their files, donât just tell them you did it. Tell them why it took time, what the difficult parts were, what your software streamlined, etc. By putting emphasis on your work, the customer will perceive your value. The last thing you want is to make your work appear trivial, because in that case theyâll be wondering what theyâre paying you for.
That being said, you shouldnât boast. Your goal is to get the prospect excited, by making them want to use your software. You donât need to impress them by explaining how you implemented a feature â they donât care â but you should instead demonstrate how it will simplify their lives. The difference matters.
One trick here is to space out in time what you show them. If youâve done many things this week, but you have nothing to show the week after, then balance things around. The prospect has a limited attention span, and thereâs a limit to the technical mumbo jumbo you can throw at them at once. A steady drip of small wins is more memorable than a single firehose meeting.
Remember that the prospect is buying you as much as the software. They canât grade your code, but they can tell whether you make their problems feel manageable. Narrate the hard parts, space out the wins, and bring some enthusiasm. The experience of working with you is part of the value theyâre paying for.
The prospect has decided to become a customer. Theyâve signed a contract, which is usually binding for at least one year. Now comes the onboarding phase, where the goal is to get them to be proficient with your software. An onboarding is similar to a pilot, in the sense that thereâs a lot of heavy lifting and teaching to perform. For instance, parsing their messy data to ingest it into your tool. This should be less stressful than a pilot, because theyâve already signed a contract. However, onboarding will necessarily test the relationship.
The customer has formed an impression of what your software will do for them. This impression might have been sweetened by the person who sold them the software. And the software will probably meet their needs, but they first need to go through an onboarding phase for their usage to be smooth. Unless youâve built intuitive self-serve software, which was not the case at my company.
Onboardings demand an unusual time investment on your side. And the customerâs patience will wear off the more it drags on. My advice is to compress the onboarding as much as possible. If you can afford to do at least one catch-up meeting per week, then do it. Itâs usually more efficient to do the same amount of work in two months than it is to spread it over four months. It keeps the momentum going, and it leaves a good impression with the customer.
Be solution-oriented. Sometimes onboarding can feel like fitting a square peg in a round hole. Maybe the customerâs data maturity is not there yet. Maybe they are missing some required data points. Maybe their data is there, but itâs messy. The main reason youâre here is to work around these problems. Itâs easy to whine and put all the troubles on the customerâs back.
You have to learn when to ask the customer versus when to fix it yourself. This is an ability you acquire over time. Now when I meet a new customerâs IT point of contact, Iâm able to perceive whether theyâre capable or not. If I ask them to fix something on their side, I need to trust them to follow through. If they donât, the project will be at risk, and youâre the one who will be blamed. Trust the right people, and if thereâs nobody to trust then do it yourself.
In a healthy SaaS company, youâll review onboardings and deep dive into the ones that went over schedule. The reflex in those retros is to point at the customer: they were late providing data, their IT was unhelpful, their team kept changing. Some of that is even true. But blame is a dead end, and it wonât make the next onboarding go any better. A good solution engineer assumes that whatever the circumstances were, it was their job to adapt. If something went wrong, itâs on you. Even if youâre not a Navy SEAL, the concept of Extreme Ownership should resonate with you.
When possible, itâs better to treat the customer as a partner. Personally, Iâm not a fan of the usual balance of power that customers are used to. I donât want to be just another resource in their eyes. I always try to make them see me as a helpful partner, on an equal footing.
Itâs cheesy, but donât forget to have fun. Make jokes. Onboardings can be stressful, but if no lives are at stake, then thereâs no reason for a tense atmosphere. Youâll be working with this customer for years to come, if things go to plan. So be nice, do a good job, and eventually the customer will mellow.
Of course, this isnât something you can impose. Trust is something you obtain after putting in the hard work. Be humble at first, be more efficient than what the customer is used to, and eventually you will earn their respect. Sounds obvious, right?
Love creates growth.
This was often quoted at my company. The idea is that customers you treat well become the channel through which the next ones arrive. When youâre a startup, the earlier stage you are, the more prospects are reluctant to work with you because of your size. Youâre great at punching above your weight, but the prospect hasnât worked with you yet, so they have no strong reason to trust you. What theyâll usually do is have a chat with one of your existing customers. This can make or break a deal. This is when you appreciate the worth of all the hours you poured into helping your customer.
Some customers will be happily content with your software and get on with their lives. Some customers are more demanding, and expect your software to accommodate their every whim. When these customers are nice to work with, they can become design partners.
Ad hoc work that doesnât fit into your product roadmap has to be avoided. Thatâs not what youâre here for, youâre not a consultant. Itâs important to learn how to say no, and log customer demands into the product feedback pipe.
Your role is to be the person the customer likes and trusts. If something is wrong with your solution, and the customer is putting the blame on you, you should deflect to someone else in your organization. You should say âyouâre right, this part of the software is pretty bad, let me put you in touch with someone in our Product teamâ.
Some difficult customers just love being design partners. They love basking in the limelight and being heard by people. And itâs a win-win situation: Product feeds off customer feedback.
In some cases, customer demands are impossible to fulfill and unreasonable in the first place. In order to not significantly degrade your relationship with them, you should put them in touch with a âbad copâ at your company. This can be the Account Management team, which will explain that their demands do not fit in their contract â hopefully your contracts are quite clear as to what your solution provides. Sometimes these situations escalate and involve founders/C-levels. This isnât a problem: as long as youâre the good cop and someone else can play bad cop, you handled it well.
I enjoyed being a solution engineer. Itâs a refreshing change from working on software in the background. I also sense that being in front of customers turned me into a better data scientist. Itâs much easier now for me to put myself into the customersâ shoes, see things the way they do, and perceive what matters in the software I design.
Iâm convinced many data scientists and engineers underestimate their worth outside their usual scope. The clarity of thought a data-trained person brings is still underappreciated across many parts of a business. Plenty of companies still run on a swamp of ad hoc Excel files, with no real system for organizing themselves. That bar is lower than it looks from inside a tech team.
These days, Forward Deployed Engineers and Product Engineers are well sought after, and each is having its moment. With the rise of AI, and the commoditization of writing software, your worth can increase by becoming a technical mind that can chat with customers.