Commission models around the work you know
A business can originate the capability it wants, refine how it behaves, and put it to work. Technical production can become a service it buys.
A bicycle workshop knows which questions turn a vague enquiry into a useful appointment. What bike is it? When did the problem begin? Does the customer need a puncture repair, an inspection or a specialist the shop cannot provide?
The owner also knows which promises should remain with staff. A request for tomorrow morning is a preference; it becomes a booking when somebody confirms the workshop’s capacity. That distinction is part of how the business works.
There is useful material for a model here before anybody has named a model architecture. The starting point is knowledge of the service, its customers and the decisions worth making.
Let the business originate the project
Consider Fieldwork, the fictional bicycle workshop we use in our application example. Its site describes routine repairs, mechanical work on e-bikes, specialist referrals and the details staff need before assessing a job.
A project can begin with that website and a short description of the work. SYSTEM1 examines the supplied context and proposes capabilities to develop. An intake tool is one direction: identify the kind of enquiry, ask for missing information and route it to the appropriate next step.
Watch the actual project flow: supplied business context, an edited suggestion, a validated prototype tool and a published widget answering an e-bike puncture enquiry. The film spans testing and refinement; its final request runs at the recorded speed. This prototype uses an existing model, with the workshop policy expressed in the task and tooling.
The owner’s useful contribution might be a correction: “Always leave turnaround confirmation to us.” That changes the tool’s behavior and the examples against which it should be tested. The resulting capability belongs in a customer-facing widget, an internal desk interface or an existing application, depending on where the business needs it.
This is the product we are building: a streamlined way to develop models and the tools that make them usable. A business can begin with its operation and refine a proposed result. It does not need to organize every technical stage of model production before finding out what might be worth creating.
Let an example reveal a better requirement
The first idea will rarely contain every useful distinction. Suppose an early intake example treats all e-bike enquiries as specialist work. The owner notices that the shop repairs their tyres, brakes and other mechanical parts; electrical faults require referral. A concrete example makes the missing distinction easy to express.
Another example asks for an exact price before a mechanic has inspected an unfamiliar fault. The owner can define what the tool may explain and what requires an assessment. Each correction turns operational knowledge into behavior the project can develop and test.
Eric von Hippel’s User Toolkits for Innovation examines why design can benefit from remaining close to the person who knows the use setting. Important details may be expensive to transfer completely, and some needs become clearer only through trying a design. His toolkit criteria include complete trial-and-error cycles and working in a language the user already understands.
That suggests a demanding product standard. Giving the owner a place to type instructions is one part of the interaction. The system also needs to produce something they can inspect, exercise and correct. Their correction must survive into the developed model and executable tool. “We do mechanical e-bike work” should become a tested distinction, rather than remain an incidental line in a conversation.
The distance from a technology company can vary
- A software company may want an API inside a product it already operates. Its team can specify state, examine contracts and compose decisions with other services.
- A workshop may want a small interface on its website. It needs to ask the right questions, return a usable next step and remain understandable when the service changes. The owner may never inspect a request schema.
- A larger service business may have an operations team and existing systems, with no dedicated model-development team. It may want a decision capability inside scheduling, with staff handling the cases that need further judgment.
These are different routes into the same kind of purchase. The business commissions a capability shaped around its work. SYSTEM1 supplies model-and-tool development; the resulting interface meets the business where it will be used.
A capability can make a new service possible
The opportunity extends beyond recurring questions in an existing workflow.
Imagine a learning business that lets a group request a workshop before it appears in the catalog. A group wants to deliver short talks, receive individual feedback and try an opening again. An instructor proposes one evening of demonstrations and discussion. Another proposes two meetings, with time to revise between attempts.
A useful comparison could ask whether each proposal provides the activity the group requested. Topic words alone would be insufficient. A proposal that includes individual feedback but leaves the second attempt unclear should produce a question the group can resolve with the instructor.
group proposes an activity
↓
instructors propose ways to provide it
↓
model compares each offer with the request
↓
group and instructor clarify the arrangement
↓
an agreed session becomes bookable
This is a proposed service. Its value is the activity people can arrange through it. The group originates something it wants; the instructor can reshape the offer using professional judgment; the business supplies the process through which they reach agreement.
The next group might bring photographs for critique or a scene to rehearse. A developed comparison task could accept those new requests as inputs within its evaluated scope. The company would keep operating the capability across many encounters. New customer input does not automatically require producing another model.
Develop a continuing capability
Once a model becomes part of a business’s service, its relationship with the tooling matters. A changed outcome may require a different next question. A revised policy may invalidate an old example. A new interface may expose a case that the earlier workflow never encountered.
The project therefore needs to preserve the task, examples, model version and executable behavior together. Staff should be able to show the case that failed, refine the intended behavior and evaluate the change before relying on it. A technology team may work directly with the API and source history; an ordinary business may work through examples and its deployed interface.
We are building a company to make model creation and operation an ordinary business purchase. SYSTEM1 begins with decision models and the tools around them. The bicycle workshop and the proposed learning service illustrate two reasons to want that purchase: make existing know-how usable in software, or create a service that becomes practical once the necessary judgment can be developed and run.
The business supplies more than requirements. It supplies a view of the work that is worth doing—and can discover a different possibility by trying what that view makes buildable.