In yesterday’s post, we discussed how building a story around the resolution of customer problems is a way to attract customers to your solution, yet few in the OSS industry seem to go about it this way.
To build this story though, you have to understand your customers. For example:
- What functionality of yours do they use
- What processes do they run using your tools? Is it the complete process, or only a sub-set
- What networks do they run it over
- What data sets / sources do they needs
- But most importantly….. why???
Understand these things and you can build a set of process / network-device / data bundles (aka use cases) that serve multiple purposes:
- For demos – They demonstrate how your solution solves end-to-end problems, not just offers functionality
- For benchmarking – If these are the most important end-to-end processes for the majority of your customers, then these are the ones you should seek to make ever more efficient
- For regression testing – To ensure your most important features are not broken by product enhancements
- For Proofs of Concept – When customers want to trial your product against another, it can be quite time-consuming to set up an environment with the context the customer is seeking. Using a set of use cases as repeatable building blocks will often provide the basis on which to customise the last final 10% rather than building an entirely bespoke PoC model
Creating use cases is all about increasing repeatability, which is not only reducing effort, but also increasing reliability of the factors listed above.
2 Responses
I fully agree. What is your experience at how good customers are at defining their use cases, respectively paying outside consultants to help them defining them? How well do customers agree internally on what their use cases are?
Hi Roland,
Great questions…
Actually, my intent of this was for vendors (rather than customers) to create a generic set of common/valuable use cases that they could use repeatedly across their own product suite for demos, testing, training, etc.
Then to answer your questions:
Q1. What is your experience at how good customers are at defining their use cases
A1. 50/50. Some have been good at defining their workflows, possibly independent of which tool ends up facilitating any given step. Others, haven’t documented or standardised at all.
Q2. paying outside consultants to help them defining them
A2. In the ones who already have well-defined use-cases, their internal teams have process definition teams. For the ones who are only considering them out of the necessity of OSS transformation, then I’ve found this challenge often falls on a combination of OSS vendor experts, customer experts and extenal consultants
Q3. How well do customers agree internally on what their use cases are
A3. Often very difficult to get concensus on, especially when an OSS transformation is driving change to workflows, isn’t it? I have some very interesting stories around this when helping customers with their workflows. 🙂
Interestingly, your line of questioning becomes even more important where customers want automations implemented for them, often without them realising automation comes from having a consistent workflow/use-case to follow.