Product Frameworks

​

Below are some mental models I've been able to summarize from various sources, experiences, notes I have made from before that I would like to keep in mind and try to implement 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 and perhaps a bit overwhelming at once.

​

Frameworks in order:

​​

1. Communication

2. Being concise

3. Writing things down

4. Keeping track of todos

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

6. Creating a product strategy

7. Leading a brainstorm

8. Testing ideas before investing time into them

9. Driving consensus with stakeholders

10. Growing others on your team

11. Giving people feedback

 

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

     • ​Write like this person

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 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 to create 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. 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

​

​