I have this sense that the other OSS, open source software, holds the key to the next wave of OSS (Operational Support Systems) innovation.
Why? Well, as yesterday’s post indicated (through Nic Brisbourne), “it’s hard to do big things in a small way.” I’d like to put a slight twist on that concept by saying, “it’s hard to do big things in a fragmented way.” [OSS is short for fragmented after all]
The skilled resources in OSS are so widely spread across many organisations (doing a lot of duplicated work) that we can’t reach a critical mass of innovation. Open source projects like ONAP represent a possible path to critical mass through sharing and augmentating code. They provide the foundation upon which bigger things can be built. If we don’t uplift the foundations across the whole industry quickly, we risk losing relevance (just ask our customers for their gripes list!).
But you may ask how organisations can protect their trade secrets whilst embracing open source innovation. Derek Sivers provides a fascinating story and line of thinking in “Why my code and ideas are public.” I really recommend having a read about Valerie.
Experts know a lot…. obviously.
They have lots of answers… obviously.
There are lots of OSS experts. Combined, they know A LOT!!
Powerful indeed, but not sure if that’s what we need right now. I feel like we’re in a bit of an OSS innovation funk. The biggest improvements in OSS are coming from outside OSS – extrinsic improvement.
Where’s the intrinsic improvement coming from? Do we need someone to shake it up (do we need everyone to shake it up?)? Do we need new thinking to identify and create new patterns? To re-organise and revolutionise what the experts already know. Or do we need to ask the massive questions that re-frame the situation for the experts?
So, considering this funky moment in time, is the real expert the one who knows lots of answers… or the person who can catalyse change by asking the best mind-shift questions?
May I ask you – As an OSS expert, are you prouder of your answers…. or your questions?
To tackle that from a different angle – What is your answer : question ratio? Are you such an important expert that your day is so full of giving brilliant answers that you have no time left to ruminate and develop brilliant questions?
If so, can we take some of your answer time back and re-prioritise it please?
In the words of Socrates, “I cannot teach anybody anything, I can only make them think.“
“An organisation buys an OSS, not because it wants an Operational Support System, but because it wants Operational Support.”
So if our customers are not investing in our OSS, what are they actually investing in? Easy! They’re investing in the ability to solve their own problems and opportunities in future.
If we don’t actually understand operations, what chance do we have to deliver operational support? We keep hearing the term, “customer experience this,” “CX that,” so it must be important right? Operational support staff might be a few steps removed from us (intentionally or unintentionally) but they are our “real” customers and the only way we can develop a solution that empathises with them is by spending time with them and listening (not always easy for us know-it-all OSS builder-types).
And just because we have a history in ops doesn’t mean we can assume to know this time. Operations are different at each organisation.
So, are we sure we understand the nature, extent and context of the unique problem/s that this customer needs to solve (not wants to solve)?
Omni-channel is an interesting concept because it generates two distinctly different views.
The customer will use whichever channel (eg digital, apps, contact-centre, IVR, etc) that they want to use.
The service provider will try to push the customer onto whichever channel suits the service provider best.
The customer will often want to use digital or apps, back-ended by OSS – whether that’s to place an order, make configuration changes, etc. The service provider is happy for the customer to use these low-cost, self-service channels.
But when the customer has a problem, they’ll often try to self-diagnose, then prefer to speak with a person who has the skills to trouble-shoot and work with the back-end systems and processes. Unfortunately, the service provider still tries to push the customer into low-cost, self-service channels. Ooops!
If the customer thinks they have a problem, they do have a problem (even if technically, they don’t).
Omni-channel means giving customers the channels that they want to work via, not the channels the service provider wants them to work via.
Call Volume Reduction (CVR) projects (which can overlap into our OSS) sometimes lose sight of this fact just because the service provider has their heart set on reducing costs.
“You can have more – if you become more.”
I believe that this is as true of our OSS as it is of ourselves.
Many people use the name Operational Support Systems to put an electric fence around our OSS, to limit uses to just operational activities. However, the reach, awareness and power of what they (we) offer goes far beyond that.
We have powerful insights to deliver to almost every department in an organisation – beyond just operations and IT. But first we need to understand the challenges and opportunities faced by those departments so that we can give them something useful.
That doesn’t necessarily mean expensive integrations but unlocking the knowledge that resides in our data.
Looking for additional funding for your OSS? Start by seeking ways to make it more valuable to more people… or even one step further back – seeking to understand the challenges beyond the walls of operations.
“It’s not unusual for something to be positioned as the high performance alternative. The car that can go 0 to 60 in three seconds, the corkscrew that’s five times faster, the punch press that’s incredibly efficient…
The thing is, though, that the high performance vs. low performance debate misses something. High at what?
That corkscrew that’s optimized for speed is more expensive, more difficult to operate and requires more maintenance.
That car that goes so fast is also more difficult to drive, harder to park and generally a pain in the neck to live with.
You may find that a low-performance alternative is exactly what you need to actually get your work done. Which is the highest performance you can hope for.”
Seth Godin in this article, What sort of performance?
Whether selecting a vendor / product, designing requirements or building an OSS solution, we can sometimes lose track of what level of performance is actually required to get the work done can’t we?
How many times have you seen a requirement sheet that specifies a Ferrari, but you know the customer lives in a location with potholed and cobblestoned roads? Is it right to spec them – sell them – build them – charge them for a Ferrari?
I have to admit to being guilty of this one too. I have gotten carried away in what the OSS can do, nearer the higher performance end of the spectrum, rather than taking the more pragmatic view of what the customer really needs.
Automations, custom reports and integrations are the perfect OSS examples of low performance actually being high performance. We spend a truckload of money on these types of features to avoid manual tasks (curse having to do those manual tasks)… when a simple cost-benefit analysis would reveal that it makes a lot more sense to stay manual in many cases.
“With the increasing pace of change, the moment a research report, competitive analysis, or strategic plan is delivered to a client, its currency and relevance rapidly diminishes as new trends, issues, and unforeseen disrupters arise.”
By the same token as the quote above, does it follow that the currency and relevance of an OSS rapidly diminishes as soon as it is delivered to a client?
In the case of research reports, analyses and strategic plans, currency diminishes because the static data sets upon which they’re built are also losing currency. That’s not the case for an OSS – they are data collection and processing engines for streaming (ie constantly refreshing) data. [As an aside here – Relevance can still decrease if data quality is steadily deteriorating, irrespective of its currency. Meanwhile currency can decrease if the ever expanding pool of OSS data becomes so large as to be unmanagable or responsiveness is usurped by newer data processing technologies]
However, as with research reports, analyses and strategic plans, the value of an OSS is not so much related to the data collected, but the questions asked of, and answers / insights derived from, that data.
Apart from the asides mentioned above, the currency and relevance of OSS only diminish as a result of new trends, issues and disrupters if new questions can not or are not being asked with them.
You’ll recall from yesterday’s post that, “An ability to use technology to manage, interpret and visualise real data in a client’s data stores, not just industry trend data,” is as true of OSS tools as it is of OSS consultants. I’m constantly surprised that so few OSS are designed with intuitive, flexible data interrogation tools built in. It seems that product teams are happy to delegate that responsibility to off-the-shelf reporting tools or leave it up to the client to build their own.
With the holiday period looming for many of us, we will have the head-space to reflect – on the year(s) gone and to ponder the one(s) upcoming. I’d like to pose the rhetorical question, “What do you expect to reflect on?”
It’s probably safe to say that a majority of OSS experts are engaged in delivery roles. Delivery roles tend to require great problem-solving skills. That’s one of the exciting aspects of being an OSS expert after all.
There’s one slight problem though. Delivery roles tend to have a focus on the immediacy of delivery, a short-term problem-solving horizon. This generates incremental improvements like new dashboards within an existing dashboard framework, refining processes, next release software upgrades, releasing new stuff that adds to the accumulation of tech-debt, etc, etc.
That’s great, highly talented, admirable work, often exactly what our customers are requesting, but not necessarily what our industry needs most.
We need the revolutionary, not the evolutionary. And that means raising our horizons – to identify and comprehend the bigger challenges and then solving those. That is the intent of the OSS Call for Innovation – to lift our vision to a more distant horizon.
When you reflect during this holiday period, how distant will your horizon be?
PS. Upon your own reflection, are there additional big challenges or exponential opportunities that should be captured in the OSS Call for Innovation?
Eric Ries’ “The Lean Startup,” has a short chapter entitled, “Get out of the Building.” It basically describes getting away from your screen – away from reading market research, white papers, your business plan, your code, etc – and out into customer-land. Out of your comfort zone and into a world of primary research that extends beyond talking to your uncle (see video below for that reference!).
This concept applies equally well to OSS product developers as it does to start-up entrepreneurs. In fact the concept is so important that the chapter name has inspired it’s own hashtag (#GetOutOfTheBuilding).
This YouTube video provides 10 tips for getting out of the building (I’ve started the clip at Tendai Charasika’s list of 10 ways but you may want to scroll back a bit for his more detailed descriptions).
But there’s one thing that’s even better than getting out of the building and asking questions of customers. After all, customers don’t always tell the complete truth (even when they have good intentions). No, the better research is to observe what they do, not what they say. #ObserveWhatTheyDoNotWhatTheySay
This could be by being out of the building and observing customer behaviour… or it could be through looking at customer usage statistics generated by your OSS. That data might just show what a customer is doing… or not doing (eg customers might do small volume transactions through the OSS user interface, but have a hack for bulk transactions because the UI isn’t efficient at scale).
Not sure if it’s indicative of the industry as a whole, but my experience working for / with vendors is that they don’t heavily subscribe to either of these hashtags when designing and refining their products.
Does your OSS collect primary data to #ObserveWhatTheyDoNotWhatTheySay? If it does, do you ever make use of it? Or do you prefer to talk with your uncle (does he know much about OSS BTW)?
Omnichannel will remain full of holes until we figure out a way of tracking user journeys rather than trying to prescribe (design, document, maintain) process flows.
As a customer jumps between the various channels, they move between systems. In doing so, we tend to lose the ability to watch customer’s journey as a single continuous flow. It’s like trying to watch customer behaviour under a strobe light… except that the light only strobes on for a few seconds every minute.
Theoretically, omnichannel is a great concept for customers because it allows them to step through any channel at any time to suit their unique behavioural preferences. In practice, it can be a challenging experience for customers because of a lack of consistency and flow between channels.
It’s a massive challenge for providers to deliver consistency and flow because the disparate channels have vastly different user interfaces and experiences. IVR, digital, retail, etc all come from completely different design roots.
Vendors are selling the dream of cost reductions through improved efficiency within their channels. Unfortunately this is the wrong place for a service provider to look. It’s the easier place to look, but the wrong place nonetheless. Processes already tend to be relatively efficient within a channel and data tends to be tracked well within a channel.
The much harder, but better place to seek benefits is through the cross-channel user journeys, the hand-offs between channels. That’s where the real competitive advantage opportunities lie.
Regardless of whose estimates you read, OSS is a multi billion industry. However, based on the relatively infrequent signing of new vendor deals, it’s safe to say that only a very small percentage of those billions are ever “in play.”
In other words, OSS tend to be very sticky, in part because they’re so difficult to forklift out and replace. Some vendors play his situation extremely well, with low install costs but with strategies such as “land and expand,” “so sue us” and “that will be a variation.” These honey pots hide the real cost of ownership.
Cloud IT architectures such as containerisation and microservices can provide a level of modularity and instant replaceability between products (ie competition). When combined with a Minimum Viable Product mindset rather than complex, entwining customisations, you can seek to engineer a lower lock-in solution.
The aim is to ensure that products (and vendors) stay in-situ for long periods based on merit (ie partnership strength, functionality, valuable outcomes, mutual benefit, etc) rather than lock-in.
“The gameplan tells what you want to happen, but the scoreboard tells what is happening.”
John C Maxwell
Over the years, I’ve found it interesting that most of the organisations I’ve consulted to have significant hurdles for a new OSS to jump through to get funded (the gameplan), but rarely spend much time on the results (the scoreboard)… apart from the burndown of capital during the implementation project.
From one perspective, that’s great for OSS implementers. With less accountability, we can move straight on to the next implementation and not have to justify whether our projects are worth the investment. It allows us to focus on justifying whether we’ve done a technically brilliant implementation instead.
However, from the other perspective, we’re short-changing ourselves if we’re not proving the value of our projects. We’re not building up the credits in the sponsor bank ahead of the inevitable withdrawals (ie when one of our OSS projects goes over time, budget or functionality is reduced to bring in time/budget). It’s the lack of credits that make sponsors skeptical of any OSS investment value and force the aforementioned jumping through hoops.
OSS is a powerful multi-purpose tool, much like a hammer.
If OSS is my only tool, do I see all problems as nails that I have to drive home with my OSS?
The downside of this is that it then needs to be designed, built, integrated, tested, released, supported, upgraded, data curated and maintained. The Total Cost of Ownership (TCO) for a given problem extends far beyond the time-frame envisaged during most solutioning exercises.
To be honest, I’ve probably been guilty of using OSS to solve problems before seeking alternatives in the past.
What if our going-in position was that answers should be found elsewhere – outside OSS – and OSS simply becomes the all-powerful last resort? The sledgehammer rather than the ball-pein hammer.
With all this big data I keep hearing about, has anyone ever seen any stats relating to the real life-time costs of OSS customisations made by a service provider to its off-the-shelf OSS? If such data exists, I’d love to see what the cost-benefit break-even point might look like and what we could learn from it. I assume we’re contributing to our very own Whale Curve but have nothing to back that assumption up yet.
Data quality is the bane of many a telco. If the data quality is rubbish then the OSS tools effectively become rubbish too.
Feedback loops are one of the most underutilised tools in a data fix arsenal. However, few people realise that there are what I call big circle feedback loops as well as little circles.
The little circle is using feedback in data alone, using data to compare and reconcile other data. That can produce good results, but it’s only part of the story. Many data challenges extend further than that if you’re seeking a resolution.
The big circle is designing feedback loops that incorporate data quality into end-to-end processes, which includes the field-work part of the process.
Redline markups have been the traditional mechanism to get feedback from the field back into improving OSS data. For example, if designers issue a design pack out to field techs that prove to be incorrect, then techs return the design with redline markups to show what they’ve implemented in the field instead.
With mobile technology and the right software tools, field workers could directly update data. Unfortunately this model doesn’t seem to fit into practices that have been around for decades.
There remain great opportunities to improve the efficiency of big circle feedback loops. They probably need a new way of thinking, but still need to fit into the existing context of field workers.
Since reading the first book on this list, I’ve become a very avid and wide-ranging reader. The seeds sown by the book list below have immensely helped enrich the content you see here on the PAOSS blog and other PAOSS content.
You’ll begin to notice a very curious thing about this list though. There are only two books in the entire list that are actually about OSS. I have many OSS books in my library, but most struggle for relevance beyond the author’s frame of reference – they have been written from the specific technical experiences of the author, which are rarely transferable to other OSS. Either the technologies are now out of date and/or the details / terminologies were pertinent only to that OSS time and place. It’s one of the reasons that PAOSS content is specifically intended to abstract from technology and deliver insights, methodologies, processes and frameworks that have a broader relevance and greater longevity (hopefully).
The remaining books in the list have not been written with OSS in mind but definitely provide insights and perspectives that are transferable to the challenges we face in the OSS industry. In no particular order (except the first being the first…)
Rich Dad, Poor Dad
by Sharon L. Lechter Robert T. Kiyosaki
This was the book that changed it all for me. Whilst its intent is to educate on personal finance, the effect it had was to lift my eyes beyond the purely technical. Like 95%+ of people in our industry, I had previously only ever focused on delivering the best technical solution I could with the assumption that this would deliver a great customer outcome. I now know that the challenges we face are far bigger than that!
Insanely Simple: The Obsession That Drives Apple’s Success
by Ken Segall
The greatest OSS (but non-OSS) book I’ve read. The first half of this book in particular delivers powerful examples of simplification at all levels of an organisation as experienced by an advertising executive working alongside Steve Jobs at Apple. The OSS and communications industry need more people who are able to wield the simple stick like Steve did.
by Jason Fried, David Heinemeier Hansson
These gentlemen have built a strong business around the Basecamp project management suite of tools. In Rework, just like their blog at 37signals, they provide brilliant contrarian insights into how to run a software business… Or any business for that matter. Efficiency and simplicity are the mantra ahead of the Red-Bull fuelled heroics spouted by many organisations in the software industry. One of my all-time favourite business books.
Enchantment: The Art of Changing Hearts, Minds, and Actions
by Guy Kawasaki
Guy defines enchantment as, “the process of delighting people with a product, service, organisation or idea. The outcome of enchantment is voluntary and long-lasting support that is mutually beneficial.” If there was ever an industry that was in need of enchantment, it is the OSS industry right now.
Rain: What a Paperboy Learned About Business
by Jeffrey J. Fox
An easy to digest story about a boy with a paper-route learning the key tenets of rainmaking, the ability to delight customers and make sales (and projects) happen.
Killing Giants: 10 Strategies to Topple the Goliath in Your Industry
by Stephen Denny
There are a number of goliath incumbents in our industry. However, I suspect that most of the required disruption is coming from the Davids of our industry, despite the burning platforms at the goliaths. Interesting reading for a different perspective on innovation and change.
Anything You Want: 40 Lessons for a New Kind of Entrepreneur
by Derek Sivers
Derek Sivers was a professional musician before starting his own business, one that helped sell the CDs of the long tail of the music industry, musicians overlooked by the big labels. This might sound barely relevant to the OSS industry but there is an uncommon clarity in the way that Sivers views businesses, customers and delivery. Many of his thoughts really struck a chord with me (bad pun intended).
Principles: Life and Work
by Ray Dalio
Built around the principles that Ray Dalio codified at his company, Bridgewater Associates. Many of his principles of team and culture seem like common sense, but helpfully compiled into a single volume. Not all OSS teams have these principles mastered.
by John P. Kotter
OSS projects are challenging to implement. Through harsh experience, I’ve learnt that even technically perfect implementations are prone to fail if the organisational change effort hasn’t been managed well. Whilst there are newer change management methodologies available, I still find that Kotter’s 8 steps provide a valuable framework for building OSS change management strategies around.
Endless Referrals: Network Your Everyday Contacts into Sales
by Bob Burg
In the early days of my career, I’d gone from one project to the next, with my head down focusing on delivery. This book opened my eyes to the value of staying in touch with past colleagues and adding value to my network. The results have surprised me so I recommend this book’s teachings to anyone who is purely tech-focused.
The Idea Factory: Bell Labs and the Great Age of American Innovation
by Jon Gertner
Put simply, this is probably the most inspiring book I’ve read in relation to the communications industry. The groundbreaking innovations (including OSS) that were developed within R&D powerhouses like Bell Labs during the 1900’s are staggering and something that we can barely even aspire to today. It’s no coincidence that the OSS Call for Innovation references this book
Linchpin: Are You Indispensable?
by Seth Godin
A call to action to become a linchpin, someone who delivers in territory where there is no map / rule-book, someone who inspires those around them. OSS needs more linchpins.
Dangerous Company: Consulting Powerhouses and the Companies They Save and Ruin
by Charles Madigan and James O’Shea
This book provides some insights into the best and worst of management consulting. It is a little old now, dating back to the late 1990’s but it had a significant impact on me when I read it in the 2010’s. It describes some of the unscrupulous acts / tactics / results that have lead to the poor reputation that consulting has in some circles. It also reinforced a strong belief I’ve always had in doing right by the client before the firm because building reputation and integrity ultimately benefits the firm anyway.
Made to Stick: Why Some Ideas Survive and Others Die
by Chip Heath, Dan Heath
The term “stickiness” was popularised by Malcolm Gladwell in “The Tipping Point.” This book borrows the term and looks to explain why an idea or concept remains sticky. OSS tend to be so sticky, in many cases to the detriment of the customer experience, but our industry is also in desperate need for powerfully sticky new ideas and approaches.
Purple Cow, New Edition: Transform Your Business by Being Remarkable
by Seth Godin
In a cluttered or fragmented marketplace, like OSS, it is difficult to stand out from all other suppliers. Seth Godin introduces the concept of the purple cow – when you’re on a long trip in the countryside, seeing lots of brown or black cows soon gets boring, but if you saw a purple cow, you’d immediately take notice. This book provides the impetus to make your products stand out and drive word of mouth rather than having to differentiate via your marketing.
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich
by Timothy Ferriss
Starts off strongly but drops away rapidly in the second half IMHO. The words of a friend of mine aptly paraphrase what Tim Ferris talks about in this book, “Only do what only you can do.” Prioritise your efforts on what make you truly unique and use other efficiency tools and/or engage others to do the rest
Mastering your OSS: Operational Support System Implementation Tips and Techniques
by Ryan Jeffery
This is the best OSS book that I’ve written (so far), but with new material in the pipeline, watch this space for even better publications. It provides the frameworks, processes, insights and recommendations that will help guide you through the myriad of challenges, technical or otherwise, that you will face in the world of OSS.
Power Listening: Mastering the Most Critical Business Skill of All
by Bernard T. Ferrari
Bernard Ferrari advises the use of the Pareto Principle to listening. In other words, spending 80% of the time listening and only 20% talking. It’s such an important trait for all technical resources, yet perhaps somewhat uncommon unfortunately. As the “hired gun,” there is a tendency to start firing from both barrels verbally as soon as you meet with the customer. But the most insightful insights are the ones that are understandable to the customer. They have to be relevant in terminology, desired outcomes, roles/responsibilities, respective capabilities, etc, etc. You only get that context from Power Listening.
The Click Moment: Seizing Opportunity in an Unpredictable World
by Frans Johansson
Johansson also introduces the concept of the “smallest executable step” as a mechanism for harnessing the apparent randomness of our modern, rapidly changing world. He suggests that we make many small bets rather than one massive bet as a means of improving success rates. OSS are complex systems so any small deviation makes predictions of completion time, resources and cost difficult. As implementers, it’s our job to remove as much complexity as possible
Harder Than I Thought: Adventures of a Twenty-First Century Leader
by Robert D. Austin, Richard L. Nolan
More than anything else, one paragraph has stuck with me from this guide to project change leadership, “….once you start a company transformation, it’s like a stampede. If you try to lead from the front, you get trampled; if you try to lead from the back, you have no impact. Best to lead from the side by carefully nudging and turning the stampede to avoid everyone going over the cliff.”
“Alchemy is the ancient practice of trying to turn lead into gold… alchemy was an art based partly upon experimentation and partly upon magic.”
Benjamin Radfordhere on Live Science.
The definition of alchemy is, “part science, part art,” according to Geoff Leong. To William Whewell, “In general, art has preceded science. Men have executed great, and curious, and beautiful works before they had a scientific insight into the principles on which the success of their labours was founded. There were good artificers in brass and iron before the principles of the chemistry of metals were known; there was wine among men before there was a philosophy of vinous fermentation… Art was the mother of Science.”
In OSS, we have the science / experimentation part well covered. Indeed, we have great creativity in science / experimentation.
But are we lavished with the curiosity, the art or the magic (apart from the “magic” within some OSS product slide-decks)? Who are our Michaelangelos, Ben Franklins, Steve Jobs, et al – those who are preceding OSS science with art?
Simple question – Do you have any in your organisation?
Let’s say you act for a service provider and the diagram below represents the number of variations you could offer to customers – the number that are technically supported by your solution.
That’s 13,824,000 colours.
By comparison, the following diagram contains just 20 colours:
If I asked you what colours are in the upper diagram, would you say red, orange, yellow, green, blue, etc? Is it roughly the same response as to the lower diagram?
If you’re the customer, and know you want an “orange*” product, will you be able to easily identify between the many thousands of different orange hues available in the upper diagram? Would you be disenfranchised if you were only offered the two orange hues in the lower diagram instead of thousands? Or might you even be relieved to have a much easier decision to make?
The analogy here to OSS is that just because our solutions can support millions of variants, doesn’t mean we should. If our OSS try to offer millions of variants, it means we have to design, then build, then test, then post-sale support millions of variants.
However, in reality, we can’t provide 100% coverage across so many variants – we aren’t able to sufficiently design, then build, then test, then post-sale support every one of the millions of variants. We end up overlooking some or accept risk on some or estimate a test spread that bypasses others. We’ve effectively opened the door to fall-outs.
And it’s fall-outs that tend to create larger customer dissatisfaction metrics than limited colour palettes.
Just curious – if you’ve delivered OSS into large service providers, have you ever seen evidence of palette analysis (ie variant reduction analysis) across domains (ie products, marketing, networks, digital, IT, field-work, etc)?
Alternatively, have you ever pushed back on decisions made upstream to say you’ll only support a smaller sub-set of options? This doesn’t seem to happen very often.
* When I’m talking about colours, I’m using the term figuratively, not necessarily the hues on a particular handset being sold through a service provider.
OSS tend to be powerful software suites that can do millions of things. Experts at the vendors / integrators know how to pull the puppet’s strings and make it dance. As a reader of PAOSS, chances are that you are one of those experts. I’ve sat through countless vendor demonstrations, but I’m sure you’ll still be able to wow me with a demo of what your OSS can do.
Unfortunately, most OSS users don’t have that level of expertise, nor experiences or training, to pull all of your OSS‘s strings. Most only use the tiniest sub-set of functionality.
If we look at the millions of features of your OSS in a decision tree format, how easy will it be for the regular user to find a single leaf on your million-leaf tree? To increase complexity further, OSS workflows actually require the user group to hop from one leaf, to another, to another. Perhaps it’s not even as conceptually simple as a tree structure, but a complex inter-meshing of leaves. That’s a lot of puppet-strings to know and control.
A question for you – You can make your OSS dance, but can your customers / users?
What can you do to assist users to navigate the decision tree? A few thoughts below:
Prune the decision tree – chances are that many of the branches of your OSS are never / rarely used, so why are they there?
Natural language search – a UI that allows users to just ask questions. The tool interprets those questions and navigates the tree by itself (ie it abstracts the decision tree from the user, so they never need to learn how to navigate it)
Use decision support – machine assistance to guide users in navigating efficiently through the decision tree
Restrict access to essential branches – design the GUI to ensure a given persona can only see the clusters of options they will use (eg via the use of role-based functionality filtering)
I’d love to hear your additional thoughts how to make it easier for users to make your (their) OSS dance.
As recently discussed with two friends and colleagues, Raman and Darko, Proofs of Concept (PoC) or Minimum Viable Product (MVP) implementations can be a double-edged sword.
By building something without fully knowing the end-game, you are potentially building tech-debt that may be very difficult to work around without massive (or complete) overhaul of what you’ve built.
The alternative is to go through a process of discovery to build a detailed document showing what you think the end product might look like.
I’m all for leaving important documentation behind for those who come after us, for those who maintain the solutions we create or for those who build upon our solutions. But you’ll notice the past-tense in the sentence above.
There are pros and cons with each approach, but I tend to believe in documentation in the “as-built” sense. However, there is a definite need for some up-front diagrams/docs too (eg inspiring vision statements, use cases, architecture diagrams, GUI/UX designs, etc).
The two biggest reasons I find for conducting PoCs are:
Your PoC delivers something tangible, something that stakeholders far and wide can interact with to test assumptions, usefulness, usability, boundary cases, etc. The creation of a doc can devolve into an almost endless set of “what-if” scenarios and opinions, especially when there are large groups of (sometimes militant) stakeholders
You’ve already built something – your PoC establishes the momentum that is oh-so-vital on OSS projects. Even if you incur tech-debt, or completely overhaul what you’ve worked on, you’re still further into the delivery cycle than if you spend months documenting. Often OSS change management can be a bigger obstacle than the technical challenge and momentum is one of change management’s strongest tools
I’m all for deep, reflective thinking but that can happen during the PoC process too. To paraphrase John Kennedy, “Don’t think, don’t hope, (don’t document), DO!” 🙂