OSS Procurement Events: Buyers do Judge the Book by the Cover

One of the things I love about my job is all the vendor demos I get to see. Product demos are one of the four important steps in the “inverted pyramid” vendor selection process we follow with our carrier and utility clients as we go about finding a best-fit new OSS and/or BSS solution for their needs. And the vendor selection process is an important pre-requisite for any network operator before they embark on a vital OSS/BSS transformation.

The process we use is very different from the ones used by most carriers. Our approach has been derived from the experiences of sitting both sides of the fence – as a network operator (buyer) trying to evaluate the best-fit solution for their unique needs, and as an OSS/BSS vendor (seller) trying to demonstrate why a solution is best-fit for an operator’s needs – as well as the facilitator trying to bring buyer and seller together.

This privileged position has allowed us to garner many insights into buyer and seller psyches as well as ways in which we can bring the two together more efficiently (in terms of time, cost and resources).

I’ll share two of those insights with you in today’s article and they’re closely related.

Buyers do Judge the Book by its Cover

There’s an old saying, “don’t judge a book by its cover.” I’m sure you’ve heard of it. Sad to say, but an element of this happens on almost every vendor selection. There’s almost always a vendor (or vendors) that has lots of functionality, but their user interface (UI) is dated and/or their workflows are clunky (even when a skilled user from the vendor company is driving).

To look deeper into the analogy:

• The Cover of the Book: This is the equivalent of the UI of an OSS. If your OSS UI looks unattractive or old, the evaluator will almost always assume the rest of the product is also old, inefficient and not worth considering more deeply. You’ll quickly be filtered out from further analysis
• The table of contents (TOC) of a non-fiction book: This is equivalent to the list of features of your OSS. Many evaluators don’t have the time or interest to read the whole book, so they’ll only look for the TOC or summary. Yes, it helps to confirm that all the right topics are being covered by the book, but it doesn’t tell you whether there’s any quantifiable value being provided
• Content of the Book: This is the equivalent of the workflows of your OSS. The most important part of your book is how it reads and what insights or learnings it delivers. If the workflows are inefficient, it means the solution is inefficient. Not many vendor evaluations ever get down to this level by benchmarking or comparing the efficiency of a solution. This is partly because it can be time-consuming and costly to do so

By comparison, we do look at the cover for an initial impression / indication of fit for purpose, then do a fast-scan review of the TOC, but then narrow in for a closer look at the contents to identify the specific features and end-to-end workflows that most move the needle for a given network operator client.

We’re less interested in the number of features across the X-axis (the TOC), but more interested in the effectiveness of the features in the red-box (the content relating to the parts that most move the needle).

Unfortunately, many of the OSS vendors out there are designed by highly skilled engineers for highly skilled engineers. For these product designers, we suggest you spend more time on UI / UX / CX than you currently do. As mentioned above, the initial UI impressions can tend to be the first layer of filtering out done by the network operators.

The Power of Simplicity

Don’t underestimate the power of making things easy for your customers:

• Easy to understand / learn (the book’s cover)
• Easy to evaluate / differentiate (the book’s table of contents)
• Easy to justify (the book’s contents that solve each buyer’s unique needs and problems)
• Easy to understand pricing
• Easy to order
• Easy to install
• Easy to configure
• Easy to implement
• Easy to secure, protect and ensure business continuity
• Easy to integrate
• Easy to evolve

I recently had a demo with a vendor that proudly announced that it can deliver full solution implementations in 9 months whereas competitors take far more than 12 months. Having spent years building these solutions, I know full well how much effort these solutions can take to implement, so their claim was definitely something to be proud of.

However, they appeared to be a bit taken aback when I asked, “What would have to happen if you could deliver in 2 months instead of 9 months? Would that give you a drastic competitive advantage?”

The answer is undoubtedly yes, but from their looks, I had the impression they’d never thought to ask a question like that. Nor even thought it possible perhaps?

What if we took it further – instead of 2 months, what about “the one person, two day challenge?” Could one person who’s not yet familiar with your solution (but has pre-requisite skills) set up your OSS / BSS product and demonstrate your product’s most essential use-cases with their own data / configurations and then demo to colleagues within two days? Would that be a game-changer for getting your OSS purchased by buyers?

Unfortunately, every extra month of delivery adds significant additional cost, effort and risk – all factors that prevent or delay OSS projects getting approved for implementation.

But it’s not just the delivery cycle we need to improve and take costs / risks out of. We also need to hasten the sales cycle. It might not be immediately obvious, but they’re closely linked.

“The confused mind says no,” so every little doubt a buyer has results in an extension to the sales cycle. It already takes many buyers 18 months to two years or more to make a commitment to buy an OSS so it’s incumbent on all of us – buyer and seller alike – to help drastically reduce the sales cycle.

Sellers may lament that it’s the buyers who take so long to decide. That’s certainly true, but there are so many things that sellers can do to make it easier for buyers to make a purchasing decision.

This reminds me of the story of when Brad Smith took over as CEO of Intuit in 2008. Intuit was already a well-established company known for products like QuickBooks and TurboTax. However, as with many large software companies as they mature, they were dealing with a large number of customer complaints and operational challenges.

Upon taking the role, instead of crafting a grand strategic plan for his first 90 days as many CEOs do, Smith took a very simple hands-on approach. He dug into customer feedback, reading complaint letters, online reviews and support tickets. He attended customer service calls and asked his team to collect extensive customer feedback to identify recurring themes and frustrations.

Instead of the 90-day plan, he created a list of things that needed fixing, including user interface issues, bugs and confusing workflows that customers had been complaining about for years. Fixing immediate problems and inefficiencies was Smith’s focus rather than developing new products / features or making re-org decisions.

Could the same apply to our OSS? Could we create a list of things that prevent new buyers from signing up to buy your OSS today? What layers of friction would need to be eliminated to make a purchasing decision a no-brainer and slash the sales cycle?

Put simply, we need to find ways of making things easier and faster:

The OSS Friction Continuums below possibly also give some hints about how to make it easier to buy your solution.