A 🧵 on the most popular advice in product

"We need to focus"
"Focus, focus, focus"
"We need to prioritize"

I hear these things daily in teams everywhere.

But I've come to realize something. Instead of focusing on WHAT to focus on, focus on focusing. Let me explain.

(1/9) We’ve probably all witnessed the following cycle:

“we need to focus” → lots of effort to prioritize and focus → a great start → things slip → back to the old way (perhaps with a slight makeover).

We see this in ourselves AND in our organizations.

(2/9)

Some end of the week analytics/data thoughts from my work at @Amplitude_HQ with amazing customers and future customers

1/n Without usable data, all bets are off 2/n Even with amazing decision domain chops, and analytics chops .... if these people can't collaborate all bets are off

@Amplitude_HQ #Analytics

There are some things that are *much easier* to learn before building something

And some things that are almost impossible to learn until someone is using a product/thing

the trick is knowing the difference

What heuristics do you use? some I use

in B2B, when it comes to making an existing "job" easier, more efficient, less error-prone, etc. it is fairly easy (with the right methods) to map out the inputs/outputs/goals of that job in a solution agnostic way. No need to builds something to figure that out

Now that OKRs are a checkbox item in many digital transformation efforts, I wanted to share some observations from working with customers/future customers at @Amplitude_HQ

1/n: You can't OKR your way into a strategy. OKRs aren't a strategy. They "deploy" a strategy 2/n

You can't OKR your way into contextual awareness.

OKRs are a time-bound goal setting framework. Not a framework for surfacing assumptions, beliefs, hypotheses, etc.

They are an *output* of those things. Not an input.

let's talk about "dependencies"

when a leader talks about a "lack of ownership" or "too much consensus", I immediately focus on dependencies.

there are
1) hard dependencies
2) mushy dependencies

people see the hard ones, but not the mushy ones.

here's why it matters 1/n 🧵 Imagine you have a leader who pops their head up once and a while to provide "context".

...and a team that "can't be decisive"

What looks like a "lack of ownership" from the outside, is a persistent fear of the leader popping up. Of not having context.

Mushy Dependency

2/n

Here's a helpful way to think about...

segmentation
personas
and model building in general

1/n
Use your imagination and imagine a product that could serve every human on the planet. 2/n Well that is extremely difficult. Companies are limited in terms of the “motions” they can support.

Let’s think about WHY people segment

Say you are onboarding new SDRs. They are just starting ... you could get away with something very simple.

Some tips for giving INCLUSIVE career advice on Twitter. I fail often at these.

1/n: Assume that ppl have had "pop" management, leadership, and self-help advice/memes imposed on them from an early age. One person's casual, truthy, wisdom, is another person's trigger. 2/n: Don't assume that the power dynamics you have enjoyed, are the same power dynamics that other people have enjoyed.

Similarly, don't assume that your struggles necessarily make you a great arbiter of other people's struggles.

I facilitated a discussion on "don't bring me problems, bring me solutions" today, and it was so amazingly interesting.

Some paraphrased quotes:

"I've never had the luxury to bring problems. What is it like?"

1/n "Ultimately, if you want to get ahead, you are going to need to bring solutions. There's no other way"

"There is complaining, and then there is trying to get a conversation going. People think I'm complaining. But I'm not. Can I get better at that?"

2/n

For years the phrase "we just need the right people in the right roles" has annoyed me to no end.

I've reflected a bit on why. Here goes...

1/n - It tends to accompany extreme overconfidence in the ability to judge the "right" person (and "right" role). 2/n - It tends to ignore implicit biases, and systemic discrimination.

"Right" = "someone I can identify as right".

"Someone I can identify as right" = "Someone who matches my pre-programmed perception of what is good/effective".

Imagine if you could only go to a doctor if you knew your diagnosis..

..or a therapist if you knew what to do.

..or a trainer, if you knew how to structure your workouts?

Crazy, right?

But that is EXACTLY how many "shared" teams operate.

Here's why it is broken. 🧵(1/n) When people CAN figure out what they need, it makes sense to create a "request form" and have people fill it out.

But when they can't, doing so can be damaging.

Either they:
1) avoid asking out of fear/embarrassment
2) prematurely converge on an ask

