需求分析，产品经理绕不过的第一个门槛

——“我有一个价值十亿的idea，就差一个程序员了。”

这句话在创业圈火，在产品圈也是一样。每一个产品经理都想做出一款特别的，甚至可以改变世界的功能或者是产品。这些功能和产品往往是从一个或者几个简单的需求和idea开始，越做越大。但是，用户真的需要么？最终的产品和功能真的解决了用户的痛点么？

前些天看了孙继新老师的文章《产品方法论之：菜鸟做加法，高手做减法》，颇有感触。结合着这两天搭个人博客和公众号以及以前的一些经验，简单来谈一下产品初期对于需求取舍的看法。

Insert：大而全让你寸步难行

踏雪的第一个产品，应该是大学时的第一次创业。当时美团外卖和饿了么还没有出道，踏雪瞅准学校里外卖横行，却没有一个统一的平台将他们整合在一起，于是就打起了这个主意。

踏雪的执行力还不错，当即拉来几个小伙伴就商讨着做这件事。一边向学校和老师要资源，一边就做起了产品规划。

小明说：“除了外卖，学校周边的饭店、网吧、宾馆，我们都可以做起来，统一在平台上，这样他们想要什么，我们就有什么。”

小刚：“对对对，我们还要加上地图，这样用户就知道怎么过去了！”

小红：“加上自习室提醒，告诉同学们哪里有自习室。”

小张：“对，还要有即时聊天功能，万一自习室人满了，有人说一句，大家就不需要白跑一趟了。”

( `)3′)▃▃▃▅▆▇▉ 你们是认真的么！

当时作为完完全全的产品菜鸟，踏雪不停的点头，对啊，这个功能肯定有人要用，加上加上，这个也对，加上加上。于是，产品的原型就变成了彻彻底底的四不像。

这个例子，很简单，大家一眼就能看出，很多需求是伪需求，比如聊天室，真的会有同学在聊天室里喊一句，自习室满了么？地图，有多少人需要在自己学校也看地图呢？自习室提醒，用软件吃喝玩乐的同学，会是经常去自习室的同学么？最后，我们最初的想法，不应该是整合一个订外卖的平台么？这已经离我们的初衷越来越远了。

这个例子看起来很傻，但是很多做产品的同学，在一开始做产品的时候，会犯下同样的错误。不自觉的往产品中添加功能，而这些功能，往往变成了产品的负担，让产品越来越臃肿，自己的思路越来越混乱，最终导致偏离初衷，走向失败。

踏雪在做产品的时候，每每见到新的需求或者想到新的功能，会这么做：

1. 问自己这个功能是否真的需要，和产品相辅相成。需要，进入下一个问题，不需要，记录到自己的idea库。
2. 问自己这个功能在现在是否真的需要，优先级有多高，是否立马就要做出来。还是需要，立马加到计划列表并高亮，不需要，记录到自己的idea库。

即便是这样，踏雪有时候还是会犯下添加不需要或者优先级较低的功能，那么——

Delete：开工之前，别忘了再删一遍需求

这次，拿新搭建的博客举例。

踏雪原来是做开发的，又不喜欢某浪等blog提供的模板，于是选择了购买域名和服务器自己搭（用的WordPress，套了主题后修修改改，没有那么复杂）。

在选择服务器的时候，众多服务器厂商的众多套餐晃的踏雪眼花缭乱。怎么挑选？

踏雪用做产品的思路去选择。首先，博客的定位是这样的：个人博客、产品经理相关。那么博客算是个小众博客，再加上踏雪是个新人，没有什么人气，一段时间内流量不会太大，那么买流量大，储存量大的服务器，显然没有必要，这个需求，删掉！

服务器和域名搞定，安装wordpress。自己写主题？显然“敏捷开发”（套用主题）更适合，那么自己写主题这个需求也删掉。

接下来挑选主题：踏雪的内容以文字为主，可能会有一些图片。那么播放音乐和视频的功能就完全没有必要，删掉！

文章会有评论，但以交流为主，头像这种社交性偏强的东西没有必要，删掉！删掉！

于是，博客的雏形就有了：

不大的服务器，准确易记的域名，文字和图片为主的内容，以及交流为主的评论。

于是半天的时间，踏雪的博客就搭好了，剩下的就需要花时间，一点一点的填充博客的内容了。

所以，在产品真的开工之前，我们需要对产品的每个功能和需求重新进行一次评估，只要不是真正立即需要的需求，统统砍掉。

那么问题来了。

“蓝翔！”

(╯’ – ‘)╯︵ ┻━┻

┬─┬ ノ( ‘ – ‘ノ) {摆好摆好)

(再掀一次} (╯°Д°)╯︵ ┻━┻

踏雪要问的是：“如果砍掉的需求需要，或者没砍掉的需求不需要，再或者没砍掉的需求不够准确怎么办？”

Update：迭代中完善，改变世界也要一步步来

迭代更新这个事，需要大量的数据和用户反馈来支持。踏雪也没有发现一个特别共通的特点。

简单的举个踏雪遇到过的小例子。

踏雪做过的一款APP里，有一个发表话题的功能。这个功能在APP里是必须的，但是很多用户对这个功能的作用并不够清楚和了解，于是踏雪对它进行了一个小的改动，收到了很好的反响。

在发送话题前，弹出一个小框，引导用户选择是提问题还是分享经验或照片。

简单的功能升级，或者说需求升级，引导用户做出更规范的行为，即让用户知道他可以干什么，也让后台对内容的管理更加方便，数据统计也更加清晰。

很简单，却很有效。

\(￣）￣)/赞\ (￣）￣)/;

那么对于迭代更新，大家一定要谨小慎微。千万不要把添加功能当作迭代，千万不要没有条理的去满足用户需求，真正的解决了用户痛点，才是一个好产品一个好功能。

增删改的基本要求

至此，踏雪浅入浅出的讲述了一下自己对“增删改”功能和需求的一些看法。重中之重，便是谨小慎微。

而增删改的基本要求便是：大胆猜想，小心求证。

本文为作者 @踏雪Monkey（微信公众号：踏雪Monkey）投稿发布，转载请注明来源于人人都是产品经理并附带本文链接