Discovery information sketch


A good discovery call/meeting should start at this level but Let's be clear from the beginning. "I want to build a new website" or "I want to send emails" do not constitute a business objective. As the name suggests, it's either a company or business unit level objective and would be more something like "we want to upsell our existing customer base to increase revenue" or "we need to make our business more profitable by decreasing our operational costs".
Ideally, the company will have a well defined and documented strategy that they can share with you under NDA that will give you plenty of details on their business objectives and what they already have in mind to achieve them.
In any case, you need to get to the bottom of it and keep asking "why?" till you're at the right level as you might not get the information you need right away.
See below an example of what the conversation could be like:

  • SC:"What are you business objectives?"
  • Client:"We want to replatform our current Content Management System?"
  • SC:"Interesting, can you tell me more about the underlying reason Why?"
  • Client:"Because we have too many of them and want to rationalise everything on one platform"
  • SC:"and what's the intent behind that?"
  • Client:"We actually have an objective to cut down maintenance costs by 20% over the next 18 months." -> Bingo!


Now that you've got the customer's vision, you need some tangible, measurable KPIs (Key Performance Indicators) that will later be useful to agree on what success looks like.
During your discovery, you need to differentiate, the business KPIs from your stakeholders' personal KPIs as they might differ. For example, the business KPIs of a company might be to increase market share by 5% while your main contact, let's say the Head of optimisation, is going to be KPIed on conversion rate only. Make sure you gather both. Your customers will be putting their careers on the line by choosing your technology so you need to make them as successful as the business itself.

What does Success
look like?

The same way as with the business objectives, you need to keep the discussion at a business level. "Achieving a 360 degres view of the customers" is neither the final outcome nor something you can measure and track. "Increasing the conversion rate by 1%" would be a great input.


If you've got the the desired outcome and the KPIs right, then it's mostly a matter of translating that into ROI (Return on Investment) and $$$. You'll be spending much more time with your customer and your value engineering team (if you have one) to build the business case and the ROI figures but getting a feel of how much $$ would be generated out of a "1% conversion rate increase" for example, will give you a good indication on whether your product's cost can be justified.
If their objective translates in $100K revenue increase and that your platform's TCO (Total Cost of Ownership) is $300K then you should be concerned and either look for a bigger problem to solve for them or be straightforward with them and call out it's not gonna fly.


So the use caseS (there will be few usually) will be a level below the business objectives and you'll definitely be flirting with the "How" to achieve the business objectives. So if we keep the same example, the "1% conversion rate increase", then a use case could be "To get a 360 view of your end customers across online and offline to better optimise their path to conversion".


This one is quite straightforward and can be summarised by the following discovery question: "Why can't you achieve the desired outcome (with your current technology) today?".
Note that I have left the technology part in brackets because I would suggest to keep it as open as possible considering that the gaps could very well be people/skills or process related.


Coming now to the awkward question. "What's your budget?". A question that some people tend to struggle with during discovery, afraid to appear rude and offend the customers.
Contrary to what people might think, there's no reason for customers to take it personally. You're here to make some business with that person afterall and it's crucial for both side to identify early if there's a "misalignment" between the customers' budget and their ambitions. From there, you can spend more time educating them on TCO (Total Cost of Ownership) including ongoing costs as well as phasing their project to make it fit within budget. This will give the opportunity during phase 1 to prove ROI (Return on Investment) and to later justify additional budget for the following phases.
Keep in mind as well that there are different ways to "get an idea" of their budget by asking undirectly how much they are currently spending for their platform or even by socialising some ball park figures and observe their reaction.
In some case, no budget will have been allocated and you'll have to support building the business case to unlock it.


Timeline is a straightforward one. What is the timeline you're working towards? Do you have a compelling event like a new product release that will dictate the go-live of this project? Do you need to realise this objective by end of this calendar year?
Note that the absence of a compelling event will present the risk that this opportunity might drag on unless you manage to create some element of urgency by putting forward the cost of doing nothing for example.


This one is the bread and butter of any good sales person, it's about navigating a customer's organisation and identifying the budget owner, decision makers, the influencers and potential champions. Ultimately, you need to identify whoever is connected to or has some interest/investment in the project.


A bonus one for your discovery that is not on the initial drawing above: partners. As you identify the different parts of the customer's organisation, you need to understand which partners are already supporting them with their strategy, design, implementation and maintenance. They can be precious allies and will know the current ecosystem way better than you. Not to mention that the solution you'll be designing will impact them in some shape or form and hence, you need them onboard.

Liked this article?

Interested to read more on related topics?