惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
Engineering at Meta
Engineering at Meta
月光博客
月光博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Tailwind CSS Blog
博客园 - Franky
The GitHub Blog
The GitHub Blog
大猫的无限游戏
大猫的无限游戏
The Cloudflare Blog
B
Blog RSS Feed
云风的 BLOG
云风的 BLOG
小众软件
小众软件
罗磊的独立博客
Microsoft Azure Blog
Microsoft Azure Blog
I
InfoQ
美团技术团队
H
Hackread – Cybersecurity News, Data Breaches, AI and More
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
C
Check Point Blog
WordPress大学
WordPress大学
博客园 - 【当耐特】
博客园 - 司徒正美
D
Docker

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
背景篇 | 从0到1打造一个小程序(一)
HappyCame · 2023-06-22 · via 人人都是产品经理

小程序以其轻便、操作简单等特点受到了众多商家尤其是中小企业的青睐,并且迅速壮大,成为品牌运营的重要渠道之一。本文作者自己设计了一个小程序,并复盘了过程中的经验和错误,与你分享。

2017年微信小程序上线至今已经过去6年了,我在今年刚完成了自己的第一个小程序作品,只能用“说来惭愧”形容。作为一个toB类型的产品,做出一个toC的产品,虽然很简单但是整个过程也是一波三折,到最终上线我还是很开心的,毕竟体验了一把toC产品的日常工作。

下面就对整个过程做一个简单的总结,各位同行看后,欢迎留言交流或是提出各种宝贵意见。

一、需求来源

大家应该都看过腾讯产品能力素质模型,我相信每一个第一次看到能力素质组成说明和测评结果雷达图的人都有一个想法,就是我也想测一测,看看自己的水平如何,如果是在腾讯属于什么职级。

于是我就找来完整版的能力素质说明,发现这个模型覆盖的范围较大,有些市场/渠道相关的能力项是我的行业不需要,所以跟我实际情况的适配性较低,继而对测评结果的期待值一下子降低了很多。

但是这个种子已经在心中种了下来,于是我开始寻找一个能与自己适配性较高的产品能力项组成进行测评。整个过程主要经过以下三步,信息获取——资料整理与归类——结果输出。

二、信息获取

寻找范围大致有以下四个渠道:

  1. 行业公认的大咖级人物的分享或著作,比如余军的《产品方法论》,苏杰的《人人都是产品经理》,杨堃的《决胜B端》,琳达·哥乔斯的《产品经理手册》,王慧文的《清华产品管理课》等。
  2. 可以找到的各个公司内部的产品职级晋升制度说明,这个大家都知道的,一个产品经理应该具备什么能力各个公司会根据自己的需要进行总结和考察,比较经典的就是腾讯和百度的。
  3. 产品经理相关技能培训机构的课程,可以说这些机构和课程设计上都是对应的产品经理需要具备的能力,尤其在产品专业能力方面非常全面。
  4. 还有就是各位产品同学们的个人感悟,光咱们人人都是产品经理平台上就有许多类似的文章,从个人实际工作经验角度出发进行分析和总结,我看了很多这种文章,看完之后发现大家说的都很有道理。

就这样一大圈下来,我发现由于整体比较散,在加上产品经理也分好多种,要求也都有区别。如果汇总起来那能力项肯定是多如牛毛啊,如下图所示没个100也的有50个了,按照这个去测评的话,那直接劝退了。

三、信息归整

前期资料收集完毕,接下来就是整理和归纳的过程,同时也是一个从多到少的过程。

第一步先进行分类,我已腾讯产品模型的分类为基础进行二次加工。像学习能力、执行能力、沟通能力这些,属于职场通用的基础能力

然后把ToB的产品经理的能力提取出来作为专业能力,例如需求管理、产品设计等。

然后把心里素质相关内容放到一起作为关键素质,性格决定命运嘛,所以心里素质也很关键。

然后是把运营能力独立出来,因为这是让一个产品真正产生价值主要方面,再根据运营对象的不同进行罗列。因为产品经理是一个需要什么都了解的职业,所以把需要了解的各方面的知识归类到一起作为知识储备项。最后就是一些晋阶的素质能力项,主要包括团队管理,领导力,战略能力等。

如下图所示:

第二步是精简,上图可以作为一个全面工作方法理论框架为日常工作进行指导,比如近期学到了什么内容,遇到什么坑,复盘的经验都可以一一记录到对应的分类中(这部分可以另开一篇文章来讲,结构化学习和记忆)。

