新产品创意，如何从产生到落地为需求

注：本文写自2023年9月，当时发表在我的个人公众号上，但因为一些特殊情况公众号后来被封了。今天将这篇文章搬运过来，我后面要写的一篇文章会引用这篇文章。

本文是我关于可行的新产品创意如何从产生到落地为需求的一些思考，欢迎讨论。前方预警，本文较长，需要耐心观看……

上篇：如何产生可行的新产品创意

新产品创意的产生过程可分为四个阶段：混沌期、研究期、概念验证期、样品验证期，如下图所示。首先，在混沌期我们基于大量持续的信息输入和思考从而产生源源不断的混沌原始的产品创意；然后将它们投放进漏斗模型，在研究期内进行创意内容的反复研究、补充，筛选出我们认为初步可行的创意；再将这些创意继续投入到概念验证期，进行验证和反复完善，直到我们确认创意可以被商业化或是应该被放弃；最后我们在样品验证期进行创意对应样品的开发与评估，评估通过后即可得到真正可行的新产品创意。

上述四个阶段看似云淡风轻，但做起来还是比较“折磨”人的，一些提醒事项可供大家参考：

“茫茫不知向何处”的混沌期

1、从概率学角度上看，原始创意越多，开发出好产品的可能性越高。而为了在混沌期形成足够多的原始创意，则需要保证大量持续的信息输入和思考，信息输入包括但不限于行业新闻、研究报告、客户访谈、内部反馈等，从而形成自己关于行业、产品、商业模式等的认知和直觉。
2、要保持记录自己的创意灵感，它是否可行不重要，重要的是培养出能够时刻关注痛点的潜意识。
3、总结自己的创意形成方法，并不断进行试验、改进。我粗略总结了三种产品创意形成方法，可供参考，我感觉第一种是最常见也是见效最快的。

一是“做填空”，从不同维度梳理客户业务（如业务对象范围、业务生命周期），梳理产品线现有产品方案矩阵，发现那些未被满足的需求，针对性进行满足；
二是“建生态”，通过产品之间的信息聚合、有机联动，建设行业内或产线内的产品生态圈；
三是“搞颠覆”，利用新技术、新商业模式来重构以前的产品玩法，对已有生态进行颠覆式创新。

“内心上演激烈争斗”的研究期

我们对原始创意进行研究、补充，各项内容包括但不限于：企业战略、产品线目标、方案矩阵、产品定位、核心价值、市场潜力、竞争分析、客户认知、技术预估、其他风险等。我发现这个阶段人容易不自知地“自嗨”，容易写一些虚头巴脑的东西（如追随一些舶来的概念、估算一些过于乐观的数据）来说明创意的价值，包括我自己有时候也会有这个问题。这个阶段还是要务实，要把每个点都论证扎实，要符合国内市场特色、企业特点等。注意这个阶段也要和产品线领导能够达成一致，如果意见不统一也就没必要进入下个阶段。

“笑对千夫所指”的概念验证期

概念验证期一定不要省略，必须将创意概念进行一定范围内的路演。一个是面向前端体系（客户/销售/售前/方案，注意保密），确保想做的东西的确是市场所需的；另一方面是面向后端体系（产研/售后），增进大家对产品线业务的理解，还可能收获一些意想不到的好建议。实践中有些团队会跳过概念验证期直接进入样品验证期甚至直接投入标品开发，我觉得是非常不妥的，既丧失了一个可以极大提升不同团队间协作热情的机会，又把一堆明明可以提前排的雷非要集中引爆。

“胜利就在前方”的样品验证期

到样品验证期这里，新品创意基本就快尘埃落定了，保险起见，我们需要进行更进一步的最小化验证，确保新产品创意的关键价值是有把握能交付的，并同样面向上述两个体系进行样品路演（这时候已经可以和前端体系协作储备实验局项目了）。根据具体情况，有时候我们的样品仅仅只用于核心技术验证，但有时候我们也会将其作为新产品的第一个最小化标品版本来做（这里会有一定的设计风险，建议尽早引入需求人员），后者就已经涉及到创意的落地实现了，咱们往下继续看。

下篇：如何将新产品创意映射为需求

如果你看过一些关于2B产品业务规划和建模的书籍，你可能会发现它们普遍都提出了全面且精细的业务设计框架，但就是不知道要如何套用到安全产品之中。这里我有一套“心法”，很粗糙，很简单，但非常管用，少侠或可一试。

我将创意到需求的映射过程主要分为两个阶段（下图中的两个弧形箭头），一个是将创意映射为产品需求，另一个是将产品需求映射为功能需求。

