top of page

Product Frameworks

​

Below are some mental models I keep in mind in my day-to-day to help with a variety of aspects of my role as a Product Manager. Some of these can apply to other functions, or even to life outside of work. I'll eventually write a post about each of these topics, but for now they're [relatively] concisely in one page.

​

Other related topics I've written about:

  1. Product Management resources

  2. Product interviewing

  3. How I think about my career

  4. Cross-functional collaboration

  5. Running a crisis prevention team

​

​

Frameworks in order:

  1. Cross-functional collaboration

  2. Communication

  3. Being concise

  4. Writing things down

  5. Keeping track of todos

  6. Knowing that what you’re doing is worth doing

  7. Creating a product strategy

  8. Leading a brainstorm

  9. Testing ideas before investing time into them

  10. Driving consensus with stakeholders

  11. Growing others on your team

  12. Giving people feedback

  13. Getting behind-the-scenes eng work recognized (e.g.: backend/infra/platform work)

  14. Feature requests/bugs from stakeholders, but you don’t want to prioritize them:

  15. Investing in processes and systems to keep team effective long-term 

  16. Making the case for getting incremental support for your team (eng/PM/TPM/Design/Analytics/etc.)

  17. Individual contributor Product Manager vs manager of Product Managers

  18. Picking good metrics

  19. Goal alignment

  20. Tie-breaking disagreement

  21. Trust building

  22. Org design

  23. How to structure a growth org

  24. Managing up

  25. Should you go for a promotion? If so, how to get it

  26. Incentive structures and values

  27. Quarterly/half retrospectives for team

  28. Running an exec review (in a large company)

  29. Evaluating if you’re ready to expand scope (aka get promoted)

  30. Self-reflection for perf reviews

 

Cross-functional collaboration

​​

  1. What I learned about cross-functional collaboration from being a PM at Lyft

​

Communication

​​

  1. Optimize for over-sharing

    • Don’t risk preventing others access to info that would be helpful to them

  2. Make sure to optimize for understandability of what you’re communicating

    • Don’t bury the lede - your ask / main point should be at the top!

    • Optimize your comms’ for your audience

      • Don’t actually want to know all the context upfront

      • Tons of emails already

      • Bored with long content

    • It’s not useful to communicate a ton of stuff to people if they’re not reading/listening to it

    • Minimize noise, maximize signal: highlight key takeaways and use minimal words / avoid being verbose

  3. Treat emails like synchronous conversations

    • Incrementally provide context as the other person asks for more, rather than overloading them with a rant upfront

  4. Use the simplest possible language

    • Avoid acronyms or fancy words that most people don’t know

    • If you can't explain it simply, you don't understand it well enough

    • If your message has words that would get highlighted by this simple writing checker, consider simplifying

  5. Occasionally check with audience to make sure that frequency/method/content of communications work well for them, and adjust if not

 

Being concise

​​

  1. Think about the audience for your comms and optimize for them (get a ton of emails and docs already, bored with long content, don’t actually want to know all the context upfront)

  2. Treat emails like synchronous conversations - incrementally provide context as the other person asks for more, rather than overloading them with a rant upfront

  3. Treat docs like a choose your own adventure:

    • Start with just the info everyone needs

    • Give people options to open supplementary material that they think they need (rather than putting it all in front of them off the get-go)

  4. If your message is longer than 250 words, include a TL;DR at the top

    • Even better - if it’s super long write up a doc about it and link it in the message so it’s not even visually taking up space in the first message

 

Writing things down

​

  1. You’ll forget things. Important things that will set your team back.

  2. Write down everything. All notes from team meetings, from 1:1s, etc.

    • Have a doc for every person you have 1:1s with and for every recurring meeting you’re in
      • Header for every day you had a 1:1, set of topics beforehand, notes afterwards of what you talked about, and highlight action items

    • Track what was talked about for posterity as well as action items

 

Keeping track of todos

