Observations on Product Management

I’ve spent 10 years now building products — from consulting, to startups, to larger teams like Airbnb. I wanted to capture some of the things I’ve learned, mostly for my own memory. But if others find them useful, great! Mostly these are things that are either obvious but no-one ever says them, or non-obvious but important. This first list is of aphorisms is more general; I’ll share observations on particular themes too. I also try and be explicit on the usage of Product Management (a discipline) and product generally (the stuff we create). The job of Product Management is to deliver good products to end users. The sheer number of possible definitions of good, product and user mean there’s no standard look to a Product Manager. But if you don’t deliver, the product is not good, or no-one uses it, you’ve done it wrong. Your product, especially if you manage people directly, is not the product. It’s the process that builds the product. Designers output interfaces/interactions, engineers output code, product managers output process. ‘Process’ includes the frameworks for reasoning about a problem, how the team interacts and communicates, expectations of the product, expectations of the team, timelines, what success and quality look like, how decisions are made. Process is not inherently bad. There’s good process and bad process. Good process is any that allows the team to produce better work faster, with joy and elegance. Bad process is anything else. Be wary of people who hate process. Sometimes they have been burned by bad process, often though they fear process is a) the same as bureaucracy or b) will limit their contributions. If you are a new Product Manager to a team that hasn’t worked with one before, the first order of business is proving to the team that your process increases their contributions and joy, not decreases it. It almost doesn’t matter what the product is. The greatest attribute of a Product Manager is a strongly developed ability for metacognition. First, to be able to introspect oneself and see how your words, actions, choices are affecting an outcome. Second, to introspect a process and understand why it is or is not working. Most Product Managers (and everyone probably) spend too little time thinking about to solve a problem. They jump straight into solving it. Problems come in different shapes, and not all need the same process. The process that shipped the last product is unlikely to be the one that you need for the next. how It is easier to macrobullshit than to microbullshit. It is impossible to bullshit good engineers, designers, data scientists, researchers. If the team isn’t calling you out on something fairly regularly, you’re doing it wrong. Where there is skill to move mountains, there is no need for the faith that moves mountains. Faith cannot last — eventually someone has to build something. Incremental development and vision are not orthogonal; they both require the other. All product must start with a vision — a point of view — but then be built critically step by step. It’s ok to learn something new as you go. Being data-driven is not vision. People who cling to being data-driven rarely create anything new or interesting. I also personally find it hard to explain why to them. Update: wrote my . Take a read! Observations on Data, Metric & Goals