这“2.5”个B端产品方法论，我想分享给你重在|付费|运营者|内容|知识

编辑导语：关于B端产品的相关知识，大家已经了解了不少，然而关于B端产品方法论，不同的人会有不同的见解。本文作者通过回顾自己4年的平台产品工作经验，总结了“2.5”个B端产品方法论，希望对你有所启发。

文章插图
距离上次发表文章已经过去30+个月了，在当下这家公司负责了15+个项目（还没算上一些不成项目的流程优化），高效的工作效率/沟通效率让我能够同时负责多个项目且脑子不堵车。
接近4年的平台产品工作经验，又临近工作更换的节点，将这段时间的一些个人思考和收获梳理成型，和大家分享。
前言：由于行业/公司/部门的情况不同，造成了不同产品岗位所需要的能力不同。但抽象一下，所有（产品）岗位提供的都是解决问题的能力。当然问题是五花八门的，但解决问题总有相同的方法/思路。
笼统来说，解决问题总共有三个步骤，且分先后：

分析问题关键
提供解决方案
效果验证
…
循环迭代（分析/解决/验证新的问题）

文章插图
一、分析问题在分析问题上，有个很著名的梗<怎么把大象放进冰箱？>。答案大家都知道<打开冰箱门，把大象放进去，关上冰箱门>，不妨就以这个问题来展开讨论。
1. 细化流程分析问题的首要步骤，毫无疑问是要先细化问题。一个天马行空的问题，不代表问题本身100%是天马行空的，一部坏的电视机可能只是某个零件出了问题，放大象进冰箱我们也可以帮忙开关门。
可惜的是，大部分人的第一反应是对问题本身全盘否认。而一旦否认问题后，问题解决者的价值也就一同被否认了（或者变成了否认提出问题的人的观点），毕竟没人愿意为一个解决不了的问题去投入成本。
回到放大象进冰箱的梗，细化流程之后，问题就清晰很多了。

打开冰箱门——可行（成本低）
把大象放进去——存在难度（成本高）
关上冰箱门——可行（成本低）

【这“2.5”个B端产品方法论，我想分享给你】再对第二步拆分，从某地把大象运到冰箱前，引导它进去。流程拆分得越细，要解决的问题就越清晰，相应的，解决问题的方法也就越清晰。
2. 到底要多细我的答案是，细到能解决的地步，或者尽你所知道的程度就足够了。这分两步细到能解决，问题解决了，继续细没意义，除非再细下去能有替换方案降低成本。
尽自己所能的细，是自我安慰的选择。信息/知识容纳量的大小，在一定程度上等于一个人的智商/能力/价值的水平，不要在超出自己能力范围的东西上对自己要求过高，否则只会给自己带来挫败感。
而尽自己所能的细，要做到这一步也不容易。这要求我们对自己所了解的东西融会贯通，做到举一反三。在工作场景中，这要求我们能够结合项目过往的内容/正在执行的方案/将来可能的规划，给出一个成本最低的答案。
再结合例子来看：

从某地获得大象使用权（当然偷一个也行，不过违法的成本可能是无限大的）
运到冰箱前
引导它进去

如果公司有钱买下一头大象，那么使用权问题就解决了。如果公司刚好是海运行业，那么运输问题就解决了。如果公司里面有员工当过动物园饲养员而你又知道，那么引导的问题就解决了。
但公司能用的资源往往不是充足的，如果能创造出未有的方法（将成本无限大的问题转为成本有限的问题），或者选择更低成本的方法去解决，中间的gap就是问题解决者的价值所在了。
这个方法在现实情况中也是多种多样的，可能是员工的人脉关系，过往工作的知识储备等等。
3. 为什么要做？在ab两点上，都是对问题提供解决方案的思考。
而在实际工作中，特别是产品经理，经常遇到上下游提出的各种需求。这要求产品经理在问题的出发点上进行更多的思考，做不做，为什么要做，做了后收益是否足够可观，而不是直接埋头去想怎么做。
如果仅是为了展示部门能力而把大象放入冰箱，那么将部门的资源拿去买大象（内部消耗）是否值得？但如果是为了向股东/客户展示能力而获得更多合作机会，那么听上去就是一个不错的方案了（不过我在工作上，很多时候都是先思考细化流程，分析发现成本过大，反推目的，梳理责任边界，然后拒需求的hhh）。
在分析问题的方法上，分享一些我实际遇到的例子，解决方案足够旁大的都已经成为我简历上的项目了（我的经历在文末）：