Product Planning Series: Requirements

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.

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

davidwlocke

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.

Elaine Chen

@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.

davidwlocke

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.