Links

• Brian’s full Course Notes
• Stream on Frontend Masters

On variety of work

I am rarely bored at work. There are certainly tedious things, and a day full of end-to-end meetings can be tough, but I get to engage in so many aspects of product development that it keeps me engaged. I get to dabble in design, development, UX research, people management, resource allocations, recruiting, administration, legal, accounting, etc.

Money related code

a very real problem I faced at Stripe: developers really do not like changing code that deals with money and for good reason: bugs cost real money.

Principles of good communication in Product Management

Audience

Know who you are writing to. How you write a memo to be consumed by everyone at a 10,000 person company will be wildly different than a memo sent to executive leadership. How you run standup for a group of engineers will differ from a gathering of product managers.

A big part of the audience you are speaking with is knowing what you want from them

And on a related note

By highlighting points of unknowns, you can invite your audience to help share the context you are looking for.

Context Setting

You need to give your audience just enough context for them to be able to make a decision

Minimal viable context, if you may.

If some of the people know it and it’s important to your message, give a short summary and link to somewhere they can acquire more context.

Reduce the surface area

You want to keep your conversations focused, & on topic. Only share what is necessary Meetings that get derailed can be ineffective.

Don’t convince people who don’t need convincing

Say less.

Technical writing is different from novels or essays

Keep it effective and efficient.

On Preparation

a lot of the work you do will never be visible to anyone, and that is okay

How engaged are your typical readers?

rarely a reader will take more than five minutes to read a doc. One to two is a pretty engaged reader. Five minutes is a highly engaged reader.

Diagrams

Well made diagrams allow you to organise & tell a story in a way very hard to do with words. Use these skillfully.

Executive Summary

Start your docs with these. it places important details upfront. This is another effective way to do context setting.

You can even use a hook to grab their attention. Is this clickbait? I think not, if you aren’t actually bullshitting😆

Stripe calls these sections BLUF - Bottom Line Up Front

Running effective meetings

Communicate your intention

What do you want from the meeting? What do others need from it? What is success? What would be a waste of people’s time?… It allows you to set an agenda. It also allows you to say, “We have an objective in this time slot, and we are getting off-topic."

No Agenda, no attenda

For important meetings, send the agenda out beforehand.

Timeboxing

Timebox key topics to keep discussions from derailing or going on longer than they should.

Come in with a decision made

Meetings where you make decisions by committee, where someone comes in, presents a bunch of info, and then asks, “What do you all think” suck. It always ends up with the loudest voices in the room dominating and frequently ends up with someone’s opinion as the solution rather than the room’s consensus. Don’t do that. Instead, make a decision yourself. It’s your meeting, do all the research, and come in with an opinion in your presentation.

Own the flow of the meeting

Generally, you want to control the flow of the meeting. People should regard you as being the meeting runner, and you should lean into that. A good rule of thumb is to not pass off the presentation to someone else when it can be avoided. Ask them to chime in, but you should be the one presenting.

Tangents

These can be the most impactful part of a meeting. But can also be be a massive distraction of someone indulging themselves. Up to your discretion on which is which.

• Lean on agenda + timeboxing to steer the conversation back into control, if need be.
• Another option is to request an async thread to be started to capture a tangent.

Don’t be afraid to interrupt anyone. Occasionally, they may push back and say, “This is important. Let’s discuss now,” but more often than not, they’ll respect the agenda..

Semi related is inoculation theory.

The idea is that if you know this thing is going to come up, address it first before the person can bring it up.

Metrics

Stats

you should learn some basic stats as a PM. It will help you understand what is happening and be able to storytell with numbers better.

Sampling

A truly random sample is representative of the whole. Getting a truly random sample of your users to run experiments with, you’ll get a better rounded view of what helps and what doesn’t.

Your NPS is always lower than you think, because customers who already churned aren’t answering the quiz. Neither are the disengaged people. Double selection bias. - Jason Cohen

Related - The Uselessness of Net Promoter Score

p-value

A p-value can be thought of: “How confident are we in this statement."

Graphs

Similar to diagrams, use these only when relevant, and to drive a point home. Choose an appropriate one for the story you’re trying to communicate.

North Star metrics

Every team/organisation needs these. they guide your day to day decisions. the why behind our actions.

any project you undertake should affect your team metrics. Whenever I start a new project, I generally write down the problem I’m trying to solve and then the metrics used to measure if we are going to be successful or not.

User Stories

A user story is almost always the form of “as , I want to ."

Be careful these are not just reframings of what you wanted to do. “As a worker with frequent users, I want to be able to use the Metaverse to take meetings.” This is just taking what you want the user to do and reframing it as a user study. “As a worker who takes frequent meetings, I want to have a more personal experience with my coworkers despite a remote culture” would be a much better framing of a user story.

Don’t make problems up then frame them as user stories.

Research

A word of caution when speaking with your customers: a lot of the time, your customers don’t actually know what they want. They’ll say, “Yes, I want feature X,” but in reality, if you build it, no one is going to use it. They’ll think they want something, but in reality, it is just an indication that there’s a problem there that isn’t being solved correctly.

There’s many different ways to do research. Just Enough Research by Erika Hall is a good place to start to learn this skill.

I have User Stories. Now what?

After you have a bunch of them, you have to prioritise and turn them into product specs, at which point design & engineering are ready to take it on.

Just always keep your users in mind. That alone will give you a leg up on a lot of product managers.

Product Specs

A general outline of this doc.

Some projects will have less than this, and some will have more.

1. The BLUF / Executive Summary

2 to 4 sentences that summarize what problem exists and what we are going to build to make it better than it is.

2. The Problem Statement / User Stories

how we discovered it was a problem (our metrics said so, our users are tweeting it, the support tickets, or we are just making a bet that this is a good idea)

On a sidenote, a word about creating a minimum lovable product. Don’t sacrifice UX & what makes your product special in the pursuit of shipping faster.

3. Goals and Non-Goals

Non-goals help avoid scope creep. Reminds me of how Shape up’s chapter on setting boundaries

4. Key Metrics

How are we tracking whether this was a success or not?

5. Rollback Criteria

I encourage you to think about “when do we stop trying on this.”

Trap door decisions: a decision that once you make it, you can’t go back

Since learning this framing, it’s become somewhat easier to make decisions around trade-offs. “Is this reversible? if so, how easy is it to reverse?” - I find myself asking this question often.

6. Timelines

Again, Shape up’s chapter on setting boundaries is helpful here.

7. Designs / Mocks

The polish of these depends on your audience. They can be delivered in many different forms.

• Screenshots you draw over & annotate
• Hacked html + css pages
• Draw.io or similar
• Fat marker sketches
• Figma

8. Technical Concerns / Outstanding Questions

Sometimes, questions just can’t be answered till the project starts. This is a good place to call those out, as well as any outstanding uncertainties.

9. Appendix

…Rest

Planning

Without some sort of plan, you tend to suffer strongly from recency bias, where you tend to work on the things that you have been most recently thinking about, which is not always the most effective thing.

Fit around your org

You can bring your own spin to how you handle planning, but the whole point of planning is to drive organisation wide alignment, and simplify collaboration. With that said, make sure how you plan is aligned with the company’s culture.

Some like to think in quarters, some do 6 week sprints, and so on.

Follow company wide themes

Similar advice to north star metrics. Some companies will explicitly publish themes for the season, sometimes you have to read the room.

Stability, UX improvement, cost reduction

Make projects completable

Be specific. Explicitly set out a goal, or timebox a problem. If it’s a long project, make sure it has timelines.

By the time something is on the roadmap, it should be researched

Prioritising

Impact, risk, cost. this matrix can help a lot with prioritising.