The core logic of putting Stakeholder Capitalism into practice

Over the past couple of days, I have gone back through some of my early research diagrams. There was no AI then. Many of the ideas were already there, but I had not thought every relationship through, and the practical steps did not quite connect.

Looking at them now, I think some of those basic ideas are worth taking further. Bringing that earlier thinking back into real business, and combining it with the AI tools we have today, makes it possible to work out roles, processes and rules in more concrete terms.

This time, I have brought the core logic of putting Stakeholder Capitalism into practice together in one diagram. First, I want to make clear how a business creates value, how people participate, how work moves forward and how contributions are handled. Then we can refine each part against actual business needs.

Four ecosystems: first clarify the business's basic relationships

I still use the resource, operations and management, customer, and capital ecosystems as the foundation.

The resource ecosystem includes people, organizations and partners, as well as knowledge, technology and other resources. These need to come together in products, services and solutions that can actually be delivered.

The operations and management ecosystem organizes both the production and sale of value. I would like the core team to stay lean, focusing on direction, rules, coordination and results while also building channels, maintaining customer relationships and moving daily work forward. When particular capabilities are needed, the relevant roles can be brought in.

The customer ecosystem brings demand into the business. Customers buy, pay, use what they receive and bring back real feedback. Whether a product is useful or a service solves a problem ultimately has to be judged through the customer's actual experience.

The capital ecosystem looks at how capital can participate as the business develops, what the conditions for participation are, and how responsibilities and risks are borne.

These four ecosystems are four ways of looking at the business's relationships. They should not simply become four departments. The same person or organization may be part of several ecosystems at once.

To see whether things are working, return to the business results

Once people and resources are connected, the business needs a clear thread running through the work it actually does.

I see that thread as identifying needs, organizing production, completing sales and delivery, checking results, and then continuing to improve on that basis.

First, understand the customer's problem and the value we intend to provide. Then organize resources into a product, service or solution, connect with customers through channels, and complete the transaction and delivery. After that, check whether the customer received the expected result and whether revenue, costs, payment collection and delivery met the business's goals.

A lot of work may have been done without this whole sequence working properly. When results fall short, follow the sequence and ask: did we misunderstand the need, offer the wrong thing, fail to connect through the right channels, or run into a delivery problem?

Once the problem is clear, we can work out who needs to do what next. Customer feedback and business results then feed into the next round of value creation.

Give participation a clear place in roles and work manuals

I would like people who help build the business to be able both to contribute value on their own initiative and to take on tasks in response to actual needs.

Some people spot a problem, propose a solution and want to get something started. Others have a clear area of expertise and deliver when a suitable task comes to them. There should be room for both approaches, and every role should be able to participate in these ways.

For the practical arrangements, we can begin by analyzing responsibilities and then prepare a work manual for each role. What the role is responsible for, what it receives, what decisions it can make, who receives its output and how completion is confirmed all need to be clear.

A manual should help people get work done. Once they join a specific project, participants should know their place, how their work connects with what comes before and after, and who can coordinate when a problem arises.

There is a boundary here. Customers who only consume follow the purchasing and use process. Investors who only invest follow the relevant investment process. Their identity as a customer or investor does not itself require a co-builder's work manual. If they also take on a specific contributing role, they then work under the manual for that role.

Look at both when a task arises and where it comes from

Routine, periodic, triggered and passive are task attributes I want to retain in work planning.

Routine tasks are work that needs to continue as part of everyday operations. Periodic tasks happen at an agreed interval.

Triggered tasks arise only when an SOP reaches a particular point. We may not know in advance exactly when that will happen. For example, a review task arises when a customer submits material that needs checking and the process reaches the review stage.

Passive tasks are tasks a person receives after someone else raises a need or assigns the work.

These attributes can overlap. A monthly piece of work can be periodic and also assigned by someone else. A task triggered by a process reaching a particular point can also be assigned to the relevant role.

Distinguishing these attributes helps us understand when a task is created, where it comes from and who should handle it. They should not be treated as mutually exclusive kinds of roles, or used to restrict any role from contributing proactively.

Connect the four SOP directions as the problem requires

I want performance SOPs, business SOPs, functional SOPs and action SOPs to become progressively more specific, from overall results to detailed execution, while supporting one another.

The core operations and management team begins with performance SOPs, keeping its attention on value creation and business results. When a problem appears, it can decide which work at the business, functional or action level is needed.

Take a delivery delay. First, find out where it happened. If the problem is a handoff within the business, change that business process. If contractual, financial or other support is missing, bring in the relevant function. If the problem lies in a particular operation, clarify the method and delivery standard for that action.

There is no need to go through all four layers every time. Work on whichever layer the problem calls for, then return to the business results to see whether the problem has been resolved.

The process itself also needs proper connections between stages. What did the preceding stage deliver? Which prerequisite results must the next stage verify? What conditions must be met before it proceeds? How does each stage's purpose serve the overall process goal? All of this needs to be clear.

That is how SOPs can become tools for collaboration and improvement. They can be adjusted when new problems arise, while practices that prove useful are retained.

Rules for contributions need to connect with actual work

After participants deliver their work, there needs to be review and verification, assessment of contributions, and a process for putting the applicable rights and entitlements into effect.

Who verifies the work, against which standards, who has authority to decide, who bears costs and risks, and how a disagreement can be reviewed all need rules grounded in the actual business.

I think the first step is to keep the supporting evidence. We should be able to establish what was originally agreed, what was actually done, what results were delivered, how they were accepted and which rule was applied in the end.

Completing a task does not by itself establish a fixed share of rights or entitlements. Customer acceptance, confirmation of contributions and implementation of entitlements each have their own matters to check. The specific allocation, and the rights and obligations that apply, must be determined by the actual entity, its rules and the agreements in place.

Rules also need further refinement in practice. Quality problems, conflicts of interest and disagreements during collaboration can all provide grounds for improving them. This diagram first sets out how these parts connect; the specific arrangements still need to be tested in real business.

Actions, results and accumulated capabilities: bring AI into the work

In my early research, I kept thinking about the relationship between actions, results and what we retain from them. With AI now available, I think this can be made more concrete.

We need to look at an action together with the result it produces, whether that result serves its purpose, and which practices are worth keeping. Effective methods can gradually become formal arrangements, rules, work manuals and SOPs.

Capabilities that suit AI execution and can be reused can become AI Skills once they have been validated. When similar work comes up later, people can use those capabilities and check the inputs, process and results.

Co-builders can also participate using their own AI tools. Role manuals describe responsibilities and requirements, SOPs explain how to collaborate, and AI Skills support the parts of the work suited to AI. It also needs to be clear where human judgment, review and authorization are required.

I hope the capabilities we retain will help with the next action. People do the work with AI assistance, results are verified, and effective practices are fed back into the system. Over time, this can build capabilities the business can keep using.

Next, take one real piece of work through the whole process

This diagram reflects my current thinking about the practical mechanism. The detailed arrangements still need work, and practice should be allowed to change how I understand it now.

As a next step, we can choose one real piece of business with a clear scope and a deliverable, and connect the whole sequence: needs, roles, tasks, SOPs, acceptance, contributions and the handling of entitlements.

Record, one by one, where the handoffs do not work, which rules are unclear, which capabilities can be handled by AI and where people still need to make a judgment. Then update the manuals, processes and Skills.

What I most want people to see is how the work gets built up, step by step. The business keeps creating value, participants contribute and collaborate under clear rules, and real results help us keep improving the relationships and mechanisms.