Product Management 30/60/90 Day Plan

There are different paths that each product manager takes, but the common ones I've seen are: 1. Joining a tech company as an Associate PM or an intern straight from college. For college grads, I suggest starting by connecting with other product managers (e.g. via LinkedIn) to better understand what we do. There are great books available on this topic as well -- "Cracking PM Interview" is among my favorites. I also created a series of videos explaining tech jobs and what do I do in more detail - https://www.youtube.com/channel/UCsAz_arwNkiPobhi09VrMFg 2. Transition from other roles e.g. Engineering, Professional Services, Support. This path is easier, as it assumes that you are already in a tech company and can make connections with internal PMs. Picking a PM as a mentor or just becoming a friend with one is a great place to start. I also need to point out that PMs sit at the intersection of Business, Technology, and UX (Customer) -- that is why engineers who transition to a PM team will have an advantage as they understand the technology much deeper. On the other hand, someone in Support who wants to become a PM brings a much deeper understanding of a customer.

There is a fork in the PM career path road: one is becoming a people manager, the other becoming an expert in a deep thinking product area sans managing a team.  My recommendation is to figure out which one is right for you. Many folks want to jump into management simply because they think this is the only way to grow, make more $$$ and so on. That is not true. Big and small orgs I have been a part of value senior individual contributors that are passionate about their individual craft. Speak with folks from both paths, and see which one resonates more with you. Try mentoring people and see if you like helping others succeed through your guidance as a "management path" check.  Then, share your thinking with your manager to get them to help you moving along this path. 

This is a very interesting question and one that I keep touching upon on almost all career conversations with my teams & mentees. There is no one typical career path for PMs, which can be both liberating and challenging at the same time! It's liberating since PMs have the chance to shape their careers to what they would like it to be, playing to their strengths and having a fulfilling life & career. It's challenging since every industry and many firms in the same industry have different definitions & requirements for what a PM is! For instance, even within FAANG firms, the definition of a PM is different - Google requires PMs to market the work of their Engineers, Apple PMs are usually good at their domain of expertise but execute on Sr Management decisions, Amazon PMs are Business/ Program Managers with heightened focus on a few metrics, Netflix PMs are very Technical (most of their PMs were former Engineers or Architects) and Meta offers almost the full buffet but also the most agency & empowerment to PMs. I touched upon some of the PM archetypes in another answer and its great to see that PMs can succeed in any shape or form tht adds value to their firm! PMs who are early in their careers will do well to join established firms to understand the PM tracks and how senior PMs have shaped their careers. Working in a start-up or a 0-1 environment usually turbo-charges a PM's career but only if the PM is aware of their strengths & know-how to leverage them. I have found that alternating between large firms & startups or between established products/ projects and 0-1 initiatives is the best way one can gain the most perspective and shape their careers as PMs.

I have been a part of small teams, large teams, a PM consultant and an entrepreneur. I have yet to scale a PM team beyond the first PM but here are the things I would consider: * Structure your team based on where the company will be in a few months/years—hiring should reflect the company’s vision and serve as a blueprint for where the business is headed. * Ideally, each one of the identified goals above would have a subject matter expert (e.g. a retention PM, a growth PM, a localization PM, an Enterprise PM, etc). As the team scales, you'll be able to move away from hiring generalists and seek experts who have deep domain knowledge. * Consider training young PMs through an internship program. This will give you the opportunity to mold your PMs and instill your preferred process early on. * It’s never too early to define a set of guiding principles and establish a process. Shaping the product team’s DNA at the onset will pay dividends as the company grows and consistency is maintained. * Hire with diversity, equity and inclusion (DEI) in mind: a diverse team means broad perspectives and creative ideas. It is not only the right thing to do, it also helps businesses innovate at a faster rate and reach financial success.

The simple answer is to hire PMs :) .  That said, I'm assuming you are asking more of how to structure the team to scale to the needs of the organization as you hire * Define the discipline: Hire PMs that align with your definition of product management. You'll also need to setup the discipline (see my answer on establishing the function) * Enable each PM to own their area of the product or business end to end as you set up the team.  This is crucial.  Often this means aligning PMs to specific personas or specific products that your company has.  I personally tend to avoid aligning an organization to the technology pieces, instead focusing on the end to end experience across all layers of the stack, so the value delivered is clear. * Keep the team at an appropriate size: I like to see PM teams run lean.  This forces good prioritization and focus and prevents slicing the areas too much.  That said, lean does not mean stretching PMs so thin that they have no time to think ahead and become only reactive. * Don't forget about design: Also start investing in the design organization so you keep the PM and design teams in balance.

