Notes on growth and strategy design
Before you scale Growth, Design what you need to learn
What working on commercial strategy for an open-source AI platform taught me about positioning, buying journeys, and building growth systems that learn before they scale.
by David Soh
09 Sep 2026
11 min read
Growth strategy
Customer Strategy
Product Marketing
Before this work, most of my experience with growth came from SMEs, particularly F&B, and more conventional start-ups. I was familiar with questions of acquisition, positioning, customer value and conversion. What I had not yet encountered was a business where widespread product adoption could exist so independently from monetisation.
That became the central tension in my work on growth and strategy for Open WebUI, an open-source AI platform. The brief sounded straightforward: help turn strong adoption into a clearer commercial opportunity.
The familiar responses were all available. Refine the customer segments. Find leads. Strengthen the sales narrative. Improve the landing page. Build a more deliberate pipeline.
But before optimising any of those things, I kept getting stuck on a more fundamental 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.
The Premise
Before asking how to scale sales, I needed to understand whether the commercial story was coherent enough to scale.
That changed the nature of the work. What began as a growth problem started to resemble service design: trace where value is created, where it becomes unclear, which actors have different incentives, and which assumptions need to be tested before the organisation commits to scaling anything.
The important shift was not from “business” to “design”. It was from treating growth as a sequence of activities to treating it as a system of decisions.
The first lesson: Adoption is evidence of utility, it does not mean there is evidence of a market.
Open-source adoption was a powerful signal. People had enough of a problem to search for a solution, install it, configure it and keep using it. But those behaviours still did not answer three commercially important questions: who will pay, what will they pay for, and what has to happen for the purchase to become urgent?
A developer might value model flexibility. An IT leader might care about deployment control. Security may care about data boundaries. Procurement may want contractual accountability. An executive sponsor may care less about any single feature than about making AI usable across an organisation without creating another uncontrolled layer of tools.
They can all be talking about the same product while valuing very different outcomes.
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.
My working distinction became simple: usage is evidence of utility; a market requires a buyer, a buying trigger and a reason to exchange money.
That sounds obvious written down. In practice, it changed how I looked at market sizing. A huge universe of organisations “adopting AI” was less useful than knowing which twenty organisations were worth speaking to next and what we expected to learn from each conversation.
The second lesson: Features do not become value until someone can explain the consequence
One of the simplest exercises became one of the most useful: take the language of the product and keep asking, “so what?”
Translating capability into consequence
Product language → Organisational meaning/value
Capability
Commercial Consequence
Self-hosting
Greater control over deployment, data flows and where the AI interface sits inside the organisation.
Model flexibility
Teams can change or combine providers without rebuilding the entire employee experience around one vendor.
Role-based access
AI can move from individual experimentation toward something an organisation can govern as shared infrastructure.
So my working distinction became: usage is evidence of utility; a market requires a buyer, a buying trigger and a reason to exchange money.
The point was not to simplify the technology until it became meaningless. It was to identify 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 was where my design background became unexpectedly useful. Service designers constantly translate between levels: what a person experiences, what the organisation must do backstage, and what systems or policies make that experience possible.
Product marketing required a similar translation in reverse: technical capability → user consequence → organisational value.
The third lesson: Revenue has a service journey too
In much of my previous growth work, I could treat marketing, conversion and purchase as relatively legible parts of a customer journey. An open-source enterprise software complicated that model considerably.
The commercial journey was distributed across actors, someone might have already discovered and use the product, another person may validate it technically and someone completely different might becomes the internal champion. Security, legal and procurement introduce different requirements, while leadership wants confidence that the platform can survive beyond experimentation.
A simplified enterprise buying service
Multiple actors, multiple confidence gaps
01 Usage
Discover
A user or team already sees utility.
02 Problem
Validate
Technical fit and feasibility are tested.
03 Purchase
Champion
Someone has to make the internal case.
03 Purchase
Approve
Security, legal and procurement need evidence.
03 Purchase
Adopt
Value still has to survive rollout, renewal and expansion.
Once I mapped the journey, several “marketing problems” started looking like gaps between stages.
A technically convincing product does not automatically equip an internal champion to win budget.
A strong demo does not automatically answer procurement. Community enthusiasm does not automatically create an enterprise proof story.
Growth started to look less like a funnel and more like an end-to-end conversion service.
I started building the operating system around the sale, not just the sales assets
A deck or landing page could improve the surface, but neither would tell us whether the organisation was actually becoming smarter from each customer interaction.
So I began defining a lightweight revenue operating system, the artefacts themselves were not especially revolutionary or glamorous (to me at least). Their purpose was to make learning cumulative.
Self-hosting
Who appears to experience the problem most intensely?
Qualification criteria
What makes an account worth learning from now?
Buying triggers
What changes the problem from interesting to urgent?
Pipeline stages
Where does confidence increase or collapse?
Decision Log
Which assumptions changed, and why?
Weekly revenue memo
What did the organisation learn that should affect the next decision?
If five prospects object to the same thing, that should become a product-marketing insight. If one segment repeatedly reaches pilot and stalls at security review, that should change what evidence is prepared. If a lead appears because of a particular infrastructure or regulatory trigger, that should change how similar accounts are found.
"An early growth system should be designed to learn before it is designed to scale."
Strategy became less about looking certain and more about knowing what still needed evidence.
There was a temptation to make everything look more certain than it was. Create a polished TAM, pick an ICP, write the definitive positioning statement then draw the funnel and finally present it as strategy.
But early-stage strategy is provisional by nature, and 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.
We have to take a human-centred approach so to speak. To quote Hellon – "change hearts, change numbers".
What we knew
Signals already visible in the product, community, customers and conversations.
Why does it matter?
Patterns that seemed strategically plausible but still required validation.
Who pays, and why now?
Claims that should shape the next conversation, experiment or commercial decision.
"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."
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 was not whether I believed in growth or design.
It was how I understood their intersection.
I approached this work drawing on two core “toolkits” that have consistently delivered results for me: my background in driving growth for established businesses, and a service design practice grounded in research, systems thinking, and human-centred approaches.
I became interested in whether design methods could directly address commercial questions that traditional growth frameworks often overlook. For example: What is the real problem we are monetising? Who feels this problem acutely enough to pay for a solution? At what point does confidence break across the buying journey? How does the organisation adapt its assumptions quickly enough to keep pace?
This experience further reinforced that design is also about shaping the logic that connects customer problems, product capabilities, organisational decisions, and commercial action.
I see research as an integral part of the revenue engine, not just a discovery phase to finish before business decisions begin. Positioning goes beyond copywriting; it is a deliberate choice about the problem the company wants to be recognised for solving. When thoughtfully designed, a CRM can serve as organisational memory, not just an administrative tool.
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
What I would takeaway
Before scaling growth, clarify the problem, define the value, and map out the path to market. Establish feedback loops so you can adjust each of these as new evidence emerges.
I began with a mandate to make a commercial opportunity clearer. What I learned was that scaling revenue depends first on scaling understanding inside the organisation and among the customers it hopes to serve.