(2/n)

This is one of the biggest traps in scaling a company

Everyone should be aware of it.

1/n
At some point, someone will decide that one things is working well. It is time to try 2 things. This almost always involves the assumption that there are some common things between the two 2/n
But it isn't that easy.

#1 is more stable and practiced

#2 is less stable and practiced

The assumption that you can support both with common services is a little shaky. These are very different motions.

"what do we wall thing about being more data-informed?"

AMAZING

1/n cool, so I'd like to replace my feature-focused roadmap with a list of experiments and a target input to impact

"wait a sec..." 2/n yeah, and when we find better measures for things, we can iterate.

"hold on, we can't change wha...."

"we need to find someone who has done X before"

can be a dangerous slope

1/n it involves knowing what X is. And if you need X, there's a good chance you don't know what X really is ... 2/n

It means that you need to be able to figure out if the person really did X. Very few people operate in a vacuum. To ascribe X to one person is a dangerous slope.

I've been reading a lot of great threads about the difference between "idealized" product management & "real world" product management.

as someone who contributes a fair amount of content, and interacts w/ a wide cross-section of teams, it has really gotten me thinking

1/n 2/n

It goes w/o saying, but one problem we have here is communicating about "the real world" is exceedingly hard! Even in books. It takes...words.

Much easier?
1) Generalized, high-level, good-sounding advice
2) Angst
3) Pragmatism ("apply in context","be curious")

"our product is terrible, we're in trouble!"

"our product is amazing! we're golden"

the crazy thing: both things can be true-ish

How?

1/n 2/n

People who care deeply about putting things in the best light will seek out information that confirms that.

People who care about fixing things that are broken, will seek out information that confirms that.

What actual, specific, behaviors would we observe if someone was good at product thinking?

Specific enough that someone without a lot of tacit knowledge would be able to say “that’s happening”. some off hand

1/n

Better Proxies for Value. We'd observe them challenge a "success metric" and ask if there was a better proxy for actual value exchange. Fewer overt vanity metrics (or at a minimum, leading indicators mapped to trailing indicators)

This is an important distinction

There are "frameworks" that

1) evolved from active practice in the field.

2) are attempts to frame lots of experience (e.g. based on the messy world I've seen, there are three categories of X)

And 3) pure teaching frameworks.

(1/n) One is not better/worse, but they are different.

1. has been "tested" in context. That context is important

2. very much depends on the "observer", the collector of experiences. In some ways these are theoretical constructs.

3. needs the learning context outlined

(2/n)

Some thoughts on pivoting to product

to pivot to product, it will help to have:

1) SME (e.g. healthcare, EMR)
and/or
2) deep persona expertise (e.g. nurses in large hospitals)
and/or
3) strong skills in a key PM skill area (e.g. analytics)

How about certifications (1/n) IMHO, certifications can help in one of two situations:

1. A company with no product chops using something like "CSPO" to fill tons of newly opened positions because of an "agile transformation"

2. A signal you're serious...

#2 is interesting ... (2/n)

ok: "buyer personas"

one of my biggest lessons of the last year is that when sales/marketing think "personas", they are thinking:

"we need to teach people how to sell"
"we need the fastest way to close deals"
"I need to teach a junior salesperson who to prospect"

1/n ...their goal is actually the *least* amount of complexity/information needed to do their jobs.

IOW, say one message will resonate everywhere, or one qualifier will get you "buyers"

....well, one "persona" will do

When you understand this ... 2/n

work in B2B SaaS?

something I've learned, and re-learned over and over -- at @Amplitude_HQ especially talking to so many teams.

It is vital -- absolutely vital -- to understand your product in the *broader landscape* of a customers workplace.

Why? 1/n ...when talking to a customer about your product, you will always trigger the instinct for them to be helpful and provide information about YOUR product. Which is good...

...but also a challenge.

The reality is that your product is a tiny part of their world. 2/n

when you've found your team prematurely converging -- jumping to specifics too early -- what were some contributing factors? ...this is a weird one, but often it seems to happen when the bulk of the team is tied up with something, and a smaller group -- e.g. designer and PM -- are under pressure to "tee up" the next thing