最近有朋友留言给我，提到：“最懂业务的产品经理，才是最重要的。”

这一句话，读起来好像没有错，可站在产品经理的成长与职业发展呢？

其实，懂业务的产品经理，其实要想跳槽，并不轻松。

反而，这类产品经理成了是谁都可以做的产品经理。比如门店运营经理、销售部经理、甚至是HR部门，都可以跨界来做产品经理，因为他们都懂业务，所以他们可以做自己的业务系统。

懂业务，才造成了人人都可以做产品经理的低门槛现象。这样的产品经理并不缺少，而且总是拿不到高薪，不具备竞争力。

所以，当看到别人告诉你，懂业务的产品经理是最重要的，实际上是底层逻辑的错误了。技术、设计、以及营销才是一个职场产品经理的壁垒，

做产品经理要想拿到高薪或者更好的职业发展，我们更应该关注其产品经理的核心竞争能力、以及企业需要的是什么。

1.每一家公司的业务都不一样

做产品经理后，我们会积累公司所在的行业知识，还会积累专业经验，还会熟悉这家公司的商业模式。

而我们提到的业务，其实就是这家公司的商业模式，是基于行业知识下的商业模式。

一家公司基于某个行业的用户痛点或者行业痛点，才催生了自己的产品。产品经理基于痛点场景来设计产品的。

所以当你选错了行业，本身公司所在的行业痛点市场规模小，那么这个产品经理的发展前景并不明朗，同时薪资待遇涨幅也不大，所能够得到的专业知识成长也非常有限。

比如做区块链的产品经理，即使非常懂自家商业模式，但是出去找工作，仍然还是在简历上以“通用”的功能模块、技术架构来作为自己的履历成绩。

如果只是懂业务，而没有技术栈、设计或者营销层面的能力，那么区块链公司的任何人都可以做产品经理，这样的产品经理自然就难以跳槽了

2.在一家公司入职，业务知识重头再来

因为每一家公司的商业模式都不一样，所以每一家公司的业务都不一样。当你要跳槽去新公司，你会发现以前的业务知识只能帮助你提升简历筛选或者是面试通过率，但是真的到新岗位，新公司的业务知识都要重头再来。

因为这家公司的产品、商业模式的都会有不同，为了保证工作成绩，重新学习他的流程、业务、产品知识。

所以懂业务的产品经理，反而是还是重头来。你的技术知识、设计知识和营销这能将会一直跟随你。

3.业务学习真的简单，相比专业知识

如果问学习难度，专业知识的学习是枯燥的。就像让你花时间去学习编程开发一样，所需要的精力、专注度都是需要自我驱动、案例作业完成的。

而业务则是呆的时间久了，就自然就积累了。特别适合“耳听目染”的被动学习。

所以我在给只是懂业务的产品经理新同学说，你只是给自己妥协，没有花时间去研究技术能力、设计能力以及研究营销知识，选择轻松的方向发展。

坚持学习，学习一项技术在身上

产品经理这个职位，总会被人说成：“什么都不懂，就只会瞎指挥”。所以要想拿到高薪的产品经理，一定要有拿得出手的一项技能，这一定是专业技能。

所以，如果你还在做产品经理迷茫，就去提升自己的专业知识。一定会在具体的工作与需求评审上、以及同事协作上，别人就可以认可你的专业度。

而不是只是在哪一亩地里掌握业务知识。

今天的分享就在这里。

产品经理，如何定义一个完整的版本边界

做产品经理期间，我们需要在产品研发任务里界定一个版本，作为当前产品研发工作的节点。比如1.0、2.0、3.0各个版本的本质区别与边界是什么？

对于1.0版本来说，一定是完成基础又是核心的场景，满足了用户刚性需求。

在工作的时候，越是高级的产品经理在后期越要学会自己来定义版本进行向上汇报，而初级的产品经理只需要干活就行了。

很多中小团队，都没有定义好一个最终版本。容易多花时间在产品研发上，错过了最佳运营时间，或者就把产品做复杂了。

不少产品经理，可能会贪心自己的价值，在需求设计上过于复杂，将一个功能变成了3个甚至是4个功能。

所以掌握定义一个完整版本的技巧，显然是有助于提升自己的工作价值。那么为什么定义版本难呢？有3个原因

1.需求总是随着时间在变化

在一个ideal过程中，需求只有在最终产品上线、或者到用户手里了才会发现有调整。

一个需求对应的项目研发任务，产品研发上线至少是3个月以后甚至是一年。这期间企业也在运营，业务产生变化，就会有新的需求产生。

在早期的设计方案里，可能就没有考虑到现在的业务场景。

2.老板今天和明天各一个想法

还有一个常见的原因是：老板自己都没有想清楚要做什么！

在刚开始的版本里处于探索期，这个时候就一直在测试各种新功能，只知道要做一个APP、或者网站，但是具体里面有什么核心的功能，老板自己也没有想清楚。

3.热点技术和风口

除了企业内部的需求变化，还有一个完整的版本计划，也会受到热点技术、风口影响。

比如如今大火的大语言模型CHATGPT，那么即将上线的产品就会在期间考虑是否增加大预言能力，提供与时俱进的AI能力。

通过这类新颖的底层技术与热点，吸引更多用户。

4.如何定义一个完整版本

我在带团队做0到1做产品时候，也常常出现早期产品设计方案和后面的上线版本是有较大区别的情况。

因为只有真的在落地时候才会知道具体原先设计的方案有哪些具体的错误，只是越是高阶有经验的产品经理，这种“失真度”会越来越低，但不会趋近于0。

简单来说就是上线和预期的效果一致的成功率会越来越高，我分享一些自己个人定义版本的经验，可以下面5个维度作为边界

1.数据类型

比如PMTalk产品经理社区早期就是提供图文和问答功能，在1.0版本里不会提供AI、视频等数据格式。围绕这个数据类型作为边界

2.明确用户对象与角色

产品是提供给用户使用的，而你的第一版本主要是解决什么样的对象用户或什么角色，用户如果有分层，那就主要解决哪一层用户。

比如在蓝泡排版里面我们主要是解决公众号和小红书创作者的样式排版问题，至于内容创作、以及其他平台不是在当前版本计划里。

3.详细的线框图产品设计方案

让团队都定义清楚一个版本，线框图的产品设计方案是不可少的。一个具体的产品设计方案，并且通过了开发、设计、产品团队需求评审，这样的版本规划是非常具体明确的，大家可以清楚的知道工作量、技术难度。

以线框图的产品设计方案，作为这个版本的最终产物。而在执行过程中如果遇到技术不能实现的，就进行删减，如果要变动为新的产品设计方案，就放在下个版本完成，注意当前版本就只少不多。

并且梳理出如下的优化项需求池，对于需求进行版本管理

4.提升速度与功能性能

在一个版本里，我们总是会想在这个版本里，顺便提升产品的访问速度、或者提升页面的反馈效率，因为我们总是难以在需求规划阶段知道实际上的操作效率。但大部分的速度提升与性能，都是和技术架构方案有关，需要通过技术重构才能完成，所以建议单独花功夫，把这类版本放在后面了。

5.全局交互的更新

还有在版本里，我们在早期没有把全局的交互定义清楚，就导致一个产品里的不同独立功能交互体验有区别，而要进行全局替换可以当做一个版本单独来做，尽量避免一个版本做一点。

全局交互应该独立作为一个版本来解决，包括搜索、导航栏、页面提示、弹窗等。

通过以上5个维度，我们可以来作为版本的边界，如果你正在纠结版本完整度，可以参考这篇文章。

今天的分享就到这里。