In the olden days, most people followed a waterfall method. It involved writing “complete” specifications on exactly what had to be built, how it would be built, how it would work, look, etc. You’d have the “complete” package of documentation up-front and then you’d start coding. Seems like eons ago…

Then we were introduced to agile development, which encouraged us to throw away big specifications and go with user stories, or to eliminate documentation entirely and just start coding, building things iteratively.

I’m greatly simplifying the evolution of software development into a couple paragraphs, but you know the drill — specifications went from being necessities to being outlawed. To draw a quick parallel, the same has happened (to a large extent) with business plans. They started out as big ass documents you’d write before doing anything practical / hands-on with your business. People then decided they weren’t necessary whatsoever. We’ve now found a middle ground (which is constantly shifting and evolving based on practice and results vs. whim) with things like the Lean Canvas, which provides us with a focused and simplified means of designing a business.

I’d say the same holds true for specifications. And I’ll admit it, I like them, and I haven’t gotten rid of them. But I’ve definitely changed how I write them.

I like to write. I find it’s a great way of recording structured and unstructured thought. Documents are useful for organizing and re-organizing thoughts as well. So I tend to start any new product requirement work with a specification. It’s not an ultra-lengthy and detailed description of how every feature will work or look, but a generalized description of the requirements (from the client’s perspective – which is more like user stories). These early specifications (call them “product briefs” or anything else you’d like) often include brainstorms and rough ideas too, as a way of capturing that information for later use or integration into the product.

My specifications often include descriptions of things we may (or will likely) build in the future. Not to overwhelm developers with detail, but to eliminate as much future risk as possible. When starting iteratively with something small, it’s often easy to forget (or ignore) stuff that’s going to come down the road, and so it’s not well-planned for. Inasmuch as I’m a fan of building small, iteratively, and releasing often, I don’t like the prospect of getting caught with my pants down later because we didn’t have even a bit of foresight. And occasionally these forward-looking notes become priorities sooner rather than later; having them described – even briefly – in the specification, helps move them into place and adjust development plans.

I don’t see specifications as ultra-descriptive product roadmaps. I see them as four things:

1. A high-level, but “all-encompassing” brain dump;
2. A customer-centric description of the value we’re trying to provide, describing the functionality to be built short-term (often including ideas, brainstorms, differing options);
3. A future-looking description of things to be considered, and potentially planned for; and,
4. A launchpad for discussion, debate, validation (or invalidation) with customers … a “working document.”

Specifications aren’t writ in stone. Quite the opposite. They include text, mockups, wireframes, diagrams, scribbled notes, etc. Throw it all into the mix and organize it in such a way that it makes sense for you and your team. As quick as we want to release, as iteratively as we want to develop, there’s still merit in planning before doing.