• Startup & Investor Resources
  • Recent Posts
  • Search
  • Contact Me

Instigator Blog

Lean Analytics, startups, angel investing, product management and more!

The Specification is Dead; Long Live the Specification

November 14, 2011 by Ben Yoskovitz

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.

Filed Under: Product Management

Want more content like this?

Signup for free and you'll get new content as soon as it's available. Thanks!

Ben Yoskovitz

Founding Partner at Highline Beta, a hybrid venture studio and VC firm that works with large, ambitious companies to identify new areas of opportunity through internal and external innovation.

Previously I was VP Product at VarageSale and GoInstant (acq. $CRM), and Founding Partner at Year One Labs.

Angel investments include: Breather, Spoiler Alert, SendWithUs and others.

My bio »

Buy Lean Analytics

Lean Analytics

"Lean Analytics is the missing piece of Lean Startup!" - Dan Martell, founder Clarity

Get the book at leananalyticsbook.com

Get updates

I've moved to Focused Chaos a newsletter focused on startups, investing and more. Please visit there to subscribe and get weekly content.

  • Startup & Investor Resources
  • Recent Posts
  • Search
  • Contact Me
Views expressed here are mine and mine alone.

Copyright © 2023 · Built on the Genesis Framework