虽然工作多年，但作为产品经理还是升级打怪初级，所以想记录一下自己的产品心得，当作自己工作的复盘。
2020年12月底我入职新公司，一周后接手一个新项目，项目目标是尽快将公司目前在使用的系统实现对外输出技术能力。我是去年年初从C端转到B端做产品，带着一个重构B端项目失败的经验，我觉得做B端产品最重要的了解业务，接手这个项目我的短板很明显：不了解业务，不了解系统，跟技术和业务的同事没有磨合过。幸好我的老板非常信任我（因为是我前老板），还有给力项目经理（公司有一个质量管理部门，会给每个项目配置一个专门的项目经理，项目经理主要推进各节点，跟项目经理学习到了很多项目管理经验，准备下次总结），让这个项目至今在顺利进行。
我整理了一下时间线，一周时间了解系统，需求沟通，一周时间画原型写需求，第一次需求评审通过，第二天技术方案评审前，业务方需求变更，变动较大，进行了第二次需求评审，评审过程发现问题，小会解决问题，进行第三次需求评审，业务方在需求评审会议上对已确定需求有争议，暂停需求评审，线下沟通后，第四次需求评审通过。需求评审，技术方案评审确定时间比计划延期一周。
经过4次需求评审才确认需求，除了不了解系统等客观原因，我复盘了下整个过程，总结了一点经验教训
1.搞定需求方
B端产品，最重要的是搞定需求方呀！！！需求来自3个小leader，经常没有统一意见，不在一个职场，有些疑问我跟A沟通后，在需求评审时，B完全推翻。正确的操作应该是拉群，三人一起确认，需求评审前，需求方要完全认可产品设计，即使有需求变更也要根据变更的程度，决定是重新评审还是放到以后迭代的时候实现。
2.明确项目目标
有的项目目标可能是快速上线，有的目标是用户体验好，项目目标应该是需求方，研发统一的认可的，项目目标可能在项目过程重发生改变一定要跟需求方沟通确认好，这个目标可能决定了一些需求的实现方式，也可以避免一些干扰意见影响项目进程。
3.坚定自己的产品设计
不要因为大老板一些建议就随意变更自己的产品设计，至少要回去考虑清楚，因为一般自己的产品设计都是经过一番考虑的，大老板的意见可能是自己的一些经验未必能用在这个产品，可以说，我考虑一下这个点，是否需求改动，不要当场就确认大老板的建议，否则后面可能还要调整回来。
4.产品设计改动要通盘考虑其他关联的点是否也要改动
即使一个小点的改动，也要考虑是否会影响其他关联功能。
暂时先这么多吧。