This is a situation that our team went through last year, scaling from 2 PMs to 10 over 12 months. Before hiring any additional PMs, we first took the time to survey the teams that existed in our current state. We reviewed the tools they owned, their missions, their place in the lifecyle of the motion that we support (Quote to Cash), and made our decisions from there. Certain teams needed to be consolidated, others needed to be created, and some simply needed more structure. With a plan in hand, we outlined our most critical hires; we focused on Senior Product Managers that could take our initial vision and existing teams forward. The goal was to stabilize core areas of the overall set of products that we owned first, which would buy us time to expand on that vision and thoughtfully set up the new structure. For areas that were lower risk, or that had established Engineers leading the team, we brought on PMs, knowing that they would have more room to figure things out. Finally, once SPMs had established stability over the teams they were brought on board to lead, we added APMs to ensure a healthy pipeline and create opportunities for those looking to break into the space.

Building with intent is key. As a first PM or TPM, you are often running a one-person show. You wear multiple hats and you tend to be scrappy, flexing to what the business needs you to do. That approach works wonders up to a certain scale but soon exposes its flaws. When you think about scaling out from there, here are a few things to consider - * Understand your business (replace with org or product team) needs deeply, ideally the 1 to 2 year trajectory of where it is going. That’ll tell you what type of product person you need to hire next. Someone with augmenting skills (Growth PM to scale out in new markets) or complimentary skills (a Technical PM to build better platforms)? * Hire strong leaders in advance. Some take the approach of waiting until the teams grow to a certain size, before they hire leads/managers. I’d suggest the opposite, for a few reasons - * Strong Product leads think big picture and know how to design orgs for the future * Coming in early gives them the opportunity to grow product expertise better. They get to be a part of the evolution of the product which is critical * They are good at hiring too * As much as I advocate for hiring strong leaders early on, promoting talent from within is equally important. Look into your cross functional teams to see if anyone might be a great fit for product roles on your team. One of the best Technical PMs on my team was a Data Scientist 4 years ago. * As your Technical PM org grows, there will be overhead in terms of decision making, co-ordination, communication etc. Optimizing your org design to minimize such overheard to the best extent possible is useful. * Aligning with your business structure and locations is an obvious one. * Ensure diversity. This is often an area where orgs struggle. Hiring more of you is not a great recipe for success. Finally be open to updating your org/team design as business and people grow.