​

  1. Consolidate all action items into one list so that it’s easy to track what you want to get done

  2. My system is breaking all action items into:

    • New and unprioritized: Get random thoughts out of head, trust that it’s written down somewhere and will be prioritized later

    • Backlog (On Ice): Things I want to eventually do, but not urgent or time-bound

    • Waiting On: Blocked by someone else (e.g.: waiting for a person/org to get back to me on something)

    • This Week: Keep in mind what’s being worked on throughout the week

    • Today: Focus for today

    • Done: For posterity

  3. Any given task should be one discrete thing - if it’s overloaded into multiple actionable things break it down into pieces and if they’re still related to each other tie them together with a theme of some sort (e.g.: “epic" in product speak)

  4. Tools:

    • For teams: JIRA

    • For yourself: one doc with action items, Todoist, Trello, whatever works best for you!

 

Knowing that what you’re doing is worth doing

​

  1. Applies to progressional things like prioritizing backlog of projects/action items for self and for team, and also to life stuff like if you’re on the right career path

  2. Think about what matters the most to you / your team and figure out how to measure it (what game are we playing and how are we keeping score)

    • Anything you’re considering doing should map well to these goals/metrics

  3. Ask “why?” a bunch of times for a given thing you’re doing / are being asked to do until you feel like you understand root cause well

    • For things that you’re spending a lot of time on in life, like your career, ask “why?” a bunch of times until you feel like you understand why you’re investing so much of your time into it. If you think the real reason why is a good thing, keep doing it. If not, maybe don’t.

 

Creating a product strategy

​

  1. Make sure you are clear on what you are forming a strategy for

    1. Define all key terms and goals you are working with

  2. Define your key objectives

    • Ideally quantitatively measurable
      • In some product areas this is harder (e.g.: safety, compliance, social impact). Approximate as closely as possible, and involve human/qualitative intuition as needed

    • How will you know your strategy is effective in accomplishing your goal?

  3. Define your target users and customers

    • Who will be using the product? (users)

    • Who will be paying for the product? (customers, does not always == users)

    • What are their use cases? Articulate some stories from their point of view

  4. Map the steps your user needs to go through to reach the ideal behavior that supports your key objectives

  5. Understand the current state of this journey

    • If existing product, data and qualitative insights on where gaps exist today

    • If not-yet-existent product, qualitative research into what users think of your perception of the steps

  6. Brainstorm possible solutions to close gaps

  7. Prioritize solutions based on ratio of `eng cost` / `impact to your key objectives`

 

Leading a brainstorm

​

  1. Materials needed

    • Pack of sticky notes and pen/sharpie per person

    • Wall where you and your team can stick all the sticky notes on throughout the brainstorm

      • Ideally a whiteboard so you can create a couple visual groupings of notes for the brainstorm (late in the brainstorm)

    • Optional: Projector so brainstorm leader can prepare quick slideshow for intro

      • Projector not needed especially if you have a whiteboard - could instead write up context ahead of the brainstorm

  2. Agenda (1.5 hours in total):

    • Introduction (~5 minutes): What is the context/goal around the team that’s brainstorming? Mission, user problems, OKRs, etc.
      • Prepare this ahead of time as either slides or pre-whiteboarded thoughts
    • Step 1 (10-15 minutes): Everyone on your own think of as many ideas as possible for all of the steps your users take throughout their experience
      • Keep in mind what you believe to be the daily/weekly/monthly needs of the user

      • Can pre-define a couple buckets of areas to brainstorm for to provide a bit more structure, or can keep it totally freeform (both are totally valid!)

    • Step 2 (20-30 minutes): One by one, everyone take a turn to go over all of your sticky notes to the group, and place the stickies on a big whiteboard (when there's overlap, layer them over the stickies)

      • If we identified buckets to brainstorm for, can separate the wall into sections to put sticky notes into (can group together live or pre-define buckets)

    • Step 3 (5 minutes): Everyone gets a pen/sharpie, and has 3 votes in total to tally onto specific sticky notes that they think are the most important to focus on in the planning cycle

 

Testing ideas before investing time into them

​

  1. Talk to the users of the idea to validate that they care before investing lots of time into it

  2. Try a hacky/easy way to create a version of the idea first to validate that the idea will be valuable before building it out for real

 

Driving consensus with stakeholders

​

  1. Think through the perspective of what your stakeholders care about

    • What decision-making framework are they using?

  2. Word things from the perspective of how they think and what they want

  3. Start with company-wide goals, ensure alignment there, then go down level by level to the question at hand, ensuring that it maps to the company-wide goals in a language that your stakeholder speaks and agrees with

  4. Could even help to write down somewhere for each key stakeholders how they view the world so you don’t forget how to tailor things to their preferences

 

Growing others on your team

​

  1. Frequent enough 1:1s to keep a pulse on how they’re feeling about their work / the team

    • Maintain 1:1 doc to keep track of themes, action items to improve their work life, etc.

  2. Aim for decentralization of decision-making and ownership

    • PM’s job is to develop frameworks for the team as a whole to align on and then be able to use without the PM in the room
      • Consistent decision-making anyone can make

      • If PM gets hit by a bus tomorrow, does the team have enough to keep executing?

    • All team members should feel (1) ownership to care about team’s problems, and (2) empowerment to autonomously make changes that improve the team

    • All team members should feel comfortable owning communication/getting recognition for their work

      • While PM is ultimately responsible for stakeholder communication and having skills around clear/concise communication, should help all team members to cultivate similar skills and to update the company on wins that they themselves drove

  3. Don’t give teammates direct answers to their questions - give them frameworks that they can apply to solve their own problem and any related/abstracted problem

 

Giving people feedback

​​

  1. Your perception of someone and related feedback you give is solely a reflection of your unique / incomplete perspective of that person

    • Don’t think your perception of someone is the holistic reality of who they are

    • Your feedback for / perspective on someone is an incomplete representation of that person given that you have only seen what you have personally seen

  2. Three levels of feedback and how valuable they are

    • I have X intuitive feeling about someone
      • e.g.: “I feel like this person is really good at Y or really bad at Z"

      • Not super useful nor actionable, and not very helpful to tell someone (or in professional contexts, their manager)

    • I have specific examples of interactions with someone that made my feel a certain way

      • e.g.: “I observed this person do X, and it made me feel Y"

      • Very helpful since it’s actionable (change X behavior is Y reaction it caused is unideal)

    • I have a feeling that someone has some set of values, based on some things I have observed

      • e.g.: "I think that this person believes X, I have Y examples to back up why I think this, which makes me feel Z"

      • Most useful sort of feedback since it has the specificity/examples piece of #2 but also goes the next step to think through what implications that might have on the person’s values (if this person does A, maybe they believe B and would also do C)

  3. Good feedback should always be actionable

    • Concrete ways to improve, or at least to be aware of the thing and be able to incorporate that into future behavior

 

Getting behind-the-scenes engineering work recognized (e.g.: backend/ infra/ platform work)

​

  1. Problem: user-facing eng teams get the most recognition (“sexiest" products)

    • In contrast, ICs on infra/platform/backend teams often don’t feel comparably recognized

    • Need to make sure those ICs get the recognition they deserve

  2. Many tactical ways to solve that, but ultimately most people care primarily about their manager, their director and above, and their mentors recognizing their efforts

  3. Plenty of possible solutions, should experiment and see what works best for your org:

    • e.g.: Ensure your team’s wins get included in org-wide monthly/etc. ship rollups

    • e.g.: “Fix of the Week” where exec recognizes most impactful bug fix/optimization

    • e.g.: One-off comms for big wins and ping org leadership to pile on praise and CC execs

  4. Meta-point: figure out how to solve this for Cities, abstract out to something that can help all behind-the-scenes teams, and socialize so more teams start recognizing ICs better

 

Feature requests/bugs from stakeholders, but you don’t want to prioritize them

​

  1. What is the impact of the task? Ask the reporter to help clarify

  2. Explain why the team cannot afford to prioritize the ask, contextualized around the team’s goals (incentive structure) and ongoing projects (prioritized roadmap)

  3. Keep track of all of these in a bucket of tasks to “hopefully get to eventually"

    • These sort of tickets make for great starter tasks for new engineers on the team. Not relevant to seniority, but rather to familiarity with the code base

  4. Look through these every so often

    • If impact changed, reprioritize

    • If other teams might care about the work, ask them to consider taking it on

    • If there are manual approaches to 80/20 a solution, ask operations partners to explore those

    • If there are common themes across many the requests, might be worth building something more generic that tackles several issues at once

 

Investing in processes and systems to keep team effective long-term

​

  1. Even if you don’t think you have too many things to keep track of now, prep for that future

    • Will eventually be overwhelming / too much to handle ad-hoc

    • Historical work archive will eventually be too much to parse through while doing new work; will make you move slowly when references needed

  2. Invest upfront in processes

    • Regular team check-ins to make sure everyone is on the same page on an ongoing basis (stand-ups, weekly roundups, whatever works best for your team)
      • Set context/vision/short-term goals for the team

      • Can do this for yourself too - set aside time to reflect on where you’re currently at and where you want to be

    • 1:1s and team meetings with notes for them all

  3. Invest upfront in infrastructure

    • Keep things simple and have small/concise workflows/hubs for your teams to work out of. Goal is to make it as quick/easy to move as possible, both today and farther down the line

    • For ops teams: avoid monolithic docs/spreadsheets tracking workflows and opt for / decomp into easier to work out of systems

    • For prod/eng teams: avoid monolithic codebases and opt for / decomp into easier to work out of systems

    • For yourself: invest upfront in a system for tracking your thoughts, to-do’s etc., before you have too many thoughts to remember / too many things you want to do without the organization to actually end up doing them, etc.

 

Making the case for getting incremental support for your team (eng/PM/TPM/Design/Analytics/etc.)

​

  1. Think from the perspective of who you’re asking:

    • They probably have to go ask their manager —> up to execs often to get it approved

    • Everyone needs more headcount; answer why you should get it before other teams

  2. Boils down to: with X more heads we could do Y more projects with Z incremental impact

    • Make it incredibly clear what Z is, backed up with Y as context on how the X incremental heads would get us there

  3. Sometimes Y and especially Z aren’t perfectly clear, but confidently stating that you know you’ll be able to have more impact with more support goes a long way

    • i.e.: I currently don’t have bandwidth to think about long-term team strategy as the PM, that would be unlocked with more support

 

Individual contributor Product Manager vs manager of Product Managers

​

  1. IC PM’s job is to:

    • Own team’s output
      • Execution towards goals

      • Ultimate metric success

    • Increase the team’s capacity

      • Frameworks to speed up and democratize decision-making

      • More headcount as needed

      • Keeping teammates happy and motivated

  2. PM manager’s job is to:

    • Be responsible for their IC PMs doing the above, and making sure themselves too that it happens
      • Give reports autonomy and agency to run their areas their own way, while coaching through challenges and holding accountable for outcomes (both business and relationships)

    • Grow them into their career goals

      • Mentorship and coaching

      • Find opportunities to help reports grow into their goals

    • Serve as an escalation point to help with execution as needed

 

Picking good metrics

 

  1. Start with the user problems / company goals

  2. What user action —> metric best represents those problems/goals?

    • Ideally easily quantitative, but don’t shy away from ones that are less so if they’re the right ones

    • If it needs human judgement to evaluate, instate a quantitative framework/scorecard that the team can consistently replicate (i.e.: a “unsafe score”, and then the metric can be something like to have zero P0-1 “unsafe score” tickets on the platform)

  3. The most important metrics (aka North Star metrics) are often hard to change in a stat sig way quickly

  4. To pick a proxy metric, ask yourself questions like:

    • What would a user do earlier in their user journey that would cause them to do the action represented by the North Star metric? (i.e.: to transact more often, to retain for longer, etc.)

    • If evaluating the success of a proposed new feature: what would a user need to do with this feature that would make them more likely to do the action represented by the North Star metric, that a user who didn’t interact with this new feature would be less likely to do?

 

Goal alignment

​

  1. Do you all have a shared framework for how to make decisions? If not, build one! This is one of the most valuable things PM contribute to teams

  2. The framework should represent business goals and user value in a quantitative way

  3. Debating options should always be grounded in those goals

 

Tie-breaking disagreement

​

  1. Ultimately, PM are not dictators. Things only move forward if everyone on the team is aligned (this is better in terms of culture/values, not just a reality of the role’s responsibilities)

  2. Best you can do at the team level is drive alignment around a decision-making framework and use that to guide debates on what to do

  3. If, despite that, there’s still disagreement, you can use product reviews with leadership to tie break. Align with your org lead ahead of time on your intent to resolve a conflict, set up a review with the stated goal of reviewing a set of options to choose from, and let the larger team with leadership involved reach a conclusion that feels more ubiquitous

 

Trust building

​

  1. Spend time with these partners and become their friend!

  2. Recurring 1:1s, proactively ask for their advice on things, occasional candid lunch or happy hour, etc.

  3. Doing this can not only be genuinely fun, but regardless of how compatibly you are socially, this is super important to make your partners feel heard and respected. And they’ll respect you more in return

 

Some thoughts on org design (not holistic, will add more later)

​

  1. Centralized functions the company needs to be really good at right now (growth team for growth-heavy companies, platform teams for companies with lots of tech debt / unstable, etc.)

  2. Once you’ve gotten good at these, decentralize it for maintenance / instilling good ongoing culture

  3. Decisions on how the org should be structured should be made top-down by someone who supervises all the people / problem spaces; otherwise people will get territorial / not want to give up areas that they currently own, and will end up resenting each other

    • Ideally decisions get made starting from an original position where they don’t know who in the org they’ll be

 

How to design a Growth org: three teams

​

  1. Create new levers

    • Think of new incentives to grow new users, retain existing users, and increase users’ frequency

    • Each lever has a cost curve associated to how much business value you derive from an amount of money pumped into

  2. Optimize existing levers

    • Move the cost curves down for each existing lever by optimizing how efficient it is (lower CPA, improve conversion rate, etc.)

  3. Allocate budget across all levers

    • Allocate growth budget across all levers such that an incremental dollar put into any lever yields equivalent business value (at this point they’re all perfectly balanced)

    • For most companies this starts off as a manual process, either centralized across the entire platform or distributed to local teams that own their markets’ PnL

    • Goal should be to automate this process

 

Managing up

​

  1. Make sure you’re aligned with your manager on what you’re expected to deliver and how the your outcomes will be evaluated

  2. Overcommunicate context and progress so they can never say they didn’t know something about your team

  3. Worry about all the things related to your area before your manager has the chance to

    • Poke holes in your own work (imagine you’re reviewing your own work), think proactively of risks/opportunities, etc.\

 

Should you go for a promotion? If so, how to get it

​

  1. What do you want out of your career? (Read this)

    • Write it down, like I did here

    • If the next path on your career track would help you to accomplish your career goals, go for it!

    • If not, don’t do it just for the sake of doing it. Be authentic. (Read this)

      • Don’t subscribe to the rat race. There’s no need to continuously go for the next level in your field. Once you’re operating at a level that you find intellectually interesting, that achieves the impact you want to be affecting, that pays you what you need to live the lifestyle you want to live, while still having the balance with other parts of life that you care about, and whatever else is important to you, you should feel content with that

  2. Do you think you’re not making as much money as you should be making?

    • Do you know what the market rate is for people at your level in your role with your scope at companies of a similar size?
      • If not, interview around and/or ask people in other companies to get comparison data points

    • Is what you’re currently making in that range? Either at your current level or at the level that you think you should be performing at?

      • If not, this is a good reason to go for a recalibration of pay and/or promotion

  3. How to get it

    • Understand what the expectations are at the next step of your career path

    • Align with your manager explicitly on what the gaps are between where you’re currently at and where you need to be to be at that next level (and write it down)

    • Work to demonstrate those things, and if your manager agrees / is able to convince other decision-makers of the same thing, you should get it!

    • If you think you’re ready and your manager / other decisions-makers don’t, either accept this and keep working towards alignment, or go work somewhere else that values you at that level (Read this)

 

Incentive structures and values

​

  1. Every company has its own set of incentive structures to get you to behave and perform in ways that are deemed best for the company’s goals and culture

  2. This typically boils down to “what things you need to do to get promoted / to get a raise”

    • Can also come up in other ways, like what leadership recognizes people for
      • e.g.: "employee of the month" type awards

  3. Some examples of these might be:

    • Driving business impact (promoted/recognized based on outsized contribution to OKRs)

    • Being liked by teammates (peer reviews heavily weighted in promotion process)

  4. What you’re incentivized to do is just as important as what you’re not being incentivized to do

    • e.g.: Helping other people/teams if what they need your help on isn’t related to the OKRs you’re meant to hit

    • e.g.: Doing what’s morally just for the people impacted by the product you build, even when it conflicts with the OKRs you’re meant to hit

  5. If you care about the rewards that are being used to motivate you (i.e.: getting a promotion):

    • Understand what the most important incentive structures are and optimize your time in your role to deliver on those things
      • e.g.: Drive metric impact, don’t help other teams if it doesn’t help you meet your goals, be really friendly to the people who will be your peer reviewers / who will be responsible for getting you promoted

  6. But it’s most important to think deeply about:

    • What your personal values are
      • For me, it’s helping/growing other people around me, and making sure the products I build do the most good for the people it touches (and inversely, that the products I build don’t do harm to those people)

    • And if the incentive structures of your company align with your values

  7. Fortunately, on a long enough time horizon, the incentive structures for success transcend whatever your company set up locally

    • Treating others with respect and compassion, and giving to others, develops the sort of relationships that will support and inflect your career

 

Quarterly/half retrospectives for team; basically ask the following questions

​

  1. How did we go about setting our OKRs for this planning period?

    • Why did we think at the time that these were the right goals?

    • How did we set the targets?

  2. How did we go about prioritizing our projects for this planning period?

    • Why did we think at the time that these were the right projects?

    • How did we do the cost estimates and estimated ship dates?

  3. For the OKRs we missed, why was that?

  4. For the projects that took longer than planned, why did that happen?

  5. What did we learn from the above that has influenced how we'll be planning/executing in the next planning period?

​

Leading an exec review (in a large company)

​

  1. Know what your goal is

    • Alignment on the strategy you’re currently executing against? Looking for more perspectives on the strategy? Etc.

  2. Understanding your audience

    • Ask your main audience members directly what they want to get out of the review (goals, agenda items, questions on their mind, etc.)
      • And in what format they want to discuss (slides, word doc, etc.)

    • Anticipate the communication preferences of your main audience members (more visual/abstract, likes to get technical/in the weeds, etc.)

    • Anticipate the main questions that will be asked based on your planned content

      • Have canned answers/data prepared

      • Prime allies who’ll be in the review ahead of time to advocate for the outcomes you’re aiming for

      • Be open-minded and genuinely try to learn from the alternative opinions you’ll find in the meeting. We’re all in this together and you definitely haven’t thought through everything  🙂

  3. Building bridges

    • If the main audience member(s) have many layers of management, try to pre-review with their relevant reports (if they’re involved / will be in the room) to make sure they’ll be aligned

    • Spend time with team leads you’ll want on your side ahead of time. Meet with key stakeholders 1:1 (or in groups), and have larger “decision-making session” pre-reviews with them

  4. Getting your team involved

    • Your engineers, scientists, designers, etc. inevitably do a majority of the work (analyses, design, etc.) that is the basis for the review

    • Include them upfront in planning the content

    • Identify functional leads to have at the review

      • Ask them to sit with you at the table during the meeting

      • Encourage them to speak up throughout the meeting when questions relative to their work comes up

  5. Keeping focus

    • Keep the meeting as small as possible to avoid randomization / loss of focus

    • During the meeting, start with a clear agenda

      • TL;DR of the content, key questions for the reviewers, and intended outcomes for the meeting

    • Throughout the meeting, overtly note key decisions that are made (committing to X, punting on Y until later, open question Z needs to be answered next time, etc.)

      • Make this super clear to everyone in the room - could even write it on a whiteboard

      • Send this out to everyone at the end of the meeting

    • When the meeting gets derailed (inevitable), find a good balance of keeping the room in check time-wise while letting strong personalities air out the things they care about (otherwise they’ll keep finding ways to bring it up)

    • When a point of debate is brought up where you want to make sure a specific perspective is considered, proactively ask the subject matter expert in the room specific questions that’ll get them engaged (eg: “Hey X, what do you think? How might this affect Y?")

  6. Be humble

    • When good things are discussed, thank the people who actually made it happen (hint: not yourself)

    • When bad things happen (bad test results, accidental misrepresentation of some facts, etc.), acknowledge it, say its your fault, and move on

 

Evaluating if you’re ready to expand scope (aka get promoted)

​

  1. Bring it up with your manager proactively!

    • There’s zero chance you’ll progress if you don’t bring it up yourself

    • While bringing it up doesn't guarantee a promo automatically of course, it helps get the promo next cycle

  2. Set a plan with them around what you need to demonstrate to provide enough evidence to justify getting more scope

    • Write it down so you can point to it later and say you’ve executed towards it

    • If your manager isn’t able to articulate specific things you need to do to get to the next level, ask them (and yourself) why you’re not already at that next level now then

  3. Differentiate between `scope of current role` and `how much the company trusts you to autonomously drive impact within your scope`

    • The fact that your role has a lot of scope means people see lots of potential in you and think you can grow quickly to fill those shoes

    • That’s different from showcasing over a reasonable period of time that you can effectively and autonomously drive impact at that level of scope, to the extent that your leadership trusts to let you run that area without supervision

      • “Reasonable period of time” definition depends on the company - typically 12 months unless you CRUSH things for 6 months. But that’s more of a manager-by-manager sort of thing

 

Self-reflection for perf reviews

​

  1. Why are you writing a self-reflection? How will it be used during perf / calibration?

  2. Let’s say it’s to help your manager to write up their summary of your performance for the calibration committee to read and decide on your rating based on

  3. If that’s the case, then your manager is your audience, and the calibration committee will see what your manager writes up based on your self-reflection

  4. In which case, you want to write up a self-reflection that is optimized to help your manager best represent you the way they think about representing their reports

  5. Talk to your manager, get their preferred way of doing it, and write it that way! (eg: with all my managers, I get a template from them on how they want self-reflections to be formatted / what stuff to focus on)

bottom of page