知果：这些年，我从0-1打造B端产品的“九步法”感悟

Hi，欢迎来到知果的知果日记。

---

关键词：我的经历、打造产品“九步法”

想写这篇文章挺久了，但一直不知道从哪个角度切入去写，感觉自己想表达地挺多，可因太零碎不够体系，因此迟迟没有动笔。

直到上次我在公众号发表了“我对B端产品MVP的5点感悟与3点总结（实战版）”一文后（下有链接，可直接点击查看），收到了一些读者的咨询，以及一些读者表达受益匪浅之事，让我决定还是打算写写我从0-1打造B端产品的经历与一些感悟。

我对B端产品MVP的5点感悟与3点总结（实战版）

说来很奇妙，从我开始接触B端，就一直与基建类、中台类B端产品缠绕在一起。如知识图谱、监控运维、大数据平台、资源管理系统、LowCode、D2C、企业级基础组件、企业级设计体系等，它们均是属于底层形态的产品，而非业务应用侧的产品。

通过与这些产品打交道，我逐渐建立起了自己的抽象思维能力——从复杂关系中抽取共性的能力。而对于这些共性的抽取、应用、迭代、再构建（如此往复循环），我也是乐此不疲。每当从繁杂中梳理出来线头的时候，那种感觉别提有多高兴与舒畅了。

当然，以上产品并非都我主导，一部分我以主设计师+半个产品经理的身份参与，另一部分我以产品经理的身份主导展开。不论是作为设计师，还是作为产品经理，我都在思考如何做出一款被客户认可的产品，而不是一款自嗨的产品。记得前些日子有一位企业管理者和我聊起产品，他问我，说：“知果，我最近在思考一个问题，想听听你的意见？你认为一个好的B端产品，具备哪些特点？”我说：“第一，第二……”（你可以看下图）

随着经历越多，我也越来越发现，大家都想要能从自己手中培养出一款好的产品，可「好」怎么理解，每个人却不尽相同。「好」产品要怎么来，大家也处于迷茫阶段。对此，我也想趁今天的文章，对自己从0-1做B端产品的经历进行简单梳理（选择一些我印象相对深刻的），与你进行简单分享。或许不和你想的完全一致，但期望能抛砖引玉，互相多多交流。

我已经有些记不得，到底自己是如何从一名纯设计师慢慢进入产品经理行列的。我坐在自己的木椅子上，听着窗外淅淅沥沥的雨声，看着天花板一点点往前回忆。慢慢地，以往参与与负责过的B端产品逐渐在脑海中清晰，记得我以主设计师身份参与的第一个B端产品是运维监控平台，直到现在，它还在稳稳地运行着，服务着包括招商证券这么大级别的客户。现在也有一个专门的产品与研发团队，对其在进行迭代与运营。

很谢谢运维监控平台，是它领我进了B端大门，让我开始逐渐了解什么是B端，什么是B端产品。不过因为我参与设计运维监控平台其实不算从0-1，因此，我将它跳过了。我的思绪定格在了知识图谱系统。

知识图谱系统算是我以主设计师+半个产品经理身份参与的系统，其让我渐渐有了自己思考构建产品的意识。由于当时团队人手紧缺，并且该领域较为新兴（现在知识图谱已经耳熟能详），因此我被推上前线，承担起两个职责：一个是设计产品形态与信息架构，一个是设计产品界面交互与视觉风格。

对那时的我来说，我连知识图谱是啥都不知道，更别说界面要怎么构建了，完全毫无头绪。于是和产品团队负责人高频交流、分析竞品、学习图谱基础知识，其实当时整个团队都对知识谱图不太了解，都在各自学习中，几乎谁也不比谁更懂。但我们都互相打气、加油、互相解答疑问。

后来，我以大约每两天一版产品原型的迭代速度，通过“画-评审-修改”的循环，在大约两周内完成了最终方案的敲定，接着再开始进行交互设计与视觉设计。从知识图谱项目中，我学习到了很多，总结起来有5点：

1.1、接手一个不懂的产品后，不要慌，先与产品总负责人沟通基本情况，再对业务进行学习和了解；

1.2、不要急急忙忙开始设计解决方案，而是要先搞清楚一些核心问题，比如产品解决什么问题、客户是谁、他们会怎么使用产品等；