The first PM hired into a company, or in a division of a company, will usually be an individual who can wear different hats on any given day. (see one of my favorite product management graphics: https://medium.com/@productboard/the-many-hats-of-product-managers-4692aab2fff) The decision to grow and scale the PM team beyond your first product hire is made after discussing needs and opportunities with stakeholders, but also by gaining important insight from the existing PM that's been working in the trenches.  When deciding who the next hires should be, I've found it helpful to first validate the problem and opportunity landscape and map out the pillars of your product strategy, e.g. systems, tools, applications, infrastructure, data, end user touchpoints, etc. It's obviously challenging to add too many people at once, so you'll have to prioritize the first couple hires and balance need, impact and culture. Remember that your PM team in the early days is a reflection of you as a leader, you are essentially scaling and complementing yourself to expand the team's overall strengths. I can't stress culture enough in the early stages of building a PM team. An unhealthy culture can make or break your ability to establish cross-functional trust which is super important from day 1. 

I'm not sure it is the most effective because I've really only used one strategy, but it has been effective for me. 1. Grow your own scope, take on more than you can handle, do a good job of pitching the problem space and opportunity and get broad consensus that this work is critical and required. 2. Then make it clear and obvious that to succeed in this new problem space it will require you to drop a piece of your current scope that is critical 3. Hire for that role In particular something I'll note is that the best thing to give up to grow a team is the thing you're closest too. The thing you know best. It'll be the hardest thing to give up, but in doing this you help guarantee that the person you hire is best set up for success and that you'll be a good manager/mentor for that person.

Contrary to popular belief, it's not about writing a job description as fast as possible and starting to hire! It's important to spend some time upfront thinking about the team you are trying to build: 1. Define your team structure: Think about how you want to set up your product team - what are the main product areas to be supported? What areas might grow down the line? What areas need specific skill sets? It's helpful to give each PM a clear focus, in terms of user they're focused on and problem they're solving rather than a clear feature. For instance, when I worked at Pinterest, we were much more interested in hiring a "Discovery" PM rather than a "Homefeed" PM. At Figma, we hired for a "Collaboration" PM rather than a "Comments" PM. You don't want your PMs attached to features, you want them attached to specific users and their problems. Features come and go, problems don't.  2. Define your PM competencies: Think about the attributes you care most about as a PM. Is your company exceptionally data-driven, and therefore candidates needs to be analytically savvy? Is your company a B2B company and therefore candidates need to be business-oriented and able to interface with Sales? Factor in the skillsets you already have on your team - if your team is already highly technical, do you instead want to complement your team with more creatively-oriented PMs? What domain knowledge is necessary for each role? Write down the attributes you care most about, how they'd evolve for different levels of seniority and how you'll evaluate candidates on them. This is absolutely critical before you start hiring so that you have an objective and clear interview process. 3. Build your pipeline: Create your job posting, and promote it across LinkedIn and other job sites. Start to talk to candidates both formally and informally (reach out to interesting folks on LinkedIn and make connections). For senior roles, often times you need to keep conversations going with candidates for a until they're ready to interview. It's better to wait to get the right candidate than to make a hire decision in a hurry. Also, it's a good idea to get folks within your company to refer people in their network - amazing people often know amazing people! Create a referral program and spread the word. Once you have these pieces in place, you can start interviewing to find the right candidates. I'd suggest that until you have a big enough team and enough confidence in specific PM hires who understand the business/role well, that you limit hiring responsibilities to a very small group to start so that you can maintain a strong and consistent bar for the type of talent you hire.

As a first PM, you will need to be very judicious with how you allocate your time and resources. In fact, I think that’s true for larger companies as well. There are always going to be more ideas than resources available. As a product manager, you are responsible for translating the company’s vision into a roadmap so your first priority should be internalizing the company’s goals. Is it to drive sign-ups? Increase retention? Increase MRR? Or something else altogether? Narrowing in on that top goal helps to weed out work that may be less relevant. Once you’ve identified the top goal (there may be more than one), filter out any initiatives that do not map to this goal. The exceptions being pressing engineering initiatives (i.e. a platform upgrade, reducing technical debt etc.) or time-sensitive projects. Hopefully, you’ve been able to narrow down your list through this process of elimination. This is where a prioritization framework will come in handy. My go-to is the impact/effort matrix. It is very similar to ICE and RICE but simpler and more visual. For each initiative, assign an estimated impact to a measurable goal and a level of effort. Make sure to collaborate with your engineering and design counterparts when evaluating each initiative. This will reduce the chance of your own bias getting in the way and lead to better prioritization. For those initiatives left on the cutting room floor, think of a way you could still make some progress—is there an MVP you could run to learn something while the teams are working on the selected initiatives? There might be a low-cost way to validate assumptions via user research or data deep dive so that by the time you go through this exercise again, you are able to make a more informed decision.

Honestly, the first product manager for a company is probably not ready to establish a prioritization framework. The first PM probably needs to focus on customer discovery, market discovery, MVP intuition, and experimentation. Until you have established product-market fit with enthusiastic customer demand, rigorous prioritization is probably bikeshedding. Once you have that fit, that's when you'll start to get inbound requests/ideas/complaints from current customers, potential customers, new market segments you hadn't considered, and sales teams eager to displace competition. Then you can start thinking about a model to trade off product vision, addressable market expansion, competitive threats, technical debt, quality & reliability, scaling bottlenecks, and so on. The question you'll ask is: What can the team work on today that maximizes short term opportunity without hobbling long term viability? Product priorities more often resemble a Bayesian decision network than a flow chart.

There are many great approaches to this question – and to some extent, it will depend on what the company values. If you're a first Product Manager, it is most important that customer needs / expectations are at the forefront of any framework.  With my teams, I sometimes like to use a graph, where one of the axes represents customer impact (how much does this product or feature postively improve their lives?) and the other maps effort or investment. That will give you an easy 2x2 where there is a clear set of high impact, low effort/investment things that represent quick wins. You'll also have a category that points to high impact, high effort/investment that require deeper exploration. Another approach I've seen popular in some areas is defining features as table stakes, nice-to-have, or surprise-and-delight – and scoring from there where current offerings stack up, compared to market. While there is no question we must offer table stakes, how the company approaches the other tranches of value will depend on the company's point of view on the market, the team's capabilities, differences or nuances in the customer base, and overall ambition.

The great thing about being the first hire is something that is also great about Product Management: there is room for interpretation. My philosophy has always been more heavily focused on understanding how things operate current state, finding out pain points as well as the more successful parts of a product, and leaning on those insights to form your next steps. In certain scenarios, what a team may need is for someone to roll up their sleeves and do the work to keep the lights on for a product. It may be months before you can get the product to a comfortable enough place to think about weeks, months, or quarters ahead; however, that time allows you to gain knowledge of the product itself. In other scenarios, a product may be operating just fine, and your task will be to understand where it can go next. Your time will be spent with customers, stakeholders, engineering and others to understand the areas of opportunity that exist. You don't always need to reinvent the wheel or start from zero just because there was not a product team in place.

First PM in a company! I have not done it, nor have anyone in close network to have a good understanding. My guess is that they have to establish right roles/responsibilities on what to carve out from the CEO. Perhaps focused on scaling up product for next million users (or take on next set of enteprise clients), or execution focsed. Do take this with a grain of salt as I am guessing based on when should a CEO hire their first PM.

When you are the first PM, you are straddling several priorities: 1. Finding product market fit 2. Scaling the team 3. Scaling the product The biggest failure mode is trying to do 2 and 3 before you do 1: As the first PM, your foremost priority should be to establish product market fit. Distibuting that effort across more people dilutes the effectiveness because information gets lost along the way. Once you enter scaling, things become more complicated. Here the biggest failure mode is becoming your own bottleneck and entering what I call the doom loop of hiring: The less time you spend on hiring, the more you become a bottleneck, and therefore it becomes harder to spend tie on hiring.  So the crux is: Figure out if you have product market fit (many great posts about how you know) and then dive into hiring before spending too much time scaling the product - even if it hurts.

In my experience a prioritization framework is foundational to establishing a great working relationship within your own team and stakeholders. I'd also argue that if executed well in the beginning, the framework may not change much regardless if you are the first or 10th PM at a company. In fact, it may be a bit more straightforward as a solo PM since the prioritized list of needs and deliverables is a direct negotiation between you, stakeholders and your delivery team(s). As the product organization grows you'll notice that blockers, dependencies and enablers exist within your own product peer group as much as your business and engineering partners. Product teams even become each others' stakeholders along the way.  As the first PM, you should always establish ways of working and a framework for how the prioritization process will run: how you collect and understand requirements, validate impact, align on definitions of done, agree on and then communicate a prioritized delivery plan. I've used different versions of the RICE and MoSCOW methods in the past, which I suggest you look into.  Don't skip out on doing things in a documented and structured way because you are riding solo, trust me it'll pay off in the end :) 

