34 Product Lessons

it was my birthday last week!

It was my birthday last week, and I wanted to reflect on the pieces of advice I’ve found most valuable and/or given most often.

I'd love to hear yours! Hit reply and tell me one of your favorite lessons.

---

Hiring

1. The best PMs come from everywhere. During my time at Kickstarter and Lola I got to see Ian, Jen, Jeremy, Rachel, and Brendan move into (and succeed at!) product roles. On an existing product team, if you find the right person don’t get too hung up on if they’ve had the title or if they’ve worked in the industry or in b2c/b2b/b2d.

2. One exception: you'll regret any conversation you have with someone who wants to do PM because they are “good at strategy," or "doesn't want to code.” It never ends well.

3. It’s easier to move laterally to get your first PM job. Being in an adjacent role helps you demonstrate your interest, inclination, and aptitude for the job. You can often experiment or take part of the role before making a big shift.

4. "How to become a PM" knowledge gets stale quickly. The field has changed rapidly. You shouldn’t ask someone who made the shift to product 10-20 years ago how to do it. You're best off asking advice from earlier-career PMs than experienced ones.

5. When you don’t get a PM job, it rarely has to do with your skills. PM job descriptions are vague. Lots of rejections have nothing to do with something the candidate did “wrong” in an interview and more to do with the profile being refined over time, especially for experienced PMs.

6. A promising early-career PM will be good at starting or finishing, but rarely both. Ian Todd told me this early in my time at Microsoft. Being good at starting means having creativity, enthusiasm, and the ability to motivate others. Being good at finishing means being detail oriented, fastidious, and thinking through the edge cases. An established PM must have learned to do both.

7. Engineering leaders are the real teachers. Most early stage PMs will learn more from working with a senior engineer, a tech lead or an engineering manager than they will from their own manager. (Evan Stavrou was the first EM/TL I worked with and taught me a ton).

8. In an interview, the questions a candidate asks matter more than the answers they give. No team is perfect. The questions a PM candidate asks will often show what went wrong in their last role and how they’re hoping to work in this one. Pay attention to them.

Doing the Job:

1. Writing and drawing are the best ways to make sure you know what you’re building. If you can’t write it down or draw it on a whiteboard, no one can build it.

2. The clever solution isn’t always right. It can be easy to approach a set of stakeholders as a puzzle to figure out a solution that will make everyone happy. Just because you solve the stakeholder puzzle doesn’t mean it will work commercially. (Learned the hard way with Video Mode).

3. There's no one right way to innovate and build product. Most people develop a “go to” way to hone their intuition. In my early career it was an over-reliance on IDEO-style Human Centered Design. It took a pretty painful conversation with Regina Dugan about Pascal's Quadrant to get me to realize I was wrong, and HCD is only one way of innovating.

4. The more lenses you can add, the more powerful you will be. Each background, industry, or approach can add a new way to look at a challenge. Adding them will multiply in value a lot more than refining one.

5. You have to do your way, not the way someone else does it. If you’re doing something and it’s working, don’t worry too much if it’s “right” or there’s a book that says how to do it. Same for “do I need to learn to code?” and “do I need an MBA?”

6. Write short docs. No one will read them otherwise.

7. Be extremely clear on your first two priorities, and know what your third to fifth may be. Everything after that is likely to change after you learn more. Writing it down might make you feel secure but doesn’t reflect reality.

8. Decide how many product "hacks" you'll try out for a hard technical problem before just solving it the right way. It can feel productive to move fast and avoid the hard problems, but sometimes that doesn’t work. (Learned the hard way with the Dark structured editor).

9. Sometimes the most important part of the job is doing nothing. Bored PMs spin up weekly meetings, status emails, and all sorts of other fluff to feel better. It creates superfluous work for the team. If there’s nothing useful to do, going to learn something or even literally do nothing is a better choice.

