Top Hacks from a PM Behind Two of Tech's Hottest Products

Obviously, you have no authority over the founders or cross-functional stakeholders you’re presenting to — you also probably don’t have authority over the engineers you work with. You have to be a good communicator and make things easy for people.

QA a new feature, write the first blog post, make mock-ups your designers might think are amateur but will give them inspiration. Do the boring stuff that makes a difference and moves things forward.

You may not be the decider at the table, but it’s your responsibility to make sure a decision gets made. Half of this is getting the right information in front of them. The other half is getting the right people behind them.

Keep the presentations short, 10 to 15 slides max. Most of the time, they can just be sent to the team over email unless there’s something really controversial. You should try to eliminate as many meetings as you can.

Distilling a product review down to 10 slides can be a challenge, but it's an excellent forcing function to provide a full but simple snapshot of where your project is at.

If derailments crystallize into serious decisions, it is a good idea to pin founders down to brass tacks. Ask them directly: ‘So is that a decision? Then make your next actions clear: We’ll follow up on that point and come back to you.

More importantly, only agree to decisions in a meeting that you’ve had a chance to think through and feel confident in your team’s ability to execute. 

Use the decisions made by founders to get things done. Use them to motivate your team and the teams you need to support you. Employees are usually at a company because they respect the founder.

For all these reasons, positively relaying what happened in product review meetings, and very closely tying future actions to founder asks is a great way to get people aligned.

If fielding founder requests and concerns are a major part of a PM’s job, an even bigger part is motivating and coordinating designers and engineers to reach company goals. This comes with its own share of personalities, land mines and mind tricks.

To inspire a team, tell a good story. Then break it down into an execution plan.

Work with short milestones, ideally two weeks. It’s impossible for an engineering team to have a detailed six-month roadmap. It will never be accurate. In two weeks, people understand what they can get done this week and next week, and they can keep it all in their heads. It’s also enough time to make substantial, visible progress.

There are two types of meetings — decision-making meetings and status update meetings. Both should be kept short and only include the relevant people. Status meetings should be based around what people have accomplished. Demos are the best.

Culturally, you should set a low bar for demos not needing to be super polished so people aren’t afraid to show their stuff early. Applaud each other.

Create an environment where engineers can’t wait to show each other what they’ve built, and they leave eager to go back to it.

You have to be protective of your time and your team’s time. As a PM, you’re in meetings all the time where executives are very blunt and say that things aren’t working at all and the team needs to do a better job at X, Y or Z.

You have to develop a thick skin, and then you need to learn how to translate all of the criticism you hear into something motivating.

Engineers usually take it upon themselves to think through all the edge cases to any scenario, but they really appreciate it when PMs and designers beat them to it.

Engineers want to be inspired by the vision, see a plan for the tactics, and then see how the latter will add up to the former with all things considered.

Big technology companies are now known for deploying new products and features internally before testing them or releasing them to the public. It gives product managers and engineers a chance to work out the bugs and safely gather feedback.

It gives them a glimpse of what their friends and family will see, and one of the greatest joys of being a product manager or an engineer is being that guy who helped build something everyone you know uses and loves.

• You need a team task list that transcends a simple bug system. It should be big, ideally on a whiteboard that everyone can see and consult.
• You have to be a ninja-quality expert at email. Being responsive is mission-critical. It’s okay if engineers and designers are bad at email, but PMs absolutely cannot be bad at email. You have to get back to people right away.
• Maintain your own task list and organize it into sub-lists: today, this week, someday and maybe. Never silently drop a task and don’t tolerate silent drops from the people on your team.