There are a few different vectors to consider here. There is the effort/impact matrix, which is pretty good at helping identify low hanging fruit - essentially mapping out potential workstreams on a 2x2 matrix (High effort/high impact, low effort/low impact, etc). This can help cut through the noise as a good first step, but isn't the only thing you should be considering. Other lens I apply are things like: * Customer - how many customers does this serve? VIP customers? Is this a want or a need? This gets to the "impact" part of the 2x2. * Urgency/timeline - how flexible is the schedule for this? Is it immovable (like compliance/legal requirement) or can we work to create space on our roadmap (perhaps deliver a smaller milestone, negotiate a different delivery, etc).  * Scope - can we potentially cut scope or re-scope to help move quicker (example: do a proof of concept to answer effort questions, running an experiment to get an early read on impact, etc), or is there potentially another way to solve the problem that we haven't considered. Change we change the "effort" calculation? * Expected outcomes - this gets back to the impact, but you will be surprised, especially in an org that may not have a product presence, that there may not be a clear definition of success or outcomes a project is trying to achieve. Part of the role is to apply process and discipline in this area.  Keep in mind that in organizations where Product is nascent or does not exist, oftentimes there is no one defining the "why", and potentially there is a lot of discussion on the "how" and the "what." One of the biggest impacts you can have as a product manager in an organization is being very clear on the why. You may find that the team is focused on the wrong things (e.g. focusing on building "bright and shiny" features rather than things that customers may actually care about, or doing custom work for a particularly vocal customer, etc). Part of the hard part of product management is saying no to things/pushing back, making tough choices and potentially killing projects that don't provide clear business value.     

