Archive for August, 2011

Product Planning Series: Requirements

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]

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.

DO

  • 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
DON’T
  • 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.


%d bloggers like this: