http://www.flickr.com/photos/lorena-david/ / CC BY-NC-SA 2.0

Lately, I find myself writing MRDs for companies I work with.  It’s always a great challenge to construct a good MRDs, but these recent experiences have really been wonderful: I’ve had the rare opportunity to create the company’s very first MRD.

This, naturally, has its pros and cons.  On the up side, you get your hands into something which is pure, raw, and full of vision, instead of delving into a well-formed (or a not-so-well-formed) product with a well-thought-of (or not-so-well-thought-of) business model and a well-constructed (you get the idea) marketing strategy, and trying to make your way through all the constraints and legacy issues that involve a mature product process.

However, the risk in handling an MRD in such an immature stage usually involves the company having a clear enough vision but not a clear enough focus, which tends to make the requirement gathering process rather shaky.  There’s often a great deal of uncertainty, lack of confidence and no real clear-cut objectives.

This is not necessarily something that should receive a reprimand – it’s quite natural.  However, while the rest of the management, often the business and marketing ends, can throw ideas around the room and stare far into the horizon, there should be at least one designated driver among the lot with her feet planted deep in the ground.  This is usually the job of the product marketing person.

Obviously, there are many “how-to”s out there on how to write the best MRD – this is not a post like that; I do, however, wish to convey a few techniques for getting the other people committed and focused on the task at hand.  This, later, can be translated to a document using a template of your choosing.

1. Get the CEO involved.  Make sure the CEO is part of the process.  This is important for two reasons: first, there are certain answers you will only get from the CEO that are crucial for laying the groundwork for the MRD; second – with the CEO in the room, the rest of the group will feel more committed to the task.
2. Just the facts.  It is our job to get the facts straight, at any cost.  Ideas and visions are perfect for brainstorming sessions, and I’m sure each and every one of us can daydream with the rest and the best of them, but this is a luxury we can’t afford right now.  You need to put your foot down and demand straight answers, backed up by logical explanations and as many facts as you can.
3. Start from the top.  The best place to start when constructing a good MRD, which is basically the company’s upcoming product strategy plan, is to begin with the most highly strategic aspect – business goals.  Ask questions like: when’s the next fund raising round?  How much will it be?  How long do we have with the current funding?  When would it be best to present the product?  To whom would it be best to present it to?  What kind of a business goal would that milestone aim to accomplish?  These questions and others like them will help you position your future plans in the overall business roadmap of the company.
4. Work your way down.  After you understand the major milestones that are expected from the company, start drilling down and do your best to make the product roll-out serve these goals.  Start by creating major product milestones that will go along with the business milestones, allowing yourself an ample margin of error.  Then, map out the major features for each milestone, making sure that only the most important ones are addressed, and that they all aim to serve the business end.
5. Don’t go too low.  Try to avoid the implementation pitfalls.  Do not start developing actual features, or try to see how different use cases affect certain aspects of the system – if you do that, you’ll never go out of the conference room.  That’s what PRDs are for.
6. Lay out an architectural plan.  Try to get engineering to draw out the product’s architecture in the most abstract way possible, yet taking into account elements such as deployment, distribution, scale, privacy, security, databases, etc.  I find this process to be extremely helpful in discovering new directions, coming up with exciting capabilities and mega features, and finding out major issues that should be addressed at this stage.  There’s something very evocative in seeing a diagram in a vision-driven meeting.  But remember rule no. 5 – don’t delve too deep!
7. Resources, resources, resources.  Always keep resources in mind.  Make the CEO commit to providing you and engineering with the resources you’d need.  The MRD should point out this information, sure, but the meeting should make everyone aware of how much the project would cost, in general terms, of course.  In other words – when the document comes out, the bottom line should not come as a surprise, or you’d find yourself going through the same meeting all over again, even more than once.
8. Be constructive.  Try too look at things from different angles – try to extrapolate a single element in the system to any actor or use case you can think of.  It’s amazing how many cool ideas come out of that.
9. Discourage destructiveness.  It is clear that MRD meetings are not easy to manage, since this is where vision and practicality meet.  Such encounters are hard on everyone, and sometimes people tend to get discouraged, especially when they’re told to stop dreaming and get real.  Try to notice defensiveness and entrenchment in people and do your best to open them up again, yet always making sure that their focus is well grounded.  Oh – and that goes for you too.
10. Set a time limit.  Make sure that both the meeting and the creation of the MRD are set to a limited time.  This further assists in maintaining focus, driving people to action and decision, and making sure everyone is on the same page.  Remember – an MRD is a map, and a very rough one at that; but it sets the tone for everyone during the upcoming product development period.  The better limits you have – the more focused your MRD will be.  And that is a blessing, no matter what they say.