编辑导语：做产品时往往会遇到一些坑，如果不能及时地发现总结，下次可能还是不能避免陷入同样的困境。本文作者从亲身经历出发，描述了如何做出一个完整的产品，同时为大家讲述了在做产品时容易遇到哪些坑，以及规避这些坑的方法，希望大家阅读本篇文章能够有所收获。

第一次做一个完整的产品，我遇到了哪些坑，哪些是本可以避免却强行踩进去了，哪些是不得不踩踩才知道什么叫做坑。

本文简单整理了一下过程，发出来供自己回看及与大家交流。

最近身体状况欠妥，嗓子疼，有点感冒，口腔溃疡，头很疼，情绪果然影响人的身体健康。但我还是舒了一口气：精神压力无处排解的，身体还是会想办法释放出来。

我司在今年逐步完善产品部门，而我也从原来的ERP部分需求分析的角色顺理成章的过渡到了产品。

说实话，以前也算是有做过产品的工作，例如写一个完整的PRD，配合开发澄清我的功能设计，但对接的开发方比较简单，要么是一个小程序的开发，要么是ERP的同事。

因此我甚至觉得，做产品和种地区别不大：沟通需求是确定要种什么，功能设计是确定在哪块地怎么种，传递需求与功能就是把种子种在土里，剩下的就是偶尔去地里看看情况，掐着点等待收获了。

然而我井口的天空终于被一个新任务强行扩大了，这次村里给我一个大项目，让我负责一个大客户的需求，他的需求很清晰，要满汉全席的全部原材料。

满汉全席，我没吃过，蒸羊羔、蒸熊掌、蒸鹿尾儿，烧花鸭，烧雏鸡，烧子鹅……？

一、确定功能范围

1. 确认本阶段“满汉全席”原材料

第一次搞这种大任务，很慌，强行让自己冷静下来，毕竟有我的领导们，他们身经百战，阅人无数，让我在深夜里翻来覆去想不出答案的问题，对他们来说可能就是一首歌的时间。

先跟领导们沟通方向，得出村里的战略方向：不止这个客户想要满汉全席的原料，我们也想向其他客户提供此类服务。

但为了让当前这个客户尽快吃上饭，本期先种植吃饭必须的原料，也就是先搞MVP（最小可行性产品）让客户试用起来，在过程中慢慢迭代逐步满足全部需求。

收到这个指令，我的内心平静许多。搞一个最小的闭环流程，范围是可控的。

我只需要筛选范围内的必备元素即可，因此二话不说，开始收集信息，整理吃饭的必须原料清单，例如要米饭，要青菜，要水果，等等。

必须原料清单准备齐全，跟领导们沟通，确认问题，调整修改，准备找真正种地的农民沟通种子种植的问题了。

2. 问题提醒

这里其实是自己给自己挖了一个坑，我们在确定最小功能合集的时候，根据内部主观判断而没有考虑用户的期望值。

我们认为某功能在流程闭环中并非必备而排期靠后，后面交付给客户一期功能的时候，对方表示非常不满意，客户认为上线必备的都没有产品没法用，这让我们很被动。

除了与客户沟通清楚需求范围，在普通的标准项目上，面向B端的产品本身就会有一个客户的定制化需求与产品本身需求的矛盾。

不同企业流程不一样，不可避免会有不同方案，这种情况都要走配置吗，这是一个值得思考的问题。

二、确定研发排期

1. 寻找种地的人

理想很丰满，现实很骨感。农民的地不只为我而种，我只能静静等待他们这一茬收割完成，然后告诉他们我要种什么。

客户再催我也没有办法，领导也知道这种情况，领导不动，我亦不动。

2. 问题提醒

假如不能按照客户想要的时间安排，且自己没法协调时，一定需要找领导沟通，让领导来协调与研发与客户的关系。

三、向研发宣讲需求

1. 告诉农民我要什么

后来，大约2个月后，领导通知我农民们土地空余出来了，可以召集大家开个大会沟通一下下一阶段的工作了。

