Valuable and Functional Requirements
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.
