Building a Product Management Team

I'm going to suggest a few processes, but please do scale each process to the size of the organization. Treat your processes like you treat your product - establish 2-3 internal customer problems that are actually worth solving, and solve them with an MVP of a process and iterate as you learn - don't try to introduce everything at once. * Quarterly priorities: Getting into the habit early of writing down the plan for the quarter is a good muscle to build early in establishing the PM discipline even with only a handful of PMs.  Focus on articulating the big bets for that quarter a...

Expanding the team from 1 to multiple people comes with a set of pitfalls that I’ve learned the hard way. And many other factors such as Org culture, line of business, product lifecycle etc, have a telling effect on the type of pitfalls you’ll encounter, so take this with a grain of salt. Here are a few things worth considering - * N degrees of separation: The larger your org grows, more layered your teams are (typically). Ensuring that you and everyone on the team feel connected to each other in a meaningful way is super critical. Here are a few tactical things you could do - ...

Here's how I'd think about it: * Some planning cadence where strategy and roadmap can be reviewed at different levels of fidelity. (Annual, Quarterly etc.) * Product review with key cross functional stakeholders that isn't viewed as a gate keeping exercise but a feedback process and of course has PMs giving each other feedback * Experiment review where the focus is creating excellent hypothesis, treatment arms, and making sure you can measure what you need to * Cross functional discipline review and the two most critical ones are UX review that is of course led by the ...

The most important process you can set up is a retrospective of some kind. I talk about this in more detail in another answer, but as you add people, ensuring that you have ways of sharing and improving your processes is fundamentally important. Any process you introduce should have a strong reason for existing. While company breakpoints might point to the need for specific processes at an organizational level, within a small product team it's less prescriptive. But since you're product people, you have tools for this! As your team grows, start by identifying the problems. Once you've de...

There are different types of updates that need to be communicated to the rest of the company and how those get communicated is different * Vision/Roadmap: At least annually, live at the annual kickoff to the company.  A recording should be available at all times, as well as part of the sales enablement and onboarding materials.  A vision is high level and helps internal teams get excited about our direction and share that excitement with prospects and customers * Major launches: Major launches typically are for a new product launch or new category of capabilities.  These i...

At the company level, there are a few different methods of communications to keep everyone abreast of updates: 1. Product Notification emails (Ad Hoc) - These emails have a set template and allow product teams from around the company to share updates to their areas in a digestable format as major features go out of the door.  2. Product Newsletter emails (Weekly) - The weekly newsletter summarized major product updates and initiatives to all product team members.  3. Quartery Business Review meetings (Quarterly) - These larger meetings gather key parts of the business to...

Great question, and it doesn't have a single answer. One thing that is important is having a consistent, accessible, forum/location for people to see: * What's been released; * What's coming up; * Metrics; * Issues/outages/major bugs. The details of how you do this will depend on a few factors: * Size of your company * Whether you're distributed, in-person, or hybrid * The type of space/collaboration tools you use * The team culture For example, a very small, in-person team might rely on a weekly Iteration Planning Meeting and some physical information radiators on the wall. A v...

Today, our org structure follows the ethos of "Small, autonomous teams". In this structure, we generally have a PM paired with a Technical Lead (Eng), somewhere between 3 - 5 Engineers, and a Business Systems Analyst to focus on operational and analytical tasks. Some teams have a Design/UX representative as well, where applicable.  Hierarchically, we have these teams organized into Pillars, with a shared broader mission/remit. Pillars are led by a triad, with a Senior PM, Product Lead, or Group Product Manager aligned with an Engineering Lead (above TL) and a BSA Lead or Design Lead wher...

I've noticed a trend in the tech industry for product organizations to follow a structure that Spotify helped craft over the years, in which a company is organized into business sub-orgs that roll up into their own respective product and engineering leads. And those leads oversee various squads that make up the product areas within that sub-org. At CookUnity we call the product areas "zones", in which a product lead exists to drive the product strategy and manage the PM team. In smaller companies (<500), those product leads are likely the direct leadership team for the Head of Product.  ...

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 ...

