For most of my career to date, I have been responsible for identifying and implementing an Enterprise Software solution for my customers. I have been operating in this capability, for over ten years. In many cases, I have been also the architect ultimately accountable for the successful technical delivery of that solution, once it was identified and agreed upon.
In this article, I will share some thoughts around managing the Solution definition process in an Enterprise Software engagement, from the point of view of a Solutions Engineer.
Starting from a diagram showing where these steps fits within the overall engagement itself, we will discuss the key differences between Qualification and Scoping (at the technical level). I will then share some tips which, based on my experience, are significant to improve the overall management of these steps.
Sounds good? Let's jump straight in then.
Anatomy of the Technical Qualification and Scoping Process
Technical Qualification and Scoping are critical moments that are embedded in either the pre-sales or post-sales processes of a Customer engagement. By 'engagement', I mean all the interactions unfolding between someone looking to solve an issue and someone else offering a solution for that problem.
Generally, before a commercial agreement is reached the accent will be on qualification. Once an agreement is in place, the focus will shift heavily on scoping and solution design.
This is not to say that these activities are strictly compartmentalized. For example:
To reach a commercial agreement between parties, many buyers will want to get a reasonably detailed understanding of the solution to be. This could be either through a Proof of Concept implementation or a high-level architectural design. In such cases, scoping a solution at the right level of detail will be crucial.
After the commercial agreement is reached, it is not uncommon that a customer will bring forward new aspects not considered before, or changes to the original plan. When this occurs, these must be reviewed and qualified accurately so that they can be either incorporated into the existing scope (if appropriate) or further discussed when they introduce a significant change to what was originally agreed.
In this article, I want to focus on the Pre-Sales part, and what role qualification and scoping have in this context. Here is a diagram illustrating a typical workflow and where these concepts come into play.
Let me highlight some key aspects:
As we see, we have two tracks running in parallel (Commercial and Technical). The commercial track is led by the opportunity owner - usually an Account Executive (AE). They are ultimately responsible for the execution and outcome of the whole process and will be at hand to facilitate all the phases of the Technical Track. In most organizations, the Solution Engineer (SE) will lead and be ultimately accountable for the Technical Track.
I won't be spending time discussing the Commercial track. I wanted however to highlight the Commercial Qualification stage, which then usually develops into Technical Qualification, and the Proposal stage, which needs a positive Technical outcome to be completed (summarised as Technical feasibility and Technical fit).
While the diagram is sequential, we shouldn't think that we will always move strictly from one stage to the next and never look back or iterate on previous stages. Instead, consider this as a useful blueprint, to begin with, and adapt depending on the complexity (or simplicity) of your scenario. For example, there may be three macro areas that need to be treated with separate "mini" technical tracks. One of these three might be a "nice-to-have" solution that, while important, will not form part of the initial package. For a Customer, it might be still important to understand that topic, but it is unlikely to be a key decision factor and might be managed separately.
Within the Technical Track stages, I have highlighted whether this is a predominantly qualification or scoping activity. Sometimes qualification and scoping are used as synonyms, but I think there is a subtle difference between the two (more on that later).
The Proof of Concept stage is an optional step: sometimes a good technical demo is all that is required to confirm the potential solution to a customer problem, and then we can move forward directly to Scoping and Solution Design.
I have included an interaction with the Technical Track during the "Paper Process" phase. The Paper Process phase indicates generally a stage where we have a high level agreement to proceed, and we have started drafting the required paperwork to complete the engagement. During this phase, it is not uncommon to receive additional technical questions from the Customer department engaged at this point (for example, Legal, Security etc...). These questions are generally looking at overarching aspects of the Solutions (certifications / data management / service level agreement etc...), which is why I labelled the step as "Non Functional Requirements". We won't be covering this phase in this article.
Qualification and Scoping: what is the difference?
I mentioned earlier that more often than not the terms Qualification and Scoping are used interchangeably. Sometimes they can be seen as synonyms.
In my opinion, this is the key difference:
Qualification is what happens when we still don't know much about something and we need to check our understanding. We are investigating and looking to generally validate that we can solve the issues presented to us.
Scoping is what happens once we have confirmed our high-level understanding, and we are iterating down to the required level of detail needed to confirm our proposed approach. We could also be iterating up, moving from very narrow and specific requirements to the bigger picture.
Consider this example: we get pinged by our friendly AE about an upcoming call with "AcmeCorp". They give us a summary of what has been discussed so far, and list some "technical requirements".
Sometimes (if we are lucky), these requirements are already well specified and clear. More often than not, there will be a more generic problem statement which could mean many different things. Other times, the requirement may be a very small capability needed, without any other context.
In all of these cases, the first and most important thing is that we qualify. Even in the first case, we shouldn't take for granted that the information we have got is final or even up to date. When we get to talk to "AcmeCorp" ourselves, we will be responsible for asking questions to determine what is the main concern and objective of the customer.
At the end of that call, it will be our job to summarise back what we heard and ask if our understanding is correct. If the customer confirms then we have Qualified this opportunity (from a technical point of view) and we can move to the next steps - provided that we think we can help them.
We then move to the Scoping phase, where we guide our Customers in seeing first-hand how their problem can be mitigated or removed completely by implementing the solution we have in mind for them. There will likely be many more details that will be uncovered in this process. The customer will have more questions and will want to understand exactly how they will be able to apply the solution we are proposing to their specific use case. Maybe they will want to test drive it themselves with our guidance.
If both steps are successful, there will be a clear, mutually agreed scope between ourselves and our Customers. The Customers will also have a firm understanding of what our Solution, as scoped, does to cover their requirements.
Again, don't forget that these are not assembly stations in an automotive manufacturing line. We will need to quickly switch from the qualification to the scoping mindset while "en route", all the time, as we learn more about the problem we are trying to help with.
Many times, even our Customers will be learning and gaining deeper insight about the issue they set out to solve, and there will be discoveries and challenges all along the way. They might even see the original issue from a different perspective, once they spent sufficient time dissecting it with you.
This is exactly why being a Solution Engineer is an interesting and rewarding job 😎
Some practical steps to improve your Qualification and Scoping
You might be agreeing with all the above, but what can you do to improve how YOU carry out these crucial steps in your organisation?
The truth is, the principles behind it are quite straightforward. Imagine when you have a problem/need and you are looking for a solution. You will have done your initial research, and have a shortlist of candidates. You will then evaluate each one on the surface of what they seem to be providing. You will dig out reviews or feedback from other people who already used these products or services.
You will reach out to each, expecting your queries to be answered in a satisfactory manner and in a timely fashion, with courtesy. You'll make sure that you are about to buy a square peg for patching your square hole, and not a triangle-shaped contraption.
You'll expect to be advised of the different qualities and materials of each peg and clearly understand why you should pay more for that specific model you eyed out, compared to the one that broke and needs replacing. Then you'll make a decision.
This will not be that different (at a conceptual level) from any type of sale of a product or service.
What will make the difference here is the execution, in other words how the whole process will be experienced by your customer. Again, imagine when you are on the other side of the table, what experience would you like that to be?
Here are my tips for each "operation mode" you will find yourself in during the pre-sales phase as a Solutions Engineer.
Set expectations with your Account Executive
Before a call is even scheduled, you should work closely with your AE and agree on a plan of action. Clarify the topics you would like to cover, and what are the desired outcomes of the call from your perspective. If expectations have been set already with the Customer, ensure they are appropriate. If they aren't, agree on how to address and reset these expectations during the call.
Prepare ahead of the meeting
You should be discovering as much as you can about the organisation and people you are going to discuss with. Can you find out what technologies they employ today? Do they have a technical blog that gives you an idea of what is important to them? Who is going to join the call, and what level do they operate at?
Don't plan for a super technical deep dive if the customer joining is the CISO of the organisation and will be looking at a more holistic overview. Still, have that technical deep-dive segment ready in your back pocket if the CISO turns out to be particularly interested in the architecture of your product 😉
Use the time to ask about things you cannot easily find about yourself. However, if you have found out something, and it's crucial, it's always best to confirm your understanding quickly in that call. Don't leave assumptions unchallenged.
Make it a conversation
I've been at the receiving end of corporate/generic presentations countless times, and many times it's not a good feeling. Plus, these overviews should have been already covered earlier in the commercial process.
In a technical qualification call, your goal is to understand the "lay of the land" on the Customer side and what are the needs/problems that they are facing. It is useful to ask a few open questions to get the conversation going. Listen carefully to what you are being told, and ask for relevant clarifications.
When appropriate, summarise back what you heard to your interlocutor and check that you have understood correctly.
A good outcome here is to get to the end with a confirmed understanding of the problem/issue/requirement. A great outcome is to have already mapped it to a potential solution!
Maybe you already solved a very similar issue for another Customer, and in some cases, you are allowed to share that story. This is a great way to further confirm your understanding and also to show that a very similar problem has been already solved.
Confirm next steps
Once you have gone through the technical qualification, make sure it is clear to all parties what the next steps will be. The AE working with you will likely help drive this and take note of the actions, but having your notes is best practice. After all, the AE may not appreciate some specifics that the Customer shared on the technical implementation side of things.
If there is a need for a further qualification round - perhaps because some significant aspects are still unclear and might need discussing with a different set of people - put forward already some tentative dates for this to happen.
After the meeting
You or the AE should be following up by close of business that day with a summary of what was discussed, the key outcomes of the discussion, and the list of actions and target dates.
If, following these conversations, you already have a good grasp of what the solution could be, attach any relevant technical documentation or even a high-level diagram of the system, showing where your solution would come into play. Offer a demo of that specific capability to your contact.
Importantly, before that follow up, check first that the stars are also aligned on the Commercial Track. If they are not, there is a high risk that any further concrete step might be a waste of time for everyone involved.
What about Technical Demos?
This topic is quite frankly too vast to be covered here - there are entire training courses that focus on this specific area only. One for another day!
Present a plan to your Customer
Once you have captured the required qualification details, confirmed that a solution in principle exist and gained the approval of the Customer in moving forward, it is time to demonstrate in more detail how the features that you demoed to the Customer can be applied to their specific use case.
If the Demo was particularly successful, you might have covered it there already. If the case is complex, or the Customer wants to gain hands-on experience on the platform, then a Proof of Concept might be the next logical step.
In all cases, we need to be mindful of both our Customer's and our time. Proposing a plan goes exactly in this direction.
For example, we could offer a call to review a specific feature with the development team that would be responsible for integrating and implementing it once the agreement is in place. After that, we could arrange a follow-up session to summarise and present the Solution, to be reviewed with that Customer for a final technical validation.
Having a plan gives structure to the actions taken by both parties, and seeing what all the steps will be will give everyone a chance to advise and add/remove steps that are required or unnecessary. Bonus points if you can also give indicative estimates of effort for any task that must be done by the Customer.
Proof of Concept / Trials
Engaging in a Proof of Concept (POC) is a significant undertaking for both the Customer and your organization. The Customer must allocate the time and the resources to test drive your solution, you will need to support the whole effort from start to finish, and your organization will need to provide an environment for the test to take place.
Consequently, it is imperative to make sure that we are not wasting anyone's time. Thankfully, because you have done your Qualification (have you, right?) you know that this will not be a futile attempt at spinning wheels. Even then, you need to be proactive and include a POC execution plan that you will share with your Customer, in a document (preferably a collaborative one). In my opinion, the document should include at least:
Key stakeholders on all sides (including partners, if involved).
Key customer dates (both for the POC itself and for the solution deployment).
The products that are part of the POC: this might be a subset of what is in the offer. Let's focus on what needs a technical proof only.
The details of the environments to be used for the tests.
Scenarios & Success Metrics: each aspect to be tested should be agreed upon with the Customer. Each one should be attached to a defined success metric: this can be a yes/no answer (for functional checks) or something measurable. Ideally, these metrics should underpin the overall business metrics that the AE will include in the proposal.
Assumptions & Limitations: if we are making any assumptions, let's note them down and have them shared with our Customers in our document. Same if there are some limitations (for example, "we agreed to not cover scenario X because of Y, as discussed with Z"). Transparency is key, and a shared collaborative document goes a long way.
Timeline: how long the POC will run? When are we meeting to check progress, and to draw conclusions? By which date do we need a Technical Proof Outcome decision? What happens when the POC is deactivated?
References to our documentation: much better to have them bookmarked in a shared document than lost in some e-mail thread our Customers can no longer find in their inbox. The same goes for any important Q&A we addressed during the whole process.
It should be fairly simple to build a template for the document itself, then re-use it appropriately for your engagements. In my experience, most Customers will greatly appreciate this type of guidance during a trial period and will use the document to keep track of actions and important notes.
It should go without saying but... you should always partner up with your Account Executive for advice, insight and help. When dealing with technical scoping, it is easy to get sucked up into the minutiae and develop some "tunnel vision" that focuses only on the implementation. We are Engineers after all.
Yes - we are engaged because of our expertise and technical knowledge, and Yes even our customer expects us to split hairs when talking about the technical capabilities of our platform. Even so, it pays off to keep a good sense of the overall picture … and guess what, your AE's chief job is to keep a very vivid painting of the whole situation at all times!
For example, we are dying to show our Customers a particularly elegant technical solution, when our AE tells us that one of the Customers just shared with them a painful anecdote about having attempted to implement something similar in the past. Phew! At least we now know that this is a sensitive topic and we should be careful when presenting it. Or we could decide to present an alternative, less elegant (in our mind) approach - which we know works as well and is less risky.
Teaming up goes both ways: thanks to our "Engineering" focus, we might be able to spot opportunities that would just fly over the head of someone non-technical.
Be proactive and discuss these with your AE: it might turn out that adding a solution for the extra scenario you identified would vastly increase the projected benefit for the Customer, with a marginal cost increase to the Solution, making the overall proposal much more compelling to everyone. Sweet! 🙌🏽
Think Long Term
As I mentioned at the beginning, I have been part of post-sales implementation teams for many years, and I've seen many times what is the difference between a good and a bad handover, and how painful that can be for everyone involved.
When an agreement is reached, things are just getting started. All the scoping and planning now needs to be translated into flawless execution. The very first impression on the onboarding side of things will set the tone for the relationship between the Customer and our company, for better or worse.
As Solutions Engineers, we can do a lot to increase the probability of starting with the right foot. Starting from Qualification and Scoping, we now have a very good idea of why that particular Customer has chosen us. What is important to them? What features are critical? By when do they need to be up and running? We should have this information already neatly documented as the output of the process.
Make sure that the crucial information is passed on, so that when the Customer begins to onboard they will not feel like they are repeating themselves or - even worse - that they now feel completely disconnected from the prior conversations.
After all, the Customer has likely chosen your solution not only because it will solve their issues but also because, having worked closely with you during the Technical Track, they now trust your recommendations. Repay that trust by sharing comprehensively your acquired knowledge with those that will be on point for delivering on your promises, and be available to step in again in the initial onboarding phases to make it seamless.
If, even then, something crops up and goes wrong, do your best to support and advise the onboarding team. Help them get past the hurdle as quickly and painlessly as possible, and keep your Customer in the loop.
In this article I have shared some thoughts around managing the Solution definition process in an Enterprise Software engagement.
Starting from an illustration showing the overall process, we discussed the key differences between Qualification and Scoping (at the technical level). We have then reviewed some suggestions aimed at improving how we manage these steps.
I hope you have enjoyed this article. I would be delighted to know your tips and tricks on this topic. Please feel free to leave comments or suggestions below.