产品经理不是傻截图，是基于需求分析的截
编者按：本文来自微信公众号“Kevin改变世界的点滴”（ID:Kevingbsjddd），作者：Kevin改变世界的点滴。
近期带着团队在进入项目的快速启动。我们在早起采用了蓝湖、禅道、teambtion的方式管理开发任务、UI设计任务、测试问题、需求管理。
当项目通过立项，产品经理带头组建团队后，首先第一个困难是是需求还没有出来，导致后续人员没办法开工。一个项目的带头人通常是产品经理或项目经理来做产品研发项目的负责人。
没有需求，就开发无法开工写代码。甚至连UI设计都没办法启动，此时场景要想不浪费时间、不让开发、UI设计、测试同学闲着产品经理可以干什么？
这个场景是几乎在产品经理都会遇到的0到1搭建项目碰见的。通常是公司要新起项目，同时团队有资源进行探索的背景。
到底出需求应该怎么最快？我今天提一个方法：截图
最快速做需求的方法找竞品
前段时间，我写了3篇关于产品经理和竞品的关系。用竞品顾名思义就是找同行业竞争对手公司的APP、PC等形态产品。
找竞品的好处是可以帮助将抽象、虚无缥缈的战略方向变为可落地的“实体”。很多时候在项目初期我们只有一个商业模式，知道怎么赚钱。但是产品有什么字段、主功能以外的子功能、页面流转逻辑我们是很难从无到有规划的。
在这里我建议竞品的使用主要聚焦在他们的核心功能、交互规范上。
聚焦竞品的功能描述、UED规范
1.功能描述
比如编辑器，可以知道开发时间成本、需求的实现复杂
比如商品列表，可以知道商品的列表、配置页、个人中心我的订单
比如首页，首页包含了产品的商业模式核心路径。可以看看竞品是如何做功能聚合、活动运营
▲APP首页的糖葫芦聚合版块
2.交互规范
PC端的页面在鼠标滑动、点击、键盘输入交互效果
UI设计风格、页面尺寸、页面大小
▲交互规范
什么都没有，要想快就从”截图和搭框架”开始
我们都知道，曾经有个段子特别火。
“别说那么多，给我一个竞品，我开始抄”
其实背后是讽刺产品经理、老板等没有创新，用着别人的方案却说自己着听起来天花乱坠的方案。
但实际上我们在产品无论是硬件还是软件研发中还是要分前端、后台。在移动互联网时代下前端常规分为包含客户端、web。
后台则包括运营管理后台、数据后台、业务后台。
在前面提到的用竞品方式，我们可以快速整理出若干的竞品截图。如下是我们早期在搭建PMTalk产品经理社区期间所找的其他类型社区产品：简书、知乎、qura、Facebook。
▲pmtalk编辑器，增加文章分类
▲简书编辑器增加收藏夹
直接截图的前提，首先要需求一致
我们前面提到了找竞品、以及在快速启动下用截图的方式。但有一点要注意，截图不是意味着照抄。
每个互联网产品业务都不同。就以社区来说，PMTalk是做产品经理用户人群的内容、简书是以小说、散文为主。内容形态不同，导致产品经理常用的话题比如运营、数据分析，在简书里则是小说分类、章节连载。
▲简书的作者关注榜
▲pmtalk的作者关注榜
因此许多截图都需要产品经理二次处理。以下是我在带团队工作中输出以竞品截图为基础做产品需求的原型。
▲通过截图的想设计
▲基于截图的二次需求设计输出的UI设计稿子
截图通过二次需求设计，达到开发同学能知道要做什么、能力界限，设计同学要知道页面复杂难度。
要多提一点，刚步入产品新人工作期间，早期是没有经验判断哪些需求需要画原型、哪些页面截图的经验和习惯。
产品新人认为小的需求比如APP的开屏页，自己只要想一个开屏文案就UI设计师直接做了。其实这是有问题的，产品经理的交互产物一定要是原型、文档，至少要有原型。
同时关于项目启动前期，针对技术的框架也是可以通过竞品的讲解和截图使用让开发同学并行搭建框架。比如产品的消息通知、社区内容管理、后台对用户管理、微信第三方登录注册。
类似用微信管理登录注册，是对接开放平台，需求是非常具体的、颗粒度很小的，就可以达到了。
开篇说的，当团队项目成员组建起来。是让团队开发、设计先等着产品经理出需求?还是产品经理先用竞品截图的方式马上同步并行？
其实2者的选择各自有优势，前者可以在规划中有更多时间，可能会减少一些技术弯路、产品设计的坑。后者就是快、但后期可能会出现功能重构的问题。
但无论在小公司、还是大公司，时间的紧迫性都是第一。
时间稍微晚点，就可能聚集更多的项目推动阻碍。所以时间是第一要素，快速的推动到上线到运营阶段。
▲只丢截图就开发设计的错误做法
因此千万不要以为截图的产品经理就不会做产品，反而知道那张图能够截图即可开发、设计，会用截图的产品经理可能才是功力深厚的产品经理。
因此我在2017年发布的每天体验1款APP，通过快速拆解APP的主功能、交互设计、商业模式、目标用户、产品属性。
一个产品经理刻意一年体验90款APP以上，相信你就会知道功能模块的具体逻辑、页面数量、用户群体、商业模式可行性。
好今天的分享就在这了。