There is quite the post over at Tyner Blain about requirements. While I don’t discount the usefulness of this type of information, I’d drown if I had to write something like this. MRD, PRD, SRS, FRS — acronyms galore. Now, don’t get me wrong; I’ve learned a ton from the Tyner site, and it’s run by some super-smart (read: way smarter and more experience than me) product manager’s. This is just an observational post about how the start-up environment I’m in is so much different.
I’ve get e-mails by some folks that are just starting out in Product Management regularly, and a lot of them ask the same questions: how do I start writing an MRD? How do I move that into a PRD? How do I position this to management / board? And of course, there’s the mistake of blurring requirements with specifications, and trying to insert non-function req’s with functional req’s, and on, and on.
I’m a start-up kid. I love them, and will probably work in start-ups for the rest of my career. I’ve never worked for a large company, so I can only imagine that the level of detail that the Tyner post goes into is required in that type of an environment. But, man…it’s gotta be simpler than that. My eyes glaze over just thinking about writing all this out.
Now, the fact that I’ve been blessed working for incredibly smart CTO’s / founders, and being able to comfortably talk about stuff to the CEO’s and VP’s of each company I’ve worked for. I do admit — it is an advantage. But, at the end of the day, taking all the time to do this work is just not in the cards for a 20-30 person company. If it is, something probably needs to be streamlined.
To me, requirements are simple. UI is pretty simple too, especially if you have someone that can actually design UI’s and people working on the product that are sensitive to usability and user experience, as all product manager’s should be. I try to spend extra time (and even in my own time) reading about these topics. I’ll never be an expert, but knowing some of the fundamentals makes it easy to have really great conversations that end-up creating solid experiences with a product.
I can only speak from my own experience. However, writing out feature bullets while having market data close at hand (spreadsheet, napkins, whatever) to justify prioritization by version (and thus by quarter), and grouping features logically is the best way to go. No one can argue that opinion trumps data. It doesn’t.
If you have a super-smart and super-motivated team of people working on the code and making a product come to life, they are probably going to be stifled, and quite frankly think you’re a jackass, if you spend 1-2 months cranking out requirements. Especially when the product is going to change in quite a few ways during development. That’s inevitable. Or at least, it should be. I’m not talking about scope creep / feature creep, but what I am talking about is being flexible and disciplined enough to allow cool stuff to take place (within the span of the product vision and objectives) that isn’t going to hinder schedule, but just enhances the product that much more. Those types of things can’t be stopped just because they weren’t written that way as a requirement.
There are trade-off’s to doing it this way. For example, it is a challenge to keep everyone on the same page due to the lack of detail. I try to look past that, and talk about the flexibility and the sensical part to doing it more freely.
This type of approach fits in with a non-typical release cycle that I’m encountering as well. This post is long enough however, and I’m not sure if it even makes any sense, so I’ll loop back and explain Aggregated Releasing (might be a crappy name for it) another time.
{ 2 comments… read them below or add one }
Hey Adam,
Thanks for the link and for the great insights. And trust me when I say I share your concerns about the complexity and acronymity of the big company software development process. I think the situation has evolved as a result of mixing the bureaucracy of big companies with the need to delegate responsibility.
I’m currently working on a project for a client where each document has over a dozen people who have to approve it (enterprise software migration project from a legacy system to a new solution). There are as many people, just on this team, as there are in a start-up.
Requirements documents are all about communication. There’s a vision that someone sets for a product or project. When that person has direct, regular communication with the team that makes this product a reality, then the documentation approach will be very different than when a distributed team of fifty people are all three steps removed from the person with the vision.
Another factor is specialization. When a person has the opportunity to play multiple roles, she don’t need an artifact for communicating with herself. And the distinction between a product requirement, a software specification, and a high level design is academic. Her thought process should be focused on “is this a good idea?” not “am I putting design details into the specification?”
Structured requirements frameworks are sort of a “command and control” approach to creating products. Think of it as a military analogy – headquarters sends down the objective (secure France), the field commanders put together a battle plan (secure Paris, etc). Each squad leader has an area of responsibility and (ideally) knows how his squad’s contribution (secure that bridge) supports the whole. This approach is not designed to be nimble (which is a problem), but it can be adapted to improve flexibility and responsiveness.
Another factor is frequency of change. The squad leaders have to adapt to changing circumstances (blow up that bridge and secure the hill) most frequently. They also have to adapt to changes in tactics (forget Paris, Normandy is the key). Rarely does the objective change (forget the French, let’s protect Australia instead).
The layers of requirements documents exist to help people operate within a well-understood scope. The squad leader can decide to blow up the bridge based on what he knows. But he better not abandon Paris unless someone looking at the bigger picture tells him to do so – he doesn’t have the context to make that decision.
A smaller, better, more tightly knit team can communicate those changes (think special forces, to extend the military analogy) effectively without the overhead. The objective is communicated directly to the squad leader. And the people on the team have the generalist skills and perspective to adapt without guidance. Essentially, they make “battlefield commander decisions” in a narrow scope.
A start-up needs to have people who can make these decisions, prioritize and adapt. People who’s roles are not narrowly defined. In your example of going from cocktail napkin to feature bullets, you’re doing exactly this. And I think you should.
Interaction design is a great approach for creating products with start-up teams. Note, teams within a big company can operate like a start-up, but most do not. These start-up teams are implicitly making prioritization and marketing decisions when they develop designs for the solution. And with the right people on the team, they will be good decisions. Alan Cooper takes a craftsmanship-centric approach when describing how these decisions should be made: provide what people need, the way they need it. This approach requires a good understanding of the users. If you don’t already have it, you have to go get it before you can get started.
I believe the “ideal process” (a bit of a holy grail) would include the user-centricity of user centered design. It would also drive people with the “just do _something_ now, improve it later” approach of agile processes, and the explicit adaptation to change. It would also incorporate a mechanism for defining the vision, strategy, and approach for a product that borrows from the structured requirements frameworks that folks like Karl Wiegers promote. This would allow teams to be effective on a larger scale, with more specialists in the mix.
Every project will benefit from having a vision that is written down. A presentation or email from the founder, or an MRD can serve this purpose. When the members of the team have the skills and a sufficiently narrow scope to operate with just this (explicit) input, they should. When they don’t, an SRS can serve to separate “what” from “how” and allow the experts to focus on one or the other. It’s just a different way of splitting up the work (horizontal versus vertical).
A UI designer who can balance competitive inputs, user goals, and prioritized functionality with dependency on implementation approaches can operate vertically. An engineer who can imagine the benefits of, alternatives to, and ways to interact with a potent technology/algorithm/heuristic can operate vertically. A product manager who can invent the UI and architectural designs that will achieve her product vision can operate vertically. All of these people together – vertical collaboration. Ideal people to have on a project team that is allowed to operate like a start-up.
For every person who can operate vertically, there are (swag warning) a hundred who can’t, but who can operate horizontally. I know people who, while good at one level, have made statements like “I’d rather be a garbage-man than design a UI” and “I don’t care how it works, just make it work.” Would I want these people to operate vertically? Hell no. If they were on my team, could I find a way to help them contribute? Absolutely. That’s where the process starts creeping in.
The process, I believe, has evolved to protect companies from specialists making decisions that they can’t or don’t want to make. Whenever I see software with a crappy user interface, I wonder if it was designed by my garbage-man.
Some companies only know how to work with specialists. They are dependent on process, and team members operate horizontally. Is it less fun? Certainly would be for me, and sounds like it would be for you.
Hopefully the stuff I’ve been writing about the “heavy” requirements processes will help those hundreds of non-start-up teams be more effective. And ideally, the vertical players will get ideas that help them stretch even further up and down the chain. Guess this is a long-winded, rambling comment, but hey – you started it.
Thanks again for the great thoughts, and for reading at Tyner Blain!
Adam, despite the “rambling”, I enjoyed reading both your post and Scott’s comment.
I have been struggling to understand Scott’s requirements framework. My suspicion has always been that the MRD/PRD/FRS/SRS onslaught of documents:
1. Is harmful to organizations (startup or not) that produce them all.
2. Employs terminology (“requirement”, “functional”) in a logically inconsistent or highly inelegant fashion.
3. Reflects a substantive misunderstanding of requirements.
In short, I do not believe, as Scott states, that the distinctions are “academic”, even for a “vertical operator”.
To give a concrete example, I recently wrote on my blog about Johanna Rothman’s negative experience with a product. One of her complaints was that it took too long for her to accomplish her goals using the product. She blamed her experience on “implicit” requirements that the developers of the product apparently failed to uncover.
I disagree. The problem stemmed not from a mere failure to uncover the requirement, but from confusion over what constitutes a requirement. Limits on the amount of time it takes for a user to accomplish a functional goal are not implicit requirements. They are standard nonfunctional requirements that should appear in almost every genuine requirements document (unless you’re using neurorequirements). It doesn’t matter whether you’re a “vertical operator”; interaction design means nothing unless you understand the goals you’re trying to achieve. The goals are the requirements.
Is it legitimate to produce different levels of specifications for a product? Sure. But the people who call all of these specifications “requirements documents” are generally the same people who lose sight of the underlying goals, resulting in products that frustrate users like Johanna Rothman. The fact that many of these people ignore nonfunctional requirements or put them in a document called a “functional requirements specification” confirms my suspicions.
But Scott isn’t your typical requirements analyst, which is why I look forward to his continuing the discussion I’ve started on his blog.