摘要: 关于产品规划，可以从寻找用户问题、分析市场/竞品/产品数据、明确产品目标/路径、设计功能矩阵、业务&技术风险评估几方面开展，即围绕寻找问题->明确目标->设计路径形成产品演进。
1、用户问题
用户对产品反馈有哪些问题？哪些是用户刚需？哪些是非刚需？外部用户电话/QQ/微信沟通，内部用户面对面访谈。沟通前准备问题清单，沟通后将结果分类（如：功能操作易用性/手册帮助指导/客服沟通渠道/产品赋能力度），每类形成TOP3～5。

2、市场/竞品/产品数据
市场数据，可以通过企业收录平台、咨询报告平台获取，了解产品领域的用户群规模、用户群领域分布，掌握产品市场空间。
竞品数据，页面指标可以通过Alxea统计，系统指标可根据参加线下论坛/沙龙时收集的宣传数据、竞品网站页面内容反推（如：基于分类目录的商品列表估算SKU、商品列表页单价和使用人数估算GMV） 。
产品数据，针对用户问题通过报表平台或开发导表统计关键指标。  阅读全文      摘要: 做产品，每天跟各类人群沟通交流是常态，面对各种需求，我们可以从哪些方面去着手分析和判断，使产品的解决方案既解决了用户痛点甚至制造惊喜，又夯实了产品模型，而且沿产品策略又进了一步。下面梳理一些思考点：
需求是用户或组织在某个场景下存在的痛点以及诉求。而需求分析就是发现问题、去伪存真、解决问题的过程，分析维度含：
1、基于产品定位
在产品的定位和愿景下，需求是否违背产品初衷，是否偏离产品路线，这和产品是先定位出来还是渐进明晰找到定位不冲突，即使产品策略是分阶段实现，每个阶段的需求也都应该围绕产品定位去分析。  阅读全文      摘要: 产品工作过程这个话题，做过的同学想必不陌生，经历一些产品及功能的设计后，也梳理和总结产品工作过程，都有哪些工序，设计过程是怎样的，如何合作去完成产品以及过程中的一些感悟。
一、产品前期的那些工序
二、产品中期的设计过程
三、产品后期的工种合作
四、产品经历的一些感悟  阅读全文      摘要: 最近牵头的一个项目上线发布，涉及外部合作，除了一般的需求调研沟通、产品设计评审和研发过程管理之外，还多了对运维实施和合作方的沟通协调。过程中经历的一些场景和脑海里项目管理思路反复在碰撞，把它们梳理和提炼出来，分享和自勉，以更好地开展以后的产品工作。
对于兼容产品经理和项目经理的情况下，产品层面需要快速学习业务并结合产品现状整理业务点，为产品设计做铺垫。项目层面需要充分了解业务方期望以及项目任务（市场、运营、产品、开发、测试、运维方面）的进展现状及约束条件，为项目管理做铺垫。  阅读全文      摘要: 产品从0到1上线运行了大半年，上线初期为了里程碑、KPI，项目组难免会存在完成任务式的心态，尤其是项目成员由各方技术团队抽人拼凑而成、某些业务性强的模块开发过程中，技术在驱动产品的情况，产品可扩展性和健壮性的设计情况可想而知。在着手产品重构任务时，首先想到的便是了解现状，含：业务和技术两方面。技术方面，主要从表结构开始、跑产品的门户流程，通过门户流程看数据生成规则和数据流向来梳理产品现状。业务方面，和运营、用户沟通了解目前产品存在的痛点，优先级情况。在摸清楚业务和技术现状后，和市场、运营伙伴沟通业务规划、对标了解竞品业务、与用户沟通挖掘潜在需求则是下一步要做的工作，该阶段需要尽可能收集多的信息输入，以让设计可以考虑到更多的业务场景，使设计更加科学、合理和具备扩展性。  阅读全文      摘要: 大家都很清楚，互联网产品功能开发出来只是开始，不断的运营迭代才是关键。产品设计之前，除了我们常说做的市场调研、竞品分析外，条件允许的情况下尽可能在设计前期接触用户，了解一手需求并做梳理分析很重要。产品设计过程中上除了考虑交互、功能和流程，还需要思考该功能上线后如何积累到需要的数据，为产品迭代提供指导依据，否则很容易陷入经验主义，走偏方向。产品上线后，定期的看数据、解读数据，形成潜意识的习惯很重要。
产品工作没有成型的套路可以复用和一成不变，相信每个产品人都是在不断摸索和调整，包括我自己，下面结合实际的经验，梳理和分享一些设计观点，不对斧正。
观点一：点、线、面，逐步分析完善需求。  阅读全文      摘要: 互联网是一个野蛮生长的环境，面对大众的多样化需求、行业的快节奏决定了产品人必须要自我驱动，快速学习、系统思考，积极改变、拥抱变化，除了专业技能，对产品人的心态、观念和综合素质要求是比较高的，因为需求来源于用户的生活体验，这里的用户也包括自己。
经历过运营商产品工作，需求调研、系统分析、产品设计、需求编写/管理和交付能力属于基础技能，客户交流/售前/售中/售后支撑与引导能力可以认为是中阶，产品规划和经营能力则属于高阶。而互联网产品工作，除了需求分析和产品设计，市场/用户调研、头脑风暴、数据分析和运营思路也是必不可少的环节，中阶则更多是行业认知能力、体系化产品思路、观点分享能力和产品影响力。高阶，应该在于对行业走势的判断力、产品定位和路径规划能力、方法论输出能力和新人培养能力。  阅读全文      摘要: 最近在做一款前端产品的设计，产品前期的调研相对顺利，但在设计过程中挣扎过、纠结过、兴奋过也郁闷过，五味杂陈。技术出身的产品经理，设计产品时往往容易陷入技术思维的陷阱，将简单的功能复杂化、将用户想象成和自己一样的思维方式去过度设计，设计出来的原型稿历经几轮PK讨论下来，精疲力尽之余不断在反思和审视自己产品观念中的那些劣根，拔掉方能成长。
中/后台产品的设计从事较多，而在做过几轮前端产品设计后也逐渐发现它的可爱之处。于是想梳理一些对前台、中/后台产品设计方法上的区别之处，以更加全面的视角去看待产品的规划和设计。  阅读全文      摘要: 2015年初，从原来的虚拟运营商跨进云计算这个业务，领域的转变让自己在工作过程中逐渐了解云计算、开放平台这些以前不曾接触过的对象。产品工作不像开发、测试这类，相对来说没有通用的学习范本和标准，产品经理唯有在工作中结合实践总结工作方法并且根据新的实践不断反思和修正，才是正确的成长之道，他人的知识终究是他人的，你永远无法了解那些知识背后的逻辑，所以不能盲目借鉴，要善于辨别和吸收。
这一年集中阅读了《全新思维》、《学会提问》、《金字塔原理》、《浪潮之巅》、《社会心理学》、《影响力》，在工作过程中重读了《启示录》、《产品经理修炼之道》、《网站数据分析与实践》。思维方式的锻炼是这一年的重心，现在的产品工作和以前的研发、系统分析与设计工作相比涵盖面广、综合性强、要求全面，对个人思维中以前行业固有认识必须打破，学习和接收新的思维方式是首要任务。  阅读全文      摘要: 最近在做一个前台网站的产品改版设计，设计之前后将以前的产品笔记翻出来重新阅读了一遍，开展新产品的设计过程中，也来梳理一些心得体会。
一、设计任何一款产品之前，我习惯先用脑图将产品思路进行梳理：
1、思考
1）产品的用户群是什么？有哪些行为特点？
2）之前用户调研的痛点需求？运营反馈的痛点需求？
3）竞品都有哪些优缺点？
2、回答：
1）产品核心功能清单有哪些？
2）根据核心功能归纳产品定义的一句话描述？  阅读全文      摘要: 最近围绕平台产品开展需求调研、产品定义和产品设计的过程中，也在思考对于产品子系统间的规则约定和遵守，即如何设计产品规则并让各子系统共同遵守，从而更加合理地完成产品子系统间的交互&协同设计。
平台产品设计需要紧贴组织的业务定位，形成产品的定位，再结合现有的应用架构去进行产品定义和设计，这里不过多谈论理论方面的内容，只是结合这段时间的经历，分享自对产品子系统间如何交互&协同的一些看法：
1、业务场景规则
在设计产品子系统间的交互&协同时，从用户使用场景出发是必须的，但用户和数据流为何要经过子系统？有哪些用户和数据会经过子系统？用户和数据流经过子系统后都流向了哪些子系统？最终给用户提供什么样的数据输出？这些思考在做业务分析时开始考虑，定义好业务场景才能为产品子系统间的交互&协同规则提供规则约定。  阅读全文      摘要: 产品生命周期的概念都很熟悉，加入这个圈子前也做过大小各类项目，也负责过项目的从无到有直至上线。但严格意义上来讲，互联网产品从无到有的生命周期体验，还是首次接触。在这里不探讨产品方法，只记录和分享自己在产品不同阶段经历中的一些感触。

