---

Creating a Minimum Viable Specification

(courtesy of KEYJ)

If you’ve never read about the Abilene Paradox, go read about it. (Or if you have a bit more time, read the original article.)

In the Abilene Paradox, individual participants don’t speak up about what they want in a group decision, and the result is an outcome no one really wanted. The process of making that decision results in missed expectations and projects that are a disappointment.

When building projects and features, it’s hard to make important decisions because two team members (or teams) don’t have clear expectations for the results the team will see when the feature is done. Taking a small amount of time to declare “this is what we’re building, these are our assumptions, and this is what we’re going to do next” generates positive feelings and goodwill for any project.

“Just Build It And Figure Out How Later”

There are many screamingly obvious things that cause projects to fail, and yet people (us included) make the exact same mistakes over and over.

Once you think you’ve got your arms around an idea, it’s tempting to get going immediately. Pausing might be a good choice, too. By building before thinking about the results other teams expect from your project, you may end up with these outcomes:

• Delivering a project late or way over budget
• Playing “Whack-a-mole” with bugs on different clients and platforms
• The Angry Faces of Business Stakeholders when they realize the thing they got doesn’t do the thing they were going to get
• Confusion and apathy by customers who your team feels “just don’t get it”
• Hand wringing and confusion by internal staff who have no idea how to explain the new thing and what it does

All of this results in wasted effort, caused by

• poor expectation setting leading to low engagement and commitment
• weak requirements, because no one set expectations for the group
• results that don’t follow expectations
• and a general lack of transparency

In short, we could do better.

What is the Big Goal?

We all want to build great products and services — full stop — and we sometimes get there. With the right tools and process, people collaborate remotely, locally, synchronously and asynchronously to build software products and services that deliver the almost-magical product-market fit. We dream about creating The Next Big Thing.

An anti-pattern often occurs when teams set out to build The Next Big Thing (or even the next small thing). People fail to deliver a product, feature, or idea because they didn’t build a specification to organize the team using a shared understanding to think about, design, and build that thing.

Failing to write a specification is not new.

I’ve talked to friends at other companies about their “black sheep projects”. I’ve thought a lot about the projects I’ve managed that could have gone better. These failed projects have a common thread: a specification that is too complicated, has multiple owners, or just isn’t done.

When you talk to the individual leaders of teams about these projects, whether directly to engineering, to operations, or leadership, you hear similar things:

• We weren’t involved in the specification
• The delivered product was different than what we thought
• It’s someone else’s job to fix this.

And you don’t usually hear about the solutions those teams worked on together to deliver a different result.

The best teams trust their individual contributors and their managers to do the jobs they are excellent at getting done. The best teams have mechanisms for “raising your hand” when unexpected results occur. And the best teams treat conflict as an expected outcome and have mechanisms in place for expecting and resolving that conflict.

Fixing with The Smallest Change Possible

To help us better reach The Big Goal in any project, what if there were a Minimum Viable Specification?

What would be in it? Who would write it? And how would you measure that it was any better than the failed processes and decisions we make today?

This suggestion is not a “one-size-fits-all” solution — it is a proposal for the minimum necessary to bring engineering and business teams together to solve problems — and projects may need more or less than what’s described here.

What is a Minimum Viable Specification?

1. The clearest path to what you need to do to get to done.
2. Small enough to declare a single problem and solution in about 15 minutes, but not smaller.
3. Big enough to avoid writing a specification for every idea.
4. A name we all use to describe the idea.
5. A description of the problem statement, the assumptions we’re making, and why we are doing this thing.
6. A statement of the outputs we expect from this specification.
7. The way we will measure how things are going and how often.
8. How we propose to expend time, cost, and effort to do it and consequently, when we think it will be done.
9. A place we are able to discuss how things are going.
10. A Parking Lot for the ideas we generate that don’t matter right now.

An Example Template

I’ve been using this example to validate the idea of a Minimum Viable Spec. It’s a living document, so the more iterations it completes, the better it will get.

Here are some items I felt were important to add:

• the what — simply put, what are we building?
• the why — what’s the business reason for doing this thing?
• shared understanding — when we are done, what are the outcomes we expect?
• the who and the how — which resources will do this, and how will they get it done?
• planning — when we have an oh sh@$#% moment, what will we do?

An example — your mileage may vary

Get An Example Template Here.

You can build one of these templates too! If it’s not confidential and you’d like to share, please add it to the templates folder for the project on Github.

Enough Description to Fit the Back of a Napkin

This project will be a failure if it creates the very situation it is trying to resolve. We’ve all seen what happens with projects that attempt to describe every eventuality. They never get done.

How much description do you need? If the idea is very small — the addition of a field to an API — you might be able to summarize it in a single sentence. You should also be able to use a Minimum Viable Specification for a larger project, though this initial idea targets features that typically take 4–20 hours of developer time.

And what would success look like for a Minimum Viable Specification? If people use this type of approach to create simple and valuable statements about the products they are building, it will be easier for business and engineering teams to work together and see whether or not we’re making progress. We iterate on this process one spec at a time.

How do I get started?

If you’re interested in helping, please consider doing one of the following things:

• Contribute to the project at https://github.com/gregmeyer/minimum-viable-specification — suggest changes to the example template, or create your own template
• If you don’t have a GitHub account and want a Google Docs version, see here.