带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何满足这些战略目标，当我们将用户需求和产品目标转换成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。
范围层定义：定义项目范围就相当于我们同时在做2件事，这是一个有价值的过程，同时能产生有价值的产品。过程的价值在于，当整个事情还处在假设阶段时，它能迫使你去考虑潜在的冲突和产品中一些粗略的点，我们能够确认现在能解决哪些事情，而那些必须要在迟一点才能解决。产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确啦这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同的语言，定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
产品经理需要把经理放在新功能的思考上。
做项目，要有一个工作流程、日程安排、在项目重要节点设置里程碑。
文档定义需求：1、知道自己或者公司项目在建设什么
2、知道自己或者公司不需要建设什么（众多的功能看是否是对项目的战略目标是需要的），众多想法涌现时，用问的那个记录他们，可以为我们提供一个评估这些想法的架构，帮助我们了解他们是如何（或者是否）满足我们当初所承诺要做的哪些事情。
当前难以满足的需求，可以成为下一个版本的基础，遮掩就能形成一个不断循环的开发过程。
功能和内容：在范围层我们从讨论战略层面的抽象问题-我们为什么要开发这个额产品？转而面对一个新的问题-我们要开发的是什么？
cms(Content Management System)内容管理系统
一个内容管理系统可以实现自动化流程，能展示和交付给用户。
内容提示要专人做处理或者产品经理设计
定义需求：
一些需求适用于整个产品，品牌需求、技术需求（支持浏览器或操作系统）
另一些需求仅适用于特殊的特性。
需求的详略程度常常取决于该项目的具体范围。
功能规格说明：（功能柜个说明书）文档足够清楚和准确的说明问题
记下来：以下规则适用于撰写任何类型的功能规格说明
1、乐观：描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情比如，下面两句话的对比：
第一句：这个系统不允许用户购买没有风筝线的风筝
换成下面这句话会更好：如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面
2、具体：尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的最佳途径
对比以下例子：
第一句：最受欢迎的视频要重点标注。
第二句：上周被播放最多的視頻要要显示在列表的最前端
以上有很大的不同,说明视频受欢迎的形式,播放量多,说明是哦in重点标注的形式显示在列表的最前端,描述重点标准的机制
3、避免主观的语气：这是另外一种需求“保持明确”和“避免歧义”的途径，因而也避免了误解的可能性。
例如：非常主观的功能规格说明：这个网站的风格应该是时尚、耀眼的。
功能规格必须可验证-就是说，他必须要能证明“这个需求没有被满足”。产品工作中功能柜个需求必须找到某种方式来明确说出应该达到的标准：
网站的外观应该符合企业的品牌指南文档。（品牌指南文档有足够的时尚性负责市场的人可能去了解相关人员甚至做一些用户调研的工作）
我们也可以量化地定义一些功能，通过这样的手段避免主观性。用量化的标准来定义功能有助于知道我们是否满足需求。
4、内容需求：我们所说的内容往往指文本但是有时图像、音频和视频额能比文字更重要，这些不同类型的额内容可以结合到一起，相互协作去满足某一个需求。内容特性想要达到的规模，将对你所作出的用户体验决策产生极大的影响，内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音视频文件等相对独立元素的大小等，这些大小的估计不一定要非常精确-大致相近即可。尽可能早的确定某一个人来负责每一个内容元素也是非常重要的。
内容清单
5、确定需求优先级
由于项目范围时间里在战略层的基础上，因此我们应该去评估这些需求是否能够满足我们的战略目标（无论是网站目标还是用户需求）除这两种目标我们还要额外确定第三种范围：实现这些需求的可行性有大多？
留意哪些看上去有可能需要改变战略的特性建议，他们在制定愿景文档期间并不明显。任何不符合当前项目的额战略目标的特性建议，都要通过范围定义将其排除在外。但是如果有那么一个特性，尽管它不再项目范围之内，也超越了任何一个限制条件，但听起来任然像一个不错的想法，那么此时你可能需要重新审视某些战略目标，不管怎样，如果你发现自己在反复审视战略目标，那么你极有可能是太早进入了需求定义阶段。
如果你的战略计划或愿景文档在战略目标的范围内制订了一个清晰的优先级别顺序，那么这些优先级别应该是决定是否采纳 人们建议的相关特性的首要因素，
控制谈判的过程会比较困难，解决管理层之间的争论的最好的办法是要求“制定战略”。关注战略目标，对决策这表示认同是解决特性冲突的关键。