10 Tips for Writing Better MRDs - Part 2

In my previous blog entry titled 10 Tips for Writing Better MRDs - Part 1 - I covered five tips for writing better MRDs. I know you\'ve been waiting with bated breath for the next five tips. Wait no more, I\'ve covered them below!

Here, I use "MRD" to collectively refer to all documents created by product management and/or product marketing teams for the purpose of conveying product requirements to engineering team.

If you haven\'t read the first five tips yet, please read them first. I will wait here. Okay, you are ready?

Here are tips 6 through 10.

1. Specify What & Why - But Not How

   Product managers are responsible for understanding customer needs, and using this understanding to define what should be developed and why.
   
   The one thing, more than anything else, that causes developers to get mad with steam flowing out of their ears so fast that the accompanying whistle can be heard miles way - is an MRD that specifies *HOW* to implement each and every requirement in excruciating detail.
   
   Consider the following two approaches for specifying "Login" functionality for a customer relationship management (CRM) software that your company is developing.
   
   

   ---

   
   Recommended - Specifying *What*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the \'Login\' button - our software will remember and auto-fill his username the next time he comes to the login screen.
   
   Not Recommended - Specifying *How*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the \'Login\' button - a cookie will be written to his PC hard-drive using Javascript to save his username. Username/password will be sent to server only after this cookie is written to the PC hard-drive. The next time Mike comes to the login screen, Javascript will be used to read his cookie. After successfully reading it, Javascript will use the appropriate DOM command to prefill the username in the login screen.
   
   
   Just as good product managers are experts at understanding customer needs and specifying what needs to be done, good engineers are experts at deciding how to achieve it. Good engineers want the freedom to decide the best how to achieve the desired what.
   
   I\'ve noticed that product managers with technical background are especially guilty of specifying how. If this describes you - just say no to it from now on. Engineers will thank you.
   
   P.S. There are some rare exceptions to this rule - instances where it is necessary to specify how along with what, as the best and/or the only specification of what in these instances is the how.

2. Cover Non-Functional Requirements

   Whereas "Functional" requirements specify the features of the product, "Non-Functional" requirements specify system characteristics such as:
   
   a) Performance
   b) Scalability
   c) Availability
   d) Internationalization
   e) etc...
   
   I\'ve noticed that these are often omitted from MRDs as many product managers and product marketers consider these "technical details". I\'ve found these to be very important part of my MRDs and engineers have really appreciated these requirements being defined in MRDs.
   
   Important: When writing non-functional requirements, make them easily measurable (testable) whenever possible. Otherwise, QA cannot test it and you will have no way of knowing whether the finished product meets these specifications or not.

   

3. Review & Update

   I have a friend - we will call him Matt (his real name is Steve). Matt works as a product manager at a successful company in the valley. He had an interesting story to tell when I met him for lunch recently.
   
   They had hired a new product manager with about three years experience. Within a few months of being hired, he had somehow managed to alienate many of his fellow product managers as well as engineers.
   
   His crime? He basically considered his MRDs to be sort of like decrees. He wrote them, but did not want to review with anyone or modify it based on feedback. He just wanted the engineering team to take it and implement it without asking any questions!
   
   Don\'t be like Matt\'s coworker. Make sure to review your MRD with your fellow product managers and the development team. Keep an open mind and update the MRD based on the feedback in these reviews. This will help you create better MRDs, engineers will like you more (or at least hate you a lot less!), and your team will create better products.

4. Define Target Market & Positioning

   Most MRDs I\'ve seen do a pretty good job of covering the Target Market (who will buy and use your product) and Positioning (how your product will be positioned versus competing products).
   
   I have seen some MRDs that don\'t and the argument that I usually hear in these cases is along the lines of: "Why do engineers need to know this? Isn\'t defining what needs to be done enough?"
   
   While that question certainly has some face value, I\'ve found that many engineers want to know why a certain product or feature is being developed, who will be using it and what are their alternatives.
   
   This information helps them and other members of the product team visualize the end users and as a result do a better job of creating winning products. My suggestion is to include this information whenever possible - it doesn\'t have to be very detailed, just a couple of paragraphs will suffice.

   Like This Article?
   
   Why not share it with friends and colleagues? Just click here...

5. Include a Glossary

   If your MRD uses new terms or common terms in an uncommon way - make sure to include a Glossary at the end.
   
   This will help ensure all of your readers (some of whom may not be technical) understand what you mean when you say things like "Our software will provide SME users the option to be billed a MRC via WAP or PSMS".

There you have it - tips 6-10 of my ten tips for writing better MRDs. I\'ve shown the entire list below for easy reference as well:

1. Write From User\'s Perspective
2. Use Screen Shots
3. Write Using Simple Language
4. Use Templates - But With Care
5. Prioritize Requirements
6. Specify What & Why - But Not How
7. Cover Non-Functional Requirements
8. Review & Update
9. Define Target Market & Positioning
10. Include a Glossary

Here is to better MRDs, better products, and more success...

写好MRD的10种技巧-第二部分

       在我前面名为“写好MRD的10种技巧-第一部分”Blog文章中，我描述了写好MRD的5种技巧。我知道你一定迫切的想看到其他5种技巧，不用再等了，下面我就描述它们！

       在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。如果你还没有阅读前面的5个技巧，请先阅读它们，我会等在这里，好了，你准备好了吗？

       以下是写好MRD的10种技巧-第二部分(6-10)

6、说明"是什么"和"为什么"，但不要"如何"

       产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发.
有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。

       考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。

       推荐-描述“是什么”
       Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。

       不推荐-描述“怎么样”
       Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后，用户名和密码将被发送到服务器。下一次Mike来到登陆界面时，Javascript 将读取他的cookie，成功读取后，Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。

       我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。

       附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。

7、覆盖非功能性需求

      尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：
       a)性能
       b)可伸缩性
       c)可用性
       d)国际化
       e)等等...

       我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分，工程师们会非常感激在MRD中定义这些需求。

       要点：当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。

8、评审&修正

       我有一个朋友-我们叫他Matt（他的真名叫Steve）。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。

       他们雇用了一个有三年经验的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。
       他是罪犯？他基本上认为他的MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们！

       不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD，工程师将喜欢你（或者至少少恨你一些），你的团队也将创造更好的产品。

9、定义市场目标和定位

       大部分我看到过MRD在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做的很好。

       我还看到过一些没有描述市场目标和定位的MRD，他们通常会这样争辩：“为什么工程师们需要知道这些？拿到定义了什么是需要的还不够吗？”

       这些问题（谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的）的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。

       这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的（在MRD中）包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。

10、包含一个术语表

       如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。

       当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时，术语表将确保你的所有读者（有些可能不是技术人员）理解你的意思是什么。