You’ve just landed that PM job you’ve always dreamed of. What now?

There are many paths to becoming a PM, none of which clearly prepare you for what you are going to be doing. I will share some of my learnings from moving into Product Management laterally after interning and working in software engineering and venture capital.

Your goal

Your goal as a PM is to find out which outcomes create long-term value for your customers as well as your company and get the organization to move towards those outcomes. That sounds simple, but is actually quite hard.

It is also noticeably different from almost all other jobs you will have done before. Being a good PM is not about ticking off a to-do list in the shortest amount of time or getting your direct reports to tick off their to-do list in the shortest amount of time, which is what most other jobs are about. Being a good PM however is about creating leverage without authority.

Creating leverage without authority

To create leverage, you need to convince the people in your organization of your great ideas. To convince them, you first need to convince yourself. To convince yourself, you need to set up a system that allows you to gather insights about your customers, your product, your organization, and your competitive environment.

Convincing yourself

As a PM, there is no way around talking to customers. Make it a habit. Try to talk to a customer every week. Ask them about the last time they did [insert your product use case here]. Take copious notes. Take 5-10 minutes after the call to identify any opportunities.

Set up close relationships with someone from all customer-facing teams (sales, customer support, customer success, etc.). These people are incredibly valuable because they talk to a lot of customers. Shadow them in customer calls or ask to look over their shoulder when they work on support tickets. Make a ritual out of it so that you are able to detect changes. You will be able to identify the main problems with your product quickly.

We talked about the qualitative, now let’s talk quantitative. Learn SQL, it takes a few days. Learn how your company’s internal data is connected and build dashboards that allow you to track retention, activation, and acquisition metrics for your product. Work with your data team (if you have one) to understand usage patterns and try to create personas around them. Then try to recruit some users of each persona for interviews.

Understand your company’s business model. Try to fill in a business model canvas and ask for 30 minutes of time of the most senior executive you can get your hands on to discuss it. Update your canvas accordingly.

Convincing others

Synthesize your learnings across all the previously mentioned domains and write a monthly newsletter to ensure all the people you want to convince share the same context as you. Create a simple strategy document that outlines which product outcome you think should be improved based on your learnings, which metric you will use to track it, what your general approach will be and what you definitely won’t be doing. Share your strategy doc with everyone who could veto it officially or unofficially and ask for their feedback. Address all their feedback in 1-on-1 sessions and make sure to get their buy-in. Once you have everyone’s buy-in, set up a meeting with all participants to simply review the strategy and ensure that everyone knows that this will be the strategy going forward.

Delivering results

You have your strategy, now you need to execute. Work closely with your lead engineer and designer to build prototypes and specifications. Keep a “To-do today” list, a “Things to watch” list and a “Later” list. Every morning, update the lists to align with your long-term goals outlined in your strategy.

Come in at least an hour before your daily with the engineers and ensure you have identified all blockers on your side prior. Review communications of the last few days to identify where there might be miscommunication or misunderstanding happening. Keep 15 mins after the daily free for further questions. Don’t bother engineers every few minutes, engineering needs focus time.

Do not use Slack DMs for anything that is not explicitly private, use public channels instead to make sure everyone is up-to-date. Overcommunicate. Do not respond instantly to every Slack message, rather block time to answer all of them at once.

Set weekly goals and review them with the team. If things are not going fast enough, see it as your failing rather than blaming others. Ask what others need to be faster. Help them get it.

Be ruthless about prioritization. Refer anyone with “cool ideas” to your strategy doc and tell them why they are not the most important thing right now.

Own failures, share successes

Be liberal in taking on failures as your own and share your learnings about how to prevent them in the future. If your team has success, make sure that everyone who contributed is appropriately acknowledged.