0 -1 product development refers to building a new product or service line from scratch (0) to bringing its first iteration into the hands of customers and users (1) The first step to develop a 0-1 product is to deeply understand the market need. I look at this from the buyer perspective, the end user perspective, and the competitive landscape perspective. Unless you understand, what's needed, what exists, what's missing, and what will differentiate your solution and validate your need to exist, you cannot begin the next phase, which is product definition. 

As you progress from PM to senior PM, competencies in these 3 areas should grow: Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications that someone is ready for the senior level, like increased scope, being a reliable partner and being results driven. Here are some less obvious ones: #1 You recommend initiatives based on your strategic evaluation, instead of waiting for them to be handed to you. You are influential in your field and feel confident putting forward these initiatives. #2 You leverage relationships across the org. You can drive results from partners outside of your immediate team. You are fully entrusted to tackle complex, multi-team problems with little necessary supervision. #3 You are seen as an available and trustworthy mentor and actively seek out opportunities to help others be their best. This is my favorite by far. What are the key stages that distinguish the different levels of PMs? I think a little bit of this depends on the problem space and company. In my mind, PMs are professional collaborators, strategic assassins and bring out the best in their peers. If you can look yourself in the mirror and say you’re doing these things at scale, well, I’d say you're on the right track.

There's a lot written about basic PM competencies (https://a16z.com/2012/06/15/good-product-managerbad-product-manager/), and for any PM on my team, they should be able to do all these things you'd expect from a PM (write specs, understand the customer, communicate upwards and outwards, GSD). I'll focus my answer on a few attributes that I think are really "make-or-break" for me: * Good communication skills, both written and verbal, are an absolute must-have for any PM on my team. Whether it's through writing specs, influencing stakeholders, or pitching product ideas, PMs have to be able to communicate effectively across mediums (written, verbal), forums (large groups vs. small groups vs 1:1) and audiences (to developers, marketers, sales, executives). In particular, they need to be able to tell good stories (e.g.,, can they get their team inspired about an idea?), structure their communication effectively (e.g., can break down ambiguous problems using a framework?) and make technical concepts easy to understand for non-technical folks (e.g., can they explain how routers work to someone without a CS background?) * Great PMs "own" the problem. They're not afraid the step outside the boundaries of their function to do what it takes to get the product out the door. They rarely ever use phrases like "that's not my job" or "this was the designer/developers responsibility". Their strong sense of ownership of the problem leads them to passionately debate about the right solution, speak truth to power when necessary, but also be open to other points of view (because it's not about "them", it's about solving the problem).

Reality these days is that we mostly work in remote settings, and even when we do go to the office, some people will be dialing in. As a result, I believe 80% of the strategies have to do with focusing on the fact that we are all people, 20% are tactics and adjustments for remote settings. General alignment strategies: * Build trust ahead of time. This is fundamental and driving collaboration without it is hard * Focus on common goals. There’s typically a higher goal that teams can easily align on (e.g. Revenue, Engagement, Better experience), and the differences show up as you start double clicking into the “how”. Starting the discussion with a longer term view can also help in skipping tactical disagreements and alignments * Frame, rather than take a position. With common goals in mind, center the discussion on what the characteristics of a good solution are, rather than starting with comparing options. This helps setting a more objective ground before jumping into the solutions * Call out your biases (easier to do when you have trust). In an environment where there is trust, I expect my teams to be able to call out other considerations that may cause them to pull in a certain direction, those can be different stakeholders that push in other directions, past experience and others. Some of those reasons may be valid, some may not be valid. Calling them out can help the entire team work through them. A few remote specific tactics: * Set the right structure, if possible. This includes minimizing the number of time zones each team has to work across (In my organization we are trying to limit ourselves to 2 time zones per team, when possible). If you can, hire senior enough people in the right locations to be able to run autonomously. * Invest in getting to a clear strategic direction. Having an upfront debate on the direction is time consuming, but can then help in setting the guardrails for autonomous decisions that can happen within the teams, locally. * If you do have the opportunity to meet in person, do so. Especially when working across time zones with little overlap, a good relationship would allow you to accomplish more offline, and can dedicate the overlapping time for working more effectively through the tougher topics. While I still mostly work from home I prioritize going to the office when team members from other offices are coming to town (and I am writing this note from the airport, while waiting for a flight - going to visit my team in Austin!)