Thank you for the question and I'm sure this is exactly not the answer you're looking for which is, "it depends" You're balancing building trust and relationships, understanding your users and the business, and likely an evolving company strategy. So the question you need to ask yourself is what are you optimizing for? The runway of your company is critical to consider, but I always lean towards how might we prioritize learnings and building trust to build out a strong product roadmap

The fundamentals of prioritization are not too different when you're the first at a company. But in the early stages of a company or product, it's even more important to focus.  At an early stage company, or a new product at an existing company, chances are you're finding product-market fit. When thinking about prioritizing work in that context, you need to be crystal clear on the metrics that matter, and laser focused on moving them.  In my experience, developing and testing hypotheses is a great framework for this stage. You simply can't afford waste, so understanding what you're trying to achieve, and then explaining to yourself why your proposed feature/deliverable/problem will achieve that outcome, is worth spending time on up front.  For everything that you're planning to build, take the time to create a test plan. And always look for the fastest way to disprove your hypothesis.  Here's a simple example plan: 1. Hypothesis: "if we do x, we will achieve y" is a good format. 2. Method: How will you test this? If you can do it without building any software, so much the better.  3. Metrics: How will you know if this passed or failed? Be rigorous here! Failing an idea early can save you later. 4. Results: What happened? Document and analyze the actual against your hypothesis. 5. Call it: Did it succeed or fail? Invest in the successes, learn from them, and keep repeating the cycle.  

This is a great question about how to pave the way for two things: product strategy and product management execution. I can see this being applicable to not only first Product hires at start-ups, but new product areas a company has never pursued before. There are a few mechanisms/processes I would establish as a first priority:  1. Establish a feedback loop with the top customers, internal users, and market analysts (product mgt execution) 2. Identify the top 1 or 2 business metrics you are looking to influence (product strategy)  3. Create a cadence for a roadmap to release notes that can be published publicly for internal and external audiences (product mgt execution)  4. Review the existing competitive landscape and understand your product market fit (product strategy) 

The product manager's primary responsibility is to ensure that the right product is delivered to the market at the right time. In order to do this effectively, you will need to establish a framework for prioritizing needs and deliverables. This framework should take into account the company's overall goals and objectives, as well as the needs and wants of your customers and stakeholders.  There are a number of prioritization frameworks available with RICE, Value versus Effort, and Kano Model being the most popular ones. You can pick any of the popular prioritization frameworks or even create your own. What matters is using a systematic and structured approach to prioritize your needs and deliverables, so that you can deliver the right product to market at the right time. Another thing when picking a technique to keep in mind is to pick one that is easy to use and will fit with your company's culture and can eventually scale as the product team grows. 

I’ll apply the framework outlined above to this question and talk about setting up a Technical PM function for the first time. 30 days of LEARNING: I’ll start with a listening tour, meeting with all cross-functional leaders (Engineering, Data Science, Design, Marketing, Operations etc) and trying to understand where the Technical PMs can add value. I usually get a list of all the areas where help is needed. I ensure that the expectations from the team aligns with the Technical PM job profile and career expectations defined for that job profile. Next I get a deeper understanding of the following - 1) Overall org growth plans (hiring, site strategy etc) 2) Long term strategy for the Product/Platform along with current priorities 30 to 60 days of ALIGNING: Once I have consumed all the information, I typically create a plan to build the Technical PM function and scale out for the next 1 to 2 years. I’ll prioritize roles I’m going to fill based on where the Technical PMs can have the most impact in relation to the org priorities. I’ll ensure I have alignment with the cross functional leaders on that plan. I advocate for hiring strong leaders in advance and not waiting for the team to grow to a certain size. This is because - 1) Strong Product leads think big picture and know how to design orgs for the future 2) Coming in early gives them the opportunity to grow product expertise better. They get to be a part of the evolution of the product which is critical 3)They are good at hiring too. 60 to 90 days of EXECUTING: The next order of business is to partner with recruiting and kickoff hiring. I’d also recommend getting hands on as a leader, by taking ownership of a critical product or platform area before you staff your team. This provides the opportunity to understand the space and the challenges your team might face in their roles. Now is the time to also build some of the key processes to help your incoming team be successful. I’ve addressed some of these in my previous AMA

