Requirements for Requirements
Do you ever get frustrated when writing up your product, feature, or even option requirements for development? I don’t mean frustrated as in, “maaaan this is a lot”. I mean the frustration knowing they’re going to get torn apart because your friends in development loooove digging into the weeds. Rightfully so, I have always found the best developers come out swinging with concerns when we bring them what we think is enough to get them going. “Come on, really? Do you really need more information?”. The answer is a big fat, YES! It’s been successful for any product manager I know to be working with the development leads, at least when drawing up your first set of requirements to get the groundwork laid out. This helps when you bring them in front of the broader team to discuss what it is that you want to build, why, and for who.
The key is not to take any of this personally. We all get agitated when we are told to create yet ANOTHER ticket or to fix the wording of one sentence that you think is already clear enough. The apparent truth is that you need to make sure you have requirements for your requirements. Yes, the title is not a play on words; it’s serious. You need to suck your pride and always ensure you have some rules when it comes to drawing up those lovely little demands. Whoops, did I say demands? :smirk:
Here are a few that have helped me in the past when it comes to writing out requirements for dev:
Swallow your pride: you’re not a know-it-all! Remember that old saying, “while your opinion is interesting but invalid”? What I mean is you have to be specific and even loop in your dev friends to make sure you’re writing your needs clearly so that they understand where you are coming from. However, the more you work with your squads, the more you start to understand the lingo. Otherwise, you’re in deep…you know.
Read up: chances are there are some really great examples out there on how to write them up. I have been subject to third parties coming in from time to time and shouting agile until their faces turn blue. If you currently aren’t happy with how you’re being taught, why not have a look out there to see what the PM world offers. Who knows, you may find some method that really takes to you. The smart money says other PMs in your org probably feel the same way you do and are looking for a change.
DIAGRAMS: I cannot stress this one enough. You need diagrams with user flows showing how your thingamabob actually works with the user at the wheel. I get slammed when I am missing what would take me 10-15 minutes to make in between cups of coffee (I don’t drink that much coffee, I’d die). The best part about this is that your devs will appreciate that you have thought about all the scenarios that your game-changer will possibly have.
Ask for help dammit: I mentioned before about bringing in your dev pals for help when needed. Why stop there? I hope to Santa Clause that you have a mentor or people in the field around you that can provide some advice or help proofread some of your...I’m not saying go out and share your classified work with people outside your org, duh. I’m saying you should have a template by now that you use and could do with some proofreading. I’ve been lucky enough to have bosses who have been amazing mentors in the field. Now, I do realise that’s not the case all the time so search around in your company and gravitate towards that kind-hearted sole who can be tough as nails and tell you how it really is
There you have it—some examples of requirements for requirements that might be familiar to you or even new. If you’re just starting out, I know how tough it can be to try to get some ground, and quick. I hope this article helped, but if it was useless…hey no problem! I’m sure there is someone else out there who can give you the information you need. I’m just a lowly product manager, after all, trying to make my way in the world :)