The ideal product manager to engineer ratio can vary from company to company and even team to team, but it usually depends on the company size, product complexity, the skill level of the engineers, and the role scope of the product manager. A general rule of thumb is 1 product manager for every 5-10 engineers. * 1:5 - This is common in startups or small teams where the product manager may need to be in the details. * 1:10 - As the team and company grows, a product manager may manage larger engineering teams. Sometimes it's one large team or multiple engineering teams. Since product managers don't have time to be in the details for every project, they are expected to work at a higher level on setting product vision and direction rather than detailed product requirements. It is common for senior product managers to manage multiple teams. * 1:7 - This is the sweet spot where a product manager can still get into the details of a project while also having a lot of impact with a team of this size.

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.

Going from an IC PM to a manager role was one of the most gratifying transitions in my career. Having been a manager before in a different context prior to becoming a Group Product Manager at HubSpot, I had some prior experience leading teams and operating in an environment with broader scope and complexity that helped ease the transition. That said, I do recall a couple of things: * Saying no to your pet rock: As an IC PM, you’re the biggest fan of your own product ideas first and foremost. Given my drive for intellectual honesty, I’ve generally taken pride in my ability to arrive at the best possible answer (even if it’s not originally my own) throughout my career. I do still remember early on as a GPM saying no to ideas I thought were great in the past was a practice of self-restraint. Fortunately, this comes naturally now. Now my role has shifted to ensuring teams are focused on the most impactful work, and having strong empathy for teams when we have to say no to the incredible ideas they harbored. * Finding the right cruising altitude: Within the context of HubSpot, there’s a Product Lead player-coach role between PM and GPM. During my time as a Product Lead, I found it challenging and thrilling all at the same time to be at the right cruising altitude depending on the task at hand and who I was communicating with. The way you communicate with the team you’re PM-ing is probably not the same way you would communicate with executive leaders. * Finding your people: This is something I recall from shortly after I shifted to GPM. As an individual contributor (IC) PM you develop very deep relationships with the designers and engineers you work with day in and out. You’re in zoom meetings or on slack with them most of the day. Especially in a hybrid world, it took me a moment to shift my mindset to a broader definition of team and intentionally spend more time with the PMs and peers in the product leadership team. Fortunately, I love building new connections and HubSpotters are very warm and eager to meet new folks so this was a fleeting moment. I’m sure there are a lot more, but these were top of mind.

Product School, Try Exponent, and Product Allinace are good resources for PM interviews prep. Later is a good question. Interesting idea. I don't know of any, but it so interesting that someone should be offering it. Perhaps they might have rolled into certification or cohort courses with live projects!

Here are some of the areas one can look to potentially increase engineering team velocity, i.e. do more over the same period of time. * Cross-craft collaboration: PM, UX and Engineering. Do you make decisions quickly, or spend a lot of time debating the direction? Do you trust each other? Do people have to go back to PM for clarifications all the time (and stay blocked, while waiting for such clarification)? * External dependencies: are you sell-sufficient working on your thing, or have to rely on other teams’ deliverables and timelines? Can you either influence priority of your external components, or own all of it end-to-end if it's the latter? * Motivation: is the entire team bought into a grand idea of your thing? Do they consider it fun to work on it? Or people just “clocking in”? * Roadmap efficiency: do you frequently have to go back and re-do a thing? (e.g. late requirements or design changes) Is one-off, throw away work common on your team - or you are building with one brick over the other? * Tech debt: PM nightmare - stopping working on new features for a while. Yet sometimes team may see opportunities to modernize their codebase - unlocking unbelievable velocity for the future. Decide together if it's an "okay" time to do it now (it is never a "good time" from a PM point of view, and always is from Engineering point of view) * Perceived velocity: is your team working on something behind closed doors for a long time, or is open to share exciting, tangible, easy-to-consume updates every week? The latter would help external stakeholders to appreciate team’s velocity way more. At Atlassian, we foster a culture of micro updates (think of a Tweet-size shareout) shared every week - and we have a platform component Goals & Projects to enable this process at the organization level.

Let me give some guidance here on how I think about it. 1. It's critical to have a strong vision, strategy, roadmap, and success metrics for a team 2. Your org structure should be organized to support the pillars of your strategy 3. Beyond this there optionality to organize your team functionally the way that engineering teams are organized or strategically that maps more to your success metrics or some hybrid of both 4. Most critically though you need to have as clean as possible swimlanes for PMs. Giving them a problem area to solve gives them a runway to grow and build a visions, strategy, roadmap, and success metrics for themselves. Don't give them projects, give them problems. To directly answer your question though I organize my team strategically tackling the strategy pillars we've set out to solve and my engineering and ux counterparts map our squads to each other based on the most logical function overlaps. But this does mean that one PM may be interacting with several engineering leaders to get their work done.