the product manager is responsible for the product's success...

simple. But....wait....

1/n There are many $ successful products that are terrible for humans (both inside/outside a company). Is that success?
2/n Conversely, what about "great products" that end up being "not successful" ?

Did the product manager do their job? Where does their role begin and end?
3/n Success over the lifespan of the product? next quarter? until they leave? while company exists?

There are many ways that short term success can come at the expense of mid/long term impact
4/n Success can mean very different things depending on the stage of the company, and the maturity of the product.

In an early startup, company/product are inexorably linked. In a more established company "the product" may be one of a dozen bets, most which will fail.
5/n What if a company has very low product aspirations?

What if it doesn't believe that their products can be a source of differentiated, sustainable mid/long term growth?

Is the role responsible for success *insofar as success is defined*? Something else? Who decides/defines?
6/n Some companies believe that a product manager should "define what needs to be built"

...while others believe that the PdM should frame context/opportunities and let passionate problem solvers do the rest.

There are examples of both doing well in context.

Is one "right"?
7/n .... some orgs are all about defined roles (e.g. you define the right thing, and you build the right thing right)

...while others are about spreading the "responsibility for product success" to everyone.

There are examples of both doing well in context.

Is one "right"?
8/n ..note how these two orgs "split up" responsibility. Many more overlaps on the right... is one "right" ?
9/n ... this bring up an important question. Say you have two ways to reach success:

1) team members as equals, sense of agency & impact

2) treating the team like a feature factory

assume an equal outcome (a stretch).

are both approaches equally "successful" ?
10/end ... anyway, this is all to say that to define product management...you really need to start with how you define product success, and success overall in terms of the work experience.

this is the "it depends".

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with John Cutler

John Cutler Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @johncutlefish

5 Jan
"The engineers on my team just want to code. They don't want to have anything to do with product. They just want specs. What do I do?"

1/n Are you asking them do to X *and* do their "day job" as defined by their managers (and frankly your roadmap) ?

If so, start there...
2/n Do they have a reason to believe that doing X will in any way improve the quality of the product and make their lives easier? Have they ever seen X "work" ?

Show don't tell.
3/n Is there average day/week a quagmire of unnecessary meetings, wading through tech debt, struggling to get *anything* to work ... and jumping through process hoops to prove their worth?

If so...no they will not have bandwidth.
Read 9 tweets
2 Jan
something just occurred to me...

I think ppl look at [popular tech co] product management advice and think "oh goodness...the rigor!"

...when in fact it is really about the intentional reduction in process overhead and leaner governance/budgeting
... this is especially important for bigcos believing they "don't have the 'talent'" to operate like X

...when in fact they don't have an environment where talent can flourish like X. They have trouble letting go.
... part of this is pure $.

They might be a money printing machine, but highly highly risk averse.

They talk about "innovation" but it is in the context of a massive amount of inertia to shave off %pts in cost and a very shallow excel-drag-to-right revenue forecast
Read 4 tweets
22 Dec 20
I'm going crazy trying to explain this seemingly basic concept, but striking out. Any ideas appreciated!

At the day job (@Amplitude_HQ) I meet teams who imagine the following...that there is a linear relationship between analytics instrumentation "work" and insights ... (1/n)
Meanwhile - the teams that are actually doing the work (and integrating it into day-to-day product work), see something that looks more like this...

A quick pass at instrumentation unlocks a lot of valuable insights. Integrating it into day-to-day work unlocks even more (2/n)
Can't put my finger on the why

With a self-service analytics product, it is 1) easy to add new events, props, etc. and 2) you have a whole variety of insight variations.

With just 2 events, 5 props each, and a handful of user properties you can answer LOTS of questions (3/n)
Read 5 tweets
20 Dec 20
How should product managers and designers share certain responsibilities?

wrong answers only.
Pm: I pick the right things. You build them right ...
Pm: oh hey for that work we’ve been talking about that is five months out ... do you mind just whipping up some mocks? Nothing serious. Promise. Will not hold you to them.
Read 8 tweets
19 Dec 20
I frequently encounter leaders who believe their team(s) aren’t “ready” for taking a more outcome focused approach. They talk of “baby steps” and “learning how to crawl before...”.

Here’s what they are missing
... to learn something, it is important to practice the thing (1/n)
You don’t learn this by running a (or working in a) feature factory, cranking out the stuff sprint by sprint.

You learn by doing a version — albeit probably more controlled/structured — of the thing ... (2/n)
What might that involve?
- direct contact w/customers
- some ability to “sense” outcomes qualitatively/quantitatively
- a feedback loop

Instead of
(Someone else learns) - build - build - build - build - build

More
Learn - build - build - measure - learn - build - measure (3/n)
Read 7 tweets
18 Dec 20
have been thinking all week about experience...

I've meet execs who swear "we can't do X because we can't hire engineers like [big tech co]". Are they right?

and others who say ... "all you need is psychological safety and empowerment and ppl will figure it out"

hmm (1/n)
... I'm reminded of an environment that had an extremely strong foundation of quality (and safety, and empowerment). And exp. leaders.

In that env, a new grad would take 2-4y to really start figuring out the product thing. AND...would start contributing quickly.

and.. (2/n)
... another env with very talented/experienced folks all with 10+y experience, being mired in complete insanity. Things falling apart. Bureaucracy. Toxic company politics. It was terrible. Many people left. Some people stayed in a Sisyphean effort to fix the org.

and...(3/n)
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!