短时间内,如何快速让陌生领域产品从0到1.pdfVIP

短时间内，如何快速让陌生领域产品从 0到 1 产品汪遇到类似时间紧、任务重、没有头绪且不熟悉领域的新产品，算是工作道路上的大概 率事件。反而是一路顺顺当当按照教科书的产品设计流程做下来，最终取得胜利，大家举杯 相庆的情况寥寥无几。希望这篇文章对面临同样问题的朋友有所帮助。 这半个月内接手了两个全新的产品任务，均为自己比较陌生的领域。在原始需求一团模糊，甚至只 是由领导转述的情况下，没有一点点防备地来到我面前。 1、了解需求 “XX想做个什么什么样子的产品，你看看整理一下，过几天带材料过去沟通。 ” 这话是不是有些耳熟？是的，我们很有可能碰上这样所谓的 “需求 ”，尤其是在用户为大型企事业 单位，最开始不便直接沟通的时候。这次我也不例外，这 2个新产品一个是从领导处直接口头传达， 另外一个是市场人员转发的看完满是黑人问号的业务说明书。 由于时间要求紧，不可能留有充分的调研时间，但即便如此也还是需要从消息源了解最基础的 3个 问题： 接下来，在搜索平台或应用市场根据关键字筛选出同类产品。一个新需求新产品， 95% 以上的产品 已有与他们相近的同伴了，我们通常不需要重新制作轮子（虽然也有例外，比如其中一个是国企单 位内部定制型产品，相似的平台并不多见，至少在网络上）。 将认为典型的功能、页面、流程等碎片信息快速收集（自己习惯用 onenote ），先广撒网粗筛一遍 ，选择 10个以内最具代表性的同质产品，准备开始针对性细化梳理。 细化分析过程中，将高频出现的模块及功能点快速列出，先不要去分别排序什么的，因为目前只是 描绘整体轮廓的阶段，先要圈定出大致的功能范围。 2 、梳理产品结构 也就是俗称的搭 产品功能框架“ ”。个人是用思维导图或 Execl ，或是二者一起，将产品最核心的模块 、功能点归类整理，形成初步的产品概要面貌。 注意的有两点： 这个过程如同搭房子的打桩一般，第一点很好理解，类似于找出地基中心桩。场景分析是必要的设 计流程，也是产品经理的思维方式，这直接决定了一个产品的价值。 第2 点则是在产品有多角色用户时需要着重考虑。举个例子： 比如某个产品是物业社区类，那在梳理产品结构时，我会按照业主客户端 → 物业客户端 → 物业管理 后台的优先顺序依次进行需求梳理。再从这几个用户群视角去考虑他们最迫切想解决的问题是什么 ，之后将这些问题一一对应到可以解决的功能点上。大致是一个树形结构的思维方式，将大而广的 问题化为小而精的功能点。 顺便说一点，我们在梳理移动端产品时，往往也需要同步设计管理后台，后端设计一般是在前端基 本完成后再开始进行。原因很简单，后端是为前端服务的，前端展示的内容，决定了后端应该对应 输出什么样的数据。因此，管理后台通常也是由各类数据的汇总及分类、业务流处理、权限角色、 数据字典等支撑性功能组成。 另外，之所以选择思维导图或 EXECL 作为产品结构文档，是因为字不如表，表不如图。可视化的内 容会让人相对容易接受。在初期的产品输出中，尽量避免用一堆洋洋洒洒的文字，不利于表达也不 方便后续沟通和调整。 3 、与用户讨论，细化调整 这样在短时间内（可能是 3天，也可能不到 24 小时），基本可以拿出一份不至于太离谱的产品结 构图，同时通过之前 2个步骤也基本了解该产品的使用场景及典型功能。但这还仅是 形似“ ”，要想做 让其具有真正可用性，还是得和最根本的需求源头沟通确认，不断纠偏、调整、细化。 在与产品 A 的用户面对面沟通时，发现他们是将平台定位为一个综合性和专业性都较强的施工管理 型平台。与从市场人员反馈的平台规模存在不小偏差。同时对方也说明，虽然他们想要的功能很多 ，但目前只有若干个模块是迫切需要的。以此为基础，大致明晰了产品成型过程中的实现优先级。 产品 B 的发起方是一家信息化服务商，负责人的一家合作伙伴已在该领域进行了近 1年的调研和数据 收集，这就可以为我们完善产品、提高实用性上提供重要的参考依据，不至于让我们在