Notes on growth, design for open source start-ups
What Open Source taught me about Growth
Reflections from working on commercial strategy for a fast-growing AI platform and why adoption, positioning and revenue turned out to be different problems.
by David Soh
10 Sep 2026
11 min read
Growth strategy
Customer Strategy
Product Marketing
The Premise
A product can be useful, widely adopted and even technically impressive but still be really difficult to sell.
That tension became the most interesting part of my work researching on growth and strategy for Open WebUI, an open-source AI platform. I began with a deceptively simple mandate: help turn strong adoption into a clearer commercial opportunity. However, the more I looked at it, the less it resembled a conventional sales problem.
When I started the work, the brief in my head was almost comically direct: help turn adoption into revenue. The platform already had many of the things early software companies spend years trying to create — an active open-source community, a product people chose to install themselves, and a clear technical appeal for teams that wanted more control over how they used AI.
For many, the first thing that would come to mind was to push harder on sales. right? Find leads. Build a deck. Improve the landing page. Give the founder a better pipeline.
But I kept getting stuck on a more basic question: what, exactly, were we asking someone to buy?
Not in the literal sense. The enterprise licence existed. The product existed. The features existed. The harder question was whether a buyer could connect those things to a problem they already cared enough about to fund.
"Before asking how to scale sales, I had to understand whether the commercial story was coherent enough to scale."
It was at that moment where the nature of the work started to shift and chage.
What began as “growth” started to look much closer to service design: tracing where value was created, where it was misunderstood, which actors had different incentives, and which assumptions needed to be tested before the organisation committed to scaling anything.
The first lesson: adoption is not the same thing as a market
Open-source adoption is a powerful signal. It tells you people have enough of a problem to search for a solution, install it, configure it and keep using it. But I learned very quickly that this does not automatically tell you who will pay, why they will pay, or which part of the experience they consider commercially valuable.
A developer might value model flexibility. An IT leader might care about deployment control. Security may care about data boundaries. Procurement may want a support relationship and contractual accountability. An executive sponsor may care less about any single feature than about making AI usable across an organisation without creating another uncontrolled tool sprawl problem.
They can all be talking about the same product while buying completely different things.
The shift in how I framed the market
01 Usage
Who uses it?
Technical users, teams and organisations choosing a self-hosted interface for working with AI models.
02 Problem
Why does it matter?
Control, privacy, model choice, internal accessibility, governance and deployment simplicity.
03 Purchase
Who pays, and why now?
A specific buyer with a trigger, budget, risk to manage and an organisational outcome to defend.
So my working distinction became: usage is evidence of utility; a market requires a buyer, a buying trigger and a reason to exchange money.
This sounds obvious written down. In practice, it forced me to stop treating TAM as the answer. A huge universe of organisations “adopting AI” is intellectually interesting, but not very helpful if I cannot tell the team which twenty organisations are worth speaking to next week and what we expect to learn from them.
My thinking moved from How big is the AI market? and toward Which organisations experience the combination of constraints that makes this kind of platform unusually valuable?
The second lesson: features do not become value until someone can explain the consequence
One of the most useful exercises I did was painfully simple. I would take the language of the product and keep asking: "so what?"– In Service Design language, it is the root cause analysis, asking the 5 Whys.
Self-hosting. So what?
It can give an organisation greater control over how its AI interface is deployed and where data flows.
Model flexibility. So what?
Teams can change or combine model providers without redesigning the entire employee experience around one vendor.
Role-based access and administration. So what?
AI can move from an individual experimentation tool toward something an organisation can govern as shared infrastructure.
The point was not to simplify the technology until it became meaningless. It was to find the organisational consequence behind the capability.
"The buyer rarely wakes up wanting your feature.
They wake up wanting the risk reduced, the work made
easier, or the outcome made possible."
This is where my background in design became unexpectedly useful. Service designers spend a lot of time translating between levels: what a user experiences, what the organisation must do backstage, and what systems or policies make that experience possible.
Product marketing required a similar translation in reverse, from technical capability to user consequence to business value.
The third lesson: revenue has a service journey too
I had initially thought of “sales” as the moment after marketing: someone becomes interested, a seller talks to them, and eventually they buy. The work made that model feel far too narrow.
For an enterprise AI product, buying is its own multi-actor service. Someone discovers the product. Someone technical validates it. Someone becomes an internal champion. Security and legal ask different questions. Procurement introduces another set of requirements. Leadership wants confidence that the tool can survive beyond a pilot. Then, after purchase, the organisation still has to adopt it successfully enough to renew or expand.
When I mapped that journey, several “marketing problems” started looking like gaps between stages instead. A technically convincing product does not automatically equip an internal champion to win budget. A strong demo does not automatically answer procurement. Community love does not automatically create an enterprise proof story.
That led me to think about growth less as a funnel and more as an end-to-end conversion service.
I started building the operating system around the sale, not just the sales assets
Once the problem was framed this way, a deck or landing page alone felt insufficient. They could improve the surface, but they would not tell us whether the company was actually getting smarter from every conversation.
So I began defining a lightweight revenue operating system: buyer segments, qualification criteria, buying triggers, pipeline stages, a decision log and a weekly revenue memo. None of these artefacts was particularly glamorous. Their purpose was to make learning cumulative.
If five prospects object to the same thing, that should become a product-marketing insight. If one segment repeatedly reaches pilot but stalls at security review, that should change what evidence we prepare. If a lead came in because of a particular regulatory or infrastructure trigger, that should affect how we find similar accounts.
The broader lesson was that an early growth system should be designed to learn before it is designed to scale.
"Strategy requires clarity about what we know and where our knowledge has limits. Recognising these boundaries allows us to focus on actionable opportunities and informed decision-making."
There was a temptation throughout the work to make everything look more certain than it was. Create a polished TAM. Pick an ICP. Write the definitive positioning statement. Draw the funnel. Present it as strategy.
But much of early-stage strategy is provisional by nature. The useful question is not whether an assumption looks convincing on a slide; it is whether the team knows what evidence would make it stronger or force it to change.
I became more deliberate about separating three things:
What we knew. Signals already visible in the product, community, existing customers and conversations.
What we inferred. Patterns that seemed strategically plausible but still required validation.
What we needed to test. Claims that should directly shape the next customer conversation, experiment or commercial decision.
What stood out at that time was that this seems like having good research hygiene. But now, I also see it as a form of commercial discipline.
…
What changed in how I see my own role
I went into the work primarily trying to see if human-centred methodologies apply could influence revenue and growth strategy methods for a start-up. I came out with a broader view of what growth and strategy design can be.
Design did not mean making the sales deck look better. It meant designing the logic that connected customer problems, product capabilities, organisational decisions and commercial action.
Research was not a discovery phase to complete before “the business work” started. It was part of the revenue engine. Positioning was not copywriting. It was a choice about which problem the company wanted to be understood for. A CRM was not merely an administrative database. Done properly, it could become organisational memory.
And growth itself was not one discipline. It sat in the overlap between product, marketing, sales, operations, research and strategy.
perhaps, the most useful learning of all was that
I did not leave with a new formula for growth
I left with a stronger set of questions that now guide my approach. I focus on identifying which problems are significant enough for customers to invest in, who feels these challenges most directly, and what conditions must be in place for them to choose our solution. I look for points in the buying journey where confidence drops, and prioritise capturing learnings from every lost opportunity. I also distinguish between the facts in our commercial narrative and the assumptions we have repeated over time.
This is the core of growth and strategy design as I see it. My focus is on making the problem, the value, and the path to market clear for the organisation, and then establishing feedback loops that help these elements adapt over time.
I began with a mandate to convert adoption into revenue. Through this work, I learned that scaling revenue depends first on scaling understanding within the organisation and among customers.