Product Management is not a straightforward job. You’ll get a lot of different opinions from a lot of different PMs of what we actually do. To further complicate things, there are Technical Product Managers, Platform Product Managers, Group Product Managers, Data Product Managers, and so many more. Despite all of that, if I were to summarize the job, I would refer to this popular meme:

Couldn’t have said the above any better. Honestly, when I first entered into the PM role, I definitely was reminded of that Office Space Scene… That said, this doesn’t mean we as PMs aren’t doing our absolute darnedest to try and line up all of our ducks to be successful at the job. I don’t claim to be the world’s foremost expert in the field of Product Management, but I’ve learned a few things in the first couple of weeks/months in the role that I would like to share with you.

First off, I want to explain why the first 90 days are so crucial in your job as a Product Manager:

Kickstarting or advancing your product career

Whether we are a brand-new PM or someone who is looking to advance in their role, it is critically important that we have an established framework going into any work that will help us be successful along the way. Keep the same running documents/spreadsheets that remind us of what we need to do both in the long term and short term open every day and constantly contribute to these documents.

The earlier you establish yourself, the better you’ll be set up for success

Listen, we all want to try and make a name for ourselves as soon as possible and the sooner we can start hitting the ground running, the better. Start building those professional relationships (chances are you’ll get to know them personally too!) as soon as possible. The more we open ourselves up and admit that we’re all human (a la chicken with head cutoff pic above) and learning together, the better trust you’ll earn from your peers.

A lot of stuff needs to get done!

As a PM, there are so many things we have to learn and do. On top of that, we have to work cross functionally across a variety of teams and departments, we have to seek the appropriate sign off and approvals from our higher ups, all while proving to our business why we’re going in the direction we are with metrics, and research, and anecdotes, and on it on it goes. It’s impossible to get everything done and sooner we understand that the better in control of what you can get done seems more plausible.

So based on the above, let’s start with a framework, which I will go into more detail below:

Stage 1 – Orient

Starting with step one, we need to use this time to try and get a lay of the land. We should try to understand at a high level what the company’s core values are, what their vision for success is and how they intend to get there (OKRs). At the same time, we should start identifying the key players and decision makers, as well as who to align with in gathering the appropriate requirements. On top of that, we should be getting familiar with the internal tools the team uses, and I can’t stress this enough: learn what data is available and where the potential gaps may be. We should be using our product that we’re trying to sell to the business every. single. day. We should become an expert on it and no one should know it better than you. As I mentioned earlier, align with those subject matter experts on the product to get as familiar if not more than they.

Stage 2 – Observe

As we get more familiar with orienting ourselves and understanding our role within the organization, we should really be focusing our attention on 3 things: Protocol, People, and Processes. Protocol is understanding all of the appropriate ceremonies involved with developing a product. Some of the main meetings include daily stand-ups (Scrum), Sprint Planning, Backlog grooming, retrospectives, and ultimately presenting feature commitments to the business for sign off and subsequent development. Depending on what type of software development cycle you are a part of, whether it is Agile or Waterfall, we should be observing all the regular meetings involved in prepping for those above meetings. As I mentioned in the Orient stage, we should better understand the People, who are the key decision makers. At this same time, we should be building empathy for them and their team and understand what their key pain points are and how you’re going to solve their problems. Finally, Process is being that proverbial fly on the wall and seeing how all the aforementioned people are managed and decisions are being made. Use that recurring document that you have open at all times to make those notes.

Stage 3 – Decide

At some point, we need to be able to synthesize all of our learnings into some kind of visual reference/document that you can refer to constantly. As I mentioned in the orient stage, we should use our high-level understanding of the organization’s vision into our own Product Vision and how that trickles down into all of the steps in getting to see that vision through. This includes building out a product strategy, consolidating journey maps, and product documents into the beginnings of Product Features and their acceptance criteria. Use Sprint cycles and Retros to understand the learnings and gaps how to improve on the next sprint cycle. During this time when we’re not participating in the various agile/waterfall ceremonies, we should be setting our own specific OKRs, and having a regular cadence of meetings with our stakeholders for a continuous feedback loop.

Stage 4 – Execute

Finally, it comes down to having the rubber meet the road and shipping a product out the door into the hands of our end users! It’s at this stage we should be paying close attention to what our customers are saying (LISTEN), gathering as much usage metrics on the product as possible (MEASURE), taking those findings/feedback loops (LEARN), and then do it all again for your next shipping cycle (ITERATE). If you were to break the 90 days down into a week-by-week view, it would look something like this:

Honestly, 90 days is not a ton of time. This can also be very apparent depending on the size of the organization; some large 5000+ employee companies will move very slowly and the larger the organization, the harder it is to ship things quickly. On the other side of the coin, a small scrappy start up can move things very quickly but single decisions can live and die within that company. That said, I hope this gives you some visual depending on what kind of timeline your organization takes to ship a product and understand your place in the new job ahead. Like I said, I don’t claim to be an expert at this, but this framework has certainly helped me to best hop on that moving train to the best of my ability.

Happy Train Hopping!