Co-Creation in Practice: Business Examples and When to Use It
Shusaku Yosa
Co-creation becomes easier to understand when you examine what participants contribute, what the organization decides, and how results return to the participants. Collecting many suggestions does not by itself show that value has been created together. Look for the connection between a customer’s problem, an idea or prototype, and a decision that changes the offering.
Read examples through participation and decisions
Break a case into four parts: how people join, what they can contribute, which decisions the organization makes, and how it explains the result. Customers may propose ideas or test prototypes while the company retains responsibility for budget, quality, and adoption. Participation does not automatically mean equal authority or joint ownership.
The scope can be narrow. Users might help improve a booking screen without deciding the service’s pricing. Explain those boundaries before asking for contributions so that participants know which parts of the problem are open to change.
Distinguish collecting opinions from developing value
Surveys and support messages are useful inputs. To describe a broader co-creation process, examine how those inputs influence proposals, testing, and learning. Make the path from contribution to decision visible rather than relying on the volume of responses.
Case | Participant contribution | Company decision | Feedback | Not guaranteed |
|---|---|---|---|---|
LEGO Ideas | Propose and support product ideas | Review and select eligible proposals | The program’s review process | Automatic production at 10,000 supporters |
MUJI IDEA PARK | Submit requests and reactions | Consider requests and decide responses | Status labels and related information | Adoption based on submission or popularity |
Fictional booking service | Describe problems and try prototypes | Budget, implementation scope, and adoption | Changes and reasons for rejection | Every suggestion being implemented |
This is a comparison of participation mechanisms, not a common contract for all three cases. Rights and detailed terms must be checked in each program separately. A well-known company’s participation scheme also does not prove that the same scheme will produce results for another business.
LEGO Ideas separates support from product selection
According to LEGO’s official help page, an idea reaching 10,000 supporters proceeds to review and may be selected to become a product. The threshold is a step in the process, not a promise of manufacturing. Keep support, review, and selection distinct when describing the example.
For your own program, specify both the condition for further consideration and the person responsible for the adoption decision. A voting mechanism needs a review process behind it. Do not imply that popularity automatically overrides feasibility or that contributors receive equal decision rights.
MUJI IDEA PARK illustrates consideration and progress updates
MUJI’s official FAQ about IDEA PARK explains consideration of requests, status labels, and related information. These mechanisms help participants understand what happens after they contribute. They do not guarantee that a submission, or a popular request, will become a product.
Read individual replies with their dates in mind. An old response is not enough to establish the current state of development. In your own process, distinguish received, under consideration, adopted, and declined. A status update and a useful explanation can prevent an open-ended expectation that every suggestion will eventually be delivered.
Check whether the problem is suitable
Question | Favorable condition | Preparation needed |
|---|---|---|
Is the problem concrete? | People can describe a real difficulty | Define the task and participants |
Can something change? | You can prototype and revise | State fixed constraints |
Who decides? | An owner has authority and resources | Agree decision criteria and budget |
What do participants gain? | Benefits fit the time and effort | Clarify expenses, payment, and withdrawal |
What can be shared? | Information and outputs are manageable | Agree confidentiality and usage rights |
How will results return? | Time exists for explanations | Assign a contact and feedback date |
Where legal or safety constraints leave little freedom, explain them before inviting broad ideas. Avoid offering apparent choice over a decision that is already fixed. The MVP concept helps frame a small test, while MVP design for a business hypothesis connects that test to a decision.
Define a fictional service-improvement exercise
Imagine users of a fictional booking service cannot find where to edit a reservation. Invite them to describe the difficulty and try two screen prototypes. State that wording and button placement can change, pricing is outside scope, and the service owner makes the final decision.
A useful record reads: problem—finding the edit action; contribution—task observations and prototype feedback; owner—service manager; response—explain selected changes and rejected suggestions after testing. Evaluate whether the same task becomes easier, not just how many comments arrive. If the issue involves first use, connect the exercise with the onboarding process.
Build a complete path from participant input to feasible change and an explained decision. Verified public examples provide useful questions to ask; your own problem, constraints, and responsibility determine the process you should run.