My personal acronym for the skills that make product managers succesfull is H.A.C.K. H for Humility. There are two particularly important benefits of humility. First, humble people better navigate the emotional roller coaster of being wrong and having to admit it. They quickly recover from situations where their ego might have gotten hurt and move on to the next experiment or iteration. Product managers make a lot of decisions and the ability to course correct quickly without dwelling produces a huge advantage in retaining velocity over time. Second, product managers need to will things into existence by leading people who do not work for them. The list of stakeholders is often long and involves different personalities. While all leadership styles have their merits, humble, servant-leadership style product managers tend to deliver better outcomes thanks to their ability to get along with others, and drive teams toward a goal. A for Analytical Skills. One of the most underrated quotes from Ben Horowitz’s iconic Good Product Manager / Bad Product Manager: “Good product managers err on the side of clarity.” Clarity of vision, clarity of spec, clarity of progress tracking. Behind all of that is clarity of thinking, which is driven by exceptional analytical skills and the ability to dissect complex systems into core elements. Unlike the whimsical “technical” skills, analytical skills are easier to spot and evaluate regardless of their variety. For example, someone who writes or speaks clearly and concisely, or organizes information well in other contexts, is likely analytical. Product managers with strong analytical skills can quickly master any syntax or context they need to have a productive conversation with engineers, or to communicate the value of technology to the market. C for Creativity. I have observed that a person’s ability to understand and articulate what makes a user experience great often comes from their creative skills. What I mean by creativity is an ability to produce objects or experiences that users enjoy. Whether it’s painting, improv, woodwork, writing or managing a running community, there is something special about product managers who can produce things others enjoy. They understand how to create value not only on the rational, but also emotional level. I have noticed that people with a pronounced sense of aesthetics tend to have strong creativity as well. A strong sense of aesthetics can manifest in how they dress, how they organize their desk, and even how they choose tools to use They all have a style. It’s less important what the style is, but that it is present. This is a clue that a person can produce an experience that at least one user (themselves) enjoys. The best part of creativity is that it is contagious. Having at least one such person on a team helps their teammates develop similar skills. I would argue that without creativity, one can become a good product manager, but never a truly great one. K for Knife. My favorite product management quote is attributed to Michelangelo (the sculptor, not the Ninja Turtle). “I saw the angel in the marble and carved until I set him free. Understanding and deciding what not to ship is the most important decision a product manager can make about product development. Spotting a future "master carver" PM during interviews isn’t as straightforward as assessing candidates for other skills. Asking a candidate about hypothetical scenarios where they have constrained resources, especially time, certainly helps, but it doesn’t simulate the high pressure that product managers will have to operate under. One approach that I use in interviews is asking about non-product related experience that involve decision making and execution under pressure. For example, you can ask a candidate how they would pack their bag, and what they would pack, if they would have to go on a two week long trip to Europe tomorrow.

Design a product for drivers driving in rush hour. I am betting every human stuck in traffic has once thought... “Dang this traffic sucks, I wish I could [insert idea].” The best answer I’ve heard is a tablet-sized visual, that is connected to the internet with key apps such as email, song playlist, podcasts, call functionality; along with the capability for partial self-driving in traffic. Once in rush-hour it kicks in, frees your attention to do other things, improves health of the driver by reducing both physical and psychological strain of commuting in rush hours and is highly scalable to autonomous-capable vehicles. I liked the answer because I’d buy this product 🤪 but also because the answer was (1) optimized for reducing real pain points (2) accounted for the future of driving (3) was a little wild, but not too out there. When I heard this answer I could tell the PM was both imaginative but grounded in solving real problems.

Becoming more KPI driven is a matter of desire and taste. No person, team, or organization attempts to change without believing that behaving differently will result in an improved outcome they care about. It's only possible when leaders buy into how it would improve the success of their teams and business (e.g. profitability, valuation growth, employee engagement, talent retention, positive social impact, etc.) Some companies are steadfast that the use of KPIs should not equate to being data driven everywhere in the company. They prefer to have data informed teams that reserve room for intuition and qualitative insights. There is no right answer here. If we find ourselves with a company that's bought into a shift towards being KPI driven, but is trying to figure out how at the team, group, or division levels, then I'd recommend the following: 1. Have the leaders of the team/group/division define their strategy for a period of time through written outcomes, assumptions, and principles that are most critical to their success. 2. Gather all the data already available and audit it for quality and trustworthiness, then see if you can model your product or business (i.e. in a spreadsheet) to see if the assumptions you've made and outcomes you've articulated can be explained by your data. If not, note what's missing and how you could gather it (and be comprehensive at this stage). 3. Work with your engineering and/or data team to instrument the metrics you need, backfilling where possible. Remember that you'll need continuous energy to ensure your data remains audited and accurate, as data corruption can severely disrupt your KPI-driven organization. 4. Develop a process for regularly collecting, analyzing, and reporting on the chosen KPIs. Without this ritual, your efforts will be for not. Being KPI-driven means knowing and using the data to make decisions. In my experience, to get the flywheel spinning, you need to have weekly rituals that can morph to monthly rituals. These can be augmented with quarterly business reviews. 5. Make sure that the chosen KPIs are easily accessible and understandable to all members of the teams. This may involve creating dashboards or other visualizations to help team members quickly see how the product or organization is performing. Repeat your KPIs at kick-offs, all-hands, town halls, business reviews, and anywhere else you gather. It's only when you think you're over communicating them that you've probably approached a baseline level of understanding of the KPIs, and how they inform decision making, across your company. 6. Provide regular training and support to team members to help them understand the importance of the chosen KPIs and how to use them effectively to improve the org. If you have a wiki, put your tutorials there. Make it mandatory to consume these during onboarding. Offer self-serve tooling. The more people can be involved with the data, the more you'll make this cultural shift. 7. Regularly review and adjust the chosen KPIs to ensure that they are still relevant and useful. Account for any changes in your outcomes, assumptions, and principles. Assess suitability annually. Set targets annually and adjust mid-year. Some companies do this more often, and your culture should dictate what's best. 8. Lastly, make sure that all KPIs have their lower level metrics clearly mapped for the company to see. Teams influence these input metrics more quickly, and the mapping brings clarity to decision making.

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!)

