The one person, two day, OSS challenge

For all of the OSS and BSS vendors out there, I’d like to issue you a challenge.

Can 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?

[Speaking of use-cases, I’ve just put the finishing touches on a the first version of a list of ~700 OSS/BSS use-cases across ~75 different personas/roles that interact with OSS/BSS tools. Drop in to this link to download it]

Why am I setting you this challenge? We’ll get to that shortly.

But first, let’s look into what facets need to be frictionless for this to happen:

1. Installation of the product must be plug and play (eg containers, or even SaaS)
2. Licencing and sales barriers like contracts, NDAs, qualification, etc must be tiny
3. Data ingest must be drastically simplified (eg pre-loaded data, standardised migration templates / patterns, simulators, Natural Language-based creation of data sets, data pipeline builders, templates, reference data, etc)
4. Training / collateral must be easy to access and consume (vids and docs to show examples of every step of the set-up, different use-cases, different configuration options, etc that show the most likely scenarios a potential buyer would run – taking the 80/20 rule)
5. Intuitive UI to ensure that users can configure and use the solution with almost no need to even refer to training materials
6. Valuable reports should be pre-established to allow users to quickly see the types of insights they can derive from the solution (both operations / transaction level reports and exec / sponsor level reports)
   (and I’d even suggest to include a business case calculator that shows the user how they can stand up a persuasive business case internally without your assistance and ensure their colleagues immediately see the value of your solution)
7. Valuable dashboards and visualisations should be pre-established that quickly show valuable operational scorecards (and ideally also show enough insights to tell the person and their colleagues what to do next when out-of-expected-bounds situations arise)
8. Starter-level Process Maps should be built that show basic versions that facilitate key use-cases and give users a platform to develop their own more customised / sophisticated processes (ideally with BPMN or other similar standardised / simplified process building models)
9. Integration and API patterns should be clear, simple and ideally even low-code / no-code (possibly even including integration patterns such as how to connect to a provided network simulator or to ingest data [as per point #3 above]). Suitable training and collateral (point #4 above) should also allow easy integration with other platforms that the users might want to integrate in their POC / sandpit
10. Admin, superuser and standard user accounts should be set up and documentation should facilitate each of your user levels because use-cases will differ. As a side-note, I’d also recommend providing obvious indicators of what user level is visible on the screen at any time (eg different banner colours for admin vs standard users). Why? Because many OSS/BSS vendor demonstrations jump between users and it can be difficult for colleagues to understand what role / persona is doing which actions
11. Security, RBAC (role-based access control), H/A (High Availability architectures), etc should be easily demonstrated because most telco use-cases will need these security, privacy, risk-reduction functions. However, it’s often these capabilities that take much longer to configure and demonstrate in many OSS/BSS solutions
12. Install anywhere so that users can install in any environment (on-prem, private cloud, public cloud) that they feel comfortable. Infrastructure and security are often major bottlenecks with OSS/BSS installations, whether production or just simple sand-pit environments, so this friction-point must be eliminated wherever possible
13. Support is a key differentiator between most vendor offerings and support in this pre-sales stand-up situation will not only get the new user started and help them build trust in you, but will also help for you to learn friction points
14. What other friction points am I overlooking? I’m sure there are others, so I’d love to hear your suggestions

Now, back to the question of why am I setting you this challenge:

1. Almost every OSS/BSS needs to reduce its barrier to entry for new prospects. In the past, we’ve spoken heavily about the “Kill the RFP” concept initially posed by TM Forum. Vendors rightly point out that OSS RFP / procurement exercises are arduous and costly (for vendors and carriers alike). But rather than pointing the finger of blame, vendors have the opportunity to use sandpit / POC environments as a way to reduce the RFP burden for themselves and carriers. It should be much easier for a carrier to install, configure and trial your solution to see if it’s a good fit, then demonstrate benefits to colleagues, rather than taking hundreds of hours and many resources to write (and gain consensus on) an RFP specification.
2. I feel we’re moving into an era where we will prioritise delivery / proof and do away with specification / documentation / talking / hypothesising / cajoling. The confused mind says no and too many prospects walk away with unanswered questions after a sales pitch. A working product demo in a sandpit environment does away with almost all the what-if questions a prospect has
3. I love this post by Tom Goodwin, “I spent about 5 years looking into how well companies have innovated and transformed over time, and I was shocked by how few examples I could find. I pondered why for years, and then it hit me. Most companies are not designed to change. They are designed to return capital to shareholders in the least risky way possible.”
   Telcos are a perfect example of this. They are growth stocks and are designed to return capital with as minimal risk as possible (which as an aside, is arguably one of the reasons they’re experiencing a burning exchange moment). OSS / BSS transformation projects represent massive risks for telco execs. We simply have to make OSS / BSS transformations more of a series of simple steps with smaller risk hurdles to accommodate the challenges they face. They don’t want big-bang deliveries or 12-18 month procurement cycles any more than you do
4. Speed to stand-up engenders confidence and proof of momentum. In doing so, it also reduces the telco’s biggest fear – that the transformation project will go over time, over budget and not deliver as much as was promised
5. You want to create product awareness, word of mouth, evangelists that aren’t on your payroll and get your product inside the castle walls that might otherwise be impenetrable to your paid sales teams
6. Focus on friction reduction efforts rather than developing new features at the far edge of the long-tail that don’t move the needle
7. Self-supported products, with a low barrier to entry, have a larger addressable market and have the potential to increase your company’s valuation (as described in this article about the SolarWinds acquisition valuation and other ways to increase valuation)
8. The lower barrier to entry also means it’s more suited to fitting into this BOS (Business Operating System) model that I’ve proposed recently
9. If it’s easy for me to set up, it’s more suited to being incorporated into my Personal OSS/BSS Sandpit Project
10. This also makes your solution easier for me to connect to potential buyers / partners and even makes it easier for small-medium solution integrators to sell / deliver on your behalf

If you’d like Passionate About OSS to help you test and/or plan how to remove friction from your solution and overall delivery mechanisms, please reach out to us to discuss.