Category Archives: Product Management

DMZ PdM Bookshelf: “Good to Great” by Jim Collins

What I’m doing

As part of our hiring at Simple, there’s a little question at the end:

Please include a cover letter telling us something awesome about you and the projects you’ve worked on, along with the best product management book you’ve ever read, regardless of claimed subject. (You like “Design of Everyday Objects?” So do we.)

We ask because we’re curious about candidates, and we get often get more information in the cover letter than we do in the resume (for instance: why are they in product management? Do they read all of a job listing before applying?)

A surprising proportion don’t have a book. For those who did, I decided I’d read all the books that came up and do a write-up on their place on the Product Management Bookshelf.

Have a suggestion for something I should read? Nope! Gotta apply.

Today’s book tldr

“Good to Great” by Jim Collins

Is it worth reading? Yes but not for the reasons you’re told to read it.

Sarcastic summary: take lessons from several companies about to fall

Well go on then

“Good to Great” is a wonderful example of survivor bias, and a cautionary tale. If you go out and take a successful actor, for instance, you can go into excruciating detail about everything they did (she puts chia seeds in their smoothies!) and attribute their success to those details. But if you don’t look at it the other way — do actors who put chia seeds in their smoothies succeed more often? There may be millions who do and don’t succeed — chia seeds may make it less likely to succeed. Blind imitation doesn’t help.

Here, in selecting companies that seemed destined to rule forever, Collins demonstrates the fallibility of this approach.

He provides eleven examples, and compares them to someone else in their space.

One great company? Fannie Mae!

“For example, the Fannie Mae people were not passionate about the mechanical process of packaging mortgages into market securities. But they were terrifically motivated by the whole idea of helping people of all classes, backgrounds, and races realize the American dream of owning their home.” -p. 110

I’ll suggest that Collins bought into their line, but also that looking back at this, it’s strange to read that and think “perhaps they should have been more passionate about the mechanics of what they’re doing, as the mission relied on it.”

It becomes a cautionary tale that a great mission without sustainable economics is worthless and even dangerous.

“Good to Great” discusses Fannie Mae’s turnaround — seven years later, having brought about a market collapse, the U.S. Government placed them in receivership, at a cost of hundreds of billions of dollars. And they still haven’t spun them back out, because it’s unclear how they’d even do that without crashing the housing market again (and because as housing prices have risen, Fannie Mae’s profitable for the Feds to hold onto, a danger in itself).

This is not isolated. Circuit City went under eight years after the book.

“Let me put it this way: If you had to choose between $1 invested in Circuit City or $1 invested in General Electric on the day that the legendary Jack Welch took over GE in 1981 and held to January 1, 2000, you would have been better off with Circuit City — by six times.” — p. 33

After that through today, you’d have lost ~1/3rd of your GE money and all of your Circuit City money. GE’s market capitalization as I write this is $289 billion dollars.

On the other hand, Bethlehem Steel was gone in two years after the book and Nucor’s up 360%. Wells Fargo took a hit along with Bank of America and then has done wildly better. Kimberly-Clark bought their comparison point.

My point is this approach: asking why the successful are successful, is ultimately limited. You can ask a lucky gambler why they’re so hot at craps and odds are good they’ll have a convincing answer — or at least, one they’re convinced of.

No one at Fannie Mae was examining their success in 2001 and realizing they’d gone wrong. Examining failure, when assumptions are open to question and it’s easier to tease out luck’s role, is in general far more fruitful.

I would bet though that “Great to Gone” would not have sold nearly as well. We look for inspiration, not cautionary tales.

Takeaways for my fellow Product Managers

In hiring consider whether favoring people from high-profile successful companies is potentially survivor bias, and also, whether people from humbler backgrounds might have learned as much or more from their experiences, even failures.

Introducing the DMZ PDM Bookshelf: Horowitz’s “Hard Thing About Hard Things”

What I’m doing

As part of our hiring at Simple, there’s a little question at the end:

Please include a cover letter telling us something awesome about you and the projects you’ve worked on, along with the best product management book you’ve ever read, regardless of claimed subject. (You like “Design of Everyday Objects?” So do we.)

We ask because we’re curious about candidates, and we get often get more information in the cover letter than we do in the resume (for instance: why are they in product management? Do they read all of a job listing before applying?)

A surprising proportion don’t have a book. For those who did, I decided I’d read all the books that came up and do a little write-up on their place on the Product Management Bookshelf.

Have a suggestion for something I should read? Nope! Gotta apply.

Our first book

Today, a leading response in no small part by being massively popular when we opened our listing, Ben Horowitz’s “The Hard Thing About Hard Things”

Is it worth reading? No.

Sarcastic summary: successful wagon-train driver reminisces about how very sore his whip hand got driving those horses to death.

There are some good pieces of advice in here: the compressed “what a Product Manager should do” summary is a succinct and useful description of the job, and there are indeed bits worth reading.

And one must appreciate a business book that isn’t told in fable form.

But it’s not good. The only connecting thread in the book is that Ben Horowitz sure went through some tough times! Over and over, there’s a crisis, but he and his team had to make huge sacrifices!

There’s never a consideration of whether the sacrifices were worth it: he’ll mention the costs his teams took on as evidence of their heroic resolve. And because they came through, it’s all justified. The skies part, options vest, and there’s glory enough for everyone to bask in.