I’ve held roles as both platform and non-platform product managers and I’d say being a platform product manager is definitely the most challenging but rewarding. The most challenging part is your solutions are more abstract and less obvious. Instead of building solutions directly for customers, you’re buildings tools for customers to build the solutions themselves. Does your head hurt yet? Let me give an example. Let’s say you’re trying to let customers customize the way their HubSpot UI looks. While you could try to build all the customization requests you get, no two customers want the same thing and it’d be impossible for our product teams to keep up with that demand. Instead, you build tools for external developers and admin users to configure the UI in the way they need. But how do you figure out which tools? Here is the usual process for regular product management: 1. Collect customer use cases 2. Identify a pattern 3. Build a solution that solves for the majority of use cases. Here is the process for platform product management with an extra step: 1. Collect customer use cases 2. Identify a pattern 3. Identify a pattern across solutions 4. Build a solution that solves for the majority of use cases. Still confused? Let me make the customization example even more specific. Let’s say you notice that a lot of customers want to display their HubSpot data in a table format on the CRM record page. Taking a non-platform approach, you’d build out every single table request that customers make. But this isn’t scalable. Instead, you build a configurable table component that customers can populate with their own data and then display. Believe me, I struggled for a long time with this adjustment in thinking but I promise if you choose to pursue it, you’ll love the wider impact that you’re able to have on customers!

Perhaps a contrarian take, but technical skills aren't the most critical for the majority of PM roles out there, except for deeply technical products or platform positions. For the general PM role, it's much more important to demonstrate your ability to delve into customer problems, set strategy, execute, and drive impact that aligns with your organization's mission and vision. Technical skills matter, but they are secondary. They usually revolve around your ability to work with engineering counterparts and understand enough technical concepts to make trade-offs, and to work with data and perform analysis for decision-making. In my experience, both of these skills are often inquired about directly.

Success metrics and voice of the customer. Ideally, at the time of defining a product strategy, you’ve also invested time in thinking about specific Goals that are important to measure progress against it. The goals should be time bound and specific and may include product usage, customer satisfaction, and financial performance. Several product organizations (including HubSpot, Google, Spotify, Twitter, LinkedIn, and Airbnb) like using the Objectives and Key Results (OKR) framework. Metrics are important, but at the end of the day, the best true north is the voice of your customer. If your customer is happy, the rest will follow.

One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your product? (Risk can be defined crudely in terms of Low, Medium, High or in some cases you might have a model with some sensitivity analysis built in). Regardless, if you can quantify the risk (and thus impact) of the problem to the final solution, you have a clear blueprint of where to begin. A related method is to consider one-way vs two-way decisions. One way decisions are challenging or impossible to reverse - these have multiple downstream effects on the solution. Two way decisions can be reversed easily or adjusted over time once you have more data. I prefer to focus my time and energy on one way decisions first, as these will build the pillars of the product. If there is considerable time or effort spent by your team on a two way decision, you can make the argument to come back to this once you have more information or once all the one way decisions have been made.

Congratulations! Being the first PM at a company can be a really exciting and formative experience, in shaping the product vision and the product organization. Here's a few things I'd suggest: * It's all about the user - user needs, user problems, user stories! Spend a lot of time learning about your customers, their needs and what they're looking for from your product. * Make sure you socialize what product management is, what your key responsibilities are, and how cross-functional partners should work with you. A "PM" can mean different things to different people, so make sure you tailor this to what your company needs and then communicate it out. * Set up your product processes early. For instance - start simple with a product launch calendar, some task management process (e.g., an agile process in JIRA or Asana), etc.

Let’s say that a product team and an executive team are aligned on the goal of improving customer satisfaction with the product (measured by a CSAT survey). The product team will then do research and perform experiments to validate the best way to impact customer satisfaction. Including executives in the research process via stakeholder interviews is a great way to get input early - executives are viewing things from a much different perspective than team ICs and often have great ideas. When the team prioritizes opportunities to pursue, the framework they use for prioritization can also be used to convey their point of view on the best way to impact customer satisfaction. If an exec suggests making an adjustment to the roadmap during the team’s roadmap review, seek to understand why and dig into their thought process. Then, seek the truth. Is there a quick way to validate or invalidate the feedback? What does the objective evidence point towards as the best opportunity to impact the goals? For more on this topic, I recommend “Cracking the PM Career” by Jackie Bavaro which has a chapter on working with executives.