There's no single right way to structure any team. Some essential ingredients to creating an effective org are to create a structure that: * Supports cross-functional work * Aligns teams to customer problems * Encourages knowledge sharing * Provides for growth Your org structure will need to change as the company grows. And you will always need to account for silos, especially once the company grows beyond about 20 people. No matter what your org structure looks like, there will be silos, and you'll need to create and support communication channels to bridge between them. Some silos a...

Be adaptable to change - don't be afraid to try different things or change a process that is no longer working for the team. For a team that is growing quickly oftentimes process gets ignored because the team is so focused on delivering/executing that they feel process may slow them down. In some cases little to no process can be a good thing, but for a team that is scaling it can be detrimental. What I try to do is understand how they are using product management processes today and then try to understand where product can add the most impact short term and demonstrate early wins to help b...

I'm a strong believer in "just enough" process, so my answer to questions like this is always some version of "it depends"! The one piece of process that every team must have is a way to reflect on, and incrementally improve, they way they work together. You can call this process whatever you like - "reflection", "retrospective", "after-action review", "post-mortem" - but it is imperative to building an effective team.  This practice will inform the way you introduce and evolve processes as your team grows. Here's the lightest-weight retro format I've ever used, which is a great wa...

The partnership with Product Marketing is one of the most important functions when it comes to rolling out a successful product. Don’t read too much into the last part of that statement though, a Product Marketing Manager (PMM) is a crucial teammate to include from the start, not just at launch time. If I know who I will be working with in advance, I tag them in Product Requirements Documents or other important materials. Sharing context from the beginning is so important!  As far as the KPIs go, we are really talking about how you measure the success of a product, and Product Management a...

While there are different specific metrics that marketing and product teams track for product launches, what's critical is the alignment between the two and agreement on the metrics to track prior to the launch. Some examples of metrics tracked by each team: * Product team: Satisfaction, usage by users and individual accounts, full funnel from a user trying the feature to actually using it * Marketing team: % of reps enabled on the new product, leads generated, competitive win rate changes * Metrics that require deep partnership: Number of customer stories/references for the c...

* Just like Shared KPI's between Engineering and Product Management, a similar shared KPI framework between Product Management and Marketing is a great way to build high quality products that bring customer delight and high ROI. This also builds camaraderie and encourages teamwork towards a common goal between these teams. * Generally PM's would own Company, Business, Acquisition, User Engagement and User Satisfaction KPI's. Examples are: MRR, Churn rate, Number of users, DAU/WAU/MAU, Number of sessions, Session duration, Churn rate, NPS or CSAT etc. * While Marketin...

I love this question because it's something I'm currently involved with at CookUnity. At a B2C company the marketing team is a Product Manager's best friend, especially in the early startup days. You can build the greatest product in the world but there are only so many Field of Dreams "if you build it they will come" success stories. You need someone out there telling your product's story and building awareness, hence the PM's need for a great relationship with the Marketing organization.  Launching a new product, a new major feature release, or even a rebrand requires a collaborative d...

Oooohhhh, this is a good one and something I spend a lot of time balancing. Product owns the product and at the end of the day both gets unearned credit and unearned blame. It is your neck on the line for the end to end experience. Thinking through the experience that users get both in product and out of product (traditionally the domain of marketing) is well within Product's scope. That being said, as you expand your career and scope you'll find more and more that you don't scale. Not just in terms of time but in terms of expertise. Figuring out a structure that lets you contribute t...

I generally think in terms of OKRs rather than KPIs, so here let's agree that we are talking about some shared measure of success! On our teams, Product Marketing is responsible for all communication about the product or feature to people outside the Product-Eng-Design org. They're our liaison to the outside world! That includes: * Creating campaigns and collateral for customers * Developing positioning documents * Developing and rolling out enablement materials for go-to-market teams * Implementing campaigns and marketing events (eg, webinars, content marketing, etc) In terms o...

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...

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 ...

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 als...

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 abou...

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 s...

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...

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 schedu...

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 tr...

Interestingly enough I see two trends in the types of KPIs product teams miss.  1) Aligning with the larger's organization or business goals - Ensuring that your product roadmap is actually impacting the success metrics (OKRs, KPIs) of the business itself is critical to knowing if you are investing in and prioritizing the right work. 2) Capturing "technical or engineering" metrics - Any work that your team spends time on should be impacting some metric. Even metrics that are technical (the most common one being latency) should be captured, reported on, and measured over time. 

