略微拓展下问题的范围，不局限于产品上线前，而将其放在产品需求文档交付之后，即产品正式进入全面开发阶段，产品经理每天的工作是什么。

• 参与制定详细的项目开发时间表

    项目开发时间表应该在与开发人员一起评审完需求文档之后的一至两天内制定出来，根据需求文档中的用例细化每一部分的开发时间。此项任务需与程序员哥哥们通力配合，首先要全面地收集他们在听完需求文档评审后对于产品本身的意见与建议，然后逐项予以合理的解释，以保证程序员哥哥们打心底里认同这个产品，认同形成这个产品的每一个需求。另外作为一个PM，也应该要对基本的开发流程有所了解，在制定每个需求的开发周期时提出正确的建议，保证最终的项目开发时间表既不会拖慢整个项目的进度，也没有超出程序员哥哥们每天正常的工作量，保证他们不会感到过大的开发压力。

• 补充程序开发过程中所缺失的资源

    如果是一个客户端产品，则最重要的两部分开发资源，一是后台测试接口，二是前端UI切图。这些资源在与技术人员一起评审完需求文档之后都应立刻提上日程，接口方面PM应尽可能地给出一份所需要的接口列表以及每个接口的基本字段，完成后将接口文档邮件给后台及客户端开发工程师，以方便他们在这份文档的基础上更为快速地完成正式测试接口需求的对接，并在双方对接的过程中，提供相应的产品方面的支持。UI切图方面，前期可以先让客户端开发工程师参考原型图搭基本的界面框架，并在这段时间内尽快与UI方面保持沟通，快速迭代出满意的设计图。设计图通过后，一到两天的时间内让UI设计师将设计图切图后打包，发送给客户端工程师以方便他们完善界面。

• 客户端后台的需求文档撰写

    思考产品正式上线后各部分的内容该如何维护、如何更新、以什么样的频率更新，即如何以最有效率的方式在客户端后台更新客户端显示数据。
对于后台需求文档，UI不重要，逻辑很重要。要求PM对整个产品的架构烂熟于心，哪个模块需要以什么样的方式进行更新，如何在网站版的后台组织这些所需要的数据。一个优秀的PM顶半个架构师，这一点不仅仅体现在产品本身某些重要的大逻辑上，在撰写后台需求文档时一样可以体现得淋漓尽致。

• 项目整体进度跟进

    对于整体项目的进度，要做到心里有数，每天更新项目进度表，了解最新的项目进展与动态，解决开发过程中已经出现的问题，并将自己看到的潜在问题尽量扼杀在萌芽之中。当然，最重要的是，所谓跟进，不是每天盯着工程师问进度，更多地是要以描绘产品未来愿景的方式鼓舞士气，让团队中的每一个人都感受到自己肩上的重任并愿意主动地去承担。

• 下一阶段的产品规划

    此处的下一阶段应分为两个部分，一是目前的开发周期完成后就需要添加的新需求或老需求的优化，二是目前产品上线后下一个版本可能要做的需求更新或整体产品的改版。优先级为先做第一部分的事情，再做第二部分的事情。第一部分的事情应形成正式的需求文档，第二部分的事情更多的是以bullet-point的形式出现在PM的记事本中，以方便在产品正式上线后结合用户反馈，快速形成一份新的产品2.0版需求文档。

• 与运营同事合作制定产品的营销推广计划

    PM生孩子，运营养孩子。产品这个小娃娃已经接近出生，后续的养育工作自然应该列入工作计划之中。在这一方面，PM重点需要去做的并不是制定出一份完整的营销推广计划，而是尽可能多地让同你合作的运营同事了解你做出来的这个产品。这个产品是什么？以怎样聪明的方式解决了用户的哪些痛点？这个产品身上所带的情怀与气质是怎样的？这个产品的目标用户群在哪？商业模式又是怎样的？相信如果PM可以帮助一起合作的运营同事搞清楚以上的这些问题，专业的PO同事一定会拿出一份让你拍案叫好的推广计划的。当然，如果PM有一些抖机灵的点子，自然也可以多于PO同事分享，这世界上哪有什么软文，被叫做软文的文章不过是写得烂到家的推广文案。

• 利用专业的测试工具进行有效的QA

    千呼万唤始出来，犹抱琵琶半遮面。产品终于开发完毕，正式进入QA阶段，没有大公司必备的专业测试框架，我们至少还有这双手。撰写测试用例，然后逐条测试，以保证产品的稳定性、流畅性、易用性。

【产品规划】产品正式进入全面开发阶段，产品经理每天的工作是什么？