我有点紧张，这次的大任务要涉及好几个农民，都是我以前没有接触过的。除了人不认识，也不知道我说的语言他们能否听懂。

宣讲需求了，果然，我说的都是我原来用的语言，我认为这都是基础语言大家都明白的，没想到其实他们原来没有种植过原材料，我说的菜名他们有的都听不懂。

过程中还有一些其他的问题，是我之前没有想到的。最后，这场沟通在磕磕绊绊种勉强结束了。不可避免的，后面农民的带头人又重新找我沟通了一遍。

2. 问题提醒

俗语有云“见人说人话，见鬼说鬼话”，在产品的岗位上，这似乎是一句夸奖的话。

面对客户的时候，用客户能听得懂的场景、功能语言；跟研发沟通的时候，他们关注实现，用系统、操作语言。

但这不同的语言特质怎么把握，怎样才能沟通顺畅还需要慢慢摸索其中的门道。

四、需求开发阶段

1. 农民永远无法按需种植

种植阶段的细节问题层出不穷，有时候是说，他们的土地是标准土地，不会只种植一种东西而专门开出水道沟渠，不会专门添加大棚。

假如说要插上一个稻草人也要好好考虑一下，有没有用，能否为未来别人服务。

这个我也是理解的，但是总不能为了你们的标准让我的体验感很差吧。和他们讨论，确认，修改，调整。我们在互相的妥协与坚持中，大家加班加点的完成了这次的种植。

2. 问题提醒

在需求开发阶段，研发同学设计自己的技术方案的时候会有他们的考虑，有时往往会牺牲掉我们想要的功能。

有时候我们觉得，这个功能去掉我接受，但有些时候，很影响体验的功能我们还是得坚持。

假如双方实在争论不下，经验不足的时候，还是去找领导讨论一下。一方面，领导的经验更丰富，另一方面，领导说的话更有分量。当然，当你就是领导的情况除外。

对于研发说某个功能实现不了，这里主要分享产品的注意事项：

• 了解实现不了的原因：是技术太复杂，还是工作量太大，或者算法实现不了
• 确定当前产品的目标：是0到1，或是过程中的迭代
• 确定功能对当前版本的影响–即功能的优先级：是体验问题还是逻辑问题
• 假如必须要做，能否目前先简化实现：妥协的功能记得填坑

五、功能验收阶段

1. 前期挖坑，后期填坑

收获的季节到来了，是时候检验原材料种植的是否符合标准了。

集中一看，基本上还行。跟客户沟通一下问题吧，客户说，半年了，我要的是满汉全席的原材料，你只让我吃饱一顿饭，这我能要？

前面挖的坑果然来了，客户不吃。

安抚好客户，确定假如要满汉全席，他认为的原材料必须有什么。安抚好农民兄弟的情绪，继续苦逼的搞个二期吧。

2. 问题提醒

一个是前面提到的与客户先明确好上线必备的功能范围，时刻与客户同步研发情况；另一个是研发加班本就辛苦，需要注意鼓舞他们的士气，有劲头继续做二期工作。

该产品自己承担的责任，不能推卸，毕竟产品是承前启后的关键角色，要有勇气和担当。

毕竟，我们的目标不是做出一个东西，而是做出来的东西有人用，最终能卖钱回来才是我们的目的。

同时，一定要注意总结，不要在同一个坑里跌倒第二次。

六、后记

这只是一个简单概述的产品从0到1的过程一部分，中间第一次协同各个中台组件的开发的困难。

第一次沟通交互设计的纠结，第一次直面自己不愿意麻烦别人的弊端，个中感受一言难尽，后面再继续来和大家交流。

另外，想分享之前看懂其他博主的一段话：我们太容易把客观事实、迫切程度、迭代规划、内心感受、同伴关系等问题搅和在一起来考虑，你在做判断的时候就很痛苦，自以为事情很紧急很迫切，却不知道哪个是客观事实，哪个是你臆想出来的恐惧。

在与客户、与研发、与自己交流的时候，冷静思考，区分虚拟与现实，与大家共勉！

本文由 @困困生活 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。