苦心转行做产品，不到一年却发现项目老被砍，没有价值和意义该怎么办？感觉做了很多“无用功”

写在前面

入职快一年的自己，想想当时可是看着苏杰老师高举的“人人都是产品经理”的伟大旗帜，投入产品大队列，希望自己能有成为敢想、敢做、和能做的豪杰。于是，在北京几家互联网公司做了近半年的HR实习后，投身到产品岗位。现在回首：什么产品经理改变世界都是骗人的，初入职场的产品汪，弱小又无助，天天和程序员相爱相杀，程序员经常说我们写文档就是抄竞品，一点技术含量都没有，自己不开发，劲整这么多花里胡哨的需求，当然我们嫌弃程序员一个小功能要开发好几天，相互嫌弃是日常，可是这些都是日常开心轻松的怼话。入职一年，发现项目被砍、负责的需求老师夭折，真的太难了！

处于崩溃的边缘 做产品太南了！

最近的工作，总算明白和程序员过招，有一招叫釜底抽薪，直重要害，无一点反击余地：你这个需求一点价值都没有，我们不做！

作为产品狗的自己只能含着眼泪，对程序员小哥说，嗯嗯~需求价值我再梳理一下，先不做了！

肯定也有产品伙伴跟我差不多，在既有的团队内，团队方向基本上比较确定，尤其是TO B的团队，感觉都做着不用过分思考或者市场上看似千篇一律的功能。日常的工作就是写PRD，注重产品功能设计，需求价值很难量化，渐渐的我们也就不和开发将价值了。只说“这个需求领导提的，这个需求很重要、这个需求业务一定要！”（哈哈哈）

坦白来讲，自己所从事的工作方向，产品需求的价值，真的是管理层的需要，不是根源于企业场景、也不是聚焦解决某个协同办公痛点、大部分是基于管理需求，自上而下的功能绑定设计。这种模式，作为没有啥方法论的产品小白，就自我麻痹了，不再敏感与业务需求的价值，希望通过产品功能上，多设计、多出彩。到最后，没有太多落地场景、或者满足不了实际的需求。

需求不经过实际调研系列

血泪教训经历：误把紧急的需求当成重要的需求，投入精力后，却一场空。（要自闭了！）

最近疫情突发，公司某职能部门提议开发【问卷调查管理】的功能，虽然团队已经存在了好些年，但是一直没有开发这类通用工具类的产品，经常是出现问卷收集的需求，临时抱佛脚开发开发。这次疫情爆发了，需求方希望能快速地收集到公司在京人员的出行信息，因此采用H5本地写死的开发模式，和后台的接口则是沿用之前活动平台使用过的接口（特别坑！），调试和开发都花了很长时间，导致业务方特别不满意，并且当时H5开发资源也很充裕了，就建议重新开发一个通用的问卷调查的工具。

欢喜：以为能大干一场，吭哧吭哧调研了竞品，梳理了几天的逻辑。最后评审时一句话：夭折了！

经历了H5本地写死问卷题目的开发模式，业务方只要改动题目或者选项，就需要H5本地改代码，再部署到生产，操作繁琐并且很依赖开发人员。因此，大家都觉得应该做一个问卷发布的后台管理工具。于是，就调研了目前非常强大且主流的问卷调查工具——问卷网、问卷星。这两个工具是目前市场占有率前几的产品。但是，考虑到内部工具，问卷调查的场景主要就是：公司性的HR问卷调查、办公室或行政活动性质的调查。再加上和内部H5开发大哥沟通，平衡开发的投入产出比不建议，后台功能做得太复杂。因此，做了简化的梳理，维护到wiki形成文档初步功能描述的列表。

等到需求评审当天，邀请了后台开发负责人、后台开发人员、H5开发负责人和H5开发人员，评审完毕后，说需求价值太低，不做实现或者做阉割版功能实现，一个夭折在初次需求评审的功能。现在想想，自己可以再多做一点，能让这个需求死的更灿烂！

图片：wiki文档中背景和目标简述（标红涉及系统名称，做脱敏处理）

灵魂三问之一这个功能价值在哪里？——满足业务发布问卷和收集问卷的需求（评审前感觉这多么精简，一句话表达产品功能目标，现在想想自己的准备确实太不充分，或者说未表达出来充分的理由和信息，评审时，开发负责人需要感知这个功能到底能支持多少人、满足什么样的需求，感觉应该从场景——痛点——功能，去阐述阐述价值。

灵魂三问之二这个功能有现有的工具资源吗？——目前我们团队没有（当时一直想着自己团队，并没有其他OA团队了解情况，其实OA系统有个2016年的新问卷调查工具（PC端的），导致评审现场大家认为需求调研不充分，选择新开发方式，浪费资源。）现在想想，以后面对任何一个需求，都想问问既有的系统是否有功能可以支持，了解历史情况，再评估，最后采用何种方式。毕竟，好几个团队都在做这个事情，就需要好好评估，自己来做的成本和效果了。

灵魂三问之三这个功能你打算用多少人做多久？——目前我就是将一期功能梳理出来，希望实现问卷信息的收集，数据统计希望放在二期去实现。（这个回答确实很不好，事后反思，太关注于功能设计而忽略了资源预估）如果时间倒流，会提前用脑图而不是列表的形式，将整个问卷调查功能的产品结构图画出来，并且标注好一期、二期、三期，有规划性，并且对每期功能有一个上线时间安排。

需求核心未把握，本末倒置导致需求沟通效率低且出现重点偏差

疫情信息填报需求中，我反复和业务确认他们需要收集的信息（问卷的题目和题项），看似和业务沟通频繁，实则很大的错误。作为产品对接人，不应该关注他们的问卷内容（文案），业务会清晰设计好自己的问卷内容，而我应该关注问卷的题型（单选还是多选、文本填空还是评分题、是否必填、是否关联跳转等逻辑）。

需求设计的价值评估，刚入职或者比较初级的产品，往往自己很难评估出来，得多和领导沟通

梳理好产品功能结构，和领导保持高频沟通和联系，确保产品设计方向小偏差。疫情期间，团队开发资源充裕，因此，领导希望能好好设计问卷功能，当时自己闷声梳理大体逻辑，体验各种竞品，但是应该在当天输出一个产品功能脑图，和领导同步一下产品需求的方向，首期能重点实现哪些功能，二期能实现哪些，他对需求有一个把控，能避免走弯路和白白消耗力气。

最后，附上夭折在摇篮的功能需求说明文档简要，欢迎大家指正和点评。

图2：夭折在摇篮的问卷需求

珍爱生命，远离产品~