When one business finds a good way to handle a recurring problem, it is tempting to carry the whole answer into the next venture. The screen, checklist or workflow already exists, so copying it feels efficient.
The useful part may be the experience behind that answer, rather than the answer itself. A different audience, setting or responsibility can turn a proven solution into a poor fit.
MightyGroupUK’s current portfolio gives two clear examples of how to share experience across different businesses. Vending-round experience helped shape VendMetrix, while the group’s digital capability supports work such as Chaperone Collective. In each case, the new venture has its own users, language and boundaries. This method helps separate what can travel from what needs to be worked out again.
Start with the problem that was actually observed
Begin with the work as it happened, before the solution was built. Record the repeated task, the decision somebody had to make, the information they needed and what made the job awkward.
The MightyGroupUK story explains how the cash-up, route, receipt and record-keeping work of a real vending round became the basis for VendMetrix. The useful lesson is wider than vending software. Direct operating experience can expose small, repeated problems that are easy to miss from a meeting room.
Write the observation in plain language. For example: “The person doing this job has to collect information from several places before they can finish the record.” That statement can be tested in another setting. A copy of the original dashboard cannot.
Separate the evidence from the old solution
Put the evidence and the existing answer in different columns. This small step stops them becoming tangled.
- Evidence includes repeated questions, delays, corrections, missing records and decisions that depend on information arriving at the right time.
- The old solution includes the exact form, software screen, equipment, terminology and sequence used by the first business.
The evidence may point to a similar underlying need elsewhere. The old solution is only one response to it. Keep it as a reference, but do not treat it as the specification.
This distinction also makes weak comparisons easier to spot. Two businesses may both use bookings, routes or member profiles, yet have very different reasons for doing so. A shared label does not prove that the same process belongs in both places.
Learn the new context before choosing an answer
The GOV.UK Service Manual advises teams to understand the full context of what users are trying to achieve, focus on the problem rather than a particular solution and test assumptions early. That guidance is written for public services, but the discipline is useful for smaller business projects too.
Use a few direct questions:
- Who does this work now, and what are they trying to finish?
- Where does the information come from?
- What does a correct outcome look like in this setting?
- Which decisions need specialist knowledge or human judgement?
- What would show that the borrowed idea does not fit?
The last question matters. A test designed only to confirm the original idea is likely to miss the awkward facts that should change it.
Keep specialist knowledge with the people who hold it
Shared digital capability can organise information, communication and routine steps, but working technology is not proof of specialist authority.
MightyDigitalStudioUK’s current work page describes its website design, build and digital-platform presentation for Chaperone Collective. The Chaperone Collective site separately sets out the community’s specialist purpose and its boundaries. It says peer support and signposting do not replace local authority guidance, employer policies, safeguarding procedures, education requirements or legal advice.
Digital work can support a specialist setting without displacing the people and official routes responsible for it. In a less sensitive project, the boundary may concern pricing approval, financial checks or customer support. The principle is the same: name the responsibility instead of hiding it inside the tool.
Test one useful part, not the whole borrowed system
A small test gives the new context a chance to disagree. It might be a paper checklist, a rough form, a clickable prototype or a manual run-through using one real example. It does not have to become permanent.
Choose one part of the job and decide what you need to learn. Watch where the user pauses, what they have to look up and which exception breaks the neat route. Ask what they would do if the test did not exist.
Then adjust the idea before adding more features. A short test that changes the plan has done useful work. A polished prototype that only demonstrates the original assumption has not.
Keep a short record of the adaptation
When the idea moves forward, record why. A one-page note is usually enough:
- the original experience or observation;
- the problem found in the new setting;
- what appears transferable;
- what had to change and why;
- the evidence from the test;
- the owner and next review point.
This gives later decisions some context. It also stops the familiar but unhelpful explanation that something was included because another business already had it.
Share standards more freely than templates
The four current MightyGroupUK brands have distinct audiences and specialist jobs. Their connection is practical experience and a set of shared working standards, not one copied operating model.
Clear language, honest status labels, maintainable processes and evidence from real work can travel widely. Screens, forms and service promises need a fresh check each time.
Before reusing a solution, strip it back to the lesson that produced it. Carry that lesson into the new setting, test it with the people doing the work and let their requirements shape the answer.