A deliverable is a proxy for a problem, and the 'proxies' are what orgs pay for, because a problem does not have a due date and a deliverable does.

The proxy gets chose early on and it gets chosen by everyone at once. Now a statement of work needs a noun, somebody has to write down what the client is buying, and a 'resolved problem' is not a line item anyone can sign. So the conversation moves, usually within the first meeting, from what is wrong to what we will make for what is wrong, and the thing we will make actually focuses on what the engagement is about. Blueprints, audits, roadmaps, redesigns, research outputs, etc. The noun gets a set date, a team, a price and a cycle for reviews and approval. From there the engagement snow managed against that noun.

Nobody is being dishonest in this. The sponsor wants something they can point at when their boss asks what the money actually bought. The consultant wants a scope that can be finished, because open-ended scopes are how projects lose money and sometimes people. Everyone's reasons are defensible, and the sum of those defensible reasons is a project where the artifact is the point and the problem becomes the context.

I wrote back in Vol 22 about why being right is not enough, and the mechanism there was ownership. A conclusion delivered from outside arrives without the process that would make anyone act on it. The deliverable problem is the same mechanism one layer up. The artifact does not only arrive without ownership. It arrives as the thing that was owned, which means receiving it settles the account. The client got what they paid for. What would they act on now and why? The distinction that I think took me longest to see is that 'done' is not a state the work actually reaches. It is the decision somebody makes, and who gets to make that matters more than the often what is made.

On most engagements, done is declared the person receiving the artifact (noun), based on whether it matches what was described. That is a reasonable test for a deliverable and a useless one for a problem. For example, a blueprint can be complete, accurate, well presented and entirely unconnected to any decisions anyone is prepared to make. It passes the review because the review was designed to evaluate that artifact. Solved has a different owner often. It is declared, by whoever lives with the problem. Often these two declarations are made by two different people at different times.

This is where in-house designers should stop feeling superior to consultants (if they do), because product work has the same shape. The feature shipped, or metric reported, perhaps the quarter was closed. Same shape, different nouns/labels. Whether the thing the feature was supposed to fix got fixed belongs to nobody in particular once the launch happens. So negotiate what 'solved' looks like before you negotiate what done looks like, and document that somehow. If the client cannot describe solved, you have uncovered even more of what your job is now, to provide that clarity. What I do differently now is less about the work and more about the conversations around the work, sometimes uncomfortable or full of unknowns and ambiguity but it provides value.

I tie the artifact to a decision as often as I can. Not 'we will deliver _____' but 'we deliver _____so that ____ can do _____.' this isn't new or profound but it's something I think is often overlooked by many (not just designers). I try to ask whether that person or owner knows they are the owner of this. We assume they feel that empowerment but being clear about it is important and you'd be surprised how often they give an unexpected response. All of this to say, none of this guarantees the problem actually gets solved. It makes the gap between done and solved a bit more visible though, which at the end of the day no matter if you are a consultant or in-house that's all you can ask for.

At the end of it all, we are each learning and evolving in our practice. Take those learnings and utilize them, grow from them, and find ways to make sure that gap between a final deliverable and a solved problem continues to shrink.