As far as I can tell, Steve Johnson is on record largely agreeing with my view. See his article, Reqs and Specs, for details.

He distinguishes between requirements and specifications, and then enumerates the following roles:

– the product manager finds and quantifies market problems, articulating them in the form of requirements
– the product architect (or designer) writes a functional specification describing the approach to solving the problem
– the product developer creates a technical specification that fully describes how the functional specification will be implemented

As you can see, Johnson mentions three types of documents, but he considers only one of them a requirements document.

Sounds like you have a sweet gig! Great points about how to stay focused in a startup environment too.

I agree that the CYA mindset does happen a lot at large companies. I think we’re really on the same page, and that the product manager should focus on, well, all the strategic stuff Pragmatic outlines.

Different team sizes will split up the work differently (vision vs spec vs design vs implementation).

There is a key factor that we may not be hitting on here too — the number of products involved and the tech stakeholder involvement. Really quick point here is, if you have 1 product (typical start-up), EVERYONE in the company wants to own it and feel like they are helping it get better. That means, and this is something I push, everyone must wear the Product Mgmt hat at some point. If you have multiple products, it’s easier because folks are more spread out in terms of where their interests lie. It’s much easier when there is more than 1 to foster a product-centric environment. But, I digress.

You are right in that, typically, product vision is driven from the top – especially in a startup. CEO / CTO / VC (let’s not forget them) comes up with an idea, and delegates responsibility for creating the thing and the PM must point out flaws along the way. Also, she must take initiative for actually getting the thing built. If you are not pointing out ways the idea can be made better, or if that’s not fostered, there are bigger issues. A person’s title must be forgotten to unabashedly create excellent products. You should all be on the same team – the customers.

That being said, I’ve created 1 template in the past that I’ve found to work well — an FRD (Feature Requirements Document) template. I define a feature as being a container for requirements, whether functional and non-functional. They can all be wrapped into one doc, and can be clearly pointed defined. Here’s the structure I have in the template:

- Introduction / Overview
- Feature vision
- Requirement Themes
- Actors
- Functional Requirements
- Non-Functional Requirements

Prior to this, I would generate a simple vision doc that would outline at a 50,000 foot view what the hell my FRD doc was talking about. This would get the point across to everyone that it needed to, then the content would be rolled into the FRD, and the Vision doc would be effectively destroyed. We are now just down to 1 doc defining everything about a feature / module / whatever. It’s not a matter of the # of docs, because in theory, you would have more than a single FRD (and it works more effectively if you do) if you were defining an entire product from scratch. This allows you to divvy up FRD’s between developers more easily and not suck out time by having valuable tech resources reading about the “vision” for something they aren’t working on. So long as they get the bigger picture of the product as a whole (and that’s much important), dev should be golden working this way.

Now, that was for the company with 85 people, in which product development was dominated with feature requests made by clients VIA Services, and the product roadmap had to fit what clients were paying for. It was a high-quality revenue stream. Right or wrong — that’s how it worked.

In the company of 14, we don’t support queue jumping / roadmap hogging as a revenue stream, so it is all proactive. It’s bliss, let me tell you. More time to spend on the market as a whole instead of those that yell the loudest. My comment about me drowning if I had to write out all those docs revolves around two absolute truths:

1 – They would take me at least 3-4+ weeks to generate
2 – I can get the point / req’s across in a bulleted list in 1-2 days for a complete product with over 100 features of all sizes (tiny to full-scale / platform entwined beasts)

My logic is, each feature I recommend, I better make damn sure I have a justification for doing so, because my VC, CEO, and CTO are going to have my hide if I don’t. They all understand I work for the customer at the end of the day, and for me, that’s just not a fed line; I really do operate & feel that way. As an aside, I’m always of the mind that opinion matters for absolute 0 in making product decisions. Unless it’s a) good for the customer and b) you can prove it’s good for the customer, it’s useless and should be shelved.

Now, if I were to take 3-4 weeks to generate documents that I could completely NULL and void if I were to call up the CEO and say, “hey — here’s my bulleted requirements list, let me tell you why I want to do features 5-10, all the others should be obvious,” that saves everyone in the company time, and thus saves overhead, and thus saves money. And that’s the name of the game for me…I just don’t see how it’s not the name of the game in all companies. There’s nothing touch feely here — just get ‘er done (JGET).

