AI adoption is often presented as a tooling decision.
Which chatbot should we approve? Which coding assistant should developers use? Which AI features should we add to the product? Which automation platform should finance, support or operations experiment with?
Those questions matter. But they are not the hardest part.
For founder-led software and digitalisation businesses, the bigger challenge is that AI changes the shape of work. It changes who can do what, how quickly ideas move from concept to prototype, which handoffs still make sense, and which skills now matter inside roles that used to be clearly separated.
The real risk is not that a business chooses the wrong AI tool. The real risk is that the organisation keeps operating as if the old role boundaries still apply.
At STRONGER Business Partners, we believe practical AI adoption should strengthen the core company rather than distract from it. That means beginning with repeated work, setting clear rules, protecting customer trust and treating AI as an operating discipline rather than a side project. But there is now a second layer to that advice: businesses also need to redesign how teams work around AI.
Because once AI enters the organisation, work starts moving.
AI usually arrives before the organisation is ready
In many companies, AI adoption has already started informally.
A support lead is using AI to summarise tickets.
A salesperson is using it to prepare proposals.
A product manager is analysing customer feedback with it.
A marketer is drafting campaign variants.
A finance manager is using it to clean data or build a first dashboard.
A developer is using a coding assistant to move across parts of the stack that previously required more specialised support.
This is not necessarily a problem. In fact, it is often the first sign that AI is useful.
But informal adoption creates a new type of management challenge. The company may have AI activity everywhere, but no clear view of which use cases are valuable, which are risky, which are duplicative and which are slowly becoming business-critical.
One team may create a useful internal workflow that nobody else knows exists. Another may build an automation that saves time but has no owner. A third may use a tool in a way that creates data protection or customer trust issues. Developers may inherit prototypes that were never designed to become production systems. Leaders may see many demos but little measurable change in the business.
This is where AI adoption becomes less about access to tools and more about organisational design.
The STRONGER starting point still holds: begin with repeated work
The best first AI use cases are usually close to existing workflows.
Support triage. Knowledge search. Proposal drafts. Internal quality assurance. Documentation. Onboarding. Data cleanup. Customer feedback analysis. Reporting packs. Sales preparation. Product discovery notes.
These areas are useful because they are familiar. They already exist inside the company. They are close enough to the core business to matter, but usually not so sensitive that every experiment creates unacceptable risk. They can also be measured: time saved, errors reduced, response times improved, manual steps removed, adoption increased or customer experience improved.
This approach protects the team from AI theatre.
It avoids the pattern where a company launches a broad “AI transformation” programme before it has proved that AI can improve one real workflow. It also gives founders a practical way to learn without turning the business into a collection of experiments.
But starting with repeated work is only the first step.
Once AI improves repeated work, the work itself begins to change. The person who used to request a report can now create the first version. The person who used to brief a developer can now prototype a workflow. The person who used to pass customer feedback to product can now cluster, interpret and act on it. The developer who used to wait for detailed specifications can now explore, build, document and test more of the path themselves.
That is the deeper shift.
The X post that names the shift
Boris Cherny, creator and head of Claude Code at Anthropic, recently described how traditional product-building functions are beginning to “melt into a new kind of role”. Looking at the Claude Code team, he suggested five emerging archetypes: Prototyper, Builder, Sweeper, Grower and Maintainer.1
The important part of that post is not the labels themselves. The important part is the change in logic.
The old organisational question was: what is your function?
Are you engineering, product, design, data science, marketing, finance, sales, support or operations?
The new question is increasingly: what mode of work does this situation require?
Does the business need someone to explore possibilities?
To turn a promising prototype into something reliable?
To simplify and remove complexity?
To improve adoption and fit?
To keep a mature system secure, efficient and dependable?
Cherny also notes that people may span two or three of these modes, and that the right mix changes depending on the stage of the product.1 That observation matters for smaller and founder-led companies because people already wear multiple hats. AI simply makes that multi-role reality more visible, more powerful and more urgent to manage.
What this looks like inside a founder-led business
A familiar pattern is emerging.
A business begins with sensible experimentation. The team tests AI in support, marketing, software development and internal operations. The early gains are real. People move faster. They produce drafts more quickly. They search knowledge bases more effectively. They build small tools that would previously have sat in the backlog.
Then the second-order effects appear.
Marketing creates a lightweight automation for campaign reporting. Finance builds a forecasting model or a dashboard. Support identifies recurring product issues before product has asked for an analysis. Product managers generate better discovery summaries. Developers use AI agents to work across frontend, backend, infrastructure and documentation. Data specialists move from producing static reports to prototyping tools that others can use.
Suddenly, the organisation has more builders than it realised.
That is exciting, but it creates a new management problem. A prototype created by a non-technical team may be useful, but not secure. An AI-generated workflow may be fast, but not documented. A dashboard may answer a real question, but nobody knows whether the data is reliable. A customer-facing AI feature may be impressive, but not aligned with the trust that customers expect from a specialist software provider.
The bottleneck has moved.
It is no longer simply: “Can we build this?”
It is: “Can we decide what should be built, who owns it, how it is hardened, how it is maintained and when it should be removed?”
AI does not eliminate roles. It changes the role system.
There is a temptation to describe AI as a force that will flatten organisations. In practice, we see something more nuanced.
AI does not remove the need for expertise. It does not remove accountability. It does not remove product judgment, customer understanding, engineering discipline, security, privacy, finance or leadership.
What it does is make many more people capable of contributing outside their old lane.
A product manager can now do more analysis.
A finance person can now prototype more automation.
A support lead can now create more product insight.
A marketer can now test more ideas.
A developer can now cover more of the product lifecycle.
A founder can now interrogate the business with much greater speed.
That is why the main challenge is not only tools. It is the operating model around the tools.
Companies need to define how AI-enabled work moves from idea to experiment, from experiment to workflow, from workflow to system, and from system to long-term ownership.
Cherny’s five archetypes provide a useful way to think about this.
The five AI-enabled work modes businesses need to manage
These should not necessarily become job titles. In many companies, one person will play several of these roles. What matters is that the organisation understands the mode of work and the handoff between modes.
1. The Prototyper: finding what is now possible
The Prototyper explores.
This person identifies a repeated pain point and tests a better way. They might create a rough customer feedback analyser, a first support triage workflow, a reporting assistant, a proposal generator or a prototype of an AI-enabled product feature.
The Prototyper is valuable because AI lowers the cost of trying. Many ideas that were previously too small, too uncertain or too slow to explore can now be tested quickly.
But prototyping needs boundaries. Without them, the company gets more demos than decisions.
A strong Prototyper needs problem-framing ability, domain understanding, AI fluency, taste and a willingness to discard most ideas. The definition of success is not “we created something”. It is “we learned whether this is worth building”.
Useful management questions:
- What business problem is this prototype testing?
- What data is it allowed to use?
- What would make us stop?
- What would make us harden this into a real workflow?
- Who needs to review it before anyone relies on it?
2. The Builder: turning experiments into reliable systems
The Builder makes things real.
This is where many AI initiatives fail. A prototype can work once in a controlled demo and still be unsuitable for daily business use. Production-grade work requires integrations, permissions, testing, documentation, security, monitoring, data quality and clear ownership.
The Builder is not just a developer. In an AI-enabled business, Builders may sit in engineering, operations, RevOps, data or product. Their role is to convert a promising idea into something the company can depend on.
This mode becomes more important as AI increases the number of prototypes. If everyone can create a first version, the organisation needs stronger discipline around what becomes a real system.
Useful management questions:
- What has to be true before this workflow is used in production?
- Which systems does it connect to?
- Who is accountable if it fails?
- How will we test accuracy, reliability and security?
- What needs to be documented so another person can maintain it?
3. The Sweeper: simplifying what AI makes too easy to create
The Sweeper removes complexity.
AI makes it easier to create content, dashboards, code, workflows and automations. That is useful, but it also creates clutter. A company can quickly end up with too many tools, too many prompts, too many overlapping workflows, too many internal assistants and too much code that nobody fully understands.
The Sweeper’s job is to simplify. They clean up the user experience, remove unnecessary steps, consolidate tools, retire unused workflows, reduce technical debt and improve performance.
This role is especially important because AI rewards addition by default. Businesses need people who are willing to subtract.
Useful management questions:
- Which AI workflows are actually used?
- Which ones duplicate existing processes?
- Which tools should be retired?
- Where has AI made the process more complicated rather than simpler?
- What can we remove without reducing customer value?
4. The Grower: improving fit, adoption and outcomes
The Grower takes something that works and improves its fit with the business.
For a product, this might mean improving product-market fit. For an internal workflow, it might mean improving adoption, accuracy, speed or usefulness. For customer support, it might mean reducing response times while increasing answer quality. For sales, it might mean improving proposal consistency without making every proposal sound generic.
The Grower is focused on outcomes, not novelty.
This mode matters because many AI projects show early promise but never become embedded in the business. They remain optional, inconsistent or poorly measured. The Grower asks whether the workflow is genuinely changing performance.
Useful management questions:
- What metric should improve?
- Who is actually using this?
- Are customers or employees experiencing a better outcome?
- What feedback loop improves the system over time?
- Is the workflow creating measurable value or just activity?
5. The Maintainer: protecting trust as AI becomes business-critical
The Maintainer keeps mature systems secure, reliable, fast and efficient.
This role becomes more important as AI moves from experimentation into core operations. AI-enabled workflows need monitoring. Models change. APIs change. Costs change. Data quality changes. Customer expectations change. Regulations and standards evolve. The organisation’s own processes change.
The Maintainer is responsible for continuity.
In specialist software and digitalisation businesses, this role is closely tied to trust. Customers may welcome AI-enabled speed and insight, but they still expect reliability, privacy, security and accountability.
Useful management questions:
- Who owns this workflow after launch?
- How do we monitor quality, cost and performance?
- What happens when the model or vendor changes?
- How do we handle incidents?
- How do we ensure the system remains compliant and explainable enough for the context?
The missing layer: decision rights
The five modes are helpful, but they are not enough on their own.
Businesses also need decision rights.
Who is allowed to prototype?
Who approves the use of customer data?
Who decides that an experiment can become part of a core workflow?
Who signs off customer-facing AI features?
Who can retire a tool?
Who owns the budget?
Who explains the decision to customers, employees or regulators if something goes wrong?
This is where governance becomes practical rather than bureaucratic.
NIST’s AI Risk Management Framework describes AI risk management as a way to improve trustworthiness across the design, development, use and evaluation of AI systems.2 ISO/IEC 42001 similarly frames AI management as a structured set of policies, processes and controls for governing how AI systems are designed, developed, deployed and used.3 The OECD AI Principles also emphasise trustworthy, human-centred AI, including transparency, human oversight, privacy and accountability.4
For a founder-led business, this does not need to mean a heavy compliance structure from day one. But it does mean the organisation needs a simple operating rhythm:
- a register of AI use cases;
- clear data rules;
- an approval path for customer-facing or high-risk use;
- owners for each workflow;
- a distinction between experiments and production systems;
- review points for quality, security, privacy and cost;
- a way to retire things that no longer help.
The goal is not to slow the team down. The goal is to make useful AI adoption safe enough to scale.
Why training alone is not enough
Many companies respond to AI by offering tool training.
That helps, but it is incomplete.
Employees do need to know how approved tools work. They need to understand prompting, privacy, verification and the limitations of AI-generated output. But the bigger skill shift is not tool-specific. It is role-specific and workflow-specific.
A Prototyper needs to learn how to frame a problem, generate options and test quickly without creating risk.
A Builder needs to learn how to harden AI-assisted work into reliable systems.
A Sweeper needs to learn how to reduce complexity created by rapid experimentation.
A Grower needs to learn how to measure adoption and improve fit.
A Maintainer needs to learn how to monitor, govern and improve AI-enabled workflows over time.
McKinsey’s 2025 global AI survey points in the same direction: organisations seeing value are not merely deploying tools; they are redesigning workflows, elevating governance, tracking adoption and ROI, and investing in role-based capability building.5
That is the difference between AI usage and AI adoption.
Usage is when individuals try tools.
Adoption is when the organisation changes how work gets done.
What businesses should consider before adopting AI
The most useful AI adoption conversations begin with the business, not the tool.
1. Where is the repeated work?
Look for work that happens often, consumes time, depends on information retrieval, requires summarisation, creates repetitive drafts or involves manual data handling.
Good candidates include support triage, internal knowledge search, proposal preparation, documentation, onboarding, product feedback analysis, QA support and reporting.
2. Where is the work already moving?
Identify where employees are already using AI informally. This is often the best map of latent demand.
Ask where people are experimenting, what they are trying to improve, what data they are using and whether the output reaches customers or only stays internal.
3. Which role mode does each use case need?
Do not ask only which department owns the use case. Ask which mode of work is needed now.
Is this still a Prototyper problem?
Does it need a Builder?
Has the workflow become messy enough for a Sweeper?
Is it ready for a Grower?
Has it become important enough to need a Maintainer?
4. What is the handoff from prototype to production?
This is one of the most important questions.
A business should encourage experimentation, but it should not allow experiments to quietly become core systems without review.
Define the point at which a prototype must be assessed for security, privacy, data quality, reliability, documentation and ownership.
5. What customer promise must not be broken?
AI should strengthen the customer promise, not blur it.
For specialist software businesses, trust is often part of the product. Customers care about faster support, better insight, fewer errors and less manual work. They also care about reliability, continuity and accountability.
If an AI use case improves speed but weakens trust, it is not a good use case.
6. What skills need to shift?
The organisation should not only ask “Who knows how to use AI tools?”
It should ask:
- Who can frame problems clearly?
- Who can verify AI-generated output?
- Who understands the workflow deeply enough to redesign it?
- Who can move between business and technical teams?
- Who can judge when a prototype is good enough to test but not good enough to ship?
- Who can maintain the system after the exciting part is over?
7. What should we stop doing?
AI adoption is not only about adding capability. It should also remove work.
If AI creates more meetings, more tools, more dashboards and more review layers without removing manual effort, the business is probably adopting technology without improving the operating model.
The Sweeper role is therefore essential. Someone must be responsible for subtraction.
A practical adoption path for founder-led businesses
For founder-led businesses, the strongest approach is usually staged.
First, map current AI use. Do not begin with a policy written in isolation. Begin by understanding what employees are already doing and where AI could improve repeated work.
Second, choose a small number of high-value workflows. Pick two or three areas where the business can measure time saved, quality improved, errors reduced or customer outcomes improved.
Third, assign the work modes. For each use case, identify who is prototyping, who can harden it, who will simplify it, who will improve adoption and who will maintain it if it becomes important.
Fourth, set the rules. Define approved tools, data boundaries, review requirements and escalation points. Make the rules clear enough that people can experiment safely.
Fifth, create a prototype-to-production path. A prototype should not become business-critical by accident. Create a lightweight gate where the business reviews security, privacy, data quality, reliability, ownership and value.
Sixth, measure outcomes. Track business value, not AI activity. Fewer manual steps, faster cycle times, improved support quality, better sales consistency, lower error rates, higher adoption and better customer experience are stronger indicators than the number of AI tools in use.
Seventh, update roles and expectations. Over time, reflect the new work patterns in job descriptions, hiring, incentives, training and team structure. The organisation chart may stay functional, but the operating model must recognise that people now contribute across old boundaries.
The founder’s job: protect focus while increasing capability
Founders should be ambitious about AI, but disciplined about adoption.
The temptation is to chase visible novelty: the newest tool, the impressive demo, the competitor’s AI feature, the internal hack that creates excitement for a week.
The better founder question is: where does AI make the company stronger?
Where does it improve the product?
Where does it make the team more effective?
Where does it reduce dependency on manual work?
Where does it improve customer trust?
Where does it help the company learn faster?
Where does it create durable capability rather than temporary excitement?
This is especially important in profitable specialist software and digitalisation companies. These businesses often win through domain knowledge, customer intimacy, reliability and continuity. AI should amplify those strengths, not distract from them.
A founder-led company does not need to look like a frontier AI lab. It needs an operating model that lets people use AI safely and effectively in the context of the business they are building.
The conclusion: AI adoption is an organisation shift
AI tools are becoming more capable and more accessible. That trend will continue.
But tools alone will not create advantage for most businesses. Advantage will come from the ability to redesign work around the tools.
The companies that benefit most from AI will be the ones that understand which work should be automated, which work should be augmented, which work still requires human judgement, and how roles need to adapt as people become capable of doing more.
The main challenge is not only choosing AI tools.
It is building an organisation that knows how to prototype quickly, build responsibly, simplify deliberately, grow what works and maintain what matters.
That is the real work of AI adoption.
For STRONGER Business Partners, this is the practical lens: AI should not distract the team from the core company. It should help the company become more focused, more capable and more resilient.
Not because the business has adopted AI tools.
Because the business has adapted how it works.
Sources
Boris Cherny, “X post on AI-era product role archetypes”, 28 June 2026. The post describes engineering, product, design and data science “melting” into five archetypes: Prototyper, Builder, Sweeper, Grower and Maintainer. An accessible rendering of the post is also available via Digg: “Boris Cherny, Claude Code creator, proposes five functional archetypes for software roles merging on AI teams”.
x.com (opens in a new tab)NIST, “AI Risk Management Framework”, overview page, accessed 1 July 2026.
nist.gov (opens in a new tab)ISO, “ISO 42001 explained: What it is and how it supports AI governance”, accessed 1 July 2026.
iso.org (opens in a new tab)OECD, “AI Principles”, adopted 2019 and updated 2024, accessed 1 July 2026.
oecd.org (opens in a new tab)McKinsey & Company, “The state of AI: How organizations are rewiring to capture value”, 12 March 2025.
mckinsey.com (opens in a new tab)