The result is if you see your leadership team reading this and talking about how much they’re inspired by it, you should be wary.

I’ll humbly submit as an outsider, as someone who has not accomplished what he has, that the truly difficult thing would have been to avoid the deathmarches entirely.

And his examples — if reading about one company’s dependence on one customer doesn’t set off all your Product Manager danger senses, you need a vacation.

Learning Product Management from Examples: Marcos

I first encountered a true Product Manager a couple years in at Expedia, and the experience with good Product Managers led me to becoming one, years later. I’m going to write them up to talk about what makes a Product Manager effective to their team, as I saw them do.

Two brief paragraphs to explain a distinction: Expedia as a Microsoft spin-off had Program Managers, of which I was one, which if you haven’t met them, I’d recommend some of Joel Spolsky’s writing (for example, his definition of the role). You’re an individual contributor — no one reports to you — and responsible for taking varying amounts of business direction, a team of developers and testers, with some fraction of a designer’s time if you’re lucky, and charged with making great things happen. Responsibility without authority. As a bonus, if you’re really good at your job, your team gets the credit, and you take all the blame when things go wrong. Given a goal, a program manager figures out what’s possible, how to get there, and then leads the expedition.

A product manager at Expedia provides the “what we’re doing.” That can be stack-ranking improvements to a particular page or feature, or a whole shopping path, product, or site. They’re responsible for the spreadsheets and figuring out what the right features are.

(All of this changes as Expedia ages, but ignore that for now)

I was put to work on a response to the rising competitive threat of Booking.com. Expedia was an amazing shopping and ecommerce engine getting beaten up in organic search, because it had never been a consideration. We had all kinds of problems: content hidden behind javascript queries, nothing tagged correctly, no cross-linking of any worth, inconsistent URLs, URLs encoded with dozens of parameters…

Anyway. Enter Marcos. I love Marcos. Marcos knew how to do all of that stuff, he had a vision, and the powers that be gave him money to spin up a huge team.

As Expedia did, they assigned a Senior Program Manager for the overall thing, and then mid-line ones like me picked up individual pieces (I’d do, say, the re-jiggering of maps pages and related content).

Here’s what made Marcos special:

He set the vision. He took the time to say “here’s what’s happening in the wider world of search, here’s why this is important, here’s how we’re going to react now with the constraints we have.” When I and another Program Manager were still skeptical, he booked a huge chunk of time with us to just sit, listen to us, and either convince us or convince us to give it some time and see whether it worked out or not.

This made my work so much more effective. I’d be looking at something like the map widget and be able to ask “given this choice, which of these better fits what we’re trying to accomplish?” and almost always be able to make a choice and keep going. And that was true for everyone else – developers, testers, fractional designers.

Marcos made good, quick decisions. I often see Product Managers (and really, everyone) confronted with a question pause too long. More data needs to be gathered, research completed, stakeholders consulted, and all the while time’s a-wasting. Better a good decision immediately than a perfect decision long after the opportunity had passed.

When we’d hit an issue with serious business ramifications — or that looked like they’d be trading one project goal off in favor of another — we’d get a hold of Marcos and say “Vendor Foo is threatening to end-of-life the API we were using, I’ve got two alternatives but one’s massively expensive and the other will require us to leak business data to someone who long-term we know is going to be our enemy”

Marcos would listen intently, ask a couple questions (“Are they threatening because they want something, or are they really trying to end-of-life this?” “Will they help us move over?” then pause, and it felt like the number of seconds he spent approximated level of complexity of the decision, and then he’d say “stay with Vendor Foo. I think they’re bluffing and if they’re not, the cost to maintain support will be less painful than the other options.”

This was so great — we could then get back to making progress right away, that entire problem lifted from us.

Marcos admitted mistakes. Making good decisions quickly means sometimes you blow the decision, and if you’re not a strong product manager, that’s the worst. Marcos would start calls with what he’d gotten wrong. “Hey everyone, so it turned out we were the only person still on Vendor Foo’s old product, and they’re going to shut it off August 1st. We’re going to keep working on them to see if we can extend that, but we need to go with another option. I’m sorry about the wasted work.”

And because he was so honest about it, and because being quick in making the good decision so often saved us so much time, he’d built up an enormous well of goodwill with everyone. So what if Marcos made one bad decision out of twenty, or ten?

Marcos reported results. When we’d launch, he’d follow-up to talk to us about whether we were seeing progress, if we were getting closer to (or farther away from) our goals. We’d get updates on what our competition was doing, and what we might learn from their next steps. We’d get more background and raw education: for almost all of us, we were new to SEO entirely, and understanding concepts like how doing quality SEO also meant improving the user experience — and when they’d come into conflict.

He participated. He loved progress almost as much as I did, and he’d see the value in our increments and make course adjustments if the demos revealed something new. He was a Product Manager who’d see a sprint demo and want to ship it immediately because he’d realize it was a compelling value, and he’d see that what we’d thought would be release-quality would require more work.

It was my first time seeing someone take on and handle adeptly the “what’s the right thing to do?” role, freeing the team to find what was possible and attack the problems, and it made a lasting impression that would eventually lead to me putting on the cap myself.

Thanks Marcos.