10. Product isn't a generalist job. At an executive team meeting, product advocates for a certain set of items, just the way any other executive does. It’s hard to see the distinction without having been a CEO, founder, or someone outside the company.

Organizational Structure:

1. Having too many PMs is way worse than having too few PMs. If you have too few, people will be stretched and others will help take up some of the tasks. If you have too many they create weird work (#17) and it becomes hard to tell who can make a decision. (Learned the hard way with Office Mobile).

2. Create autonomy between PMs. The key to not having “too many” PMs is to be clear on the division of areas of responsibility. Brett Camper did this very well at Kickstarter - Jed (creators), Daniella (community team), Leland (the hard and/or new stuff), and I (backers) rarely had overlapping issues.

3. Hiring a PM too soon is worse than hiring a PM too late. When you try to hire early so they can “prepare” theres’s nothing to do. The PM ends up being undermined because they look ineffective from the beginning.

4. Org structure impacts the product you build (or don’t). Office Mobile sat in Office, but was also responsible to Windows Phone, OneDrive (nee SkyDrive), SharePoint for a good experience. At one point the SkyDrive team deprecated their old APIs and Office Hub experience broke. There was no good way to fix this without going to the SVP level, so it stayed that way.

Product Leadership:

1. Being VP Product is nothing like being a PM. It’s probably even less similar than engineering management is to engineering, but no one ever mentions it.

2. Sometimes “vision” isn’t part of the job. Lots of people aspire to product leadership to get to drive the vision. More often than not the company already has one, or has a founder/CEO who is responsible for it.

3. When you're promoted to VP Product, the best thing you can do is make sure to call an experienced VP Product once every week to say "is this normal?" Amazing advice gifted to me by Leland Rechis. The job is so different that it just helps to have someone to talk it through with. Don’t know anyone yet? Try finding someone on Merit.

4. Set up front expectations with everyone you work with. PMs are often prone to jump in and “do what needs to be done.” This can be limiting at higher levels of the career. It’s more important to set clear expectations of who is responsible for what and revise as needed. This applies with coaches, other executives, and founders/CEOs. (Learned this one the hard way far too many times).

Team interaction and communication:

1. When someone shares an idea with you, never interrupt and jump ahead to what you think they'll share next. Founders, PMs, etc. spend a lot of time thinking about a space. When someone comes to you, it’s far more important to listen than to show that you are smart and already thought about it. Some of the hardest and best feedback I’ve received, given by Alicia Morga.

2. Your expression on your face communicates a lot, and you need to be able to control it. Some people have more of an inclination to demonstrate how they feel than others. I tend to. Using it badly can ruin an entire meeting or experience for the rest of the team. I learned this one the hard way… twice. Once by Tom Eisenmann and once by Paul English. This matters more the further in your career you are.

3. The more alignment you need, the more time you should spend in 1-1 conversations before moving forward or getting everyone in one room. The higher the stakes, the more important it is to help the conversation go well and understand all the perspectives you want. 1-1s are the best way to do that.

4. Curating the room can help get to the right outcome. Who is in the room is just as important as what the agenda is.

Extracurricular Product:

1. Treat public speaking like a product. If you’re going to bother to give a talk, do it well. Give a beta run of your talk, get numerical feedback, and adjust as needed. Gibson Biddle taught met his by reaching out to give personal feedback after a NYC Product Talk. He also wrote about it, which I highly recommend.

2. Any hobby can teach you about product management. Goes back to #12 and building lenses - you can use anything you do to learn more about how to build products.

3. Everything can be approached like a product. This is another Gibson Biddle classic, but it’s true. Product is a mindset just as much as it’s a job.

4. Pay it forward. All the best product people I know have received a ton of help in their career, and give knowledge freely. Kate Matsudaira always comes to mind here. One easy way to put yourself out there is by joining Merit.

---

If you got this far, a reminder that I’d love to hear your best product lessons! I’d also appreciate hearing if any of these resonated with something that’s going on for you at work right now.