You do not get money to throw behind marketing when you are running a not-for-profit. Hence, if you build a product, getting a large cohort of people to know about it is challenging.
This often results in a process of coalition building where organisations try to build a cohort aligned on the same goal and project the process of product/platform development as a shared goal.
Nobody enjoys the process, but everyone participates. Having seen this play out, here are some observations.
What is the difference between a product and a service?
A service company will build anything that the customer asks them to. They will often go through processes such as writing a product requirement document and the like, but when push comes to shove, they will do whatever the customer asks them to do because that is how they get paid. The output is the customer’s liability.
A product company, by comparison, asks the customer what they want, but then brings their “opinion” to the table. The opinion is precisely the reason AI cannot build products, but that is another blog.
They spend time figuring out what the workflow should be, what features are fringe and unimportant and most importantly, what the product should not be. Sometimes this results in firing some customers, but that is fine. It makes a specific cohort of customers incredibly happy, and that drives their success.
The first axiom of developing a product: Have the willingness to piss a few people off.
I often find that in the development sector, every conversation surrounding a product starts with a long discussion on governance, which often bleeds into discussions about interoperability, standards, protocols and several more minutiae.
You know the last successful product/platform that was built like this? There isn’t one.
Products are built by diktat and not by consensus. It is the success of a product that causes an ecosystem to spawn around it, not the other way around. They do not start out sitting around a table with others, figuring out how to get things to interoperate.
Google did not ask Apple for permission to build a product. It is because Google was wildly successful that Apple had to figure out how to make its APIs work. The standardisation and interoperability are a feature of success. Google Maps is the best mapping product out there, so everyone figures out how to make it work with their platform. Interoperability arises.
To sit and talk about standards and interoperability when you have not even started building your product requires some degree of pompous arrogance.
They tell you they are not-for-profit, but they do not tell you what they are ‘for’. They are for-status. Status comes to those who are in control, and hence, all the talk about governance is mostly about maintaining control. It is not about delivering a superior product, and it is not about pursuing a cause.
Honestly, the entire sector can learn a thing or two from the open source ecosystem. No open source tool was built through discussions. Someone takes the initiative and lays the foundation, and others chip in. The love for the product keeps it going and keeps contributors coming back. A lot of open-source solutions are built in a truly selfless manner, and when they do succeed, they can force terms of interoperability and standards.
We just do not have sufficient open source solutions in the development sector, and this should give us pause. If ever I come across a development sector event where, instead of a diatribe about the need for standards and interoperability, someone introduces an open source solution that they let others fork, that will be the day this sector takes a step forward in its digital ambitions.