1.3、虽然主要身份是设计师，但想要将产品设计好，需要有意识思考设计以外的东西；

1.4、没有比原型更好的表达想法与团队共识的东西了，“快速绘制、快速评审、快速迭代”是产品设计的秘密武器；

1.5、直到现在，核心界面信息架构和交互依然没变，团队主要在技术上进行探索与深耕。所以我想，不要害怕一开始想不明白产品该如何设计，最怕想不清楚直接投入大量资源研发，这才令人头疼。

先说说这款产品的现状吧，目前已经正式投入运营与接入客户使用，解决了很多企业想要快速构建系统的诉求。我问了创始人，他说现在正有条不紊地展开，虽然辛苦，但整体趋势尚可。

好了，我说说这款产品当时我参与设计的情况吧。在我接手这款产品设计的时候，已经有了一些初步的原型，原本我的角色是根据原型进行交互优化与视觉设计。由于我的职业习惯，我通常先要将产品相关的七七八八搞清楚，捋顺才会着手设计界面，因此，当我发现界面信息架构和流程不通畅时，我与创始人进行了沟通。之后他告诉我原型其实并不准确，我可以进行调整与优化。

好嘛，与是我往前再走了一步，我将该产品的整体情况进行了了解。我发现，这哪里是一个产品，这明明是一个生态，而且很多问题在之前给的原型上并没有体现出来。在确定还有富余的时间可调整原型后，我主动以产品经理的身份对产品生态进行了梳理，并且与创始人一起明确了产品演进的步骤与节奏，逐步将LowCode梳理出来。

由于有了之前知识图谱的经验，我依然通过对原型数次评审与迭代来敲定最终的MVP，然后着手开始界面交互与视觉设计。这次项目，可以说是重构了我对B端产品的认识。并且我发现，在面对复杂问题时，我竟然不知道该如何切入去解决问题。也因为这次项目，我对产品的热爱更深了，我喜欢琢磨产品，将它们当做有血有肉的人一样去塑造和思考。由于此次项目的A计划是一个生态，超越了我原来接触的单一产品维度，因此可以说，学到了不少。如果要说有什么特别的感悟，我也总结了5点：

2.1、把做产品像培养孩子一样对待，时刻思考合不合理，有没有办法可以做的更好，使尽全力出方案；

2.2、永远不要将自己锁定在某种身份，只要能把事情做好，就去尝试和突破；

2.3、理清思路后，线框图、低保证原型永远是最有效的验证方式，直到团队内部明确最终可行的方案后，再着手开始高保真原型创作；

2.4、如果它是一个生态，那么需要把这个生态的方方面面一同搞清楚，而不是一上来就开始陷入细节设计，观全局才能控细节。了解全局后，你了解点就更加容易了。

2.5、产品是谁用，他会怎么用，能解决他什么问题…也就是说客户群体决定了产品的最终形态。

严格意义上来说，很多人并不认为这是一个产品，因为它与一般的B端产品完全不相同。而我却不这么认为，在我眼里，任何为用户提供价值的均可以称为产品，一本书、一套付费课程、一个演唱会等，你会发现，它们的设计逻辑是相似的。

企业级一体化框架严格来说是一种基建型产品，其是为了解决不同B端产品在集成时具备一致体验而诞生的。可能很多同学会觉得，这不很简单，找个功能强大的框架抄一个就可以用了，可事实却不是如此。

每个客户都有自己的诉求，除了功能要满足，在视觉层面也需要一些定制化（如位置、色彩、样式等）。这个项目我是以产品经理+设计师的身份全程主导的，可以说，在这个项目上，我无法依赖任何人（所有人在此均没有经验），必须自己做出决策和推动落地。

以终为始，我进行倒推，完成客户调研、定位问题、竞品分析、原型设计与评审、风格定义与设计、推动研发落地与产品推广。可以说，扎扎实实走完了产品建设与推广的全流程。不得不说，我特别享受这个的过程：思考与解决问题。

