Product Management

Gibson Biddle came to give a product leadership talk at Google and one section really stuck with me. He mentioned how he came up with a simple statement that packs into it the role of product, while he was VP of Product at Netflix:

“Delight customers in margin-enhancing, hard to copy ways.”
– Gib

So short. So simple. Yet, much to unpack. For example:

Delight customers: The Kano model discusses the role of delight and how “Users don’t expect features that delight them. Consequently, if these features are not there, customers will not be dissatisfied. However, if they are present, they can easily have the biggest influence on the customers’ level of satisfaction.“
Margin-enhancing: A ha. The business side that reminds us that we live in the real-world, and life isn’t solely about thinking through what the user wants….. as that won’t matter if you can’t survive or thrive, which is necessary to fund more delight. I now look out for the obvious bits here…. E.g. when you can’t just buy a book on the Kindle app on iOS. That restriction isn’t in place due to user-centric reasons.
Hard to copy: show me the moats!

I work on a developer platform, and a very open one at that, so I got to thinking about how a version of the statement would make sense for the Web Developer Ecosystem team, and came up with:

“Delight developers in ecosystem-enhancing, easy to copy ways”
– me

How does this unpack?

Delight developers

A platform needs to bring a supply of users to the table, for developers to have an opportunity to reach.

ASIDE: One of my kids asked me the good ole chicken and egg question, so I showed him:

And then for fun, I asked:

What came first?
— Dion Almaer (@dalmaer) February 27, 2019

It was fun chatting through the birth of computing, and how the first users kinda were developers too, etc. It was also interesting thinking through various platforms and the stage at which third party developers were allowed on, and how it often depended on how valuable the host of the platform was as-is.

For example, the iPhone started first party, with Safari running the back catalog. The radio on the other hand….. I don’t remember it having any saved content that you could listen too if nothing was on the waves!

Anyway, back to delighting developers….. it’s important that we bring the meat of ROI (lowest cost to build your best experience for a large supply of users) but also the delight. Features such as this:

In @ChromeDevTools, hovering over a CSS property (e.g padding, margin) now highlights nodes impacted by it. Here's hovering over "padding" (green): pic.twitter.com/XlKENmP3l8
— Addy Osmani (@addyosmani) March 7, 2019

Value attracts, quality drives loyalty, and innovation differentiates.

Ecosystem Enhancing

Whatever we invest in should be enhancing the ecosystem. This means that we shouldn’t be thinking short-term. It means we should be thinking about the diversity in the ecosystem. One of the beauties of the Web is how anyone can make a home there. Grab a domain, and bob’s your uncle.

As a platform, yes you are a match maker of sorts (users and developers), but the long term aspect means that you aren’t just measuring hook ups, but family and societal growth that comes of the matches.

How do you notice weeds in an open ecosystem? You see silos that go over the top, and there are pure winners in verticals that stomp out competition. If you aren’t measuring and looking for the right things, it can look like engagement is going up and all is good…. when in fact the diversity is rotting away. We don’t want walls that keep people in and out, and even when we see people really enjoying a set of flowers, who knows how long that will last. Fashion’s change, and flowers can die out, so it is vital to not be all in on tulips.

In a healthy ecosystem, different parts interact in complex ways. You can mashup content, and someone can use an extension that makes something work better for them. The platform should be watching out for new patterns and work to bake them in so many can benefit.

Easy to copy

Rather than building first party competition that is zero sum game, we want to inspire the ecosystem and do so in a way that anyone can easily build on what we do.

We want to share building blocks, and help any sub communities throughout the stack. Open source enables us to not only share our own work in a well known way, but it also means we can participate and help other projects.

We see this in so many ways. From Chromium, to our guidance, libraries, and tools (DevTools, AMP, Lit, Lighthouse, workbox, you name it!), and with communities such as WordPress.

It’s incredibly fortunate that we can work in a way where we legitimately want sharing and copying, as we work together to garden the ecosystem, and make it the best destination to draw in more humans to play with us.

And thank you, Web community, for all of the creation and curation that you do.

In the world of management your job is partially to build the team that builds the things. As an engineering manager, I sometimes find myself thinking:

“Man, dealing with computers…. so nice. So rational.”

People are complex and predictably irrational. Fortunately, I actually like people and find the challenge of helping teams a rewarding one, even if there are some days that I come home quite pensive.

While asleep my brain is off trying to find patterns, and this act leads to connections such as comparing how teams are related to each other and their behavior and how families are structured.

When it comes to these, and peer-to-peer dynamics, one root cause is often a lack of empathy and a slew of assumptions that your brain has created in order to try to understand the complex world around it. This leads me to think “man, if they could walk in each others shoes for a day….” from time to time, and I wonder why we don’t do more to make that happen?

Some companies do a good job of having shadowing programs, moving people around so culture and knowledge can be shared, and experience can be gained. It also happens organically, as people naturally move about. But would it make sense to do this much more regularly?

I have seen the need in a few situations:

Understanding another role

It isn’t always easy to understand the trials and tribulations of someone in a very different field, or in a different role. It is easy for us to think that what we do is hard and complex (as we know about the complexities) whereas their work seems easy (as we see the output vs. the toil and training that went into it).

This also can become an issue if there are roles where people feel like more input is directed at them, and they can’t give the same level of input back. My typical example here is the engineer and the designer. A designer on my team once complained that it wasn’t fair that the engineer was giving so much feedback on their wires. They felt like they were the expert and that “I can’t do a code review and give feedback there!” That was the real issue, the perceived asymmetry. Since we are all users of computing platforms, many of us feel like we have opinions on the UX of a product that we are building. That doesn’t mean that we have the same level of deep understanding of a UX expert though, which is why they are responsible for the experience. That responsibility does NOT mean their job is to come up with all the ideas though, which is why a good UXer will listen to all and look for good things they have missed.

Also, although you may not be capable of a code review, you can review the engineering. You can look for crashes, UX bugs, jank, etc. That is very much in scope, so in reality you can have a lot of feedback back to engineering.

Understanding another team

The same notion of “I understand the complexity and only see your output” also kicks in with teams. From the outside it is easy to think that another team is under performing based on your assumptions. This doesn’t mean that they are NOT under performing of course, and it may be that this is a team that you know well, and have a deep understanding of their domain, but it isn’t always the case.

This can often happen between the “business” and “product development” worlds. The business naturally wants features and functionality and often tends to wonder why its so hard to get those screens up and running! They can also easily run into “I saw them do screen A in a day, so why is screen B taking a month!” when the complexity differences are huge. If the misunderstanding is this far off though, then the product development team isn’t doing a good enough job at explaining what they are doing 🙂

Understanding at another level in the chain

The pointy hair boss. What a moron. He has the easy job at the top! Why doesn’t he always do thinks that I want him to do? Our strategy is dumb and “if I was in charge….”. I admit to meeting plenty of pointy haired bosses, but it turns out that it isn’t as fun up there as you imagine it is. They have to manage multiple teams with complex priorities and unclear answers.

You know your area of the org deeply, but take a minute to think about what is going on in the other parts of the org, or in other parts of the company. Do you understand the strategy? Do you think you have a good handle on the context? If not you should get it from management, and it is poor form if they haven’t pushed it down to you. You can’t be expected to make the best decisions if you don’t have the context.

It is for these reasons that I think it is wise to think about how to keep organizations a little more dynamic. Change is constant these days more than ever so why not embrace it and think about how to use it to dispel some tension and gain shared understanding?