I’m assuming the question is about setting a ‘team’ vision/mission and one doesn’t exist yet. The mission statement is the “What” and the vision statement is an ambitious future state of what the world might look like when you accomplish your mission. A crisp vision/mission statement serves as a strong identity for your team and guides them during critical moments of decision making, gaining alignment, prioritizing resources etc. Here is a framework that I’ve leveraged in the past to arrive at a vision/mission statement for my teams, collaborating with our cross-functional partners. Have each person in the working group articulate the following in once sentence. * Understand our role * Why do we exist? * What is our purpose? * What principles drive our product building? * Understand our customers * What does research tell us? * What problems do they have? * How are we helping them? * Understand how the future looks like * What’ll happen if we didn’t exist? * What does success look like? Next, create the vision and mission statements based on common themes and ensure it aligns with the company’s vision & mission. These statements should typically be short, start with a verb, strive to be aspirational and endure the test of time. Once the working group of cross functional partners align, socialize with key stakeholders and the broader org. You might want to consider doing a branding splash (new logo, ordering swags) to get people excited about the new vision & mission.

Speaking to your cross-functional teams is the best way to gain a deeper understanding of your company’s goals, its processes and challenges. It’s also an excellent way to get to know your new coworkers! I like to start by telling the person a little bit about myself, the parts that don’t show up on my resume. Beyond forming a real connection with the person you’re speaking to, sharing something about yourself will lead to greater trust. In your conversations, make sure to include members of your team as well as other teams such as Support, Marketing, Sales and Data Science. Here are a few questions I like to ask: * What is your team’s biggest challenge? * What is our users’ biggest pain points? * How can I help you? * What is our competition doing better than us? * What is your preferred style of communication? * Who do you recommend I speak to next?

The listening tour is what I love most while taking on a new role. I’m a social person and I love meeting people. What better than getting to know the people you are going to work closely with? I typically have a ledger that I carry with me into these 1:1 conversations with my cross functional team members and take notes diligently. This also helps me to organize those into themes. Towards the end of my 30-60-90 day ramp up, I do a share out of my perspective on what works, what doesnt and where we could do better. Here is how my 1:1 conversations during the listening tour are structured - * Introducing myself and getting to know them as an individual - How long have been here at the company? Where did they work prior? If they are comfortable, getting to know where they live, their family and what they enjoy doing in their personal life etc * What is working well (product, team)? * What is not working well (product, team)? * Where can I and my team help the most? * What is the best way to partner with your function and vice versa?

I think it takes a thorough understanding of a product and its users to achieve success. For that reason, I am not a big believer in “quick wins”. Take the time to learn before executing and think of “winning” as the result of iterative experimentation. That said, the main thing you, as a new PM, bring to the table is a fresh perspective. That perspective is invaluable and could lead to great insights. We all tend to make assumptions about users’ behavior or their likelihood to convert or churn, but approaching these with a new set of eyes could lead to a different conclusion. You should feel empowered to ask questions and challenge prior hypotheses. A good outcome of the first 90 days would be a strong understanding of the business and your team. This can be gained by setting up time to speak to key stakeholders, interviewing users, analyzing data and doing research. All of these efforts will provide a foundation upon which you would be able to build a strategy and execute, hopefully, with several great wins!

“Rushing to prove value” is one of the common pitfalls of starting in a new role. Having said that, you want to make steady and incremental progress in delivering value. See my response to the question "What's your best product management 30-60-90 day plan to make a big impact at a new company?" for the framework you can adopt for a 30-60-90 day ramp up plan. Here I’ll outline some quick wins you can aim for but I can’t stress enough on not coming across as ‘rushed’. * Relationship building with your team. Get to know them better as individuals, take the lead on setting up that recurring team lunch or happy hour, take the lead on driving that team stand up. * Owning an in-progress project and taking it over the finish line (driving a product launch, leading a SEV). * Sharing your perspective on product/customer pain points and what we could do to get better. * Unblocking teams where necessary on a day to day basis. * Documenting product flows, platform architecture or other business critical information as you ramp up. Often times when I wanted to ramp up, the lack of proper documentation is why it takes time. You could fix that for future team members.