这套框架目前已经落地几十个产品，并且已经进入客户现场，得到了客户的验证与认可。同时，我还将框架申请了专利。当然，在这套框架的设计与推广中，我依然觉得还存在些许遗憾。譬如，由于经验不足，一些情况我没有提前考虑到，导致框架拓展性受限；再譬如，由于对前端实现方式不熟悉，有些研发要求没有交代清楚；还有，在产品推广前，我没有意识到一些B端产品的历史原因，导致推广中受阻。等等，这些都需要在今后设计产品时优化与规避。我依然总结了5点感悟分享给你：

3.1、一个新的产品即便客户认可，但若需要其付出较大的代价才能获得的，那么他很有可能放弃；

3.2、不要默默告诉客户你有了什么惊艳的神器，他们很可能觉得你瞎搞，应该在某些适当的时刻反复露一下脸；

3.3、完成一款产品的设计与研发，仅仅只是产品的开始，后面还有很长的路要走，包括验证产品与市场的匹配度、提升客户数、优化与强化产品竞争力等，真的是一堆事情；

3.4、假如你喜欢做产品，那么，做任何事情都可以采用做产品的方式去思考和执行。而不只是在接手一款拥有千万级用户的产品时才这么做；

3.5、自己思考一款产品如何做出来并推广下去，获得的感悟远远比别人手把手教你一步步该怎么做，来的深刻。

慢慢地，我开始学习独自思考它们，然后再和小伙伴们、领导、客户沟通，看看自己的想法有没有什么需要修正和改进的。比如在自己近几年负责的企业级设计体系上，其是一种在企业级层面提升数字产品界面体验设计的能力。

我把产品中零碎的信息、功能、需求等当成是一串珍珠项链中的一颗颗珍珠，我思考如何将它们逐一串起来，成为一串用户喜欢、并愿意付费购买的项链。

产品就如珍珠项链，产品经理就如打造珍珠项链的匠人。

不同的人群对珍珠项链的喜好是不同的，我们需要针对性的打造。

关于一些其他的B端产品设计感悟，我会在后续的公众号文章中慢慢与你分享。

做B端也有很多年了，一直觉得自己还挺幸运，有机会和优秀的小伙伴们一起从0-1构建一些产品。一些是我作为主要角色参与的，一些是我作为负责人主导的，不论是哪种角色，我都力求尽量把每个环节做到位，防止产品推翻重来。

在这些年，我也总结出了一些从0-1做产品的方法，我将其称为“九步法”（如下图）。当然，我会根据不同的产品，略微对以下步骤做删减或者调整。

第一步：找出问题

没有问题的解决方案是不值得去做的。你想，如果问题和痛点都不存在，那这个产品为什么要做呢？因此，正如Ash Maurya Spark59创始人说过：“必须先确定手头有没有值得解决的问题，不能在没有确定之前就花上数月甚至数年时间来推出解决方案。”

在我做D2C时，我就从自己目前擅长的领域出发，去找出需要解决的问题。我发现的这些问题一方面来自于我日常的观察，另一方面来自于一些同事的反馈。

第二步：客户调研

我们需要通过小范围的目标客户调研来明确问题是否真的存在，而不是自己臆想出来的。邀约一些客户，对你发现的问题进行沟通，看看他们都是怎么想的。你会通过访谈发现一些新的问题点，当然也会被客户否定你发现的一些问题（在他们看来并没有那么重要）。

在我做D2C时，通过客户访谈，就发现了一些我之前未曾考虑到的一些问题，这些问题对他们来说很重要。通常我随身带笔和纸，我在访谈中就随手记录关键词，回去后进行整理。一些属于我盲区的问题，我会带给我的团队小伙伴，一起来看。

第三步：梳理解决方案

当你发现你提出的问题，确实也是客户目前头疼的问题时，你就可以着手梳理解决方案了。如果有可能，你可以多梳理一些，去和客户交流，哪些方案是他们认为不错的，愿意在你开发出来后尝试或者付费的。

在我做D2C时，我将解决方案大致画了流程图与线框图（没有交互细节），然后与客户再次沟通，在他们大致认可后，我才开始着手第四步。

第四步：完成原型（MVP）

完成解决方案的原型时，我们要融入MVP思想，切不可一上来就想做个功能大而全的产品，这有可能翻船。

在我做D2C时，我对MVP运用的也不是很娴熟，抓不住重点。但在设计D2C中，由于需要在一定时间内看到产品形态以及验证其可行性，必须在仅有的人力条件下快速输出产品，因此我就不停地思考与取舍，慢慢有了自己对MVP的认识。在原型中，尽可能去掉对当下阶段来说不重要、不需要的需求。

