Do you need to build a value story, business case, or ROI model with quantifiable benefits? Here are five guidelines I use to do this effectively:
- Listen early for evidence of impact
- Express value in the customer’s language
- Challenge the customer to think broader
- Keep your business case simple
- Be transparent and collaborative
1. Listen early for evidence of impact
From your very first customer meeting, you need to be discovering and documenting evidence of impact. What is the pain, or cost to the customer of the current situation? What KPIs are not being met? How often does an issue occur? What personal goals does your stakeholder have?
Ultimately, we are trying to identify a key KPI, forecast an improvement to that KPI as a result of adopting your solution, and quantify that improvement as a financial benefit.
As you continue to conduct discovery and qualification, ask more direct questions to uncover measurements and impact. Even if you don’t get a specific answer, such questions are good to get the customer thinking about the cost of their pain and the potential benefits. For example:
- How often does the system go down?
- How many team members or IT staff do you have?
- What is the cost to the business of a 1 hour outage?
- How much time does your team spend on reporting each week?
It’s really important to make notes and capture every data point you can, because they will become useful when you want to credibly present a draft business case.
2. Express value in the customer’s language
While you might have templates that you can start from to build a business case, if they use terms that are unfamiliar or do not resonate with the customer, then you are reducing the effectiveness of your value story.
Also, the different individuals you are engaging with may put different levels of importance on the same benefit. So we need to discover what is important to each of our key stakeholders, align our value story with those priorities, and use language that the audience will understand.
An easy action to take is to look up the customer’s annual report and review their corporate goals and KPIs. Look at the words they use and reflect this language in your value story. Think about how you can convey the message that adopting your solution will positively influence those corporate goals.
3. Challenge the customer to think broader
Often we are talking to technical or lower-level people who may only have a narrow understanding of the costs or benefits. They might see a benefit in your solution making it easier for their team to complete their own tasks, but need help associating that value with financial benefits and company goals.
For example, a solution that automates testing can help teams be more efficient and deliver application updates faster. One level of benefit is that this can save costs by making the team more efficient. Another level of benefit is that delivering app updates faster can provide a competitive advantage and increase revenue for the business. A QA manager may only care about the savings against her budget, whereas the business case is much stronger when we can also tie it to revenue growth.
There might also be costs borne by other teams (eg. infrastructure management costs), which your solution will help reduce, but may not be a direct benefit to your buyer. We may need to make sure this is called out and push for it to be included in the business case.
So, while we do want to express value in the customer’s language (see #2), there are times when we also need to challenge them to recognise the broader business benefits.
4. Keep your business case simple
There is a tension here between precision and simplicity but I strongly advise people to keep a business case as simple as possible.
All business cases rely on assumptions, so a single benefit calculation with some broad assumptions is much easier to create, explain and understand than a list of 20 detailed value drivers. A more detailed and sophisticated business case model is arguably more precise, and therefore more credible, but on the whole your customer is not going to have time to get into too much detail. If they get lost and confused by the business case then they may lose confidence in you and your solution.
One of my rules of thumb is to remove any value drivers or benefit statements where the calculated benefit is low and focus on the key items and KPIs that show the most benefit. If it is not material to the value calculation then I prefer to not talk about it at all. The only exception to this might be when there is a particular value or intangible benefit that I want to highlight (see #3).
5. Be transparent and collaborative
Best practice is to build a business case together with a customer stakeholder. Fantastic practice is to have your customer’s staff present the ROI model and conclusions to management, instead of you as the vendor.
Even if you’ve built the business case independently, be prepared to walk through all the detail, and to clarify and validate the assumptions made. If a customer challenges me on a draft business case, my response is, “This is based on a lot of assumptions and we’d love to work with someone from your team to make this more accurate”.
Customers are always going to be a little sceptical of vendor claims about value, so open and collaborative agreement on the assumptions is the way to go. It’s also helpful to make sure your draft business case looks “reasonable” and “conservative” before you present it to the customer for the first time.
Does your value story reflect business benefits of increasing revenue, reducing cost and/or mitigating risk?
Thoughtful Presales 