但是作为一个可以用于测评的能力组成框架来说,需要具有一定程度的精炼度。比如审美能力、个人品味这种重要程度较低,可以在测评版中省略。像沟通能力、谈判专家、煽动力这些可以合并到一起,统称为沟通能力。精简原则有两个,一是尽量满足我当前的toB的产品经理相关内容,二是把一些重要性较低的能力项去掉或者将相近的能力项进行合并,取其通用性和重要性较高。

而且精简的过程不是一次就能完成的,也是一个多次循环的过程,精简一轮之后再继续尝试,如此循环,于是最后就整理出了一个适用我自己的个人版能力素质组成——产品能力组成自定义版。

有了能力素质组成,开始进行下一步的工作,到这里我发现每走一步就很难,而且是越往下走就越难,因为下一步的工作是针对每一个能力项拆解能力级别,并给与大致描述。这感觉像是在做一个权威性的总结工作。

这个过程可谓极度烧脑,分级标准是什么,分几级合理,如何分出递进感。光是一个学习能力就已经将我的全部精力耗尽,大家可以去看我的上一篇文章,仅是其中一个能力项就被我做了进一步的拆解,拆解后再对每一个子项分级描述。如果所有能力项都这样搞,那工程量真的是太大了。

总结来说,主要难点有2个:

  1. 一是工作量大,众多能力项都要做分级工作,如果像我之前写的对其中一个能力项再做拆解项,这个工作量没个一年半载的搞不定。
  2. 二是分级标准问题,这是更难的点,因为好多能力的高级别我自己不具备,谈何建立标准。

解决方案:

  1. 做任何事情也不是一步到位的,可以先思考一版粗颗粒度的分级描述,即直接对各个能力项做分级描述,先能用起来,然后再根据后续使用情况做进一步的拆解,细化的工作后续可以慢慢做。
  2. 站在巨人的肩膀上,结合搜集到相关资料,像腾讯、百度等各个公司的产品序列职级体系说明,都是集合了公司集体智慧的产物,然后再对其进行二次加工。这部分主要工作是再细化一轮,因为公司版主要用于级别的评定,像是一条长长的大路上几个关键节点的坐标,而我自己想做的是,在这一条长路上设置更多的坐标,让坐标之间的距离更近。这样就更具有实用价值和指导意义。

经过一段时间的输入之后,我的初版测评可以投入使用了。

分级描述:

四、结果输出

研究了这么久,自己的能力值情况终于完成了量化的工作,并以一个形象的雷达图展示出来,看着自己雷达图,主要感受有三点:

  1. 无比的欣慰,算是自己劳动的果实。
  2. 就测评结果本身而言,一个做了5年以上的产品人的测评结果居然是这样(这么大的一个圆我就占了这么小的面积),我就很惭愧了。
  3. 拥有耻辱心的我,下意识的反应是如何提升的问题。此时我突然意识到,原来这一切不是结束,只是开始,或者说整个工作的下一步是什么自然而然的出现,大家猜是什么呢?其实很简单,就是距离达成下一个级别,需要做什么,一个行动指导或是提升路径?

五、场景挖掘

答案是一目了然,但是后续的问题把我又难住了,难道我要把各个级别间的达成路径也弄出来。我要是知道做什么学习什么就能提升到下一级,我还至于测评结果是那个鬼样子?感觉我这一步一步的走上了一条不归之路。之前的工作虽然大一些,我看看书查查资料还是可以搞的,这个达成路径可不一样,几乎没有可以参考的点,我该如何下手呢?

经过一番思考之后,我又顺手掏出之前的经典理论,【简化论】(其实是一种偷懒的技巧),我先不整别的,就把我目前的测评结果,如何达到下一个级别,自己给自己提建议呗,先解决眼前的问题,我又不需要给别人看给别人用。即使不合理也没关系,后续实践的过程也可以指导并修正答案的。以下就是我给自己提的建议,此处也欢迎大家也来尝试一下这个方法。

于是在按照自我建议执行一段时间之后,我又给自己做了测评来验证我是否有成长或升级。

从图示结果看,有没有成长没法直观的看出来,我就把之前的测评结果放了进来,于是就有了这么一张图,这次再看到这张图,虽然进步不明显,但是就觉得很开心了,有付出有结果有成长。不枉我废了这么多力气做这个事情。

六、最后

事情到了这里,就基本来到了尾声。由于篇幅有限,整个过程中还有些细节我没有提及,比如升级路径那部分其实也做了其他的思考,包括如何建立长期监控、建立积分制等。以上就是我实际在做的事情,也是后续想线上化的来源。

背景就说到这里,不知各位读者意下如何,欢迎留言交流想法!

本文由@HappyCame 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。