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

推荐订阅源

Google DeepMind News
Google DeepMind News
S
Security Affairs
阮一峰的网络日志
阮一峰的网络日志
L
LangChain Blog
Microsoft Azure Blog
Microsoft Azure Blog
雷峰网
雷峰网
Recent Announcements
Recent Announcements
WordPress大学
WordPress大学
The GitHub Blog
The GitHub Blog
博客园_首页
The Cloudflare Blog
M
MIT News - Artificial intelligence
博客园 - 【当耐特】
MyScale Blog
MyScale Blog
S
SegmentFault 最新的问题
P
Proofpoint News Feed
Y
Y Combinator Blog
Jina AI
Jina AI
博客园 - 聂微东
A
About on SuperTechFans
Blog — PlanetScale
Blog — PlanetScale
博客园 - 司徒正美
G
Google Developers Blog
云风的 BLOG
云风的 BLOG
F
Full Disclosure
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Microsoft Security Blog
Microsoft Security Blog
爱范儿
爱范儿
T
Tailwind CSS Blog
J
Java Code Geeks
Vercel News
Vercel News
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Stack Overflow Blog
Stack Overflow Blog
罗磊的独立博客
小众软件
小众软件
酷 壳 – CoolShell
酷 壳 – CoolShell
T
The Blog of Author Tim Ferriss
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
博客园 - 三生石上(FineUI控件)
W
WeLiveSecurity
PCI Perspectives
PCI Perspectives
Attack and Defense Labs
Attack and Defense Labs
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
宝玉的分享
宝玉的分享
IT之家
IT之家
Hacker News: Ask HN
Hacker News: Ask HN
The Register - Security
The Register - Security
T
The Exploit Database - CXSecurity.com
T
Threat Research - Cisco Blogs

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
关于SaaS业务增长的思考【下】
运营的不惑屋 · 2024-10-11 · via 人人都是产品经理

在SaaS业务领域,增长是一个涉及多个层面的复杂过程,它不仅关乎产品和市场策略,还与销售、服务、以及整个组织的运营能力紧密相关。本文深入探讨了SaaS业务增长的多个关键环节,从讲述一个引人入胜的故事开始,到创造“遇见”的机会,再到最短时间内描述最完整的故事,每一步都至关重要。

在我们拥有了一个故事以后,我们就需要进入到第二个关键环节:让更多的人听到这个故事,

这个环节有三个步骤:媒体-内容-节奏

过去我们常说,应该基于内容去选择媒体,应该打造以内容为主的传播通路,但是在今天,我认为这个观点有待商榷。今天的媒体形式,已经明确的形成了信息茧房的状态,搜索引擎、官媒、微博、抖音、小红书、信息聚合软件、公众号等等,不同的媒体形态形成了各自的用户群体,以及适应该用户群体的信息内容,所以,适应这样的变化,我们首先要确认的就是媒体形式。

从用户的覆盖和流量来看,现在最重要的三个媒体形式,就是以私域传播和覆盖为主的公众号、以信息透传和广域检索的短视频、以针对性和特定需求的搜索引擎。针对这三个核心的传播形态,我们需要基于各自不同的媒体特性设计内容。

在媒体和内容确认后,我们需要考虑节奏的问题。就如同发动一场攻坚战,各种物资到位以后,节奏很重要,火力覆盖一定要在我方队伍还没冲上去之前,步坦协同一定要在火力覆盖之后。

大的节奏把握,一般情况下是官网+SEO/SEM>短视频>活动事件营销>自媒体公众号矩阵。

通过让大家听到故事而降低陌生感之后,我们就要进入第三个关键环节:创造“遇见”的机会。

闻名不如见面,我们听得再多,也不如能够遇见真人来的更为妥帖,所以,创造“遇见”的机会就显得格外重要,一般情况下,创造遇见的机会有两种方式:

1、通过足够多的销售人员去主动触达客户

关于这个方式,不用赘述,已经有很多人给出了满分解答。

马克·罗贝齐将他的SaaS业务定义为“每次都找拥有相似成功特质的销售人员”、“以相同的方式培养每个销售人员”、“让销售人员对相同的销售流程负责”、“每月为销售人员提供相同质量和数量的销售线索”,他认为通过这四个要素,可以达成“可衡量、可预测的收入增长”。

硅谷蓝图中,对于SaaS增长的解读是:建立一个能够平衡技巧、流程和工具之间关系的,并经过精心设计的、以客户为中心的销售组织。它需要借助流程来实现规模化扩张,而不是依靠个人,他还要能与网络融合,让销售组织人员能够使用最新网络和增效工具来达成销售目标。

2、通过关键合作伙伴和资源网络被动触达客户

关于这个方式,是我认为现阶段被忽略或者说因为疫情导致的“中断的3年”所带来的缺失。

我们需要再能够聚合更多潜在客户的场合下,与客户进行沟通和交流,包括但不限于行业协会、展会、论坛、行业沙龙、自媒体矩阵等等,这是非常重要的,因为组织市场的客户心智,并不如同消费者心智一样,可以通过以1、2个简单因素直接撬动,他们需要更多的信息,更多的接触以及信任。

