——这是我的第 104篇原创文章——学习 B 端产品，就看「司马特小分队」
今天文章比较短，但是比较普适性。
通过 6 部分，搞清楚需求。
1）背景：在什么样具体的业务场景中，我需要了解非常具体的、细节的业务场景、以及该场景的前提因素。
2）谁：是谁提出了这个需求，是直接提出还是间接转述。是需求直接人，还是非直接人。
3）需求规模：这个需求提出者的规模、类别、特征、等级，来界定需求的通用性和紧急度。
4）现有的解决方案：这个需求之所以产生，是否是因为使用某个产品、或者使用竞品的产品而附带产生，还是说现有解决方案没有解决好原生需求。
5）疼痛程度，是否这个需求是用户核心业务链路中的需求，还是相对来说无关紧要的、不痛不痒的需求。
6）核心诉求：用户在提这个需求的时候， 本质他是想解决什么问题，注重问题，而非用户需要“什么”，用户需要的往往带有主观因素。
当我搞明白这6点后，我就对这个需求有一个非常清晰的认知了。
02接下来，我们就是想产品架构1）先要确定主流程，即核心结构。
做任何东西都要先搭建主骨骼。一般来说，当我们迭代一个新功能，需要建立新的业务流程的时候，往往需要考虑，如何最合理的结合现有的业务模块或流程；而在老流程上做改造的时候，则需要考虑跟现有业务流程的延续性、兼容性、合理性关系。
2）完善分支流程和功能结构框架
这个没啥特别好说的，就是把需求转化成具体的业务分支流程，按照结构化思路把方案拆分成模块、功能点、页面、组件块。
这两步做正确，你的整体框架性方案就不会有太大的方向错误。
既然我们整个产品架构确定了，接下来就是要设计具体的功能了，主要是考量的是展现层、逻辑层、数据层。
03再者，竞品调研这个时间点，一般我会调研一些市面上做的比较好的竞品，当然这一步也可以在确定产品架构前去调研。
调研主要调研以下几方面：
1）竞品的业务背景、功能框架和流程
因为竞品的背景和自己的产品并不一样，所以有的时候我们在借鉴竞品功能的时候，其实是会被带偏的，需要搞清楚他们的业务背景，才能更好的理解他们的功能为什么这么设计，为什么这么搭建框架，为什么这么设计流程。
2）优点、亮点、创新点
有些同行真的做的很用心，做的很出色。那些出色的产品，往往会被用户传播。
从中吸收一些优质的点，并在此基础上做些微创新，其实就已经很棒了。但是依然，我们要充分考虑优点下的条件，在另一个条件下可能就不是优点了。
3）竞品背后的产品策略
比如微信加了一个”在看“的功能，表面上看类似于一个点赞的功能，背后其实是微信希望进一步打通好友之间的内容通道，从而增加内容的分发效率。
基于此，你再去判断这个功能到底好不好，是不是能真正增加分发效率，而非一个鸡肋功能。
04接下来，就是产品方案设计了这块没啥好说，把页面的作用定义清楚、把交互做的友好、把每个字段都定义的清清楚楚。最后整体串联起来，按照业务流程多走几遍，看下是否有问题。
对于B端来说，我非常强调一点，就是客户验证。
那么在正式开发前，我们会跟每个层次的头部客户确定下产品方案，是否真正满足他们的需求，流程、功能点、字段是否是他们真正所需的。
确认了这一步，基本上不会出现太大的问题，我们经常看到有些产品上线后无人使用的尴尬境地。
绝大部分原因是产品无法满足需求，或是非常不好用。客户验证能大大降低此问题的几率。
06最后，考虑的是技术实现产品方案出来后，免不了评审和开发提出的一堆问题。
1）假如你有技术思维，在产品设计的时候就能规避掉很多技术无法实现、或是很难实现的问题。
2）假如你没有技术思维，那么在这一 part 你需要和技术一起讨论，确定最优的产品解决方案。
如果一个功能的价值不大，但是技术实现难度很大，这种投入产出比其实是非常低的，也是我们应该规避的。
我们最喜欢的应该是最小的开发成本，最有效的价值，就像微信的“拍一拍”。
本质上这也是一个产品方案更合理化的过程，我们不能只关注极致的用户体验，而忽略研发成本，在现在这个精细化运作的时代，投入产出比是每个产品经理都应该有的基础思维。
作为B端产品来说，只要遵照上述的路径来迭代需求，基本就不会出现太大的问题，而且在一次次不断的实践中，你也会不断修正路径，找到最适合自己的一条星光大道。
END
司马特小分队，已经发布了 110+原创文章，还会持续更新「医疗」、「教育」、「工业」等更多垂直领域的文章。如果你正在「找工作」、或者「苦恼不知道如何成长」，那就加入我们的星球「B 端产品经理之家」吧。回复「星球介绍」，可以了解星球提供的各种福利哦。回复「优惠券」，可获得 50 元星球立减券，数量有限，手慢无。
星球成员心动的特权福利
以上就是关于做好产品迭代的6个必要步骤洪武大案演员表全部的内容，关注我们，带您了解更多相关内容。
特别提示：本信息由相关用户自行提供，真实性未证实，仅供参考。请谨慎采用，风险自负。
