100% agreement here; the larger an org grows, the more expensive it is to get information across the producer/user divide. Anything that gives a direct view into what customers are doing (or failing at!) with your product is gold.
This isn’t exclusive to software, either – one of the books I love to wave around is Eric Von Hippel’s Democratizing Innovation. It digs into this phenomenon and finds it in a wide variety of industries. https://mitpress.mit.edu/books/democratizing-innovation
I was fortunate to find it early in my open source career — it frames FLOSS and similar efforts as examples of user-driven experimentation with short feedback loops, rather than “It’s just magic that changes everything.”
The fundamental idea is that building an effective product or tool requires insight into what users of the tool or product need. But success requires scale, and soon the team‘s expertise is in “efficiently producing tools and products,” not the work that their users do.
As that gap grows, getting new and emergent needs, applications, or frustrations from the “tool-user” space across the divide to the “tool-builder” space becomes more and more expensive in both time and dollars.
Von Hippel’s work focuses on the idea of “user-led innovation“ — systems where a tool has just enough flex to it that the end users can customize it, serving emergent needs or fixing annoyances without the need for a ‘product development‘ feedback loop.
An example from his book is the rise of kite surfing — it emerged organically from customization of boards by surfers in the 70s and 80s. They experimented, shared ideas and iterated, and only when it exploded in popularity did surfing gear manufacturers get … on board. cough
Von Hippel explores that dynamic in a bunch of other industries, from assembly line tooling in factories to the Apache project. He sees a successful user-led-innovation system as a kind of outsourced R&D, where users come up with the ideas and producers figure out how to scale.
But making that kind of feedback loop isn’t as simple as just hoping. Just ask any company who’s tossed their previously closed-source project onto GitHub and hoped for a wave of user contributions. Or any design system team that tried to make “distributed governance” work…
The non-negotiable element is “the tool or product can be modified by an end user to suit their needs.” That doesn’t just mean technically possible, the actual work of customizing it has to be within the skillset and understanding of at least some percentage of the user base.
(That doesn’t necessarily mean open source, either — a robust plugin architecture, or software that’s easy to automate, can meet that criteria without users messing in its own source code. They key is that they can bash together what they need without the producer intervening.)
The force multiplier, though — the part that turns the user-customization into an innovation engine — is key. Users have to be able to share their customizations with each other. Either as blueprints or instructions or as ready-to-use bits.
At that point the R&D feedback loop of experimentation and iteration can exist entirely on the “people with a need” side of the product development fence. They can improve on each others’ work and fill new niches that aren’t (yet) mature enough to justify explicit product focus.
The thing is, though, this virtuous circle of users solving problems and filling niches might make them love the product, but it doesn’t inherently improve the product. Because so far, we’ve only talked about how they improve things to solve their own problems.
Von Hippel frames the blessing/curse of the “tool producer” role as an unfortunately necessary optimization; you begin to specialize in making the tool, not using it, because that lets you create higher quality tools more efficiently.
The trick is that many teams — especially ones that start out solving their own problems by building a new tool that catches on — don’t recognize when they’ve transitioned from insight-filled “tool users” to the optimization-obsessed “tool makers.” It creeps up on you!
One symptoms is assuming today’s users have the same problems as yesterday’s — coincidentally, problems the tool-builders remember experiencing. Lack of interest in user research is another.
Another symptom of the disconnect (going back to the initial RT) is treating product support as triage, a breakwall for bugs and user confusion, rather than a key source of insight into what they are trying to do.
Because the third component that’s absolutely necessary for a successful ”user innovation” feedback loop is a dialogue between the tool producers and tool users. A window into what they’re attempting, and what tweaks are taking off. Respect for what that happens at the edges.
Without a producer figuring to operationalize the new innovation, the “lead users” making the tweaks and customizations would just be hackers and kitbashers on the fringes. Their work wouldn’t scale up to help the people without the crossover skills to do the customizing.
In addition, some of the ideas that emerge from those systems will be innapropriate for incorporation into the core product. They might interfere with other users’ core needs, or be of little use to folks outside the niche that produced the idea.
That’s the responsibility of the tool-maker: figuring out what kind of tool this will be out of all the possible tools. What it will emphasize and what it will excel at and what it will enable but not prioritize.
This model — allowing emergent specialization of broad-functionality tools, then focusing on the governance and feedback loops that drive what hacks become Official Features — has shaped how @autogram_is approaches both design system and content architecture stuff for large orgs.
It’s been a huge influence on how I understand the value of open source to organizations (and individuals), especially those who aren’t themselves developers.
And it’s helped me recognize the profound value of teams that work directly with end-users. Customer service, technical support teams, trainers, even sales when they’re incentivized to recognize and describe emerging needs rather than simply sell through them.