当我们通过营销方式和渠道方式的结合,终于创造了这个“遇见”的机会时,我们需要进入第四个关键环节:最短时间描述最完整故事

完整的故事是最重要的,因为我们无法确保我们的核心价值点恰恰就是客户这个时间点最关注的痛点,所以在“遇见”的时候,尽可能的呈现完整性就变的很重要了。

这里面有很多的细节,我们不在此赘述,不过有一个公式可以先抽象一下:

一个公众号+一个视频号+一份PDF可下载文档+一个企业微信

第五个关键环节:创造“付款买单”的场景

我们在前面四个环节做的所有努力,都是为了“付款买单”这个场景的发生,但是付款买单这个场景包括了很多的细节,而不仅仅是我们在超市买东西最后结账的简单动作:

  • 销售链路:从第一次遇见客户开始的全销售链路,一般包括了L2C的完整链路,在销售链路中经常使用的工具主要是销售漏斗管理,以及与之配套的一系列软件工具;
  • 签约场景:签约是需要管理整个签约场景的,包括是否是有制式合同,或者需要有签约仪式,或者需要往复盖章,还是直接客户在线付款电子合同,这些签约场景必须匹配目标客户的操作习惯;
  • 议价场景:议价的前提是定价,基于商业化定价我们可以针对不同的用户群体给予不同的议价权限,包括总采购金额、分批付款的批次、流水抽成的方式等等;
  • 促销场景:促销场景的前提是在不破坏定价模型的基础上,给予少量的优惠用于促进或提升客户在当期的付款意愿;
  • 付款场景:付款场景包括了付款的方式,公对公转账、私对公转账、线上付款等等,付款场景需要基于客户的实际作业场景进行设计,以客户付款动作最少最便利为核心目标;
  • 交付场景:交付场景包括了事前承诺、交付物和事后体感三部分,特别是在SaaS软件的交付上,由于仅涉及权限开通的动作,客户在付款前和付款后并没有明确的体感,所以在开通当时或者开通后,是需要一个现场回访的动作来提升交付的质感;

2、来自于行业化适配后,带来的行业市占率、品牌声誉、知识沉淀形成的市场拓客效率上增长

与组织市场的合作,核心是建立以价值增值为目的的合作关系,这才是保障合作方能够长久合作的基本盘,在我们完成上一个阶段的工作后,基本上我们具有了一定的客户基数,有了相对完成和成熟的运营体系,从市场到成交的链路也相对完整,就必须开始完成行业化适配的课题了。

行业化适配,意味着我们能够在标准的软件上,基于某个特定行业或者领域的需求,针对性的提供与之匹配和对应的能力及服务,以帮助和支持合作伙伴实现价值增值。

通用性的行业化适配有三种做法:

  1. 研发单独的行业化产品;
  2. 利用已有能力包装行业化产品;
  3. 在产品不变的前提下,推出行业化的服务产品;

行业化适配的目标是不断提升在某个特定行业或领域的市占率,以此建立护城河与品牌声誉,并且通过一个行业领域的知识沉淀形成跨领域的洞察,为我们进行市场拓客奠定更稳健的“系统性”基础。

3、来自于交付及服务带来的留存率、客户裂变产生的增长

这也是SaaS业务与传统软件业务相比一个非常重要的差异性,SaaS业务取得新客户的比率只要超过客户流失率,业务规模就会持续扩大,因此长期保持客户留存就可以获得稳定的增长基础。而保持客户留存是一个长期的时间轴,这个时间轴的起点,是交付环节,这个时间轴的长度维持,靠服务。

但是当下的实际情况是受到定价、支付意愿和软件便捷性的影响,交付的环节越来越简单,付款开通账号,交付环节即宣告结束,这在2C的场景中是没问题的,但是2B的场景中却总是因为事前承诺或跨部门协同而产生冲突和误解。

服务最大的价值是解决合作期间可能出现的所有问题,并让整个时间轴的周期可以尽可能的长一些。这里有两个问题使我们需要回答的:

  1. 我们能不能够帮助每一个客户成功?【不能】
  2. 我们能不能让每一个客户感觉在使用过程中的舒适?【能】

通过交付和服务,我们确保了客户在使用的过程中所具有的舒适度,并且尽可能的让那些成功的客户与我们建立了更密切的合作关系,这就会带来SaaS业务的客户增长引擎中有一个简明的规则:新顾客是由以往顾客的行动带来的。

4、基于构建生态体系后形成的不可替代性带来的增长;

SaaS业务的终极目标就是构建一套生态体系,通过商业化管理理念、标准化作业流程、软硬件开放接口的共同努力,形成围绕组织市场客户的生态体系,这个体系内,每一个组织市场客户在不同的阶段和不同的场景中,都可以基于生态环境的不同选择不同的软件组合,来解决当下需要解决的问题。而开放性的接口和数据底层,则可以形成不同时间周期的沉淀,这些沉淀最终会变为数据资产和经验知识,为企业未来的发展奠定基础。

备注:增长背后的组织能力支撑

