What is technical discovery?
Technical discovery is to learn about the systems a prospect has – you’re trying to see how well they align with the product your team offers. Does the prospect have the right technical profile and IT makeup to fit with your product?
Why is it important to conduct technical discovery?
If there isn’t a match they can’t be a customer – if the technical fit isn’t good, they’re not going to be very happy or be a customer for very long. When there isn’t enough technical discovery upfront, all that discovery ends up being the implementation team’s responsibility. If they learn that they can’t meet the customers’ needs with the product, then it becomes hard (or sometimes impossible) to keep that customer.
If you skip it, it makes for a hard and expensive onboarding – it makes for really high operational costs when people aren’t able to use the product. Plus, it’s a bad experience for the customer experience.
What types of companies or products need to develop a technical discovery process?
You need some technical discovery for any product that isn’t stand-alone – if there is any point of integration into an existing system or process. People often think of it as purely being for integrating with other SaaS solutions, but if your tool is trying to get into a process, there is some form of technical discovery that has to happen during the sales process.
It can be fairly simple if there’s one key integration – e.g. Salesforce because the connection between your product and Salesforce can be established and very transactional. There aren’t too many operations that are trying to happen.
It becomes very important if you integrate with a lot of other tools – if your tool might be integrated with a lot of other tools that the prospect is already using, then all have to be essentially vetted. If you don’t do discovery upfront, you’re setting implementation up for pain; they’ll essentially need to come up with custom solutions, and that’s not scalable.
Who runs the process, and who should be involved?
Initially, the person who needs to make this customer successful should own technical discovery – when a company is first starting, it could be someone post-sales (an account manager, implementation manager, technical account manager, or customer success manager). That post-sales person knows exactly what type of technical questions customers are going to get later, and those should be brought forward to the pre-sale process.
As you get more sophisticated, the conversation should move toward pre-sales – where you’re trying to get the Solutions Engineers to do it pre-sales. If your company doesn’t have SEs yet, or if it’s a very simple discovery process, AEs can do it. If it’s complicated, with specific nuances within each of several integrated tools (e.g. complex configurations), an SE should do it.
Continually calibrate around CS – the inspiration for all those technical discovery questions starts with what our customer support people face. Also, check that you’re asking about things that are issues–there might be something that you think is a really important part of technical discovery, but then you talk to your CSM and they tell you that no one really uses it. The key is that your pre-sales technical discovery and your implementation steps must be in alignment, and iterate as your product develops.
During what stage of the sales process should technical discovery happen?
After you’ve qualified that there’s a business need – it’s not during the prospecting phase of figuring out if they’re a lead. Start technical discovery once you establish that there’s a real business need for them, to ensure that the software is going to work with their needs.
You can do a fair amount within the one-hour demo call – depending on how fast your sales cycle is. If it’s pretty simple, whoever is running the demo can weave key questions in there to check that they’re going to work as a customer. There may be a follow-up technical deep dive, workshop, or guided trial to handle detailed questions. The choice of these depends on your product and the individuals involved from the prospective customer’s buying team.
If it’s more complex or developer-focused, it could be multiple conversations – in a complex deal, technical discovery would start to go in parallel with some of the budgetary conversations and some of the later stage steps because you’re building interest. If your sales cycle is 12 months, you’re probably going to have a few weeks’ worth of meetings that are technically discovery-oriented.
What categories of tech tools do you need to investigate?
The tools you need to understand depend upon what your product does – technical discovery for every product will be different (depending upon what the product touches). You can build out the list that matters for you, based on what customers ask about.
For example, if you’re a sales and marketing tool – pay attention to everything within the marketing ecosystem.
- Data enrichment
- Marketing Automation
- CRM
- Reverse IP / ABM technologies
- Sales engagement technologies (e.g Outreach or SalesLoft)
For example, if you touch their website – pay attention to the technology their site is built with
- Is your website built on React?
- Is it a static web page?
- Is it a single-page application? If so, is it built on Angular, Ember, or React?
- What are your requirements for performance?
- Do you have security requirements for how you can load JavaScript on your website?
For example, if you’re in e-commerce – pay attention to shopping carts, payment providers, and coupon tools
- How are they listing and selling their goods? Are they using Shopify, Magento, Big Commerce, Square marketplace, etc.?
- For the cart experience, what type of system are you using for delivery? Do they use coupons or gift cards?
- How are they managing when an order is placed? This likely touches their ERP.
- How are they collecting money – what different payment providers do they use? What’s the rate that each one takes?
What information do you need to collect from the prospect (and how do you collect it)?
Demo → questions → workshop – usually you’ll do a demo to get people interested, then there might be a couple of questions (and they might decide to loop in their technical counterpart to get them involved). Do a conversation with them, ask some more high-level questions on that call, and follow up with some of the things you may need more detail on. Then use that as a time to present that you may need to dive in deeper and do another workshop call and go step-by-step to determine how you solve it.
Start with getting the right people in the conversation – I know it’s kind of silly to say (but this is something that goes wrong), you have to have the people that will know the answers to your questions in the room.
Ask “will this cause issues with your workflow” – show them the workflow because you can’t ask every question. People need to see it to understand it. Ask them, “how might this process compare with how your sales team would do this right now?” That usually makes it easier for them to provide you with more information.
Make it a “workshop” – this will be a very effective tool to not just do a technical deep dive, but also to have a longer amount of time to ask questions to build context. It gives more time and hands-on experience, which has the added benefit of eliminating the need for trials.
If they’re using a technology you’ve never worked with, do some inspection – you may need to pull up during your regular discovery and say, “hey these are the questions I need answers to.” Ask if you can have access to do a technical inspection, or set up a time to go through it together.
What testing might you need to do as a part of the sales process?
You shouldn’t need to do testing for most customers – for 90% of the customers you shouldn’t have to test anything live pre-sale. Set up a demo scenario as similar as possible to the environment that they’ll have.
Make the demo look as similar to their setup as possible, so they trust it – when they see all of the things on the front of the website, they see their business. The more custom it is, the more you benefit twofold because you get them to confirm or deny that this is how it would work.
You might be able to build up your own instance for a client if there’s a common testing need – if you know a prospect’s technology stack, you can recreate some of it on your own and build up your instance. It’s very cost-intensive when doing it for the first time. So you need to determine how often you’ll be doing that to see if it’s worth it.
What technologies should you have plans to work with?
Prioritize based on revenue volume
- The most common systems – try to identify the most common technologies, operations, or systems that are at play because they’ll impact your ability to be successful with the greatest number of customers
- The systems big customers use – big customers can represent disproportionate amounts of revenue. To land big dollar-volume or strategic-value accounts, prioritize what big customers are using.
How do you handle prospects that have incompatible or challenging technical setups?
If you run into things you don’t do, figure out what they’re trying to solve for and frame other options – say “we see why you want that, but we can’t do it for XYZ reasons”. You have to figure out what they are trying to solve, what integration they want, or what capability they want. After you do that, you can give them other options and reframe their thinking.
Don’t lie, let them make the technical trade-offs – there may be things your competitors do to integrate with a technology that is more seamless than yours. When that comes up say, “Hey, we don’t do that”, but we do have these workarounds. We can do it, but we’ll have to go outside of the standard process to accomplish it. Better to be upfront than it is to make everybody look bad.
Solutions engineering is a nice balance between sales and support – Sales generally leans towards saying “yes, we can support that” and Support generally leans towards saying “no, we can’t support that.” Solutions engineering is trying to think of ways to make sales happen but also are a counterbalance to the AE’s (who of course want every sale to happen) and Customer Success, who want to make sure the customer is happy
What should you be willing to manage on a custom basis post-sale?
Avoid custom work whenever you can – avoid custom work at all costs. It should never be a large percentage of your deals.
If you make an exception, it should be for a very big deal or for strategic customer growth – and even then, make sure to scope the integration into the contract, otherwise, you’ll effectively agree to unlimited custom development.
Do listen to requests, and factor them into your roadmap – be prospect-led by the calculation of the number of requests, the monetary value, and the strategic value of the logo.
How do you streamline and track the technical discovery process?
Figure out what the big building-block questions are, and track the answers in a template – if you can start to make technical discovery simple and templatized, with no gray area, AE’s can do it, and you’ll multiply your ability to do the technical assessment.
As you get more sophisticated, build it into your CRM or turn it into a score – if it’s in your CRM that everybody has access to, it becomes part of your pipeline conversation. You can create a technical fit score, which you can factor into an ICP score (ideal customer profile score).
What are the most important pieces to get right?
Preparation is the path to success – going into technical discovery, you need to know who you’re talking to. Look at their LinkedIn, backgrounds, and even where they went to school. It tells you a lot about where these questions might come from. The more you can glean about them, the better.
Ask smart questions – if you go down a question list rapid-fire, that’s bad for you and your customer. The customer won’t feel like they’re being engaged, and it’s possible that you’ll ask them something that doesn’t apply to them. Instead, do as much research as you can manage beforehand. The questions become “smart” when they are tailored to the customer’s specific criteria, environment, and operations. Bonus: You’ll come across as much smarter and more helpful if you arrange the questions within the demo.
What are the common pitfalls?
Don’t have multiple people on your team ask the same thing – if you ask the same question where you’ve already had multiple people on your team ask it, and then you ask it again, you’re not recording it/making a note of it. That’s problematic and a bad customer experience.
Don’t let customers assume you have capabilities you don’t – be clear about what you can’t do when customers ask; don’t make the mistake of thinking it doesn’t matter. Letting a prospect believe something works in a way it doesn’t lead to wrong assumptions that could matter a lot later on.
