Over the past months, I have talked with a number of Danish B2B software companies, typically twenty to eighty people, who will tell you, often within the first ten minutes of a conversation, that they have “started using AI” and that the results have been genuinely useful, and yet who will also admit, usually with a slight shrug, that the gains have stayed strangely contained, confined to whichever individual happened to be curious enough to open a chat window or get Claude Code to produce a code snippet. That contained, individual mode of use, is what I have started calling single player mode, because it is one person using one model on an ad-hoc basis, is not a failure of imagination so much as a natural first step to apply LLMs to current ways of working, and it is also, I think, the reason so many companies plateau just as the technology starts to get genuinely capable of more.
The plateau is not really about the model. Claude, used through something like Cowork, is now quite capable of holding and working across far more organisational context than any single person carries in their head, which means the limiting factor has quietly shifted from “is AI good enough” to “has the organisation built anything for it to work with.” Single player mode answers the first question and ignores the second, and a company that wants to move past “yeah, we use AI” has to start treating its use of AI as something closer to a systemic capability, distributed and shared across the organisation, which in practice tends to mean working on three connected planes at once rather than picking the cleverest available trick.
Plane 1: Customer & Product Knowledge
The first plane is the knowledge a company already has about its customers and its own products, scattered as it usually is across project specifications nobody has reread since they were written, meeting notes that exist mainly to satisfy whoever insisted on taking them, and interview that were transcribed, summarised once, and then forgotten. Most SMBs I talk with are sitting on a genuinely large amount of customer signal that nobody has the time, or frankly the inclination, to keep stitching back together by hand. Teresa Torres addressed this problem for product teams a decade ago in Continuous Discovery Habits, where the central claim is not that customer research matters, which nobody disputes, but that research conducted as an ongoing activity produces a categorically different kind of insight than research conducted occasionally by whichever person has been assigned to “own discovery” this quarter, and that the artefact worth maintaining is not a report but something closer to a living map of the company knowledge derived from the research connecting outcomes, the opportunities that bear on them, and the solutions worth testing. This type of continuous discovery was a tough proposition for most companies and almost impossible to do for small SMBs, as they could not dedicate sufficient critical resources to the task of summarising and sharing the data. As it turns out, LLMs are excellent at this task. With a properly set-up Cowork-skills layer, an LLM can summarise existing customer knowledge into opportunity and solution maps, often creating new insights across the SMB organization.
Plane 2: Company Voice
The second plane is the voice of the company itself, by which I mean something more specific than tone of voice in the marketing sense: the accumulated, usually undocumented understanding, held partly by the founder and partly by whichever account manager has been there the longest, of which problems the company actually solves, which ones it has learned not to take on, and which way it tends to answer a given kind of question when a customer asks. That understanding is strategic and points to ways of addressing problems and solutions. It is often also single player mode by default, living in a handful of heads rather than anywhere a new hire, a support agent, or for that matter an AI system could consult it. Making it explicit, even partially, as one or more co-work skills layers with MCP-access to existing documents, turns a dependency on specific people into something the rest of the organisation can build on. .
Plane 3: The Skills Layer
The third plane is the one that determines whether any of this knowledge compounds over time, because distilled customer knowledge and a documented company voice are both, on their own, still things that are built on historic knowledge. To continuously build and improve the customer, market, product, and technology insights across the SMB organization, the third plane brings a defined set of skills, both concrete as .md-docs and abstract as skills each employee possess, that a new employee can pick up and use to pull the right customer history, get a useful, dynamic set of customer discovery questions, create the right outcomes in terms of both summaries and specific opportunity/solution designs, and share back across the organisation. Torres’s original model assumed a product trio, a product manager, a designer, and an engineer, doing discovery together every week; most of the SMBs I am describing have nothing resembling three dedicated discovery people, so the reusable skill is what keeps the opportunity space she describes open to more than three people, without each of them having to relearn a method from scratch. This is the meta-layer that lets the gains from the first two planes reach people who were never going to build their own version of either, and it is also, not coincidentally, what separates a company that applies a tool from one that has reshaped how it works.
None of this requires a grand transformation programme, and I would actually argue against treating it as one, not least because the companies that get the furthest with it tend to start narrow, with one genuinely tedious piece of customer-knowledge work or one recurring drafting task, prove that the systemic version beats the single player version on that one thing, and only then extend the pattern outward. What changes is not the ambition of any single project but the habit underneath it, continuous rather than occasional, shared rather than parked in one person’s chat history.
This is also where Copenhagen Product Collective comes in. Helping a Danish B2B software company figure out where its own first narrow case sits, across customer knowledge, company voice, or the skills that carry both further, is the kind of conversation I have most days at Copenhagen Product Collective, and if any of the above sounds closer to where your organisation currently is than you would like, I am glad to talk it through.
At Copenhagen Product Collective, I work with companies to assess their product and technology leadership structures and build capabilities across both domains. If you’re wrestling with questions about how to structure your senior leadership and team topology, let’s talk.
