What is solutions engineering?
Technical partner on a sales team – solutions engineers are product experts, but also experts in helping to articulate the business value of the product or platform they support. They support account executives on the acquisition of new customers.
Why should SaaS companies invest in solutions engineering?
To get prospect questions and answers an AE can’t – the account executive needs to be the primary “quarterback” of the relationship, but it’s really important to have a team dynamic so that a prospect can ask the questions about how the business works without them thinking of the traditional sales context. When an AE asks a question, they typically get a different response than a solution engineer would because the solution engineer is all about helping the customer understand how the technology is going to work for them.
SEs can drive positive outcomes around:
- Product blend – for companies that have more than one product, involving an SE expert in the platform is very effective at helping to upsell or add features to the product; they “blend” that positioning to a customer.
- Long term success of a customer – you’re generally setting them up for success because you’ve done deeper discovery and brought product expertise to the table.
- Number of big deals closed – you’ll be able to execute more big deals with an SE function.
What types of companies or products benefit from solutions engineers as a part of their sales team?
Any software company should have some sort of SE function – the background and skill set vary, i.e. helping drive business value vs. providing deep product expertise. Even with SMB deals, you can take a one-to-many approach–if you’re doing $5,000 deals but the SE can assist with six deals a day, it warrants having somebody in the role.
SE is especially important with a technical product, and/or big deals – some technology is super sophisticated and very technical. There are a ton of various technical questions that can come in as part of the sales cycle. Think about investing more in solutions engineering anytime you feel that you would benefit from a team dynamic, when you’re starting to close bigger deals and have more complex sales cycles.
How does solutions engineering work with or overlap with sales enablement and solutions architecture?
Solutions engineering partners closely with sales enablement – especially in smaller organizations; oftentimes enablement will depend on SE to help create a lot of technical collateral. And the solutions engineering function depends on enablement to roll out programs because product expertise is a fundamental component of the job.
Solutions architecture tends to be post-sales – vs. solutions engineering is pre-sales. Solutions architecture is more likely to report into professional services, while solutions engineering reports into sales.
What are the key activities of solutions engineering?
Demos – preparing for and running demos is a primary activity.
Technical discovery – at the beginning of a sales cycle, which should inform virtually all your other SE activities. This involves really digging into understanding the technical stack, as well as the business objectives and business process.
Technical proof of concepts – helping evaluate and prove out technical requirements for a particular product for the customer.
Pilot or proof of value – prove value of a business process, or the actual use of the product in a real world sense.
When does it make sense to bring on your first solutions engineering person?
When you notice that AE’s are pulling in technical resources – if they’re depending on somebody more technical to help facilitate advanced sales cycles (e.g. from engineering, product, implementation, etc.), that’s when you know you need to bring a SE in.
Once you have a sales team of 3-5 AEs – at this point, they’ve got a sense for what the sales cycle looks like, how good demos are delivered, and an understanding for what the key activities are in that sales cycle.
Solutions engineering can do some enablement early on – I wouldn’t recommend it long term, because it’s good to have somebody focused on enablement. However, if hiring for both isn’t in the cards or part of your budget, solutions engineering can help facilitate a lot of enablement as well.
When you hire your first solutions engineering person, what should you look for?
The ideal first hire is internal – the traditional origin story is someone coming from support; they have the inherent product expertise, by way of being at the company already.
Whether from outside or inside, look for:
- Natural curiosity
- Someone who’s good in front of customers
- Technical aptitude
- Understands the business value
- Collaborative competency – can they work well with the AE’s? This can be one of the most critical points.
What are good questions or tests when interviewing AE’s?
Have them present a technical concept – if it’s a brand new SE, an exercise I like is to ask them to present an app on their phone and have them tell you why they like it, and what purpose it serves and what value it serves in their lives.
Get a perspective on how curious they are – assess their genuine curiosity for technology. If they don’t have a genuine interest, even beyond the company that they’re interviewing for, I think that’s sort of a red flag. It’s always good to get a perspective of “what do you think about this, what are your favorite companies, or what technology are you into?”
How many solutions engineers do you need?
For a very complex product – 1:1 SE: AE ratio. If it’s a super sophisticated product, and you’re selling big deals, you need one AE to partner with one SE at all times.
For higher volume sales – 1 SE might support 5-8 per AEs for a higher velocity sale. And then you need different techniques to make that SE more scalable.
How do you provide solutions engineering scalably for less expensive products?
Establish qualification criteria – for AE’s before they engage and resource an SE, to make sure they’re at a certain stage in the sales process. They’ve done minimum level discovery and it’s a qualified deal, so they obviously can distribute their time accordingly.
Offer public demos – where you can invite customers to do a live demo with questions and answers. There are multiple customers and prospects on the demo (which prospects generally like).
Use pre-recorded demos – that you can send out at scale. Instead of having an SE on the phone, especially since a lot of customers don’t want to get onto the phone until they’re pretty well qualified these days. You record demo videos, send them to the customers, and you can track where they start to bow out of those videos as well.
Are there different “flavors” or sub-specialties within solutions engineering, when would you need each?
If you’re selling something really technical, you need credibility – depending upon the product, you may need to hire for a certain background or level of experience. For example, if you’re selling a technology solution and only CTOs are buying it, you need to have someone who has that expertise or credibility. Credibility is essential; it’s hard to build and easy to lose.
If you’re selling something less complex, you can hire more for capability – you have more latitude in terms of hiring for competency versus specific expertise.
What’s in the solutions engineering tech stack?
Tools for demos at scale – e.g. Consensus for pre-recorded demos; these are top of funnel tools that help with the delivery of demo content. They’re trying to enable demos at scale because that’s been identified across many different companies as super calorie-intensive.
SE-specific CRM systems – e.g. Vivun or Reprise; these are built around common processes that are unique to the SE function and help accommodate things like product feedback or SE requests.
Demo infrastructure tools – e.g. Walnut or Demo Stack; it used to be that companies would create a custom infrastructure to manage their demo environment, but now there are companies that’re emerging that specifically do this. These take your product and make it configurable visually, so that you can rapidly scale demos, rather than having to create a new software infrastructure to manage it.
What processes or tools does solutions engineering create at their company?
The request process – once you get to a certain size, if you have one SE supporting many AE’s, you’ve got to put a process in place for how you engage that SE.
Note-taking processes – because SE’s do a lot of discovery, I generally have a pretty sophisticated approach to note-taking.
Contribute to technical relevancy of product marketing collateral – SE is responsible for the technical relevancy of any customer-facing documentation that the company is putting out, such as technical collateral or white papers.
How do SE’s cultivate and maintain product expertise?
You need naturally curious people – who love to learn because they just have a natural tendency to lean in there and seek out new learning opportunities.
Forge a connection with product and product marketing – as soon as you instantiate an SE function, you want them spending weekly time with the product team, at a minimum. Product marketing is also a very close friend of the SE function. I work with Product Marketing virtually every day, and that’s because we both work together to ensure that the quality of content is relevant. Also we’re staying ahead of product direction and messaging and all that.
SE’s should stay on top of internal channels – like relevant Slack channels and internal knowledge base pages.
How do you measure the success of solutions engineering? What metrics do you track?
ACV attach rate or attribution – so you know how much revenue the total SE team is attached to, both as an organization and for individual SE’s. This helps provide a perspective on what quantity or percentage of revenue SE’s are attached to.
- Look at % of revenue to make sure that you’re covering the big deals – percentage of revenue covered is a good indicator of whether or not we have the right coverage across the right opportunities. This isn’t an exact science, but strive for around 70% of revenue over a certain deal size threshold. There are some smaller deals that you’re just never going to touch though, so you omit those from the data set.
- Look at number of opportunities worked to make sure SE’s aren’t spread too thin – you want to know the number of opportunities people are working on because you get diminishing returns when people are working on too many opportunities.
Keep an eye on team engagement – this isn’t SE specific, but we’re making sure that folks on the team are continuing to develop their careers and develop their own expertise.
Contributions to subject matter expertise – you want to see SEs contributing content to areas that are critical to the company.
Things like close rate are interesting, but not core metrics – I don’t know that I’d make a decision about an SE based on the close rate of deals they were attached to.
What are the most important pieces to get right?
You’ve got to find the right “unicorn” people – finding somebody who has the technical aptitude and expertise and is really good in front of customers is tricky. They also have to have empathy for the sales function to the extent that they can partner really closely with your salespeople. That’s perhaps one of the most critical things and where I’ve seen people fail the most as SE’s.
What are the common pitfalls?
Don’t be inaccessible to sales – it’s damaging to get the relationship with sales leadership wrong. If you’re putting up barriers for sales to do business with SEs, that can be super ineffective because you’re seen as an inaccessible resource, and that’s not the way you want to be perceived.
Getting the number of deals that SEs are working on wrong – you need balance. If your team is burnt out, win rates go down, and activity per opportunity goes down. So keep a tab on the number of deals that SE’s are working on, because once they get past a certain threshold, you’ll start to notice fatigue.
Don’t neglect your early SEs – I’ve seen some companies hire their first SE and then the sales leader doesn’t even talk to them and just takes them for granted. You want to make sure that you have regular check-ins with that person (especially when there’s not a built-out SE function). Make them feel like they’re a strategic member of the team, because they are!