One deliverable

Traditional agencies and consulting firms make a lot of money by selling deliverables. Projects were planned to have multiple phases, each ending with a deliverable to be approved by the client. Clever agencies created “proprietary” deliverables that appeared unique and valuable, so that they could keep more people busy for longer.

Clients expect deliverables because they fit really nicely into the corporate budgeting process. They answer the question often asked by procurement and legal departments: what are we getting for this money? An answer of, “you will get personas, empathy maps, user journeys, user flows, wireframes, pixel-perfect mockups, and HTML/CSS files” is very satisfying. It sounds like a lot of work, and often, it is.

The problem is that these deliverables don’t provide the value to the client. They are preliminary. They are temporary artifacts meant to encapsulate research and thinking. At the end of the day, only one thing matters: ROI. Did we move the needle on a metric that matters to the business, whether it’s reducing costs, increasing revenue, improving the customer experience, or something else?

“Delivering wireframes” alone never did any of those. The only way to know if your software is any good is to actually launch it. The process of creating, socializing, and approving detailed wireframes simply postpones that moment of truth. And if the working software never gets delivered, what’s the point at all?

When we realized how wasteful many design deliverables turned out to be, we created a new mantra for ourselves and our clients: “one deliverable.” At the time, and for a couple years, this meant something specific to us: the one deliverable that mattered was shippable, working software. We adopted this value straight from the Agile Manifesto: “the only measure of progress is working software.”

Since, the concept of “one deliverable” has evolved, though its original spirit is intact. This is because even working software doesn’t necessarily satisfy a project’s objectives. If the wrong thing is being built and shipped, it may be a mere “vanity” measure of progress. Have you ever been proud to ship “working” software, only to have it deprioritized, defunded, or divested? Have you ever launched a product that simply didn’t produce enough revenue to cover its costs? It happens all the time. In fact, it happens most of the time. Over the years, we’ve launched dozens of websites, web applications, and mobile apps that ultimately did not succeed in the market. It’s easy to say, “we did our job and shipped working software.” But when you’ve invested hundreds of thousands of hours into this body of work, it’s hard not to care whether or not the things you create matter in the world.

As a software design firm, we have a pretty unique stance in our skepticism about software. Most of it is bad. Much of it shouldn’t be built in the first place. We don’t want to contribute to that waste. We want to solve real problems for real people. Design deliverables don’t solve problems. Often, working code doesn’t either.

That is why you will never see deliverable-based pricing in our contracts. While we often produce various design artifacts along the way, we keep our eyes set on the one deliverable that matters: a sustainable solution to the customer’s problem.