How we fall in love with our OSS ideas

Do you know what it is that people like / love about your OSS/BSS?
Why they buy it? Why they use it? What problem it solves? How it makes their life easier?

If you do, how do you know?
Do you speak with its users? Do you survey them? Do you spend time with them observing how they use your product? Is it just the “vibe” you get?

Do you actually have a way of measuring what the masses actually use? Actually quantifying, not just guessing. 

Did you notice how I switched tack there, from like/love in the first paragraph to use in the preceding paragraph? We’ll get back to that too, but let’s first look at quantifying use / volume.

The long-tail graph below shows a product’s functional features on the x-axis and the number of times it’s used during the log-period. Are you able to log all customer use of your product and create a graph like this?

The big-impact demands are the features that get used. They’re also probably the features that were in your original MVP (Minimum Viable Product).

I once worked with a vendor alongside someone I now call a friend. We were trying to deliver an OSS/BSS project with many modules. One of the modules was proving the be quite problematic. Our customers just didn’t like it. It had lots of features that had been progressively built into the product over a number of years. The only problem was that the developers had never really spent much (any) time working in operations… or even speaking with anyone who did.

My friend was getting fed up with this particular module. He did have ops experience. He was with me on the customer site and dealing with people who also did (ie customers). He intuitively knew what the product module needed. So he took it upon himself to write a replacement and he finished it in a single weekend. A single weekend!! He showed it to key customer stakeholders on the Monday morning and they loved it. They pushed for it to become their product because it delivered what they needed. It was an MVP that needed further enhancements and functionality, but in a single weekend it did all the big-impact functions (ie the left side of the graph above).

It soon became the product that other customers used too, replacing the original product that had years of development effort invested into it. The new product became a selling point during product demos, whereas the original product had been a liability.

This reminds me of the quote below from Andrew Mason (the founder of Groupon).

The biggest mistake we made was being completely encumbered by this vision of what I wanted it to be… instead of focusing on the one piece of the product that people actually liked. You’re way too dumb to figure out if your idea is good. It’s up to the masses.”

There are some products out there on the market that have been around for decades. The frameworks that underpin them are out of date and they’re in desperate need of an overhaul. Unfortunately, their vendors are rightfully hesitant to throw away all the work that has gone into them to create a much-needed replacement.

However, if they’re able to log their use like the long-tail diagram above, they might be surprised to find that a new product with only MVP functionality might replace most of what customers actually want and need. [I do caveat the “might” in the sentence above because some OSS/BSS products do require a lot of complex capabilities]

But let’s come back to the earlier statement about love/like vs use. Not all of the functionality that customers love/like is actually used a lot. There might be functionality like bulk migration or automation of rare but complex tasks that customers only use rarely but adds a lot of value. That’s why you still need to consider whether there are some functions that appear in the right-hand block of the long-tail that need to be implemented, not just summarily excluded from your product roadmap. That’s why the long-tail diagram has red/green colour-coding to identify what’s actually needed.

A couple of final notes.

It can be harder to evaluate what people like in OSS/BSS products because they’re high-cost / low-volume (of buyers), especially compared to mass-market products like Groupon. It’s harder to evaluate directional sentiment for OSS/BSS products because the user group is compelled to use the products whether they like them or not.

Similarly, do you have a way of measuring the efficiency of what customers use via activity duration analysis? Similar to the long-tail diagram above, we have another approach for measuring efficiency of use.

If you would like any guidance on your product roadmap, especially quantifying and prioritising what functionality to add / modify / remove, we’d be delighted to assist.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.