第2章产品概念设计

第二章：产品概念设计——从用户故事到功能列表、MVP定义、技术可行性评估

好，咱们进入正题。概念设计这一步，说白了就是把用户那些零散的、甚至有点矛盾的需求，翻译成工程师能看懂的东西。我见过太多项目，需求文档写得像天书，开发团队一脸懵，最后做出来的东西跟用户想要的差了十万八千里。

我个人习惯，做概念设计前先问自己三个问题：用户到底要什么？我们能不能做？先做什么？这三个问题搞清楚了，后面的路就好走了。

用户故事不是写小说，是记录用户真实的使用场景。我建议用这个格式：
“作为[某类用户]，我想要[某个功能]，以便[达成某个目标]”

举个例子，我们给一个电商仓库设计货架系统：

嗯，这里要注意：用户故事不要写得太技术。我曾经遇到一个产品经理，上来就写“货架需要支持RFID射频识别”，这其实是解决方案，不是用户需求。用户真正想要的是“快速盘点库存”，至于用RFID还是二维码，那是后面的事。

我的小技巧：收集用户故事时，多问一句“为什么”。用户说“我要大货架”，你追问“为什么”，他说“因为要放更多货”。再追问“为什么放更多货”，他说“因为订单量增长了30%”。你看，真正的需求是“应对订单增长”，而不是“大货架”。

用户故事收集完了，接下来要提炼功能列表。这一步我习惯用卡片分类法——把每个用户故事写在一张卡片上，然后按功能模块分组。

比如上面三个用户故事，可以归为：

优先级我一般分三级：P0（必须有）、P1（应该有）、P2（可以有）。P0是缺了它产品就没法用的功能，P1是锦上添花，P2是未来考虑。

避坑指南：我曾经在一个项目中，把“货架颜色定制”定成了P0，结果开发团队花了两周搞颜色方案，核心的承重计算反而没时间做。记住：功能列表不是愿望清单，砍功能比加功能更需要勇气。

MVP不是偷工减料，是用最小的成本验证最大的风险。我定义MVP时，会问自己：“如果只做一个功能，哪个功能能让用户愿意用？”

拿货架系统来说，MVP可能只需要：

至于什么智能路径优化、自动补货、数据分析，统统砍掉。为什么？因为用户最痛的点是“货没地方放”和“不知道放了什么”，而不是“路径优化”。

我记得有个创业团队，花了大半年做了一个功能齐全的货架管理系统，结果上线后用户反馈：“我就想找个地方放货，你给我整这么多花里胡哨的干嘛？”这就是典型的MVP没做好。

  MVP的核心原则：做减法比做加法难。每砍掉一个功能，就问自己：“没有这个功能，用户会死吗？”如果不会，砍掉。

功能列表和MVP定好了，接下来要回答一个关键问题：这东西我们能做出来吗？

技术可行性评估，我一般从三个维度看：

技术成熟度：这个技术是成熟的，还是需要从零研发？比如货架的承重计算，有现成的力学公式和软件，成熟度很高。但如果是“基于AI的自动补货”，那就要评估团队有没有AI能力。
资源投入：需要多少人、多少时间、多少预算？我见过一个项目，评估出来需要5个高级工程师干半年，但公司只给了3个初级工程师和3个月时间，结果可想而知。
风险点：最大的技术风险是什么？有没有备选方案？比如货架的焊接工艺，如果供应商的焊接质量不稳定，有没有其他连接方式（比如螺栓连接）作为备选？

举个例子，我们评估“承重实时监测”这个功能：

如果评估出来风险太高，或者资源不够，那就得回头调整MVP。比如“承重实时监测”做不了，那MVP里就先用手动记录承重，等后面再升级。

我的经验：技术可行性评估不要只找技术负责人聊，一定要拉上制造工程师和供应链一起。有些功能技术上能做，但制造工艺不支持，或者成本太高，那就白搭。我吃过这个亏，设计了一个很酷的模块化货架，结果工厂说“这种结构我们做不了”，最后只能重新设计。

概念设计做完了，要输出什么？我一般要求团队交付三样东西：

这三样东西，就是后续详细设计的输入。如果概念设计阶段没做好，后面就会反复改、反复返工。我见过最夸张的项目，概念设计只花了一周，结果后面开发阶段改了八次需求，整个项目延期了半年。

嗯，最后说一句：概念设计不是一次性的。随着项目推进，你可能会发现新的用户需求，或者技术上有新的突破，这时候要敢于调整。但调整之前，一定要问自己：这个调整，是让产品更好，还是让项目更乱？

好，这一章就到这。下一章我们讲详细设计，到时候聊聊怎么把功能列表变成具体的结构图纸和BOM表。