* In terms of KPI's shared between product and engineering, I would say "Effective Resource Utilization" can be missed primarily because it can be hard to track and measure across projects/teams. * "Internal team satisfaction" is another one that PM's may not include but this is an extremely important metric that provides a good idea of the health of the team and organization. This should not be missed.

Many product organizations focus on delivery, Net Promoter Score, and user counts. One metric that I think is important to always consider is your availability and consistency of user experience in the performance of the application (latency). Using Error Budgets and thinking about uptime critically as a Product Manager helps put into tangible terms the cost to the user when your offering does not meet a performance or uptime standard. If you are offering mission-critical software, it is essential to be responsive and reliable. Lack of responsiveness and reliability can erode your base over...

This is a good one. I think there are two that often get missed and largely it is because they are hard to measure and expensive to move. 1. Product excellence. How do you measure customer delight in an impactful way? CSAT and NPS have lots of opportunities to be gamed and are frankly easily ignored. Some of the best products I've used focus on finding the right critical user journeys and continuously measure the success rates of those quantitatively and qualitatively 2. Product health. Cold boot, warm boot, latency for critical actions, crashes, uptime. All of thes...

Oftentimes, I find that Product Management teams are focused on getting the product to market that they forget that their #1 job is building a business. As a business leader, you can't be simply focused on the "speeds & feeds" or what next feature needs to be on the roadmap. You really have to understand the product's core value proposition: why would a customer choose your product over the existing way the problem is being solved today? And from here, how do you plan to monetize and scale the solution? Several PMs, like me, have engineering backgrounds. This is great because engineers a...

Great question.  To create a powerful partnership between Product Marketing (PMM) and Product Management (PM) it's essential for you to have a common set of KPIs that help you understand whether your work is generating the intended results.  Warning: For this to work best, it's great for these KPIs to be established as early as you can in the product lifecycle. PMs who wait until the last-minute (think 1-2 sprints before a feature/product will be released) risk not getting the most from this partnership.  Here's a process I would follow: 1. Provide the PMM sufficient strategic c...

This is a scenario that teams often find themselves in, especially in fast moving parts of a business. The question I would ask when looking across the existing products is "Where do I gain the most leverage from innovation?" There are certain products that simply need to work, and that have a built in runway so as to not detract from the companies success. If there is an opportunity to simplify an unnecessarily complex product, such as leaning on a 3rd party or making a capital investment to enable self-service, that time should be carved out early on to avoid growing the burden of supp...

Prioritization is key. I don’t believe in dividing ‘all’ available work across my team. I believe in ensuring my team focuses on the top business priorities and are having the most impact. I typically encourage my team to do a few things but do those really well and not ‘peanut butter’ themselves across many different areas. A Technical PM on my team might be taking on multiple product areas (typically not more than 2), but they set clear expectations in terms of what their roles will be and how they’ll spend their time across those. A few things to pay attention to - * Understand what ar...

I like this question although more specifics would help as the answer varies. It certainly is a tough skill to master though but worthwhile because this will always be the case. Even at the big companies that I've worked at in Microsoft and Google, who seemingly have all the money and resources in the world, we are always faced with this problem Here's how I'd think about it. Folks can forgive some changes to ownership over the short term but are much less forgiving of not getting critical tasks done. In other words, what is urgent and impactful but maybe doesn't support long term growth...

The candidate must “spike” (“8/10” or higher) in all of these areas, in order of importance:  1. Critical Thinking Given how many decisions and complex problems are thrown at PMs, this the #1 most important attribute I screen for. They don’t need to be a rocket scientist (top 0.5% of population) but they should be exceptional at this (top 5%). Good looks like: * Take large ambiguous problems and break them down into smaller pieces * Uses logic to convince others * Gets to the root of the issue: Think about things from multiple angles but then focuses on what matters (this is key ...

I'm lucky in that Google has a really rigorous interview process that I benefit from. Google is also known for taking a long time during that process but I promise you that is largely because of the rigor. Post that process though what I look for are three key signals 1. Grit is my first. Big companies are notoriously slow, process heavy, and plodding. But the way I look at this is that with so much user trust, such a large business, and really a huge opportunity that we have to respect we want to get it right. I tell my team all the time that if you want to go fast go ...