好久没有肆意挥洒写一篇文章了。上一次这么痛快写文，还得追溯到17年。今天看了一眼后台数据，注册用户量已经跃升到了1348735人。内心激动之下，觉得还是很有必要稍作整理。坦白说，我个人的产品经验还不是很丰富。自去年4月从51job离职到现在，独立负责整个产品项目，也仅有1年多的时间。行业内，往往把从业1年的产品称之为菜鸟。菜鸟赛季的我，其实还是蛮幸运的。没有老板和总监的坚定信任，我是万万不可能以零经验来独自负责一款APP从0到1的工作。打造一款百万级用户的产品，曾经是我刚入行时的一个目标。现在，历经10个月的努力（18年7月14号上线），我们站在了这一量级节点。虽然这个速度并不是很快，但是零广告投入能够做到这一切，我很开心。
【洞察用户】
如果让我来面试一位产品，我可能不会问他，“北京市的加油站有多少”、“怎么把大象运到楼顶”这类问题。我的第一个问题，肯定是：你怎么理解你要服务的用户？很多互联网人喜欢炫技，丢出一大篇的用户研究报告，然后把Persona告诉面试官。这种没有自我提炼思考，仅仅展示数据的用研，并不是好的用研。无法把数据背后的洞察贯穿到产品设计中去。一句话来说，没有真正理解用户。举个例子，假如我们了解到，蓝领用户的画像是，平均7个月跳槽一次，平均月薪2000-4000。看到这个数据，你怎么理解蓝领用户和白领用户在求职上的差异呢？很多人估计会不加思索说，有什么差异，都是投简历呗。如果这样想就有误了。通过刚刚提供的用户画像，我们知道，蓝领的跳槽非常频繁，忠诚度低，薪资水准不高。这种特质会带来什么呢？试想一下，一个人一年要跳槽两次乃至多次，薪资要求不高。那么他在低薪要求提供的跨职能工作的可行性下，是不是有更大可能从事多种类型的工作呢。比如第1份工作是服务员、第2份是超市营业员、第3份是快递员、第4份....蓝领群体不像白领，一份产品工作，从助理到总监，可能贯穿整个职场。蓝领用户的广阔求职弹性带来的产品启发是，我们在给他们设计职位推荐引擎时，首要追求不是职位匹配的精准度，而是求职多样性。所以去年我们上线了一个关联职位功能，用户在找服务员时，我们会给他推荐营业员、店员、收银员等多职能工作。从这个例子我们可以看出，产品是做什么？产品是提供需求的解决方案。深刻理解需求，深刻洞察用户，不停留在数据表面，是非常非常重要的。一个工作经验少、文档写作弱的产品，通过后期学习，可以慢慢变好。但是如果不理解用户，即使原型画得再溜，用户研究报告写得再华丽，也是无济于事。不同行业的产品，其实差异极大。这种差距不是因为技能库的经验无法复用，而是对行业、对用户的理解难以移植。好的产品经理，真的是一将难求。以前经常有人问我说，想做产品但是不会画高保真交互原型怎么办？我的看法是，放弃那些花里胡哨的东西，除非你是想做UX而不是产品。找一个感兴趣的行业，把行业竞品的应用商店评论完整撸一遍。我相信面试的时候，会更有话题聊的。
【决策判断】
说到底，产品是一份从事创造的工作。虽然我们在做需求的时候，往往需要做足功课，比如数据分析、用户调研，大公司还会使用A/B测试工具，来辅助产品做出决策。可是即使我们做了所有这一切，也不会有人告诉产品，功能上线后，效果一定很好。决策判断力对于产品来说，实在太重要了。有没有什么办法可以提升做需求可靠性呢？我个人比较喜欢的一个思想工具是张一鸣曾经在微博上提到的，一共4个问题：
1、做这个功能有什么确切价值？
一款产品会有很多的数据指标。产品经理在进行需求决策时，如果盯着一些细枝末节的数据，那么似乎每个功能都很有价值。所以我们在判断某个功能是否有确切价值时，要基于两点。①是否与核心指标紧密关联；②功能可能覆盖多少用户？
产品无论怎么调整，核心指标往往就那几个。关注核心数据，就可以避免舍本逐末。所有的版本迭代，都是围绕核心指标而走的。增长黑客这本书，好像把这个指标称之为北极星指标，我觉得是很有道理的。
功能覆盖的用户量，我觉得不需要太多解释了。吭哧吭哧做了半个月上线，结果只有少数用户感兴趣，我想没有哪个团队能够接受这样的局面。
2、这个功能一定重要/有什么问题吗？
孙子兵法通篇都在讲一件事：不可胜者在己，可胜者在敌。先胜后战，赢了再打。借鉴到产品领域，就是产品经理时刻要在心里想着，我这功能是怎么死的？先把缺点不足处想清楚，再去考虑它的价值。
这一步的好处是巨大的，它会帮助产品经理刹车，让我们做功能时变得更克制。克制是PM们的必修课。如果做不到，就会胡乱加功能，导致产品非常冗余，体验极差。我们总监经常挂在嘴里的一句话是，我不需要你一年做多少功能，但我希望每个功能都很好。
我个人的体会是，有时候相比做需求，砍需求的能力往往更重要。可做可不做的时候，就不要做。
3、你是如何确信这个功能价值的？
任何功能都不要主观臆断。要有依据。我现在无论是跟开发讲需求还是写需求用例，都会把需求背景讲的非常清楚。有时候往往会有几百字的着笔。为什么这么在乎？一方面是避免拍脑袋，方便后续跟踪需求时，可以清晰知道当时做出决策的依据。另一方面，则是让开发清楚知道背后的事实，让沟通理解更顺畅。
4、有更好的解决办法吗？
这一步其实是最难的。它需要你跳出当前现状，打开视野，避免禀赋效应。不是有句话么，设计不是选择A或B，而是寻找更优的第三方案。回答好这个问题，要求产品有很强的系统思考能力，目前我也在积极修炼。
【沟通与抗压】
产品经理的日常，往往是这样几幅画面：
画面1：老板把你喊到办公室，给你一些指示，大部分时候，会让人心里一凉：咦，这个功能上线后确信不会被用户打死？于是你得和他耐心沟通，有时候，还得苦苦哀求。
画面2：设计师一条微信消息把你从改变世界的美梦中敲醒，并发了一个50米大刀的动图让你细细体会。于是你屁颠屁颠跑过去跟她说，这个活动页配色不够活泼，显得过于老气。完了还得多夸奖一句，你这头发扎得真可爱。
画面3：程序员与产品经理的故事，简直就是一部互联网血泪史。有时候我细细想想，如果一个人要我按照他的意思走路并且丝毫不能出错，有时甚至让我换一条路。我想，旁边有多大石头就拣多大。把走路换成做产品，道理是一致的。在公司的部门、职级划分中，产品与技术往往不是一个部门，职级也往往一致。这种时候，你如何调动技术？更何况产品经理改需求也是职业通病，难以避免。所以，我学到的一点是，工作要交给他们，委屈交给自己。不要和技术发生争吵，卡耐基《人性的弱点》告诉我们，辩论也许会让你一时痛快，却解决不了问题。
一款产品能够上线，往往是多方力量的综合产物。作为这款产品的主要推动者，要保持和各方的充分交流，这样可以显著避免冲突。有时候，自己失误了，大大方方承认，谁让自己没做好呢？被老板或者同事责难了也不要紧，一个人有多大成就，就得承受多少委屈。
写到这里的时候，我发现文章还有很多点还未提到。然而过长的篇幅实在影响阅读体验，所以到此落笔吧。写文章的过程，是梳理思路的好时机。过去两年，账号没有更新过什么文章。今年努力一点，多写写，就这样吧。
网友评论