Product Planning Series: Requirements

[tweetmeme source=”chenelaine” only_single=”false” service=””]

This is the sixth post in my Product Planning Series.

The mere word “requirements” can make a lot of startup people wince. It conjures up the bad old days where folks spend months developing an MRD, PRD and a Functional Specification. It brings up images of Stage-Gate and classic Waterfall processes.

There are situations where big long planning documents make sense.   For example, if you are developing a medical device that needs to go through the 5(10)k process, you really have very little choice.  You have to go by the medical devices handbook which pretty much stipulates that you need to write all those documents and place them under a document control process.

However, in a startup situation, where you really don’t know if your problem, solution, and business model will jive with customers and users, overinvesting in planning documents just leads to lost time and productivity.  It also sends the wrong message to the team: instead of being open minded and work closely with customers to define the product and the business model, you are making up too much of it in the office. By the time the big MRD is written the world has already changed and the requirements could be obsolete.

I am against over-investing in requirements documents. However I am even more against not writing anything down and relying on tribal knowledge to implement a solution. That works if there are, like, 2 people in a startup. When you have more than 3 or 4 people working on the same thing, communications becomes very important. Working in a fast paced startup where new data comes in constantly is not an excuse to punt on basic common sense.  Good team communications practice begats good project execution, which will increase the probability that your product will do what you want it to do in the marketplace.  By the way, this goes for hardware AND software.  Even an agile process needs a holistic view of the end goal.

Here are some requirements do’s and don’ts in a startup setting.


  • Write SOMETHING down
  • Get buy-in from ALL STAKEHOLDERS.
  • Be practical and specific. Leave it loose at your own risk.
  • Build a top level project plan that identifies key tasks, milestones and interdependencies
  • Develop a lightweight 2 year roadmap
  • Start building anything without buy-in
  • Write a 100 Page MRD
  • Overspecify details on each feature in classic Waterfall fashion
  • Build a 5 year product roadmap with a great deal of detail
At the end of the day, for a development team to be productive, they really don’t need big long documents to describe everything. They just need a few slides on a few topics.  Here are the topics that I find useful to write down for the team. A lot of this stuff should be available for free, from the business case and who/what/why/when discussions.  Some of it is technical – like a lightweight description of the MVP.
  • Clear description of the market problem that is being solved
  • “Elevator pitch” of the solution (preferably with images)
  • Description / analysis of first target segment
  • Buyer and User Personas
  • Detailed storyboards on top 1-3 typical workflows
  • Specific examples for details encountered in each workflow
  • Considerations for human factors / human cognition
  • Top level design directions to be followed by product design team
  • Lightweight functional description of minimum viable product (MVP)
  • Quick and dirty 2 year product roadmap
  • Any external business drivers (e.g. trade shows, funding runway, etc.)
The most important thing is to do the thinking and research that will support the materials presented in these types of documents. The second most important thing is not to overthink things when you write them down.  Use the minimum possible number of pages to convey the information – don’t overinvest.  That way you will not feel too badly if customer development tells you something new and you have to trash some of these documents and write them over.

5 Responses to “Product Planning Series: Requirements”

  1. 1 davidwlocke August 18, 2011 at 3:17 am

    The bad old days of huge requirements docs were an indicator as is Agile of the market being addressed by those requirements. These two approaches where not about the past and the present as much as they were about technology (past)/early mainstream/growth vs. content (present)/late mainstream/decline/aftermarket/consumer. These very different spaces cannot be addressed by the same approaches.

    Another perspective is that even if you don’t write down the requirements (implicit), or hide the importation of requirements via APIs (implicit), the decision that we call requirements still got made. What is missing is the explication, not the existence of requirements.

  2. 2 Kitjer (@Kitjer) August 18, 2011 at 7:14 am

    A useful concept solution document is great in agile – contains key points, key value, benefits, core capabilities, end users, operators, high level experiences for both, target audiences over time.

  3. 3 Elaine Chen August 18, 2011 at 11:46 am

    @David: Agree that big requirements has its place – e.g. 5(10)k regulated medical products absolutely positively requires a big process, long docs and a stage gate process. That’s perfectly appropriate given the development cycles and regulatory approval cycles – just not cool for fast moving startups. On implicit v: explicit: making it explicit minimizes the game of “wrong rock” which kills productivity and squanders project funding so I’m a fan of explication.

    @kitjer: Touche. All those things need to be well understood by an agile team so nobody goes off on a tangent working on something that doesn’t make sense.

  4. 4 davidwlocke August 18, 2011 at 1:26 pm

    I’m not talking about documentation. Requirements are a class of decisions. Where you see a WHAT, you are seeing a requirement, regardless of its form. A user story defines a WHAT, so it is a requirement.

    In Agile, the same decisions get made. They get made in different places, but the same decisions get made. The same WHATs show up in aggregate.The understanding is gradual, eventual, and emergent in Agile, but Agile isn’t anymore agile, because the underlying system really doesn’t change all that much. The WHATs are eternal. The media, software, is transient.

    Requirements elicitation is rife with poor outcomes. I was shocked to find that it was driven by elicitor theory, rather than the meanings implicated and explicated from the functional cultures being encoded. Sad, but so. Agile doesn’t improve on this, because of the culture of the software world.

  1. 1 Product planning series: Planning a new web app « Startup Musings Trackback on August 9, 2011 at 6:42 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: