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

推荐订阅源

IT之家
IT之家
U
Unit 42
大猫的无限游戏
大猫的无限游戏
H
Help Net Security
G
Google Developers Blog
Recent Announcements
Recent Announcements
B
Blog RSS Feed
罗磊的独立博客
博客园 - Franky
J
Java Code Geeks
S
SegmentFault 最新的问题
D
DataBreaches.Net
C
Check Point Blog
Blog — PlanetScale
Blog — PlanetScale
T
The Blog of Author Tim Ferriss
有赞技术团队
有赞技术团队
腾讯CDC
博客园_首页
美团技术团队
V
Visual Studio Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
GbyAI
GbyAI
The Cloudflare Blog
aimingoo的专栏
aimingoo的专栏

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
to G 产品的标准化如何做?(上篇)
Haidee也是小新 · 2023-09-01 · via 人人都是产品经理

在不同的领域和业务中,会有不同的标准和规范,标准化能够让企业降本增效。那么,to G 产品的标准化如何做?需要满足哪些前提?本文总结了相关思路,希望对你有所启发。

一、什么是标准化

标准化是在领域+用户+业务的基础上平均可接受的作业规范和条件。

简单来说就是多个领域、多类用户、多种业务均可接受的开展业务的规范和条件。标准化产品就是企业同时面向多种领域、用户、业务提供服务的介质。

传统软件时代的定制化是客户想要什么就开发什么的产品,即使领域或业务相似可能都各有一套产品,这对于企业来说成本非常高,而标准化产品可避免这种情况。

就政务行业而言,如果不做标准化,每面对一个客户都要做一个不同版本的产品,同一业务出现多个版本。产研团队需要在每个版本重复建设相同的业务功能,且各版本内堆满了各式各样的个性化功能。不仅开发成本像滚雪球一样越来越高,产品难以维护,还使得团队对业务的理解十分割裂,无法沉淀业务价值和产品资产。

有的企业在后期可能会考虑将部分版本做合并,但这既要费劲儿地说服现有客户,避免给其带来负面影响,又要进行业务和产品功能的梳理,才能进行实际合并工作。每一次合并都需要重复一遍这些工作。

所以标准化产品最大的好处是为企业降本增效。标准化产品一次开发,无限复用,企业只需要维护单版本产品,团队可以充分钻研业务,也能更好地沉淀产品资产;对客户来说现成的产品,能够马上投入应用,且购买成本更低。

但标准化并不是什么业务都能够实现的,需要充分考虑是否具备标准化的前提条件。

二、产品标准化的前提

政务产品标准化依赖于行业标准化、业务标准化、和客户标准化的程度。

1、行业标准化

在此姑且把政务下面的各类细分领域称作行业,比如人社行业、水利行业等。

行业标准化有两个维度的考量:一是法律法规的硬性标准化,二是各地区政府基于管理的软性标准化。

硬性标准化:每个行业都需要遵守通用的法律法规(上位法),比如《行政许可法》;每个行业都有本行业内通用的法律法规,比如《水利工程质量检测管理规定》。不论是何地区、业务现状和后续如何,都需要遵循法律法规。基于法律法规,各地政府需要制定更为详细的规范要求,从上至下地发放和管理。

硬性标准化在实际工作中一般没什么问题,难点在于软性标准化。这个难点既需要考虑上级政府对于下级单位的掌控力,也需要考虑业务落地的可行性和可能阻力,这些都是软性标准化的来源。就当前政策、当前各地数字化建设情况、和发展方向来说,实现贯通且统一的大趋势是不可逆转的,只是时间长短的问题。

2、业务标准化

以我最熟悉的一网通办业务作为例子,核心事件只有两个——申请和审理,多个不同领域、多个不同事项作为条件组合在一起后,使得这两件事的内容、流程和规范变得多且复杂。但个人感觉这与B端SaaS产品设计一致,重在建立框架,然后再填充内容就好了,核心在于对业务的理解和把握。

比如B端SaaS的框架一定是特别标准的,非黑即白,因为企业用户需要准确,不会允许员工(实际用户)钻空子;而G端想做标准化产品,一定要预留有灵活处理的通道,因为政策落地实践时,存在一定盲区,或者说不那么实际,需要一些时间和灵活方式来加以辅助,待时机成熟后,这些灵活的内容要么剔除,要么转变为标准化功能。

政务产品的业务标准化,除了跟B端的一样,要求具备非常强的多场景分析能力、业务/产品架构设计能力、商业分析能力之外,还必须深入了解行业和客户特性,具备较强的预留性功能的设计能力。

3、客户标准化

不同地区、行业、层级的政府部门跟企业一样,会因为发展时间、规模、管理风格、效益、信息化、数字化程度等不同基础,使得部门人员在工作习惯、素质、管理制度、培训能力等方面参差不齐。在配置、维护、培训等方面相比企业,难度是有过之而无不及,所以政务的实施维护始终是大头。

