A design partner should change the product

A design partner is useful only if the relationship can change what I build.

I kept returning to this while preparing for a conversation with a commercial insurance broker. I wanted to understand the firm's existing technology and the work that still moves through emails and documents. I also wanted to know whether there was a narrow workflow worth testing together.

I was thinking about how to turn the conversation into a design partnership. The phrasing sounded too transactional. A design partner relationship has to be an agreement about how two sides will learn from work that is still uncertain.

A title does not create access

An ordinary customer conversation can reveal that a problem exists. Building a reliable AI workflow requires more detail.

I need to see how a case moves when information is incomplete, who notices the missing item, and what happens after someone makes an exception. A process description from a senior leader can give me the structure. The difficult product decisions often appear in the cases that do not follow it.

A design partner can provide controlled access to that reality. This might mean anonymized examples or time with the people doing the work. A parallel run may also reveal where the proposed system behaves differently from the current process. The access has to respect confidentiality and the limits of the organization. It also has to be specific enough to expose where my assumptions fail.

Without that evidence, I may build a polished version of the workflow I imagined. The partner may receive a demo that looks relevant and still does not fit the work.

The pilot is a learning contract

A useful pilot should state what both sides are trying to learn.

For the insurance product I am exploring, the question may be whether AI can reduce coordination around one document heavy handoff while keeping human approval clear. The system could operate in shadow mode, prepare a proposed action, and let an authorized person decide whether it is correct. This is a possible pilot shape, not something the broker has agreed to run.

The scope matters because broad promises hide weak evidence. “Improve operations” is difficult to evaluate. A named workflow and one measurable outcome give the discussion somewhere to return. The result might be time saved or fewer repeated requests. The correct measure should come from the operator's problem rather than my preferred feature.

The learning contract also includes failure. I should explain what the system cannot access, where model output may be uncertain, and which action remains outside its permission. The partner should be able to report when the proposed workflow creates extra work. That feedback is part of the product, even when it is uncomfortable.

Existing systems belong in the experiment

The broker I was preparing to speak with already has internal technology. That changes the design partner question.

The opportunity may sit between systems, where emails, insurer follow ups, documents, and handoffs still require people to reconstruct the state of a case. A pilot should test that boundary without pretending the surrounding software can be replaced.

This is where a design partner can prevent architectural mistakes. They can show which system is authoritative, which integration is realistic, and which manual step exists for a reason. The product can then focus on a narrow transition where interpretation helps.

AI workflow development often looks like a model problem from the outside. Inside an organization, permissions and process ownership shape what can be built. A partner who opens that context contributes more than feedback on a screen.

Partnership needs a boundary too

Close access can pull a product toward one company's local process. A request may be urgent for that team and irrelevant elsewhere. Custom work can feel like progress because someone is waiting for it.

I need to separate the partner's evidence from the product conclusion. One case can disprove an assumption. It rarely proves a market. After each learning, I should ask which part is local and which part may generalize. The broader claim needs another test.

The partner deserves a boundary as well. They should know what I am exploring and what I can support. Everything else remains a hypothesis. Calling the relationship a partnership should not turn unfinished software into an implied promise.

This is why design partners matter to me beyond distribution. They create a place where product judgment can meet operational truth before the product becomes difficult to change.

I have not formed this partnership or proved the workflow. I am still preparing for the conversation. The standard I want to carry into it is clearer now: if both sides cannot name what they will learn and what evidence could change their view, the relationship is still only interest.