I think more often than not, and I’ve gotten this from talking to some of my best friends that work in large Org’s, must of this “communication” stems from everyone trying to cover their ass and not want to make mistakes. While massive companies can claim all they want that they foster “teamwork” and environments where their folks are allowed to falter, I just don’t think it’s true. It’s built into the culture that if you make a major mistake, your kicked to the curb and the guy waiting in line for your job takes over.

So, my thinking is, this stuff is much broader than a PM generating *RD/*RS documents. I lean towards thinking they exist because if they didn’t, it would mean people really have to trust their team and peers and directs. From what I understand, it’s not your manager doing your performance review each year deciding how much food you’ll be able to put on the table. If you work for Scary Monolithic Corp, Inc. it’s some HR associate that you’ve never met before and their MO is “save the bottom line.” Yikes.

Make mistakes. Big companies have money — fight for it to actually go and talk to the product team face to face. Buy Webcams and use Skype to talk regularly. I feel that people are generally smart and *want* to get it; they want to buy in to the vision and do a good job. Work to foster the environment with dev where questions are the norm and no one is called out for asking one that’s stupid — Jack Welch taught me that there is no such thing. That’s the msg I give to my team.

I think at the end of the day, relationships would be better, a team would be stronger, and a PM’s time wouldn’t be sucked up generating paperwork. There’s no reason why all of the *key* elements of these things can’t be combined into 1 document and then discussed. The truth of the matter is, a developer is only reading & caring about 1 thing – how can they make the requirement work elegantly, and be creative at the same time. Requirements aren’t about solutions — that’s spec, and that should be coming from a tech lead anyway, not a product manager. And yes, I could see how a spec doc would be 1,000 pages, especially when you are dealing with a system responsible for billions of dollars for example.

Anyway, talk about rambling! I’m sure I’m overlooking the need to communicate high amounts of detail. Maybe I’m just spoiled in that my CTO and I are really on the same page and we get what the other is trying to accomplish.

I’m really enjoying this discussion and hope that we can agree on some points — at least between the three of us. Hey, maybe Steve Johnson is reading and will work it into Pragmatic… =)

We’ll keep the conversation going on this one – maybe some other folks will chime in as well.

Scott

A few things:

1. I should not have implied that you favor producing every document (MRD, PRD, FRS, SRS). My real point is that I don’t think it’s possible to reconcile all of the terminology (“market requirement”, “product requirement”, “functional requirement”, “nonfunctional requirement”, “software requirement”) associated with these documents. I’m even struggling to understand how you reconcile PRD terminology with SRS terminology (see #2).

2. As I see it, one of your examples of a product requirement, “The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline,” is a combination of a functional requirement (“The system shall recommend purchase amounts and timing.”) and a nonfunctional requirement (“Spoilage stemming from the system’s purchase recommendations shall not exceed 50% of the baseline amount.”). How do you reconcile this example with your contention that product requirements “are neither functional nor non-functional”? (I posed this question in a comment on your “Valuable and Functional Requirements” entry.)

3. I certainly do not deny that people use the word “requirement” and related terms in many different ways. Indeed – the diverse usages of the terms are central to my point. I contend that these diverse usages are irreconcilable, and further that their incoherence and inconsistency is destructive.

4. When linguists face this sort of problem, they explicate the terms. I.e., they account for all the usages, point out the inconsistencies and inefficiencies, and extract the essence of the terms to clarify their meanings.

5. It’s a bit like math students who say that two angles are “equal”. We know what they mean, but we also know that this terminology is in some sense “wrong”. The measures of the angles are equal; the angles themselves are congruent. In the case of geometry, this terminological confusion is rather innocuous. Unfortunately, in the case of requirements terminology, the usage is so skewed and inconsistent that it reflects, and contributes to, a requirements crisis.

6. I have no issue with two levels of documents, at least in theory. I just don’t see how you can reconcile the terminology. The PRD/SRS distinction is much more linguistically coherent if you call the SRS an FDS (functional design specification) or an IDS (interaction design specification). Such a naming scheme would, in my opinion, lead to greater awareness of the goals that should drive the product and more attention to the nonfunctional requirements that never seem to get their due.