allo capital
CATEGORY CREATION
Eight months as strategic advisor to Allo Capital. I applied the Play Bigger method of category design to its problem space, defined intent-based allocation as a new funding category, and delivered a 45-page category strategy.
8 months · Strategic Advisor
Overview
From November 2024 to June 2025 I was strategic advisor to Allo Capital, a young company building tools for onchain capital allocation: grants, quadratic funding, retroactive rewards and other ways organisations distribute money through blockchain mechanisms.
Allo had strong technology and no agreed story about what it was. I applied the method of category creation, from the book Play Bigger, to the problem space the founders were working in. I helped the team settle its priorities, defined a new category for the company to lead, intent-based allocation, and delivered a 45-page category strategy, alongside a community strategy and a report from a multi-day sprint with a major web3 platform. Allo closed its first enterprise contract during the engagement, in March 2025.
My Role
I was an advisor, not an operator. I ran the discovery interviews and the workshops, made the recommendations, and wrote the strategy documents. The founders made the decisions and ran the company. The Capital Allocation Pattern Language (CAPL), the taxonomy of funding mechanisms the category is built on, was developed by the team and me together.
What Category Creation Means
The idea comes from Play Bigger (Al Ramadan, Dave Peterson, Christopher Lochhead and Kevin Maney, 2016). Its argument: the companies that capture the most value rarely win by being slightly better inside a market that already exists. They define a new category, teach the market to see it, and become its "category king." The discipline is called category design. It is not marketing. It decides what a company is the leader of before anyone decides how to promote it.
The method rests on a few ideas:
- A point of view. A story that names a problem, shows why the old way is breaking down, and describes the new way and the category it belongs to.
- Designing it all together. The product, the company and the category are designed as one system, with an ecosystem of customers, partners and advocates around them, instead of building the product first and finding the story afterwards.
- A lightning strike. A concentrated public moment that makes the new category visible at once.
It is a method with prompts to answer and documents to produce, which is why I could apply it, not just admire it.
The Problem
Choosing how to distribute money onchain was hard. An organisation that wanted to run a grants round had to choose between mechanisms such as quadratic funding, milestone grants, retroactive rewards and streaming payments, configure them, and stitch together tools that didn't talk to each other. Most knew what they wanted to achieve; few had the mechanism-design expertise to get there.
Allo could solve that, but it had two problems of its own. Its market was crowded with grants platforms and treasury tools, each strong at particular mechanisms. And internally, the team hadn't yet agreed its priorities.
The Method
Discovery. I started with structured interviews with the team, each covering the same ground: what the category was, what set Allo apart, where the opportunity lay and what could go wrong. They showed that the team described the company in different ways, and that its priorities needed settling.
Market and ecosystem research. I mapped existing tools across grants platforms, treasury management and mechanism-design consultancies. Among those I reviewed, none offered a full path from what an organisation wanted to achieve to a configured mechanism.
A category-design framework. I chose the Play Bigger approach to category design over Blue Ocean Strategy and Crossing the Chasm, because it treats the category, the company and the community as one system. In web3, the early community does much of the work of defining a category.
Applying Play Bigger to Allo's Problem Space
One of the founders asked me to turn the book into something the company could act on. I worked in three documents. The first answered the book's own prompts about the company, the problem and the new way, using what I had learned from the team and the market. The second turned those answers into the strategy the team treated as its source of truth. The third, Blueprints and Lightning Strikes, was the plan: a map of the organisation and the public moments the whole team would work towards.
One adjustment came early. Onchain capital allocation was not a blank space; grants, quadratic funding and treasuries already existed. So the job was less to invent a market than to design the category: to find the frame in which Allo was the obvious leader. The frame was intent-based allocation.
The point of view. Allo's story had to say what was wrong with the old way and what the new way was. The old way asks an organisation to choose a mechanism and assemble the tools itself. The new way asks it to state the outcome it wants and lets the system do the rest. The whole point of view turns on one change of question.
The flywheel. In the book's method, the category, the company and the ecosystem are designed together. For Allo I drew them as a flywheel, so that each one fed the next. A clear category story brings clients. Client work, written up as public case studies, feeds the early community. The community repeats, extends and co-authors the story. I made the middle link concrete with a publication process: drafts written inside the team, then opened to the community on a research forum, where a collaborator could earn a co-author credit, and only then published on the company's own blog.
Lightning strikes. The plan treated a major industry conference later in 2025 as the main public moment, with smaller activations before it. By then the team would need one coherent story, and a script for each person who would carry it. This study ends before that conference.
One Decision Up Close: The Retreat
In March 2025 I facilitated an in-person retreat to settle the team's priorities: in particular, how to balance client services against building the platform.
How I ran it. Before any debate, the team agreed the criteria for judging the options. I used MoSCoW prioritisation (must, should, could, won't) rather than a scoring method such as RICE, because RICE needs estimates and the team had no history to base them on. Each person rated the options against the criteria on their own, and then we discussed.
The decision. The answer was a sequence rather than a choice: strategic services now, to bring in revenue and teach the team what clients needed; the platform next, built from those lessons; and the category as the long game. An explicit split of the team's time between the two kept the platform protected.
Making it stick. Everyone committed to the plan, and any remaining concerns were written down so they could be checked later: disagree and commit, made explicit. The same approach became how the team handled later strategic questions.
What I Delivered
The Category Strategy
The 45-page strategy defined intent-based allocation: an organisation states the outcome it wants in plain language, and the system translates that into a configured mechanism. Its point of view, in one line: organisations shouldn't have to become mechanism-design experts to deploy capital well; the complexity should live in the system, not with the user. That moved the conversation from "which mechanism should we use?" to "what outcome do we want?"
The strategy also set out the market position, the three-horizon roadmap, the go-to-market plan, and the flywheel connecting the category, the company and its community. Its central reframing was service work as research: every client engagement doubled as market intelligence for the platform.
The Community Strategy
A community plan for a category that didn't exist yet. It defined tiers of involvement with a clear exchange at each, without presenting the early community as a DAO, along with contribution programmes for researchers, writers and early-adopting organisations.
The Platform Sprint
In May 2025 I designed and facilitated a multi-day implementation sprint with a major web3 platform that was exploring allocation mechanisms for its ecosystem funding. I chose a documentation-first approach over rapid prototyping: the platform needed strategic clarity more than screens, and wireframes would have locked in interface decisions too early. Every session was recorded and summarised for the participants each day.
The report that followed took each of the stakeholders' needs through the same steps: their intent, the relevant patterns in CAPL, the trade-offs (capital efficiency, governance overhead, incentive alignment, implementation complexity), a recommended mechanism with its settings, and a path to implementing it with existing infrastructure. It was intent-based allocation done by hand, for a real client.
What It Led To
- A strategy the company worked from: the category, its point of view and the roadmap.
- The team aligned on a sequence of priorities, with a way of making later decisions.
- Allo's first enterprise contract, closed in March 2025, during the engagement.
- A real test of the approach in the May sprint and its report.
- A method I carried further. In WisCAM, my independent research, I used the same category-design discipline on a different question and named a new category, wisdom capital allocation.
The engagement ended in June 2025, and this study ends there too. Whether intent-based allocation becomes the way the field thinks about capital allocation is a longer story, and not one I can report on.
What I Would Do Differently
Measure from day one. Most of what I know about the change in the team came from observation. Tracking decisions and client conversations from the start would have given firmer evidence.
Make the diagrams first. Category design is partly visual design. Diagrams like the ones in this study, the old way against the new way, the flywheel, the path from intent to mechanism and the three horizons, would have sped up alignment if I had made them in week one instead of explaining the ideas again and again.
Run the sprint sooner. Moving the platform sprint from May to March would have fed its lessons back into the strategy while there was still time to use them.