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:
Understand these things and you can build a set of process / network-device / data bundles (aka use cases) that serve multiple purposes:
Creating use cases is all about increasing repeatability, which is not only reducing effort, but also increasing reliability of the factors listed above.
Making your OSS easy to use isn’t about adding more “easyness” – it’s about subtracting what sucks. “To make your stuff “easier to use” you
During my first forays into OSS, over a period of 6+ years, I averaged 85 hours a week whilst being paid for a 40 hour
The call came in at 5:43am. “The routers are acting up again down at 1313 Packetloss Lane” the night supervisor whispered, as if afraid the
Telco appears to be an increasingly tough industry. Demand for connectivity continues to soar, yet profitability and differentiation are becoming ever more difficult to achieve.
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
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.