SaaS业务的底层模型包括是两个场景的组合:软件及解决方案+B2B,因此,从组织模型的设计上他需要符合软件及解决方案公司“强产品、重研发”的设定,也需要符合B2B模式下的增长逻辑,既“任何单点改善带来的增长都会被系统性的不匹配所抵消,但系统性改善能够带来1+1大于2的最终结果”

SaaS新客增长受到“产品*市场*销售”三个系统的效率影响,而每个系统内部又存在自己的闭环逻辑,这三个系统的运营效率相乘,是整个业务增长的效率,而每个系统内部的效率相乘,则是系统自身的运营效率。

  • 产品:需求洞察—创意产生—产品原型—技术实现—市场验证—迭代优化
  • 市场:品牌塑造—品牌透传—细分营销—认知建立—线索获取
  • 销售:潜客触达—意向转化—订单签约—实施交付—口碑传播—潜客触达

正因为如此,任何一个点转突破都无法形成有销售竞争力,所以在整体的增长拉动上,需要有一个角色承担,对这个角色的职能、定义可能各有不同,但是他们的核心目标是明确的:提效与增长。

提效是在资源有限的情况下,受制于B2B业务较长的内部价值链以及相对缓慢的市场传导速度,公司需要以“端到端”流程为目标,持续的优化和提升整个系统中各个环节的效率,市场分析及调研的效率、产品客户洞察的效率、产品PRD的生产效率、技术的研发效率、市场的营销效率、销售的获客及转化效率等等,而效率之间的关联性和传导,让我们需要有一个的运营及组织机制,保证内部“端到端”效率的持续优化。

这里经常碰到的组织问题是任务不清、目标不明,容易陷入“纯数据岗”或“纯管理岗”,经常出现“站着说话不腰疼”的现象,只发现数据上的异常,不解决实际业务中的问题,那一堆数据让各个业务部门认领回家,过两个月一看,还是老样子。

这里可以尝试的解决方案有两个:

1、对于中小体量的公司,从人员成本的角度考虑,“发现问题”的责任是核心管理团队,比如CEO或者COO,而解决问题则是将于问题相关节点上下游关联的部门TL抽调组成虚拟项目组,在规定时间内提交解决方案,这一方面可以增强执行的效果,另一方面可以锻炼团队的融合;

2、对于中等及规模以上体量的公司,可以成立运营中台,通过任务清单的管理方式,逐项逐级对问题卡点进行清理,注意,这里是清理,不是解决。清理的核心是找到卡点,明确是组织链路问题,还是人员能力问题,并不解决。如果非常清晰的,可以通过引入外部第三方软件或管理工具解决的,就即刻解决。这个好处是我们可以将大量的问题抽象化,并寻找问题背后的相关性,并在明确解决方案后,调动资源一次性推动解决问题。

增长是因为软件产品、技术革新、产品商业化以及组织市场需求之间有较长的时滞性,而时滞性带来了更多的不确定性,虽然B2B的竞争相对缓慢以及温和,不至于想2C一样“刀光剑影”、“血雨腥风”,但是一旦决策失误,可能很长时间内都会让公司发展陷入困境或停滞。所以,B2B公司需要有一个团队,对增长进行探索、规划、设计以及实施。

对于资源相对充裕的大公司而言,正如我们上面提到的,增长受到组织市场的管理者和组织市场的消费者,以及技术变革、交通和通信技术发展、管理理论革新的影响,与聚焦于企业内部运转的提效不同,增长的核心是聚焦于外部变化和周期把握,并将洞察与内部的提效相融合,形成完整的闭环。

因此,增长到底是CEO负责,还是COO负责亦或者是一个团队负责呢?

有以下三个实施建议可供参考:

  1. 增长核心是CEO/COO负责,但是他需要一个小的助理团队,主要负责信息获取、信息筛查、业务匹配度判断、产品PMF验证、客户端调研体验等工作,这个团队对CEO/COO汇报,只负责信息的获取,不承担决策内容的输出;
  2. 增长核心由专人负责,该角色需要有极强的市场洞察力和丰富的内部管理经验,他可以在与核心管理团队进行对话的基础上,将市场的前瞻性变化与产品和组织能力的匹配度上的差异转变为我们的业务策略,并通过组织培训、文化宣导、资源分配等方式,调整内部团队的行动轨迹;
  3. 大中型公司,需要建立中台负责,形成类似于参谋部的机制,对管理层汇报。之所以这样设计是因为从组织管理上来说,大中型公司由于复杂的组织场景和管理分支,让他们通过小团队解决增长问题的可能性极低,因此,需要设定中台结构承担问题发现、数据分析、相似性问题解决的职能。在这里,中台本身就是一个巨大的资源协同器和信息分流器,各个业务模块的数据都汇总至中台,由中台进行拆解分析形成比照后,做出对事实现状的评判结论,如果B业务单元遇到的问题在A业务单元有了解决方案,则可以立刻执行减少时滞,如果没有他们必须有明确的汇报机制向上传递;

作者:运营的不惑屋,公众号:运营的不惑屋

本文由 @运营的不惑屋 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

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