【中英文本】产品经理基础课程-Product Management Fundamentals 4
Sprint checkpoints
Next up we'll look at the sprint process and the product manager's role in it.
接下来，我们会讨论快速冲刺迭代周期以及该过程中产品经理的职责
A sprint is typically one to three weeks during which time the team has a fixed scope of work.
一个快速冲刺迭代周期通常是一到三周，在此期间团队有固定的工作内容。
The user stories that the team has committed to finishing.
即团体承诺要完成的用户故事
As a product manager you need to protect the team from any changes to stories or scope during the sprint.
作为产品经理，你需要保护团队在快死冲刺迭代期间用户故事或范围的不会有任何更改。
As this causes disruption and inefficiency.
这将会造成中断以及低效率
So you need to make sure that stories are ready by the time the sprint starts.
所以在快速冲刺迭代周期开始前，你要确认用户故事已经被准备好了
There are several checkpoints with the team and typically these are held as meetings.
团队有几个检查点，这些检查点通常以会议的形式举行。
A week or two before the sprint starts the full team should hold a kickoff where you review the major stories that you are recommending for the next sprint and why.
在快速冲刺迭代周期开始前一两周，整个团队应该举行一次启动仪式，回顾你为下一个快速冲刺迭代周期准备的主要故事以及原因。
Any data that you've collected reinforce the priority of the work, including forecasts, if you have them.
你收集的任何数据都能论证工作的优先级，包括预测（如果有的话）
I also combine these meeting with backlog grooming.
我还将这些会议与需求池梳理相结合。
Backlog grooming is when you discuss upcoming work that may be a couple of sprints out.
需求池梳理是指即将进行的工作，这些工作可能有几个快速冲刺迭代周期。
And get input on rough level of effort, relative priority and issues or unknowns that you need to track down in order for the story to be ready for development.
并获取有关工作量相对粗略的优先级的反馈，以及需要跟踪的问题或未知情况，以便为故事开发做好准备
Shortly before the start of the sprint, the team meets again to bid on the work.
在快速冲刺迭代周期开始前不久，团队会再次开会讨论工作。
This is where the team has a conversation to agree upon the estimated level of effect.
这是团队进行对话以商定预估效果的时期。
Typically measured in story points.
通常以故事点为衡量
Story points don't translate directly into hours or days but rather are a relative indication of effort.
故事点不会直接转化为小时或几天，而是工作量的相对指示。
Sometimes larger stories are assigned to developers to research or scope before the bidding meeting.
有时，在讨论会议之前，较大的故事会分配给开发人员进行研究或确定范围。
During the bidding meeting, multiple devs bid on each story.
在讨论会议期间，开发人员会对每个故事进行评判。
Even if they won't be building it.
即使是不开发它
And then the team discusses discrepancies and bid or estimation sizes which is helpful to ensure that everyone is on the same page regarding assumption about how something will be built.
接下来团队会讨论差异并且讨论或预估故事的大小，这有助于确保每个人都对如何开发持相同态度。
Design and test also comment on work required on their parts to complete the story.
设计和测试也会评价完成故事所需要的工作
As a product manager you should go into the bidding meeting with slightly more stories prepared than you expect will be possible in the upcoming sprint.
作为产品经理，你应该准备比接下来的快速冲刺迭代周期预期所需要的，更多的故事来参加讨论会议。
You should have the stories prepared along with the acceptance criteria.
你应该根据可接受的标准准备故事
Base on the bids, the team collectively draws a commitment line to reflect the stories that you have high confidence you'll be able to complete base on the team's historical velocity.
根据讨论结果，基于以往的团队开发效率，团队共同划下了能够顺利完成故事的承诺线。
That is the average number of story points that they've completed in recent sprints.
团队以往效率是在最近几个快速冲刺迭代周期中完成的故事点的平均数量。
It's also a good idea to have a few smaller one to two point stories that are ready to build that could be nice to have work items below the commitment line for any sprint.
准备构建一些较小的一到两点故事也是一个好主意，这些故事对于任何快速冲刺迭代周期的承诺线以下的工作项可能会很好。
At the end of the sprint, the team demos their work at minimal to you as the product owner, but ideally showing it to the broader team.
在快速冲刺迭代周期结束时，团队以最小的方式向作为产品负责人的你演示他们的工作，但理想情况下也会向更广泛的团队展示。
Even if it's back-end work, it's helpful for the team to talk about what they build.
即使是后端工作，这对团队讨论他们的开发内容也很有帮助。
This is a great opportunity to celebrate the team success and remind them and extended team about why the work is a priority and how it fits into the broader goals.
这是一个很好的机会来庆祝团队的成功，并提醒他们和其它团队为什么这一工作优先级高以及它如何匹配更大的目标。
For the product team that i've led, we've had open all hands demos every other week and any team that was ready to talk could do so.
对于我领导过的产品团队，我们每隔一周就会进行一次开放演示，任何准备好交谈的团队都可以这样做。
Ideally have one of the developers or designers walk through woodchipped and explain why this is a priority for the company.
理想情况下，让其中一位开发人员或设计师参与，并解释为什么这是公司的优先事项。
I also think that this demo meeting is a great venue for PMs to share metrics and customer feedback from recent releases.
我还认为，这次演示会议是产品经理分享最近发布的指标和客户反馈的绝佳场所。
At the end of the sprint, the smaller core team perform a retrospective.
在快速冲刺迭代周期结束时，由较小的核心团队执行回顾工作。
Where you discuss what went well, what didn't go well and what changes you'd like to make in the future.
在这里，你可以讨论哪些方面进展顺利，哪些方面进展不顺利，以及将来希望做出哪些改变。
In these meetings you'll find that you need to actively take notes or assign someone to do so.
在这些会议中，你会发现你需要主动做笔记或指派某人做。
Send out the notes after the meeting reflecting decisions and action items and their owners.
会议结束后将反映决策和行动，及其相关负责人的会议记录发送出去。
We've reviewed the key checkpoints in the sprint process and will now talk about what your specific role and deliverables roles are throughout the sprint timeline.
我们已经回顾了快速冲刺迭代周期中的关键检查点，现在将讨论你在其中的特定职责和可交付成果职责
PO activities
In order for the development team to be ready to start work at the beginning of a sprint, there is quite a lot of pre-work that needs to be done first.
为了让开发团队在快速冲刺迭代周期开始前做好充足的准备，有一些前置工作需要优先完成
Your preparation work starts a good four weeks before the start of a sprint.
你的准备工作应该在快速冲刺迭代周期开始前的大约四周开始。
When you should be getting input from dev and design on costs, drafting the forecast model and securing executive buy-in that the project is worthwhile.
在这个阶段，你应该从开发和设计团队那里获得成本信息，制定预测模型，并确保高管认可该项目的价值。
When you have agreement that this is the work that you'd like to do, you update the roadmap and backlog.
当你们达成一致，确认这是你希望完成的工作后，你要更新路线图和待办事项清单。
Next you need to ensure that any external dependencies are cleared up.
接下来，你需要确保清理掉所有的外部依赖。
To the extent that your solution requires third-party integrations, you'll need to make sure that you have the appropriate licenses and deals in place.
在你的解决方案需要第三方集成的情况下，你需要确保已经获得了适当的许可和合作协议。
Keep in mind that three weeks is too short to negotiate a custom agreement with a third party.
请记住，对于与第三方进行定制协议的谈判来说，三周的时间是不够的。
So stories may need to get pushed out if that's the case at least by three weeks out.
所以，如果情况如此，用户故事开发可能需要推迟至少三周。
You should also be getting input from the extended team, including marketing, sles, legal operations, customer service and so on.
你还应该向其它团队包括营销、销售、法务、运营、客户服务等征求意见。
Some of these teams, such as sales and customer support, need time to build training materials and marketing needs time for press releases or other campaigns.
某些团队，如销售和客户支持，需要时间制作培训材料，而营销团队则需要时间准备宣传稿或其他营销活动。
So you need to involve them early enough that they can be prepared.
所以你需要尽早地让他们参与进来，以做好准备
At this time you should be working with interaction designers on customer flows and wireframes.
此时，你应该与交互设计师合作，进行客户流程和线框图的设计。
You should also engage user research to line up tests of competitor implementations or ready testers to give input on what the team is planning on building.
你还应该参与用户研究，以进行对竞争对手实现的测试，或准备测试人员，以便他们能够对团队计划构建的内容提供反馈。
Finally you should be preparing the kickoff materials to show to the core team.
最后，你应该准备启动材料，以展示给核心团队。
These can include the data indicating why this work is worthwhile and high level user flows.
这些材料可以包括表明为什么这项工作是有价值的数据和高级用户流程。
Within about two weeks from the start of the sprint, you should be working with design and dev to create whatever level of documentation is needed for your team.
在离快速冲刺迭代周期开始还有大约两周的时间时，你应该与设计和开发团队合作，创建团队所需的任何级别的文档。
That may just be wireframes if you have a well-established style guide or your team may require much higher fidelity clickable prototypes.
这可能只需要简单的线框图，如果你有一份完善的样式指南，或者你的团队需要高保真的可点击原型
At the same time you should be fleshing out the user story with more detail, including acceptance criteria so that these are ready for scoping and bidding.
同时，你应该进一步完善用户故事，包括验收标准以便为其进行限定和讨论
During the sprint, product owners should attend daily standups and make themselves available daily at minimum over chat or phone for any questions that come up.
在快速冲刺迭代期间，产品负责人应该参加每日站立会议，并至少保证电话畅通，以回答任何出现的问题。
Along with testers, you will be expected to review all stories as they are completed to ensure that they meet the goals for the work and expected quality.
作为产品负责人应该同测试人员一起，在所有故事完成后进行审核，以确保它们符合工作目标和预期的质量要求。
This may be referred to as user acceptance testing or UAT, where you'll represent the user or customer.
这可能被称为用户验收测试或UAT，你将代表用户或客户进行测试。
As a result of QA testing and UAT, inevitably some bugs or other issues will be introduced within the work in the progress.
经过QA测试和UAT，不可避免地会出现一些错误或其他问题。
Generally speaking you want to make sure that you don't ship with a new problem that you're not willing to live with for an extended period of time.
一般来说，你要确保不要在发布时出现一个你不愿意长期忍受的新问题。
Regularly shipping with known bugs that need fixing just adds to technical debt and is unsustainable.
经常性地发布带有已知BUG的产品只会增加技术债务，并且是不可持续的。
Finally during and shortly after the release, you'll communicate with the extended team to provide release notes.
最后，在发布期间和发布后不久，你将与其它团队进行沟通，提供发布说明。
You should have been coordinating for several weeks now with sales, marketing and support to ensure that their teams are prepared.
在这几周内，你应该一直与销售、营销和支持团队进行协调，以确保他们的团队做好了准备工作。
You may be asked to do in-person training or otherwise contribute to the collateral they use.
你可能会对他们进行现场培训或以其他方式为给他们提供支撑材料。
Often product managers author blog posts to announce larger releases.
通常，产品经理会撰写博客文章来宣布较大的发布。
So there's a lot to do.
所以，有许多事情要做
Where this gets a bit daunting is when you consider that this timeline only represents one sprint.
考虑到这个时间表只代表一个快速冲刺迭代周期，这可能会生畏。
If you take the case of two week sprints, you have to work for three different sprints overlapping on this timeline.
如果以两周为周期的快速冲刺迭代周期为例，你需要在这个时间表上同时处理三个不同的快速冲刺迭代周期。
Moreover some product managers are asked to support multiple sprint teams.
此外，一些产品经理被要求支持多个快速冲刺迭代团队。
No doubt the build stage is where many product managers spend the majority of their time, particularly those with product owner or technical product manager titles.
毫无疑问，对于许多产品经理来说，构建阶段是他们花费大部分时间的阶段，尤其是那些担任产品负责人或技术产品经理职位的人员。
To recap, you're responsible for the roadmap and backlog and the prioritized to user stories and acceptance criteria that populate the backlog.
回顾一下，作为产品经理，你负责制定产品的路线图、需求池、对用户故事排优先级和验收标准，这些内容填充了待办事项列表。
You also perform acceptance testing and ensure that the extended team has signed off on the work and is prepared for what is shipping.
你还执行验收测试，并确保其它团队对工作进行了确认，并做好了准备以发布产品。
Depending on whether your team is large enough to have adjacent positions, such as program managers, project managers and information architects.
根据你的团队规模是否足够大，可能还会有一些关联职位，如项目经理、项目经理和信息架构师等。
You may need to fill in other functions on a sprint team that aren't typically the product owner role.
在一个快速冲刺迭代团队中，你可能需要承担一些非产品负责人角色的职能
For example you may be expected to create user experience flows or wireframes.
例如，你可能需要负责用户体验流程或线框图。
Some product managers run usability studies on upcoming and recently released features.
一些产品经理会对即将发布或最近发布的功能进行可用性研究。
And while this role can be filled by program or project managers or dev leads, you may need to act as scrum master for the agile team as well.
虽然这个角色可以由项目经理或开发负责人来担任，但你可能还需要充当敏捷团队的Scrum Master。
The next step to discuss relates to customer engagement, acquiring and retaining customers.
接下来要讨论的内容有关用户参与度，获客和留存用户。
Sprint checkpoints
Next up we'll look at the sprint process and the product manager's role in it.
接下来，我们会讨论快速冲刺迭代周期以及该过程中产品经理的职责
A sprint is typically one to three weeks during which time the team has a fixed scope of work.
一个快速冲刺迭代周期通常是一到三周，在此期间团队有固定的工作内容。
The user stories that the team has committed to finishing.
即团体承诺要完成的用户故事
As a product manager you need to protect the team from any changes to stories or scope during the sprint.
作为产品经理，你需要保护团队在快死冲刺迭代期间用户故事或范围的不会有任何更改。
As this causes disruption and inefficiency.
这将会造成中断以及低效率
So you need to make sure that stories are ready by the time the sprint starts.
所以在快速冲刺迭代周期开始前，你要确认用户故事已经被准备好了
There are several checkpoints with the team and typically these are held as meetings.
团队有几个检查点，这些检查点通常以会议的形式举行。
A week or two before the sprint starts the full team should hold a kickoff where you review the major stories that you are recommending for the next sprint and why.
在快速冲刺迭代周期开始前一两周，整个团队应该举行一次启动仪式，回顾你为下一个快速冲刺迭代周期准备的主要故事以及原因。
Any data that you've collected reinforce the priority of the work, including forecasts, if you have them.
你收集的任何数据都能论证工作的优先级，包括预测（如果有的话）
I also combine these meeting with backlog grooming.
我还将这些会议与需求池梳理相结合。
Backlog grooming is when you discuss upcoming work that may be a couple of sprints out.
需求池梳理是指即将进行的工作，这些工作可能有几个快速冲刺迭代周期。
And get input on rough level of effort, relative priority and issues or unknowns that you need to track down in order for the story to be ready for development.
并获取有关工作量相对粗略的优先级的反馈，以及需要跟踪的问题或未知情况，以便为故事开发做好准备
Shortly before the start of the sprint, the team meets again to bid on the work.
在快速冲刺迭代周期开始前不久，团队会再次开会讨论工作。
This is where the team has a conversation to agree upon the estimated level of effect.
这是团队进行对话以商定预估效果的时期。
Typically measured in story points.
通常以故事点为衡量
Story points don't translate directly into hours or days but rather are a relative indication of effort.
故事点不会直接转化为小时或几天，而是工作量的相对指示。
Sometimes larger stories are assigned to developers to research or scope before the bidding meeting.
有时，在讨论会议之前，较大的故事会分配给开发人员进行研究或确定范围。
During the bidding meeting, multiple devs bid on each story.
在讨论会议期间，开发人员会对每个故事进行评判。
Even if they won't be building it.
即使是不开发它
And then the team discusses discrepancies and bid or estimation sizes which is helpful to ensure that everyone is on the same page regarding assumption about how something will be built.
接下来团队会讨论差异并且讨论或预估故事的大小，这有助于确保每个人都对如何开发持相同态度。
Design and test also comment on work required on their parts to complete the story.
设计和测试也会评价完成故事所需要的工作
As a product manager you should go into the bidding meeting with slightly more stories prepared than you expect will be possible in the upcoming sprint.
作为产品经理，你应该准备比接下来的快速冲刺迭代周期预期所需要的，更多的故事来参加讨论会议。
You should have the stories prepared along with the acceptance criteria.
你应该根据可接受的标准准备故事
Base on the bids, the team collectively draws a commitment line to reflect the stories that you have high confidence you'll be able to complete base on the team's historical velocity.
根据讨论结果，基于以往的团队开发效率，团队共同划下了能够顺利完成故事的承诺线。
That is the average number of story points that they've completed in recent sprints.
团队以往效率是在最近几个快速冲刺迭代周期中完成的故事点的平均数量。
It's also a good idea to have a few smaller one to two point stories that are ready to build that could be nice to have work items below the commitment line for any sprint.
准备构建一些较小的一到两点故事也是一个好主意，这些故事对于任何快速冲刺迭代周期的承诺线以下的工作项可能会很好。
At the end of the sprint, the team demos their work at minimal to you as the product owner, but ideally showing it to the broader team.
在快速冲刺迭代周期结束时，团队以最小的方式向作为产品负责人的你演示他们的工作，但理想情况下也会向更广泛的团队展示。
Even if it's back-end work, it's helpful for the team to talk about what they build.
即使是后端工作，这对团队讨论他们的开发内容也很有帮助。
This is a great opportunity to celebrate the team success and remind them and extended team about why the work is a priority and how it fits into the broader goals.
这是一个很好的机会来庆祝团队的成功，并提醒他们和其它团队为什么这一工作优先级高以及它如何匹配更大的目标。
For the product team that i've led, we've had open all hands demos every other week and any team that was ready to talk could do so.
对于我领导过的产品团队，我们每隔一周就会进行一次开放演示，任何准备好交谈的团队都可以这样做。
Ideally have one of the developers or designers walk through woodchipped and explain why this is a priority for the company.
理想情况下，让其中一位开发人员或设计师参与，并解释为什么这是公司的优先事项。
I also think that this demo meeting is a great venue for PMs to share metrics and customer feedback from recent releases.
我还认为，这次演示会议是产品经理分享最近发布的指标和客户反馈的绝佳场所。
At the end of the sprint, the smaller core team perform a retrospective.
在快速冲刺迭代周期结束时，由较小的核心团队执行回顾工作。
Where you discuss what went well, what didn't go well and what changes you'd like to make in the future.
在这里，你可以讨论哪些方面进展顺利，哪些方面进展不顺利，以及将来希望做出哪些改变。
In these meetings you'll find that you need to actively take notes or assign someone to do so.
在这些会议中，你会发现你需要主动做笔记或指派某人做。
Send out the notes after the meeting reflecting decisions and action items and their owners.
会议结束后将反映决策和行动，及其相关负责人的会议记录发送出去。
We've reviewed the key checkpoints in the sprint process and will now talk about what your specific role and deliverables roles are throughout the sprint timeline.
我们已经回顾了快速冲刺迭代周期中的关键检查点，现在将讨论你在其中的特定职责和可交付成果职责
PO activities
In order for the development team to be ready to start work at the beginning of a sprint, there is quite a lot of pre-work that needs to be done first.
为了让开发团队在快速冲刺迭代周期开始前做好充足的准备，有一些前置工作需要优先完成
Your preparation work starts a good four weeks before the start of a sprint.
你的准备工作应该在快速冲刺迭代周期开始前的大约四周开始。
When you should be getting input from dev and design on costs, drafting the forecast model and securing executive buy-in that the project is worthwhile.
在这个阶段，你应该从开发和设计团队那里获得成本信息，制定预测模型，并确保高管认可该项目的价值。
When you have agreement that this is the work that you'd like to do, you update the roadmap and backlog.
当你们达成一致，确认这是你希望完成的工作后，你要更新路线图和待办事项清单。
Next you need to ensure that any external dependencies are cleared up.
接下来，你需要确保清理掉所有的外部依赖。
To the extent that your solution requires third-party integrations, you'll need to make sure that you have the appropriate licenses and deals in place.
在你的解决方案需要第三方集成的情况下，你需要确保已经获得了适当的许可和合作协议。
Keep in mind that three weeks is too short to negotiate a custom agreement with a third party.
请记住，对于与第三方进行定制协议的谈判来说，三周的时间是不够的。
So stories may need to get pushed out if that's the case at least by three weeks out.
所以，如果情况如此，用户故事开发可能需要推迟至少三周。
You should also be getting input from the extended team, including marketing, sles, legal operations, customer service and so on.
你还应该向其它团队包括营销、销售、法务、运营、客户服务等征求意见。
Some of these teams, such as sales and customer support, need time to build training materials and marketing needs time for press releases or other campaigns.
某些团队，如销售和客户支持，需要时间制作培训材料，而营销团队则需要时间准备宣传稿或其他营销活动。
So you need to involve them early enough that they can be prepared.
所以你需要尽早地让他们参与进来，以做好准备
At this time you should be working with interaction designers on customer flows and wireframes.
此时，你应该与交互设计师合作，进行客户流程和线框图的设计。
You should also engage user research to line up tests of competitor implementations or ready testers to give input on what the team is planning on building.
你还应该参与用户研究，以进行对竞争对手实现的测试，或准备测试人员，以便他们能够对团队计划构建的内容提供反馈。
Finally you should be preparing the kickoff materials to show to the core team.
最后，你应该准备启动材料，以展示给核心团队。
These can include the data indicating why this work is worthwhile and high level user flows.
这些材料可以包括表明为什么这项工作是有价值的数据和高级用户流程。
Within about two weeks from the start of the sprint, you should be working with design and dev to create whatever level of documentation is needed for your team.
在离快速冲刺迭代周期开始还有大约两周的时间时，你应该与设计和开发团队合作，创建团队所需的任何级别的文档。
That may just be wireframes if you have a well-established style guide or your team may require much higher fidelity clickable prototypes.
这可能只需要简单的线框图，如果你有一份完善的样式指南，或者你的团队需要高保真的可点击原型
At the same time you should be fleshing out the user story with more detail, including acceptance criteria so that these are ready for scoping and bidding.
同时，你应该进一步完善用户故事，包括验收标准以便为其进行限定和讨论
During the sprint, product owners should attend daily standups and make themselves available daily at minimum over chat or phone for any questions that come up.
在快速冲刺迭代期间，产品负责人应该参加每日站立会议，并至少保证电话畅通，以回答任何出现的问题。
Along with testers, you will be expected to review all stories as they are completed to ensure that they meet the goals for the work and expected quality.
作为产品负责人应该同测试人员一起，在所有故事完成后进行审核，以确保它们符合工作目标和预期的质量要求。
This may be referred to as user acceptance testing or UAT, where you'll represent the user or customer.
这可能被称为用户验收测试或UAT，你将代表用户或客户进行测试。
As a result of QA testing and UAT, inevitably some bugs or other issues will be introduced within the work in the progress.
经过QA测试和UAT，不可避免地会出现一些错误或其他问题。
Generally speaking you want to make sure that you don't ship with a new problem that you're not willing to live with for an extended period of time.
一般来说，你要确保不要在发布时出现一个你不愿意长期忍受的新问题。
Regularly shipping with known bugs that need fixing just adds to technical debt and is unsustainable.
经常性地发布带有已知BUG的产品只会增加技术债务，并且是不可持续的。
Finally during and shortly after the release, you'll communicate with the extended team to provide release notes.
最后，在发布期间和发布后不久，你将与其它团队进行沟通，提供发布说明。
You should have been coordinating for several weeks now with sales, marketing and support to ensure that their teams are prepared.
在这几周内，你应该一直与销售、营销和支持团队进行协调，以确保他们的团队做好了准备工作。
You may be asked to do in-person training or otherwise contribute to the collateral they use.
你可能会对他们进行现场培训或以其他方式为给他们提供支撑材料。
Often product managers author blog posts to announce larger releases.
通常，产品经理会撰写博客文章来宣布较大的发布。
So there's a lot to do.
所以，有许多事情要做
Where this gets a bit daunting is when you consider that this timeline only represents one sprint.
考虑到这个时间表只代表一个快速冲刺迭代周期，这可能会生畏。
If you take the case of two week sprints, you have to work for three different sprints overlapping on this timeline.
如果以两周为周期的快速冲刺迭代周期为例，你需要在这个时间表上同时处理三个不同的快速冲刺迭代周期。
Moreover some product managers are asked to support multiple sprint teams.
此外，一些产品经理被要求支持多个快速冲刺迭代团队。
No doubt the build stage is where many product managers spend the majority of their time, particularly those with product owner or technical product manager titles.
毫无疑问，对于许多产品经理来说，构建阶段是他们花费大部分时间的阶段，尤其是那些担任产品负责人或技术产品经理职位的人员。
To recap, you're responsible for the roadmap and backlog and the prioritized to user stories and acceptance criteria that populate the backlog.
回顾一下，作为产品经理，你负责制定产品的路线图、需求池、对用户故事排优先级和验收标准，这些内容填充了待办事项列表。
You also perform acceptance testing and ensure that the extended team has signed off on the work and is prepared for what is shipping.
你还执行验收测试，并确保其它团队对工作进行了确认，并做好了准备以发布产品。
Depending on whether your team is large enough to have adjacent positions, such as program managers, project managers and information architects.
根据你的团队规模是否足够大，可能还会有一些关联职位，如项目经理、项目经理和信息架构师等。
You may need to fill in other functions on a sprint team that aren't typically the product owner role.
在一个快速冲刺迭代团队中，你可能需要承担一些非产品负责人角色的职能
For example you may be expected to create user experience flows or wireframes.
例如，你可能需要负责用户体验流程或线框图。
Some product managers run usability studies on upcoming and recently released features.
一些产品经理会对即将发布或最近发布的功能进行可用性研究。
And while this role can be filled by program or project managers or dev leads, you may need to act as scrum master for the agile team as well.
虽然这个角色可以由项目经理或开发负责人来担任，但你可能还需要充当敏捷团队的Scrum Master。
The next step to discuss relates to customer engagement, acquiring and retaining customers.
接下来要讨论的内容有关用户参与度，获客和留存用户。
Measure
The last section of the product development cycle is measure where we assess how our products are being received in the market.
产品开发周期的最后一个阶段是“评估”，在这个阶段我们评估产品在市场上的接受程度。
We cover that topic next.
我们接下来谈论这一话题
In our model, like others representing the development cycle, measurement is shown as the final stage of a development loop before cycling back through planning.
在我们的模型中，就像其他代表开发周期的模型一样，评估是在在重新进行规划之前，开发循环的最后一个阶段。
However placing it at the end of the cycle is misleading.
当然，把它放在循环的最后是有点误导的。
Metrics are something that we're thinking about throughout the process and need to be designed and built into the product before it gets released.
指标（Metrics）是我们在整个过程中考虑的内容，需要在产品发布之前进行设计和构建。
By now pretty much all companies track basics such as web traffic and transactional data, registrations, orders, inventory and so forth.
到目前为止，几乎所有公司都追踪基本的数据，例如网站流量、交易数据、注册用户、订单和库存等等。
In software and web connected hardware, analytics are baked into the product itself, through event tracking where we can monitor data such as click paths and time on each page or experience.
在软件和联网的硬件中，分析功能已经内置到产品本身中，通过事件跟踪，我们可以监控诸如点击路径、每个页面或体验的停留时间等数据。
Indeed with the internet of things or IoT, more and more devices from garage doors to vending machines are being shipped with self-reporting capability that opens up incredibly valuable data about product user and reliability.
确实，随着物联网（IoT）的发展，越来越多的设备，从车库门到自动售货机，都配备了自我报告的功能，这为产品的使用和可靠性提供了极其有价值的数据。
As reporting is becoming ubiquitous, tools used to analyze data have become increasingly sophisticated.
随着报告的普及，用于分析数据的工具变得越来越复杂。
Unless you have expertise here, it's wise to involve an analytics expert when designing your product analytics and the events that get captured for later analysis.
除非你在此领域拥有专业知识，否则在设计产品数据分析和后续分析所捕获的事件时，最好请一位数据分析专家参与。
At Urbanspoon we had a data analyst who was an expert in Google analytics and at other companies i've led we've brought in consultants for a few weeks to design our analytics requirements.
在Urbanspoon，我们有一位专家精通Google Analytics的数据分析师。在我领导的其他公司，我们会请顾问为我们设计几周的分析需求。
In general you want to work backwards with analytics because it's easy to go overboard with reporting everything which could be a drag on performance and require excessive amounts of data from the customer.
总的来说，在设计分析需求时，你要从后往前思考。因为上报所有数据可能会对产品性能造成负面影响，并需要从客户那里获取过多的数据。
So focus on designing the dashboard that you and the extended team will regularly use and any exception alerts that will tell you when something is going wrong.
因此，重点是设计你和其它团队将定期使用的数据指示，以及任何异常警报，用于在出现问题时提醒你。
You can derive a wealth of insights from your customer database, including where they are geographically, which segments are your heaviest users and what acquisition channels lead to more or less valuable customers.
你可以从客户数据库中获得丰富的见解，包括他们的地理位置、哪些细分市场是你最重要的用户，以及哪些获客渠道可以带来更有价值的客户。
Ideally you want to set up your data such that you can easily cross tab between web data, product events and customer records.
理想情况下，你希望设置你的数据，以便可以轻松地在网站数据、产品事件和客户记录之间进行交叉分析。
That way you can answer questions such as of people who added an item to their wish list in our mobile app, how many of them were existing registered customers we had seen on the website before versus new users.
这样你就可以回答一些问题，比如在我们的移动应用程序中将商品添加到愿望清单的用户中，有多少是我们之前在网站上看到过的现有注册用户，而有多少是新用户。
In addition to product and transactional analytics most software and web products can take advantage of AB or multivariate testing.
除了产品和交易分析之外，大多数软件和网络产品还可以利用AB测试或多元测试。
Live testing can validate hypotheses on improvements for acquisition, upsell, usability or retention.
实时测试可以验证对于获客、升级、可用性或保留方面的改进的假设。
The reason that you use AB testing as opposed to just releasing and watching what happens is that you want to control for any external variables that may be changing at the same time, such as marketing campaigns, seasonality or discount offers.
使用AB测试而不仅仅是发布和观察结果的原因是你希望控制可能同时发生变化的事件，例如营销活动、季节性或折扣优惠。
Also for more significant changes such as a full site redesign, AB testing allows you to limit your downside risk by exposing the new design to a sub segment of your audience.
同样，对于类似全新设计这种重大变更，AB测试让你可以通过将新设计只暴露给部分受众，从而降低风险。
While this is most common with web enabled and SaaS products, some progress is being made with mobile apps to allow live testing.
虽然这在网页和SaaS产品上最为常见，但在移动应用方面也已经开始应用实时测试。
There are many best practices to correctly execute quantitative testing like this.
有许多优秀的方法可以正确地执行这样的定量测试。
And those are worth further investigation if you are tasked with leading these efforts.
如果你负责领导这些工作，那么这些方法值得进一步研究。
Finally product managers are often involved with reviewing and providing input to financial forecasts, such as budgets.
最后，产品经理经常参与审查并提供对财务预测（如预算）的意见。
The finance team will want to understand major product changes and new product introductions in order to forecast revenue and expense associated with them, including bandwidth and the cost of acquisition and support.
财务团队希望了解主要的产品变化和新产品的推出，以便预测与之相关的收入和支出，包括带宽、获客成本和支持成本等方面的费用。
For all of these areas it's important for product managers to be self-sufficient with regards to accessing data.
对于所有这些领域，产品经理在访问数据方面自给自足是非常重要的。
Try to be fluent with whatever analytics platform your company uses, for example Google analytics in order to answer your own questions about product adoption and use.
努力熟练掌握公司使用的任何分析平台，例如 Google Analytics，以便能够自己回答关于产品采用和使用情况的问题。
If you have a sizeable customer database that you can access, consider learning SQL, so that you can create your own queries.
如果您可以访问到庞大的客户数据库，可以考虑学习 SQL，以便能够自己创建查询语句。
You play an important role in communicating data to the broader team.
你在向整个团队传达数据方面扮演着重要的角色。
Every product change that you make should be viewed as a hypothesis and the results prove or disprove that hypothesis.
每个产品变更都应被视为一个假设，而结果则证明或证伪该假设。
Moreover product use and other customer data are critical inputs into the planning and prioritization process at the beginning of the product development cycle.
此外，产品使用和其他客户数据是产品开发规划和优先级确定过程中的重要参考信息。
Congratulations on completing the product development cycle.
恭喜你完成了产品开发循环课程
Although we've reviewed most of the work of product managers, it's also important for you to realize how your role interfaces with other departments within your company.
虽然我们已经讨论了产品经理的大部分工作，但你也需要意识到你的角色与公司内其他部门的对接也是很重要的。
Before we do that however take a few minutes now to reflect on what we've covered so far.
在我们继续之前，请花几分钟时间回顾一下我们到目前为止所涵盖的内容。
Review the product manager activities list and identify your top three strengths.
回顾产品经理的工作清单，并且找出你自身的三个优势。
For each of these write down ideas for leveraging these strengths.
针对每个优势，写下如何利用这些优势的想法。
Perhaps you could teach others about this area or seek out a leadership role on a project focused here.
也许你可以在你熟悉的领域指导别人，或者在一个专注于这一领域的项目中寻求领导角色。
Also note your three development areas where you need to increase your knowledge or experience.
此外，写下你需要增加知识或经验的三个待发展领域。
Brainstorm ideas for increasing your expertise including shadowing colleagues, taking a class or reading a book.
集思广益，以增加你的专业知识，包括向同事学习、参加课程或阅读书籍。
A day in the life of a PM
After the exercise we'll look at a day in the life of a product manager.
在完成这些练习后，我们将来看一下产品经理一天的工作。
If you've never been a product manager before, you may be curious what an average day looks like.
如果你以前没有担任过产品经理，你可能会好奇一个典型的工作日是什么样的。
Given what we've covered so far, perhaps it's obvious that there is a great deal of variety in day-to-day product manager activities between companies and even while working on the same product.
考虑到我们到目前为止所讨论的内容，很明显，产品经理的日常活动在不同的公司甚至在同一产品上都存在着很大的变化。
I found that i was most effective when i started an hour or two before the development team came in whether that be at home or in the office.
我发现，在开发团队到来之前，提前一两个小时开始工作我能更有效地工作，不论是在家还是办公室。
A typically day might start with getting current on industry news, checking in on key metrics and of course checking email and other communication channels, including messaging and your project tracking software.
一天通常会以了解行业新闻、检查关键指标以及查看电子邮件和其他通信渠道（包括即时消息和项目跟踪软件）为开始。
You'll also want to take time earlier in the day to plan out what you want to accomplish for the day.
你还需要在一天的早些时候花时间规划当天要完成的任务。
Agile stand-ups often occur in the morning to minimize midday disruptions.
敏捷开发的站立会议通常在早上进行，以尽量减少工作期间的干扰。
In distributed teams in different time zones, stand-ups may be virtual with individuals checking in at the beginning of their workday.
在不同时区的远程分布的团队中，站立会议可能是虚拟的，成员在工作日开始时进行签到。
The bulk of your day will be spent working across multiple product releases.
你的一天大部分时间将花在多个产品发布的工作中。
Most urgently you need to unblock the current sprint and make sure that other teams within the company are prepared for launch.
最紧急的任务是解决当前迭代中的问题，并确保公司内的其他团队准备好发布。
You need to track down answers to open questions and clarify objectives.
你需要追踪答案，澄清目标，并解决悬而未决的问题。
You should also review and accept new stories as they are completed.
你还应该审核以及接受完成了的新的用户故事。
You also need to prepare for the next several sprints, including getting designs completed and getting extended team sign off on the team's plan.
你还需要为接下来的几个迭代做准备，包括完成设计工作，并确保计划得到其它团队的认可。
Looking backwards you should review results from the last several sprint release and review product analytics, customer feedback and AB testing results.
回顾过去，你应该审查最近几个迭代发布的结果，并查看产品分析、客户反馈和AB测试结果。
You will find that there are features that are not meeting expectations and it's not worth it to do further work to try to optimize them.
你会发现有些功能并未达到预期效果，并且不值得进一步优化它们。
In those cases removing features is often the best plan.
在这种情况下，移除最好的计划是移除这些功能
Leaving underutilized features adds to product complexity, from both a user perspective and a development overhead perspective and they will slow you down in the future.
留下未充分利用的功能会增加产品的复杂性，无论是从用户角度还是开发负担的角度，它们都会拖慢你的步伐。
Additionally you'll need to support released products and features with respect to sales and marketing.
此外，你还需要支持销售和营销，关于已发布的产品和功能。
Finally you have medium to long-term planning and research, unfortunately this often gets deprioritized given the perceived urgency of the near-term work.
最后，您还需要进行中长期规划和研究，不过很遗憾，由于近期工作的紧迫性，这往往会被放在次要位置。
Indeed a 2015 survey of product managers indicated that 56 percent of PMs said that they focused too much on development in QA and not enough on the other phases of the product life cycle.
事实上，根据2015年对产品经理进行的一项调查，56%的产品经理表示他们过多关注开发和质量保证阶段，而对产品生命周期的其他阶段关注不够。
But as we discussed in planning and validation at the beginning of this course, these phases are key to avoid wasted effort.
正如我们在课程开始时讨论的规划和验证阶段，这些阶段对于避免浪费精力至关重要。
This is when you building forecasts, iterating on your business model canvas and conducting market research and experiments.
在这个阶段，你需要建立预测模型、对商业模式画布进行迭代，并进行市场研究和实验。
You probably won't address all four of there release phases everyday, but certainly over the course of a week, you should be spending time on each of them.
你可能不会每天都处理这四个发布阶段中的所有内容，但在一周的时间内，你应该在每个阶段上都花费一些时间。
The next step in an exercise to reflect on how you spend time.
下一步是反思你如何分配时间的练习。
Write down what percentage of time you want to spend on each of the four release horizons that we just discussed.
请写下你希望在四个发布阶段中每个阶段分配的时间百分比。
Then make a record during a typical week of how you actually spent your time and add up the time for the week.
然后在一个典型的工作周中记录下你实际花费时间的情况，并将一周的时间总和计算出来。
Compare your ideal versus your actual time spent and note step that you can take to reconcile these if they're significantly out of balance.
比较你理想的时间分配与实际的时间分配，如果两者差异显著，思考你可以采取的协调措施。
For example, you could block time each week for longer term thinking or lead a team training session about your market.
例如，你可以每周安排一段时间进行长期思考，或者主持一个团队培训会议，讨论有关市场的内容。
