After much discussion, your startup – or division at a larger company – has decided it’s time to hire its first product manager. You can finally breathe a sigh of relief. How do you make sure they’re successful?

I’ve written about the first days at a new company from the PM’s perspective, but what about from the other side? These early weeks are pivotal, and can determine whether your new PM is a success or a failure. Here are some do’s and don’ts. Although directed toward product founders, CEOs, and general managers hiring their first PM, this advice also applies to anyone adding a PM to the team, at companies of any size.

Do:

Regular Mind Melds. Your PM needs to understand your vision for the product and everything you’ve learned about your customers. Eventually your PM should be able to channel you when you’re not in the room: they’ll develop instincts for what you’d say if you were there. What are you most passionate about, what irks you, and where are the third rails of your product?

Remember how Spock could touch someone’s face and share their thoughts telepathically? This was the topic of my newsletter a couple weeks ago. This isn’t just a one-time brain transfer but something that needs to be done regularly to ensure there isn’t drift between your vision and the PM’s vision. Nothing else matters if you and the PM aren’t on the same page.

Decide on a review process. With your PM, determine how you’ll handle launch approvals and staying involved in the day-to-day decisions. You’ll probably want to institute a lightweight product review process that doesn’t slow down the team or leave them in the dark. What kinds of decisions do you want escalated? It doesn’t need to be unnecessarily bureaucratic, but everyone needs to understand it. Be clear, and write it down. Eventually a good PM will be skilled at recognizing when to make a spot decision and when to escalate to you, but it might be rocky in the beginning.

Early on, a weekly product review with the team and a weekly one-on-one with your PM are good guidelines. Keep in mind that your off-the-cuff opinions and suggestions can be interpreted as gospel. Many a Product CEO has tossed out a half-formed idea and been surprised to discover their team dropped everything and worked through the weekend to make it a reality.

Reinforce their authority. Shortly after I started as the first PM at a startup, one of the engineers walked over to our CEO’s desk and asked him to make a decision on a small product feature. The first thing the CEO said was, “Has Ken already seen this?” Small actions helped establish my authority, and avoided randomizing the rest of the team. Understand that the team has collective muscle memory to come to you directly for product decisions. That certainly doesn’t mean everyone now has to go through the PM to talk to you or get your feedback, just that your PM needs to be in the loop.

Dedicate some time to think about the future. Take this opportunity to refresh your long-term vision for your product. Spend some time thinking about the future, reading, and brushing up on new products and technology. This doesn’t need to be a full-fledged Bill Gates “think week,” it could be as simple as blocking out a morning on your calendar. Share the ideas that take shape with your PM and then write a document or prepare a presentation for the company.

Don’t:

Hand off janitorial work and keep the fun stuff. You’re a Product Founder, and it’s not going to be easy for you to step away from day-to-day stewardship of your product. Sometimes it’s tempting to let the new PM take over tasks like managing the bug queue and writing documentation, but keep all of the exciting product decisions to yourself. Being a PM is certainly part janitor, but if you treat your new PM as a glorified task manager, you’ll drive them away (and you won’t accomplish your goal in hiring them: to give you more time for the rest of your job).

Check out of the product completely. You’re not handing off the product, you’re moving from day-to-day PM to owner of the product vision. One of the worst things you could do is walk away from the product completely and leave your new PM blowing in the wind. As Ben Horowitz says, if “you cannot let go a little without letting go entirely” you should consider a CEO change.

Publicly undermine them. If you disagree with your PM’s decision, take it up with them privately first. If you’re seen to overrule them the team will in short time decide that the PM’s opinion doesn’t count for much, and they’ll wait to hear from you directly on every decision. This is why weekly one-on-ones with your PM are so important: it gives you an opportunity to review progress and share your concerns without airing the laundry in front of your team. This is another recommendation that will evolve over time. It’s a sign of a healthy team to be able to disagree and debate in the open. But in these early days you can completely undermine a PM’s authority.

One of my favorite articles on this topic is by Ben Horowitz: Why Founders Fail: The Product CEO Paradox. After the Product Founder/CEO steps back from day-to-day stewardship of the product, Ben argues that their essential responsibilities must include:

• Keeping and driving the product vision
• Maintaining the quality standard
• Being the integrator
• Making people consider the data they don’t have

Once again, Ben’s advice doesn’t only apply to founders – it’s useful for anyone reducing their involvement in day-to-day product decisions.

What’s worked for you, and what hasn’t? Share your stories with me.

Go Forth*

“It’s not a human move. I’ve never seen a human play this move. So beautiful.” – Fan Hui, professional Go player and AlphaGo advisor

Win small or lose big. We’ve been enthralled watching a computer finally beat a human master in the 2,500-year-old game of Go. AlphaGo, from Google’s DeepMind unit, beat South Korea’s Lee Sedol four games to one. If you’re like me and know little about Go, you’ll enjoy this Wired article that helps us understand the historical significance of this moment.

When humans play games, we tend toward moves that will help us win big. That means we might favor an action less likely to help us win by a larger margin over one more certain to help us win by a single point. For example, an American football team might go for the touchdown to get seven points and run up the score when the surer three-point field goal would increase the likelihood of a win. The psychology is fascinating, and combines pride, loss aversion, retaliation, and innumeracy. (We also draw analogies to the physical world as a simplifying technique, which may further weaken our abilities.)

AlphaGo is immune from these weaknesses. What’s fascinating about AlphaGo is that it doesn’t care how much it wins by, just that it wins. The margin of victory is irrelevant. So AlphaGo slowly builds up the probability of a win while the human observers think the game is too close to call, like a cat toying with its prey.

Lee Sedol’s victory in the fourth match in some ways is the exception that proved the rule. Sedol won by playing a move that was so completely unexpected it introduced new complications and forced AlphaGo to make a mistake. (Read more about that here and here.) When Lee Sedol entered the post-game press conference, Demis Hassabis and the DeepMind team cheered as loudly as everyone else, showing that no matter who won – computer or human – this entire event was a triumph for humanity. We can do some deep learning too.

For more on the future of artificial intelligence, I highly recommend this two-part series on Wait But Why – Part 1, Part 2.

“It may be a hundred years before a computer beats humans at Go—maybe even longer.” – New York Times, July 29, 1997 (shortly after IBM’s Deep Blue beat Garry Kasparov in chess).

* How many complete sentences can be made from words that are also computer languages?

Good Reads

Your Customer ≠ User. Blair Reeves, a PM at SAS, feels that too many product management resources favor consumer over enterprise. Or worse yet, assume there’s no difference. In this Medium article he explains why PM’ing an enterprise product is different. (He also promises to write about the evolving role of design in enterprise software development and I’ll certainly hold him to it.)

You can’t drop new players into the middle of a firefight. That’s something game developers have long known. But players will also get frustrated by mind-numbingly boring tutorials that stand between them and the fun. Mobile app designers can learn a lot from games and Theresa Neil shares some out-of-box experience patterns that really work.