Subscribe

The Paperclip

PM102: The classic lies in product management

PM102: The classic lies in product management
Maybe "ship to learn" can become a cover for laziness. Maybe research isn't always the answer. Maybe you shouldn't release if you're embarrassed. Absolute 101 product management concepts don't always hold up to real world nuance, and this post covers how our classic learnings can sometimes fail us.
By Amogh Sarda, on the 26th of August 2021
PM102: The classic lies in product management

When it comes to learning something new, it's not unusual that concepts learnt in a 101 class are especially simplified takes on the world. When we get a glimpse of real world nuance, we realise pretty quickly that things aren't that black and white. Let's push past the 101 and get a more nuanced take on some standard product management concepts.

1. Don't use "ship to learn" as a cover for laziness

Don't use ship to learn as a cover for laziness

It's too easy to deflect thinking about how people will discover a feature, how they'll use it, if they'll find it valuable, and so on, by saying "let's ship and see what happens". Be careful that you're not just avoiding work.

There are indeed things you can't anticipate and there's some truth to "ship to learn". However, thinking is cheaper and faster than building, and helps ensure you make and measure the right things. You can go further in thought than you realise and you shouldn't underestimate that. I mean, "thought experiments" were enough for Einstein to figure out relativity.

2. It's okay to start with the solution

It's okay to start with the solution

It's common knowledge that you should always start from problems. However, sometimes it makes sense to start from a naive solution, specific tech, your strategy and so on. These are the "wouldn't it be cool if..." ideas.

Don't feel like you have to abruptly cut discussions and make sure you start from "first principles" with a problem. Give space to customers, colleagues and yourself to bounce ideas without judgement, because this can take you places linear thinking from problem to solution can't. For example, Alexa wasn't the result of some problem looking for a solution, but the result of an engineer playing around with some cool tech - a voice control speaker.

You'll need to eventually figure out if your solution is something people want, but it's okay to let your mind wander for a bit.

3. Don't ship if you're embarrassed

Don't ship if you're embarrassed

There are classic adages to start with a "cupcake" and "launch fast" because "if you're not embarrassed, you've launched too late".

While Reid Hoffman has clarified the nuances of his initial quote, I've seen this phrase used countless times to justify bad work. You ship something bad citing "it's just a cupcake", things inevitably don't work, and then you say that's okay because "it's not a failure but a learning". Rinse and repeat.

Just scoping down doesn't make it a cupcake. It still needs to be edible, and dare I say, taste good. You need to have confidence that someone will use what you make and extract some value. It may not do much, but it should do something important well. The perfectionist in you is allowed to be uneasy that it's not a wedding cake, but there shouldn't be any reason to be embarrassed.

4. Stay grounded on the problem when prioritising

When prioritising, stay grounded

Prioritisation is hard and fuzzy, and we try bring more structure by creating abstract concepts - a strategic direction, competitor landscape, "reach" or "impact" scores for "features", and so on.

Be careful you don't get too caught up in these abstract worlds. It can leave you stuck on the wrong details (e.g. "is it a 0.5 or a 1 for reach?"), or worse, with wishful thinking about how the world works (e.g. building a "strategic fit" feature to "help improve virality", only to realise it doesn't solve a real problem).

Instead of "features" or "strategic fit for vision", the most real and concrete concepts are problems people have. We should stay grounded on that above all. Establish pressing problems people have foremost, and filter that down for things that match your strategy and are a reasonable effort to tackle.

5. Your product is not that important

Your product isn't that important

You spend 8 hours a day, 5 days a week on your product. It's the centre of your (working) world, and from this vantage point, you can fall victim to the focusing illusion and form a false sense of how important all this stuff is.

Most people don't care. They have so many things they need to do, and so many things asking for their attention. Your product is just one other thing they use to get what they want.

When we misunderstand this, we do stuff that don't make sense. We expect people will readily switch over to our product, but they have existing habits they're stuck with. We expect they'll invite their teammates, but they fear sticking their neck out. We expect they want an in product tour of what's new, but they just want to finish a specific task and move on.

Of course, all this will vary based on the customer and the nature of your product, but chances are, you're overvaluing your place in your customer's world. Understand the broader workflow, habits, fears, needs and get a true sense of your place in this world.

6. Research isn't always the answer

Research isn't always the answer

Product work is a series of educated guesses with some degree of uncertainty. It's too easy to deflect decisions with "let's do more research" or "let's look at more data" but that's not always the right answer. The effort you put in to collecting information to make a decision should be a function of how important the decision is and how reversible it is.

Pause and honestly reflect if more research is needed to make a reasonable decision, and don't needlessly stray from risk. There will always be inherent uncertainty with a decision, and you need to weigh the importance and reversibility of the decision (i.e. risk) against the costs of more research.

7. Don't rush to say no

Don't rush to say no

The classic adage is to say "No" a lot, because that's how you bring focus. While this is important, I think we tend to misplay it.

When a new idea comes, it doesn't feel fair to default to "No". We have so much inertia to keep things as they are, and a new idea is rarely going to be formed enough to have immediate sway. Instead, it feels fairer to first build with a "Yes" and find all the ways the idea can work rather than all the ways it can't.

Unlike a quick deflection with "No", "Yes" requires empathy and active listening which makes it much harder to do. However, this is how we empower everyone to influence product, and help shape crazy ideas to be crazy good ideas.

This doesn't mean you should spend hours on every trickle of thought or do it all. Use your judgement, of course, but challenge yourself to first say "Yes" and support a new idea - even if just for a little bit.

8. Strong opinions, weakly held ≠ Loud opinions, always changing

Strong opinions, weakly held

The initial premise makes sense - form "strong opinions" to help decisions progress, and have the flexibility to change these views. When taken to an extreme, however, this can become an escape hatch to express loud views with no basis, and flip flop at the sight of any new information. This makes it hard to make fast, faithful decisions as there's no clear sense of what you should and shouldn't index on. We pollute what we really know with baseless judgements and oscillating opinions.

It's already so easy to fool ourselves, and we shouldn't make that easier. Form truthful opinions with a fair amount of conviction. If you don't have much basis, express opinions with a clear sense of uncertainty. If you have strong rationale, form strong opinions that you hold tight, until new information rightfully changes your view.

9. Don't add more product as a default

Don't add more product by default

Our natural instinct as product people is to solve things with more product. Kind of how entropy always increases over time, there’s a natural flow in product to add more features, permissions, templates, automations and so on. We risk being stuck, always one big release behind resolving adoption for the entire product. Andrew Chen has a great take on this.

Pause and get honest with yourself. Good product is a series of good decisions, and it's rare to have one more thing fix it all. More over, it's better to do less, better. Before you add more, deeply understand why things already there aren't working.

Wrapping up

It's hopefully clear by now that product requires a lot of nuance. Even the most common place product concepts require some level of good judgement with application. The good news is that only you are best placed to make this judgement.

Other posts

A browser made for workHow to raise for the first timeTrack your path to default aliveYour metrics belong in a systemYour product is a joke

About us

We're building eesel. It's an app that brings together all your work in one place so you don't waste time finding what you need to do your job. The Paperclip is where we write about our learnings on this journey.
Try eesel now