产品的破局方式有两点:一是开箱即用,傻瓜式操作,也就是简化业务操作+强化用户体验;二是提供预设模板,快速配置、自动或半自动配置服务,PasS对政务来说是个很好的发力方向。

三、如何区分标准化和个性化

1、什么样的需求可以做标准化?

答案是共性需求。政务行业的共性需求,在实际工作中,基于行业标准化而来的需求,全都可以视作共性需求,这些是最容易识别的;基于业务标准化而来的需求,需要产品经理仔细甄别,业务成熟度和产品经理本人对业务理解的不同,会导致界定标准差异非常大;基于客户标准而来的需求,是最难处理的,产品和产品经理需要与客户保持相同频率,共同成长,不能步子过快也不能过慢。

2、什么样的需求是个性化需求?

产品形态、使用方式等是可以立即被识别为合理的个性化需求,包括但不限于客户希望能够更换产品logo、皮肤,以及用户可按工作习惯来变更列表的排序、字段回显、筛选等。这些需求不论B端还是G端都是基础服务,关键在于如何用最小成本实现。

产品如何与现有业务进行结合,也会产生一些个性化需求,这主要是由有些业务标准化和客户标准化的参差所引起的。这部分个性化需求有几个明显的特征:

  • 不切合实际
  • 不符合产品定位和服务范围
  • 不具备通用性
  • 会产生过多的合同外建设成本

3、什么样的个性化需求是可以接受的?

  • 界面个性化需求,如前面提到的logo、视觉皮肤。
  • 功能个性化需求,如前面提到的列表排序、筛选,以及快捷入口设置等。
  • 数据个性化服务,不同职责人员的数据需求不同,如一线员工关注手头未结束任务,管理者关注整体业务进度与质量。

四、政务行业能做标准化吗

许多人对政务行业的评价都是产品偏定制,没办法做标准化。我作为政务行业的从业者之一,非常认同这个说法,因为从过去到现在确实如此,未来很长一段时间相当一部分公司也会继续这么做。但以我浅薄的从业经验来看,在行业内如果想做大做强,标准化是异常艰难但又必须走的一条路,是政务行业正在发生的变化和趋势,否则定制化的高成本低效率一定会拖垮企业。

也许不少人会把政务行业特殊的关系营销作为反驳观点,对此我们需要区分两个角度来看:

1、企业内部

政务企业要么专攻某个细分领域,要么同时涉猎多领域,后者一般体量较大。企业内部面对一个垂直领域或者关联领域时,标准化产品能够快速应用,无限复用,对新业务的改造和落地响应速度极大地提高,降本增效,是实实在在的产品资产。

组织内部效率高于市场,是企业的核心竞争力之一。

2、外部市场

关系营销确实能在短期内帮助企业获取项目订单,若组织内部效率低于市场,但凡遇上行政变动、重新洗牌之时(即关系营销失效之时),就会因为缺乏竞争力而遭遇业务萎缩。

即使各自拥有市场份额的情况下,攻克标准化的企业成本远低于完全奉行定制化的企业,因为人工成本的上涨是不可逆转之势,“IT民工”将来会越来越贵。

在我看来,政务行业并非不能做标准化产品,只是很难做,难做的原因既有厂商实力,也有客户特性,同时这一行业对标准和定制的范围界定与B端也不一样。目前能看到行业内的部分厂商在探索如何做标准化,我自己也在工作中探索。

五、政务行业能做什么样的标准化产品

政务行业可以细分成多个领域,比如数字政府、智慧城市、数字治理等。部分领域包含了C、B、G三端用户,考虑到数据安全问题,会分别部署公众侧外网和政府侧内网,业务核心需求是提升组织内外的运行效率和服务质量。

那就意味着政务的标准化,要么做基础工具层的通用产品,再用基础层工具搭建顶层应用,要么依据垂直细分领域做标准化产品,比如人社业务的垂直应用。

垂直细分领域的标准产品,让我想起七色米进销存系统,也是按照快消零售、服装批发等领域做了不同版本的产品。

以一个通用产品同时面对多个行业/领域,优点是可以大中小型客户(政府部门)都可以去使用,缺点是容易做得不够精深。而按照不同行业/领域来做多个产品的情况,优点是够深入够垂直,缺点是市场比较窄,可拓展的客户(政府部门)的层级和数量都有限。

最后

总体来说,我认为政务行业是可以做标准化,需要找到最适合本行业的 “标准” ,这既是当下的变化,也是未来的趋势,而未来结合AI手段,还将进一步解决标准化之外的“最后”的个性化业务。

下一篇我们来聊聊政务产品怎么做标准化。

作者:小新,公众号:北漂南泊

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

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

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