FIRST OFF, TAKE A DEEP BREATH AND REMEMBER, CRUSHING THOSE OKRS IS GOING TO TAKE TIME AND EFFORT. NEXT, SET CLEAR GOALS FOR EACH MILESTONE AND BUILD A PLAN AROUND IT. JUST LIKE YOU WOULD WHEN DEFINING A PROJECT, IDENTIFY SUCCESS METRICS FOR YOURSELF AND CREATE A PLAN. HERE’S AN EXAMPLE: First 30 days: Learning and Absorbing * Establish good working relationships with stakeholders: the key to being effective is having open lines of communication with your coworkers. Take the time to get to know them and learn from their experience. * Immerse yourself in data: learn where to find pertinent information, which dashboard to follow and how to query data on your own (or work with a data scientist). * Familiarize yourself with your product’s users, their needs, pain points and Jobs to be Done (JTBD). * Spend time doing competitive analysis to better understand the product landscape. * Integrate into the team’s current work and process and identify ways in which you could be helpful. 30-60: Ownership and Leadership * Assume responsibility for a project: work with your team to define the project’s scope and add requirements. * Define success metrics for the project and work with your engineers and data scientists to ensure impact can be measured and tracked. * Identify cross-functional dependencies and reach out to relevant teams. * Give a demo and solicit early feedback. Continue to do so throughout the project. * Report on the project’s progress and impact to keep everyone involved and interested. Speak clearly about the business impact and how the project ladders up to the company’s goals. 60-90: Strategy and Vision * Leverage your understanding of the business and its users to craft a vision and strategy. * Translate the above into an actionable roadmap and work with your team to define success metrics for each. * Run brainstorming sessions with your team regularly to generate ideas and prioritize them. * Evangelize: this is where your storytelling skills will come into play—make your team’s mission known, its projects familiar and its rationale clear to everyone. Write posts, speak at company meetings and bring feedback back to your team. * Become an expert: be the go-to person for your focus area.

I worked at Microsoft for about a decade and then moved to Meta to take on a new role, a few years back. That was the most unsettling period of my professional life. I’ve gotten accustomed to a certain culture, way of work life, people, tools & processes etc at one company and the thought of having to do it all over again was intimidating. I decided to build a 30-60-90-day plan in my new role at Meta to provide clarity to my team (and to my manager, myself) about how I’m going to ramp up. Deborah Liu, currently CEO at Ancestry, who was at Meta at that time, pioneered a template that is widely used at Meta. She also wrote a blog post about it linking to the template which I highly encourage you all to read and leverage. Her framing resonated well with me and I’ll share my personal take on it. First 30 days of LEARNING: One of the common pitfalls that n00bs (aka new employees) do is rushing to prove their value. I took the time to understand the new company’s culture, vision, mission, top priorities. I took the time to know the people (teams, stakeholders, partners) and began to build trust. Understanding how you and your team fit into the bigger puzzle is important. The listening tour, sitting in customer feedback sessions or taking a bootcamp class (if your company offers one for your role) are great avenues of learning during this time. Have a clear understanding of what is expected of your role and publish the 30-60-90 day plan to provide transparency into how you’ll ramp up.  30 to 60 days of ALIGNING: Having an opinion is important for any strong leader. Based on my 30 days of learning, I began to form opinions about what is working well and what isn’t and validated my POVs. Aligned with key stakeholders on what a forward looking plan for your product or team might look like. You are also getting comfortable by getting hands on (if you are an IC) or making small decisions (if you are a leader), continuing to build trust. 60 to 90 days of EXECUTING: This is when the rubber hits the road and the time when you are about to lose your ‘n00b card’ (or honeymoon period). I clearly articulated the execution plan for the updated vision, roadmap and began to lead the team down that path. At this point, I’ve gained my team’s trust and I am one with the team. This is also the time I wrote my own performance goals for the next quarter or half and shared it out. Getting feedback continuously allowed me to adjust quickly. Taking on a challenging product feature or solving for a crisis situation has always allowed me to ramp up and gain expertise quickly. I recall Sheryl Sandberg saying once “Never waste a good crisis”.