查看: 1026|回复: 146

独立负责一款产品时，该如何入手

12 主题	0 好友	38 积分

网站编辑

Rank: 8 Rank: 8

发消息

电梯直达

楼主

发表于 2017-1-15 19:30:51 |只看该作者 |倒序浏览

　　产品经理即将或者正在进入“术业化”。

　　QQ截图20161228164649.png

　　提问

　　1.最近开始独立负责一款产品，不知道该从何入手。

　　2.目前正在负责一款产品，事情太多，又感觉没有太大帮助，对产品未来没有预期。

　　回答

　　这个问题很具备代表性，产品经理这个行业目前任然是一个非标行业，一方面有许多朋友“突然”成为某产品负责人，即便曾经从未接触过产品。也有很多BAT的产品经理换了一个环境，开始带着团队从0到1，然后各种茫然。

　　基本上，这个问题可以算产品经理这条路上，灾难集中爆发的问题。谈不上标准答案，仅讲述我个人的经历以及我自身的主张。

　　产品负责人与产品经理并不是一个完全等同的角度。

　　对于产品经理而言，核心技能在于“如何做”、“怎么做”，设计的本质目的是更好的达到某几项目标，比如跳转率，转化率，付费率等。

　　而对于产品负责人而言，则更多的扮演一个舵手的角色，决定了产品未来的走向，决定了产品应该要“做什么”（暂不考虑上层干扰）。

　　我想先告诉大家两个误区：

　　误区1：

　　对于产品负责人而言，切勿过多的思考交互。

　　相信我，目前移动互联网的环境，人们不会为了交互买单，除非你做的是某小众产品，比如“交互发烧友”。市面上从未听闻某产品交互出色，交互成功的，实际上大部分产品的交互都极其普通，尤其是成熟产品，更有意思的是往往在台面上讲交互的，便是这样一些普通交互产品的交互设计师。交互可以是产品的加分项，可以提高用户的使用体验，但却不是一个决定性因素，甚至在产品初期，可以忽略不计的一个因素。

　　误区2：

　　对于产品负责人而言，切勿过多的思考玩法。

　　没有任何一个产品，能够凭借玩法长期持续下去的，“玩法”可以是产品的亮点，也可以是产品的突破口，但却不应该是产品负责人应该主要思考的方向。

　　什么叫玩法？

　　相对独立的，具有极高娱乐性的功能，比如支付宝16年年初搞得“集字”活动，又或者是微信近期推出的对照片的编辑功能。我们所看到的玩法，很多时候是以娱乐用户，增加用户粘性，增加用户活跃度，甚至增加新增为目的而被设计出来的。难以想象，一款“充满玩法”的产品，能够生存10年，5年，或者更短的时间。

　　以上两点，仅针对“产品负责人”而言，对于“产品经理”来讲，我说的，都是错的，请勿必死掐“交互”，死磕“玩法”。

　　核心基点

　　大部分的时候，企业会分配一个任务给产品经理，并将其设置为该任务的产品负责人，于是产品负责人就这样“被”诞生了。这些任务各种千奇百怪，比如我们要抓住这部分群体，我们要试验变现的方法，我们要怎么样。作为产品负责人而言，要做的第一件事，是去找到这款产品的核心基点。

　　比如，我们来做一款产品经理的软件吧，为所有产品经理服务。在这样一个任务里，核心基点便是，什么样的服务，能够是所有产品经理都需要的。这直接影响了我们要做什么样的产品，是做直播，还是做资讯，又或者是做工具。一旦确定了核心基点，大家探讨通过了，那产品价值观便已经形成了雏形。

　　核心基点决定了我们做什么样的产品，也决定了该产品短期乃至中期要遵循的产品价值观。

　　由于写文的原因，最近三个月，发现许多小团队计划在做一些服务于产品经理的项目，这里面便包括咨询类，社区类，工具类。小团队还处在发展阶段，这里就不提及了，我们来看看平常我们使用的产品：

　　Axure:定义为工具，为产品经理绘制原型提供服务，同类型的还包括sketch，墨刀等

　　人人都是产品经理:社区为主，为产品经理提供内容分享，互动的交流社区

　　社区和工具是最常见的一种产品性质。服务于相同的目标对象，选择不同的核心基点就能催生出不同的产品性质。

　　作为产品负责人而言，去定义你所负责的产品属于何种性质，是最首要考虑的问题。

　　MVP

　　当决定了产品的核心基点，我们就要考虑快速的将产品“做出来”。我们站在产品负责人的角色，再来看看这个应用甚广的MVP概念。

　　核心基点，很多时候是可以被一句话称呼出来的，往往也可以作为一款产品的slogan，比如产品爱好者学习交流平台，有态度的新闻门户，复杂世界里一个就够了。

　　反复念叨这句话吧，这会是一个挺好用的“土方法”。

　　我比较忌讳在现在一款产品开发半年，上线1.0，除非有特殊性质，比如业务，资源乃至设备关联。当然2B类产品不受这个条件限制。

　　压缩产品1.0开发时间，最有效的方法是“压缩功能”。用MVP的概念去理解，就是将产品控制在“最小”且“可行”的范围进行生产并上线试验。

　　“1”是最小的非0自然数，记忆中，这似乎是小学课本的知识点，我们这里借用一下。

　　其实，产品里很多时候都可以用“数学”的方式来解析。我们看看这两个观念结合起来会发生什么化学反应。

　　“最小”且“可行”：只有一个核心功能/只有一个主要功能。

　　你的产品，在1.0阶段，只有一个核心功能或者主要功能吗？

　　其实我现在在帮朋友做一些产品分析时，特别是1.0阶段，有个很简单的判断方法：这个产品有几个一级页面，三个还是四个。如果是四个，我就会直接和他说，1.0做重了，浪费了时间，也浪费了产品空间。

　　值得庆幸的在于，发现越来越多的产品，在迭代了很多版本之后，还是只有三个一级页面。

　　PS：曾经用一周的时间，将一款产品的1.0投入到市场使用，我记得，我把退出账号的功能都砍掉了。

　　坦白讲，1.0的APP不需要“退出”，也不需要“设置”。

　　轻装上阵，这是我的建议。

　　挑战产品生命力

　　作为产品负责人，不建议去思考交互，去思考玩法，是因为你要去挑战一款产品的生命力。

　　所谓的产品生命力，是指产品本身的脉搏，而非用户的的生命周期。简单来讲，我们去看一款产品是否健康，在于看产品的脉搏是否清晰，是否有明显的逐渐成长的过程。

　　产品负责人是去开阔未来的一个角色，我们看的不是过去，不是现在，而是去揣测未来。

　　运作正常的情况下，产品必然会越迭代越重，功能越来越多。这会导致使用成本越来越高，可迭代的空间越来越小。

　　当五个一级页面全部都使用的时候，基本就是产品负荷过重的时刻。我们的功能必然会越做越多，但如何驾驭这些功能，在无序当中建立有序，是对我们的挑战。做产品并不是在做数据，而是在构造一个小型的生态空间。基本上产品进入到3.0阶段，产品负责人就必须开始思考产品生命力的问题。

　　哪些地方可以重点挖掘，但却不会占用过多的app空间。

　　哪些地方是可以合并在一起的。

　　哪些地方能开辟出内容流，提供更多的空间可使用。

　　这个时候的产品负责人，俨然是产品结构设计师的角色。

　　文末，安利一个个人观点。

　　如果产品经理以数据论成败，我十分好奇一些做底层设计的产品经理，做空间设计的产品经理如何衡量他们的价值。产品经理即将或者正在进入“术业化”。

收藏0