这里的“产品需求”，我将它定义为站在产品系统使用前以用户视角想象我们的这个产品应当支撑哪些业务；这里的“功能需求”，我将它定义为站在产品系统使用过程中以设计人员视角看我们的这个产品应该具备哪些功能特性。特别要提的是，我们有时候写文档会将“产品创意”、“产品需求”、“功能需求”这三者混在一起，要注意有意识地进行区分。

产品需求：不了解产品的用户在向我们提要求

在确定产品需求之前，我们首先要进行产品涉众、业务场景的分析。

所谓产品涉众，就是与这个新产品相关的一切人员，不仅包括产品在未出厂前的相关人员，也包括出厂后的相关人员。涉众不等于用户，用户是产品系统的所有直接接触者，这只是涉众当中的一部分。一个产品的涉众有：公司人员（如开发、需求、风控、供应链生产、售后、工程实施等）、上游供应商（硬件厂商、数据库厂商等）、客户方人员（出资方、采购方、承建方、项目审计方、业务管理员、业务操作人员、业务审计人员等）等。一个产品的用户有：公司人员（开发、需求、供应链生产、售后、工程实施等）、客户方人员（实际业务管理员、实际业务操作人员、实际业务审计人员等）等。产品需求设计需要充分考虑各涉众的利益诉求，而不只是瞄准用户，更不是只瞄准客户方用户。

举个例子，如果产品只关注能够将客户业务跑得转，而不关心帮助客户的汇报问题，出资方给了钱却看不到可量化的回报，那后续又如何愿意继续给钱呢？尤其是安全产品，本来就属于相对边缘的业务，更应该将自我价值证明到位。

接下来就是分析涉众中有哪些用户，并找出他们各自涉及的不同业务场景（一个特定的业务目标+执行环境+执行人+执行活动），如什么情况下供应链生产人员要使用我们的产品系统做什么大概是怎么做的、什么情况下客户方的业务管理员要使用我们的产品系统做什么大概是怎么做的，等等。在描述业务场景和对应的执行活动的时候，注意不要带“设计”的思想在里面，要对其进行抽象和优化，毕竟站在用户角度，他们可不知道我们的产品功能到底是什么设计的，只知道他们自己要干哪些活，大概想要怎么去干，我们提供的产品得支撑他们去干。而通过对客户方用户的这些活儿以及怎么干的总结，也就可以得出我们产品的关键能力（注意还是不要带设计思想）。

额外说几句，对于大多数安全产品来说，其涉及的业务场景通常会比客户内定制的业务系统的要简单一些（目前还不怎么涉及复杂的多方协作，但毋庸置疑技术性还是非常强的），这也是我认为为什么大多数2B系统业务建模方法套到安全产品上总让人感觉有点水土不服。

综上，对于安全产品来说，一份至少我认为已经合格的产品需求文档包括以下内容：

• 产品定义： " XX是什么产品，用于什么行业，有什么关键能力， 能帮助什么客户解决什么问题 "。
• 客户方用户诉求：用生动或有条理的描述讲一讲产品对应的业务场景， 客户方 用户们要用它干哪些活，大概想怎么干，从而解决他所面临的困扰。
• 其他涉众诉求：可直接做具体要求，主要包括产品形态、授权方式、价格体系、部署要求、系统运维要求、性能要求、安全要求、可移植要求等。
• 产品roadmap：这个看情况，如果关键能力较多、较复杂可以考虑分阶段规划。

功能需求：产品设计者眼中的功能特性

到功能需求这一步时，建议不要一上来就罗列界面功能需求甚至是功能模块名称，而是首先要将产品需求中的“客户方用户们要用它干哪些活，大概想怎么干”映射为连贯的在产品系统中具体的主操作路径，而客户方用户未来也将按照我们设计的这些路径，在实际产品中的不同功能界面之间穿梭，最终达成他想要实现的业务目的。在主操作路径的设计过程中，我们连带着会将界面信息、功能布局等也一并完成。

这里切记，主操作路径要清晰明了，不要是“断头路”，要给用户一定的出错和反悔机会。关于如何更好地进行界面交互设计，我建议可以看看《Don’t Make Me Think别让我思考》这本书。

当我们把主操作路径及其相关联的功能需求说清楚了，其次是要完善落实产品需求中其他涉众诉求所对应的功能需求（思路和上一段类似），最后再做补充完善。如果涉及一些比较技术性的功能需求时，需求人员可以和SE/架构师合作编写。

综上，一份至少我认为已经合格的功能需求文档包括以下内容：

• 各类用户的 主操作路径 说明、 界面原型
• 功能需求规格列表（有前两个，这个可以适度放水，只写重要的即可）

至此，创意到需求的映射工作已经完毕，后续就是常规的产品研发过程、实验局、上市等活动了，就不做赘述了。

全文完，感谢阅读。