1、产品调研期
集中办公，各产品人员分工调研，编写和评审调研报告，随时头脑风暴，早晚沟通讨论（回答市场有什么）。一天下来的工作重点侧重在：调研、讨论、讲解。一天的时间基本都泡在各大市场分析网站和竞品上面。
其中，注册帐号使用竞品的过程中一般是结合业务咨询，做抽象归纳。

2、产品需求分析期
集中办公，各产品人员根据调研成果进行业务需求分析和讨论（回答产品要做什么），根据业务需求梳理出产品需求，最终输出产品需求说明和原型。一天下来的工作重点侧重在：讨论、方案PK、汇报。  阅读全文      摘要: 在大公司工作，首先要面对的是公司现有的流程、规定和条框。其次，基于成本考虑，多数大公司都采取矩阵式管理，核心部门都是共享资源，产品经理要确保争取到足够的资源才能研发出产品。作为一名初来咋到的产品经理，更是要理解这两点才能高效地开展日常工作。

对于公司现有的流程、规定和条框等硬性政策可以自主去学习了解，但对于如何在矩阵式架构中充分开展工作，在与Leader、伙伴的学习之余，更多还是要结合个人情况去揣摩、理解、总结和反思，形成一套自己的工作方法。日常工作中，大部分时间都在与市场部、UED部、开发部、测试部、运营部的伙伴进行产品沟通、需求评审及问题跟踪，不同部门承担的职能不同，使得产品经理在与这些伙伴的工作配合中除了发挥自身专业之外，对于软技能的运用也是非常重要的。  阅读全文      摘要: 需求分析能力是开展产品工作的基础技能，也是产品经理的立身之本，需求分析方法论的指导固然重要，但更多还是要去实践和思考。
最近在做平台型的产品工作，相对于垂直类产品的小而美特点不同，平台型产品更加注重生态建设，根据公司自身特色，依托现有平台资源，瞄准服务对象，从而推出一整套的解决方案。同时，相对于以前做运营商产品规划不同，互联网产品规划侧重竞品分析，业务讨论，主动规划。没有人告诉你需求是什么，BOSS定方向，产品经理基于大方向开展一系列调研、分析、头脑风暴、评审、汇报工作，最终在规定的时间产出业务和产品需求。
结合实际工作中的一些经历和体会，分5个部分谈谈对产品需求分析思路的理解，和各位交流学习，同时附上指导自己开展需求分析工作的一些方法论。  阅读全文      摘要: 加入互联网产品圈子之前看过一些互联网产品书籍，对于产品思维的感触，在自己真正踏入这个圈子的实际工作中才有了一些切身的体会和感受。下面在写给自己的同时，希望也能对准备转到这个行业的同学有一些帮助：
1、工作方式
1.广泛倾听
互联网产品面向大众用户，在做产品规划和设计时，需要广泛吸收各方意见，不管是公司内部各部门同事还是外部用户，学会主动宣传、推广和倾听用户声音是一项基本能力。
2.积极参与
和做企业级产品面向企业内部用户的需求调研和产品设计不同，在互联网上增加自己的曝光度、提高社交网络参与度、关注社会热点事件，参加线下活动认识圈内朋友，这些是以前不曾感受到的。  阅读全文      摘要: 产品需求从无到有，经历了头脑风暴、调研沟通、业务讨论、架构讨论、产品评审、开发评审。沟通无处不在，和业务人员、架构师、产品人员、技术人员、领导的各种沟通协调、汇报，一路下来梳理些沟通的方式方法，自勉和改进。
1、心态：一句很感同身受的话：开放的心态是我们要做的第一件事情，全局控制的想法其实是错觉。你不能控制人或者任何事情。你可以影响他们，但绝不是控制。
2、与业务、产品人员的沟通：
1.沟通业务背景，了解产品流程背后的原因。
2.沟通产品故事，了解产品为用户带来什么价值。
3.讨论产品方案，建设性提问并带自己的建议方案。  阅读全文      摘要: 因业务方向调整，今年1月开始投入新业务的产品工作，和之前垂直类产品不同的是，这次属于平台型产品。经历了竞品调研、业务需求分析、产品需求分析、产品规划之后，来回顾一些过去工作中的收获和反思。
相对于垂直类产品的小而美特点（追求极致体验、制造运营感、数据驱动、快速迭代）不同，平台型产品更加注重生态建设，根据公司自身特色，依托现有平台资源，瞄准服务对象，从而推出一整套的解决方案。
相对于以前做设备厂商的产品规划（根据客户需求推出解决方案、业务规划成分少系统设计成分多）不同，电商类产品规划侧重竞品分析，业务讨论，主动规划，业务需求梳理，产品需求分析。即没有人告诉你需求是什么，领导定一个方向，产品人员负责基于大方向开展一系列如调研、分析、头脑风暴、评审、汇报工作，最终在规定的时间产出业务需求和产品需求。  阅读全文      摘要: 第一次做互联网C端产品，可以将以前看过的书籍知识运用和实践，是很HIGH的一件事。刚开始投入工作时，产品感觉还比较朦胧，经过这段时间的摸爬滚打和同事的支持，思路被逐渐打开了许多。需求从无到有，横跨多个中心及部门，还涉及外部合作方，在项目沟通协调、业务逻辑分析、需求沟通评审上可以继承以前的经验，但面对赤裸裸的产品设计，火候的把握还需要继续学习。记以此文，希望在接下来的工作生活，能坚持去观察、思考和总结。  阅读全文      摘要: 互联网产品经理神话这几年在整个IT行业被各种炒，有发展红利的大背景，也离不开媒体宣传的各种产品故事。产品人为了实现自己的产品理想也好，还是为了经理title而趋之若鹜也罢，不可否认，互联网产品确实很大程度地改变、影响了我们的生活方式，让我们的生活变得更有爱和有趣。看过《人人都是产品经理》或《产品经理修炼之道》的朋友应该都比较了解这个岗位在企业中的定位、职责及发展方向。下面结合自己这半年以来的实际工作，分享自己对该岗位的理解：
产品经理定义：对产品的生命周期负责，基于公司/中心的业务方向规划产品的发展路线，管理产品规划及设计，跟进产品研发上线及运营。
产品经理职责：负责产品的市场调研、用户调研、竞品分析、头脑风暴、原型/流程设计、规划分析、产品汇报、产品立项、产品研发/上线/运营跟踪，与市场、UED、开发、测试、运营、客服等部门的同事密切配合，在产品发展的不同阶段，组织与相关部门同事开展产品沟通、讨论、评审、决策，推进产品规划和设计方案的落地、关注产品研发的迭代节奏，关注产品上线后的运营推广。  阅读全文      摘要: 进入这个互联网圈子以来，相对容易的是新业务学习、日常沟通以及项目管理，而困难的是要去改变沿袭多年的产品思路。所谓痛则通，对于这个转变的过程，自己有准备。
结合自己在通信和互联网行业做产品经历，谈谈它们的差异，主要在组织文化、组织架构、工作流程、日常沟通、需求分析、产品规划、产品设计、产品运营方面。
组织文化：传统行业组织文化偏行政权威，而互联网组织文化崇尚开放自由，团队负责人和大家打成一片，言传身教的同时注重平等开放的合作。
组织架构：传统行业的组织架构崇尚垂直式管理，行政级别划分明显。而互联网组织架构崇尚矩阵式管理，淡化行政级别，去中心化，团队负责人更多关注产品的规划和发展、团队的成长和建设，日常行政工作由专门的PMO负责。  阅读全文      摘要: 互联网，从今年5月~7月的准备，再到8月入职至今的半年以来，感受和经历有很多。年末岁尾、空闲之余，来梳理那些日子里还记忆尤新的片段。
毕业后开始做程序员、工作第3年转做了系统分析师，第5年转做项目经理，1年之后投入互联网产品至今。7.5年的职业生涯里，在收获各阶段经历的同时也在感受着互联网行业带来的各种变化。而对于转互联网的初衷及时机，概括来说有如下几点：
1.互联网产品更加贴近生活、更有趣、更喜欢
2.积累了软件开发、产品及项目管理工作经验
3.积累了互联网产品规划、设计、管理及运营等书籍阅读和笔记
4.积累了对一些互联网产品的看法和见解
从开始关注互联网产品，到感兴趣和不间断关注，到最后加入这个圈子，那些过往的情景还历历在目：  阅读全文      摘要: 高速发展的世界，需要我们迭代地开发和改进业务问题的解决方案，我们需要一些方法来持续探索业务及其问题，将这些要求告诉技术专家，他们为业务提供技术解决方案。
许多组织机构不是等待需求的所有细节都得到定义，而是更喜欢迭代完成这些业务活动，定义一些需求，开发一部分解决方案，定义更多的需求，这样增量式交付发行版本，直到解决方案被判定完成。这种迭代的方式意味着，业务环境和开发环境中的关注点、想法和变化更加同步。使开发者更了解今天的业务问题，工作的产品适合今天的业务环境。
这种持续的工作探索意味着，业务分析师持续地将新故事或需求加入分析列表，这个列表又持续地按价值进行分析，最重要的是按业务价值来分析。列表根据价值和紧急性来排列优先级，最高优先级的需求交给开发者开发。  阅读全文      摘要: 今天的大多数软件都不是拥有它的组织机构开发的，而是购买的。考虑到这些开发和解决方案选项，今天的业务分析师有一项额外任务：即决定最佳的策略来发现和沟通需求，不论组织机构决定采用哪种方式实现自动化。
以需求策略作为指导，决定从哪里开始，是否有足够的细节，你需要哪个迭代循环，记录知识时采用哪种形式，何时复查，何时让哪些利益相关者参与，何时构建原型，何时以及如何做大量的事情，让你的工作更接近为业务产生最优价值，每个项目的情况不同，有必要采用不同的做事顺序、做事细节、沟通形式。  阅读全文