examples/3p-updates.md
3.2 KB查看排版效果| 1 | ## Instructions |
| 2 | You are being asked to write a 3P update. 3P updates stand for "Progress, Plans, Problems." The main audience is for executives, leadership, other teammates, etc. They're meant to be very succinct and to-the-point: think something you can read in 30-60sec or less. They're also for people with some, but not a lot of context on what the team does. |
| 3 | |
| 4 | 3Ps can cover a team of any size, ranging all the way up to the entire company. The bigger the team, the less granular the tasks should be. For example, "mobile team" might have "shipped feature" or "fixed bugs," whereas the company might have really meaty 3Ps, like "hired 20 new people" or "closed 10 new deals." |
| 5 | |
| 6 | They represent the work of the team across a time period, almost always one week. They include three sections: |
| 7 | 1) Progress: what the team has accomplished over the next time period. Focus mainly on things shipped, milestones achieved, tasks created, etc. |
| 8 | 2) Plans: what the team plans to do over the next time period. Focus on what things are top-of-mind, really high priority, etc. for the team. |
| 9 | 3) Problems: anything that is slowing the team down. This could be things like too few people, bugs or blockers that are preventing the team from moving forward, some deal that fell through, etc. |
| 10 | |
| 11 | Before writing them, make sure that you know the team name. If it's not specified, you can ask explicitly what the team name you're writing for is. |
| 12 | |
| 13 | |
| 14 | ## Tools Available |
| 15 | Whenever possible, try to pull from available sources to get the information you need: |
| 16 | - Slack: posts from team members with their updates - ideally look for posts in large channels with lots of reactions |
| 17 | - Google Drive: docs written from critical team members with lots of views |
| 18 | - Email: emails with lots of responses of lots of content that seems relevant |
| 19 | - Calendar: non-recurring meetings that have a lot of importance, like product reviews, etc. |
| 20 | |
| 21 | |
| 22 | Try to gather as much context as you can, focusing on the things that covered the time period you're writing for: |
| 23 | - Progress: anything between a week ago and today |
| 24 | - Plans: anything from today to the next week |
| 25 | - Problems: anything between a week ago and today |
| 26 | |
| 27 | |
| 28 | If you don't have access, you can ask the user for things they want to cover. They might also include these things to you directly, in which case you're mostly just formatting for this particular format. |
| 29 | |
| 30 | ## Workflow |
| 31 | |
| 32 | 1. **Clarify scope**: Confirm the team name and time period (usually past week for Progress/Problems, next |
| 33 | week for Plans) |
| 34 | 2. **Gather information**: Use available tools or ask the user directly |
| 35 | 3. **Draft the update**: Follow the strict formatting guidelines |
| 36 | 4. **Review**: Ensure it's concise (30-60 seconds to read) and data-driven |
| 37 | |
| 38 | ## Formatting |
| 39 | |
| 40 | The format is always the same, very strict formatting. Never use any formatting other than this. Pick an emoji that is fun and captures the vibe of the team and update. |
| 41 | |
| 42 | [pick an emoji] [Team Name] (Dates Covered, usually a week) |
| 43 | Progress: [1-3 sentences of content] |
| 44 | Plans: [1-3 sentences of content] |
| 45 | Problems: [1-3 sentences of content] |
| 46 | |
| 47 | Each section should be no more than 1-3 sentences: clear, to the point. It should be data-driven, and generally include metrics where possible. The tone should be very matter-of-fact, not super prose-heavy. |
文件内容是平台检查时读出的文本，只供查看。平台不会运行包里的任何脚本或程序。