我有一点影响比较深刻的是，即便我们知道目前是MVP阶段，也不要随意写代码，毕竟如果后期获得市场认可，代码要重新优化一遍，那是几乎不可能的。所以在MVP阶段，尽可能把代码写好。更多我对MVP的感悟，可以看这篇文章：我对B端产品MVP的5点感悟与3点总结（实战版）

第五步：团队评审

MVP原型完成后，我们要先进行团队评审，切不可直接扔给设计师出视觉稿。通过几轮评审和原型完善后，就可以进入第六步了。

在我做D2C时，原型评审分为组内和组外两部分，组内是研发小组内部评审，组外是找了后期会使用该产品的客户进行评审，这期间大家都提出了很宝贵的意见。我非常建议产品经理要经常进行原型研发前的评审，避免研发阶段再提出原型不合理的问题，导致之前的时间浪费了。

有产品经理会问，每次开会，人人都成了批评家，实在不想评审（可以说是害怕）。其实我们不要把评审看的太恐怖，我们要把评审也看做是一次小型轻量的验证会。最终做决策的人还是你，你可以最终决定哪些建议采纳，哪些建议暂时收进建议池。

第六步：视觉设计

视觉设计就是视觉设计师要将原型进行美化，让用户用起来更舒服。

在我做D2C时，没有过多在视觉上下功夫，主要运用了企业级设计规范来做，又快又省力。一些强业务部分，有针对性地输出设计稿即可。

第七步：研发与测试

这个步骤我就不再多赘述了，就是研发按照设计稿还原，并完成前后端数据对接什么的，提交测试的过程。

该阶段有一个点我觉得需要注意，就是研发过程中研发工程师忽然告诉你功能实现不了了，要么实现它需要继续增加时间，这会打乱整个研发节奏。我当时也遇到了此情况。于是后面我每周五开会，确定下周需要研发的事项，然后在会议上让研发工程师评估实现难度和方案，尽量在前期控制。对于一些非常重要的方案，我们会提前几周开始准备和预研。

第八步：小范围验证产品与市场匹配度

完成MVP，就要推广出去让客户使用了。我这里讲了要小范围，也是因为我之前吃过几次亏，发现一下子大面积推出去会有两个问题：第一，咨询的客户会一下子涌进来，而团队现有能力及资源压根接不住，导致乱套了，团队一下子没了方向；第二，客户太多后，会导致对产品的评价各异，一旦出现一些负面评价，会导致团队没有精力处理，从而导致你会怀疑自己的产品是不是真的有问题。

因此，在我做D2C时，我是一个个客户去联系的，等用上了，我开始找第二个客户，然后跟踪使用反馈。小范围先验证，并且同步优化与更新产品的目标客群，逐步扩大客户范围。

第九步：迭代、扩张

要是你发现你的产品与市场是匹配的时候，那真的太好了。你就可以进入第二阶段了，也就是根据客户与市场的需求，不断迭代你的产品，然后逐步扩张你的客户群体。

这里我们要注意，切记不要在迭代的时候，就毫无顾虑地在产品中疯狂添加功能，来弥补MVP阶段克制的心理。Ash Maurya Spark59创始人说过：“不要预先制作产品或者提供服务，等客户要求了再做。你应该把八成的精力都用来改进现有功能，而不是增加新功能。”

D2C小结：

由于D2C是一款内部基建类产品，因此我顺带带着团队参加了比赛，最终从数款产品中冲出重围，获得了优胜奖（即一等奖）。不论是评委还是现场观众，都对此款产品给出了好评。

很幸运，自己不仅参与过小模块、小功能的精细化设计，也参与过大产品的整体设计与思考。这两种状态我都很享受，不过最最最享受的还是从0-1做产品。

但到目前，因为各种原因，我认为还有很多我没有接触到、以及做深的，这些都是推动我不断向前的力量。期待在学习、思考与实践中，不断迭代自己的认知，然后分享给你们。

期望我的经历与打造产品“九步法”能给你带去一些启发。

本文来自微信公众号“知果日记”（ID：gh_690a8b6479cb），36氪经授权发布。