Getting A/B comparisons running automatically in the minds of all your OSS evaluators

Are you familiar with David Heinemeier Hansson (DHH) and Jason Fried, the Co-Founders of 37signals (Makers of Basecamp and other software solutions)?

As far as I know, they’ve never had anything to do with telco OSS tools, but I do love the clarity of a lot of the concepts they share on the 37signals blog and in their books like, “Rework” (which makes it into my list of uncommon must-read OSS books) and “Remote”. They’ve helped bring clarity and a different perspective to the world of OSS for me even though I’ve never seen them write about OSS directly.

Let’s take the following quote as an example from a DHH post on LinkedIn:

“When Ruby on Rails was launched over twenty years ago, I was a twenty-some young programmer convinced that anyone who gave my stack a try would accept its universal superiority for solving The Web Problem. So I pursued the path of the crusade, attempting to convert the unenlightened masses by the edge of a pointed argument. And for a long time, I thought that’s what had worked. That this was why Ruby on Rails took off, became one of the most popular full-stack web frameworks of all time, inspired countless clones, and created hundreds of billions in enterprise value for companies built on it. But I was wrong. It wasn’t the crusade that did it. Since those early days, I’ve talked to thousands of programmers who adopted Ruby on Rails back then, and do you know what virtually every one of them cite? That original 15-minute blog video. Which didn’t contain a single comparison to other named solutions or specifically pointed arguments against alternatives. It just showed what you could do with Ruby on Rails, and the A/B comparison automatically ran inside the mind of every programmer who was exposed to that. That’s what did it. Showing something great, and letting those who weren’t happy with their current situation become inspired to check it out. Because those are the only people who are able to convert to your cause anyway.”

There are countless crusades currently underway in the world of OSS transformations. Some crusaders are from vendor-land, trying to spruik the merits of the solutions they’re selling. Some crusaders are from operator-land, trying to persuade their colleagues of the benefits of those vendor solutions. Others are trying to build a solution (and possibly a career) by being entrusted with building new OSS from the ground up.

The challenge though is that there is no perfect OSS solution and there is never a single way that OSS can solve a problem or problem set. There are always many different possible solutions, each with different pros and cons. That’s probably why there are over 500 vendors, and countless products, that serve the OSS/BSS market and that’s just the off-the-shelf variety. That doesn’t consider the home-grown and/or component-built solutions that are helping to keep telcos operational the world over.

Many crusaders are attempting to convert the unenlightened masses by the edge of a pointed argument – pointed arguments against alternatives. Pointed arguments via lengthy requirement list comparisons where requirements often extend for thousands of spreadsheet rows. Pointed arguments via solutions documentation. Pointed arguments via competitor analysis. Pointed arguments via slide presentations.

Sometimes the best form of persuasion is not to tell it or “you should” it or criticise alternatives to it or crudely thrust it upon others – but to just show it. But there’s an important step before that.

In any given product category, whether it’s billing or network inventory or CPQ, etc, there are always features that are table-stakes and done by every solution. Those features are often the first to be demonstrated in a generic manner, but to quote Shania Twain, “That don’t impress me much!”

The key is to identify and demonstrate:

1. Whether your “table stakes” features can be done vastly and visibly better (eg faster, less error-prone, more reliably, more automated, etc) than all others in the category; and/or
2. Differentiation – The small number of features that aren’t available in incumbent or competing solutions that readily show pain-point removal and/or move the needle for that unique carrier’s situation

Both of these generally require deep understanding of the local conditions before a demonstration. That’s the step that precedes a demo.

Taking the time to understand each operator’s unique challenges is the first step to creating an A/B demonstration. There are always people who are unhappy with their current OSS situation who might become inspired to check it out. If the solution you’re proposing is so much better than the incumbent solution then the A/B comparison will already be ticking over in the audience’s head. In most cases, that means you have to deliver a customised demo, probably even underpinned by a data set that’s customised to the language of the potential buyer (eg their naming conventions, their service types, their network types / makes / models, their workflows, etc)

This is one of the reasons why I’m really big on setting up two pre-implementation pieces of the OSS transformation puzzle as early as possible:

• POC Scenarios – a set of end-to-end instructions that show the most important workflows that will traverse the proposed OSS/BSS solution
• Sandpit environments – that are set up “out of the box” and then configured to demonstrate the POC Scenarios

Once these two things are in place, you can initiate all the A/B comparisons in the heads of all your stakeholders, including sponsors, end-users, administrators, team leaders, etc. You need to show without critisising, to garner support, to identify gaps or concerns, etc.

And another important element of A/B testing is standing out for all the right reasons when you do present – having an OSS purple cow is a great place to start.

Need help with your unique A/B comparisons in the headspace of your stakeholders / clients? Book a call with us and we can discuss a range of ideas that could be suited to your situation!