Veronica Hudson

There is always going to be some nuance to individual features or problem sets based on a company being SMB, MM or Enterprise. However, I do believe that many features can still be used across business types, it really comes down to pricing, positioning and packaging. For example, you might have a feature that is intially only available via API. In many cases, an enterprise customer will likely be best-equipped resource-wise to take that on, given that they have in-house engineering resources. Over time, a UI might be developed to best support common use-cases, opening that product up to a wider customer base in the SMB/MM range. One of the core differences where you'd need to make product decisions based on who you are serving is around features of scale. What are the tools that a marketing team of 30 might need that a soloprenuer does not? For example, an approvals process is likely not required for a team of 2, but it becomes more critical once that team expands, even more so if there are outside vendors like agencies involved. Roles and permissions across the tool are also key as you bring in more team members. Enterprise customers also tend to have more legal obligations/considerations when buying software. If your platform doesn't have SSO, for example, that might eliminate you from consideration before they even see the product.

As someone who moved from a CSM role into product management, I get asked this question frequently. While my answers are specific to my own experience, I've seen them work for others that have moved into product roles as well: 1. The most straightforward way to break into product management is to make an internal move. However, this does not mean you should take whatever job is open as a means to an end. If you come into a role with a clear objective to leverage that into a PM job, it won't be received well. 2. Look for small but growing companies where you can get your hands dirty across a wide variety of functions. A great example of this is a support position. You'll be very close to the customer and develop a deep understanding of their needs and use cases. You might then start to more broadly analyze trends over time and share that with product, engineering or biz ops as a way to help them make roadmap decisions. 3. Similar to the example above, find ways to get involved with product that are adjacent to your current role. (Make sure your manager is aware and ok with you taking on the extra work first!) It might be providing a monthly trend report, doing an analysis of the most common customer issues or points of confusion, or identifying potential areas of usability improvements. 4. Make your aspiration to move into product known over time. You don't want to come in on day one of the job declaring that your ultimate goal is to be a PM, but as you start to discuss career development with your manager, make sure they know that is a medium-long term goal for you. A good manager will find ways to get you involved with product and set you up for success. It's also just important for others in the org to know about your interest. One way you might do this is to set up coffee dates with other PMs on the team to learn about how they got into Product Management. 5. If moving internally isn't an option within your desired time frame, all of the above tips may help you leverage your current role into an APM role elsewhere, especially if you have metrics to back you up (ie, I created a monthly trend report that helped to inform 20% of our usability backlog over time).

I think of product management skill sets in three major buckets: technical, business, and customer understanding. When I talk to aspiring product managers, I like to gauge the maturity of their skills sets in each of these buckets. Ideally a candidate would be strong in one bucket, have some basic understanding in another, and be actively working to hone a third (although I wouldn't expect any sort of proficiency). A good example of this would be a CSM. They likely have a very strong understanding of customer wants/needs, a good grasp on the business overall, but may be lacking in their technical skill set. This is also the reason I like to consider internal hires if we are looking to bring someone on that doesn't have previous product experience. An internal team member will likely already have a deep understanding of our market, our customers and our business overall. The initial learning curve of getting up to speed on those items is much less steep and we focus on the nuts and bolts of product management.

Any time I've accepted or considered accepting an offer from another organization, there are a few things I take into consideration: * Why am I interested in this opportunity? What new challenges or opportunities does it present me that I am not getting in my current role? For example, am I wanting to step into an opportunity that is within my comfort zone so I can lean into honing my product and leadership chops? Or do I want to enter a new vertical/industry so I can diversify my skill set? * Am I excited about the problems I'll be solving? * Do I like the people I'll be working with? If I'm going to spend most of my day M-F with this team, I want to enjoy that time. * Company growth: Where is this company now and where are they going? What are their plans for growth and how does my role fit into that? Don't be afraid to ask hard questions here while you are in the interview process. * Career Growth: Does this org have a well-define path to promotion? How do they see me growing into and out of this role? * Comp: What is the total comp package? Is it competitive with the market? Does it include equity? If it includes equity, do all employees get equity or is it only for certain levels and above? (This can make hiring difficult if it isn't available for everyone) * Undefinable "feels": Usually my own intuition guides me one way or another (although sometimes I don't want to listen) Note, I didn't say anything here about FAANG or the prestige of the company. While working at a big name can definitely help as stepping stone to other opportunities in the future, it's not something I personally give a ton of weight to.

The biggest change is the importance product plays in customer acquisition via trials and retaining customers past the 90-day onboarding period. When a product is self-serve, a PM should be paying attention to how their features drive trial conversion and the role they play in the customer onboarding process. This is often determined by identifying the drivers of PQLs (product qualified leads). So, for example, if we know customers that convert always use some combination of X, Y, and Z features within a few days of signing up for a trial, we will not only work to ensure that feature experience is excellent, but partner with PMM to make sure we are pushing all trial users to adopt those features rapidly. Similarly with onboarding, we want to ensure customers are adopting our stickiest features as quickly as possible. With self-serve products, customers are typically paying month-to-month and can shop around at their leisure if a product isn't suiting their needs. (This is in contrast to SaaS tools that are contract based and typically sold on a yearly cycle with upgrades by seat addtions.) PMs should analyze what their most successful customers look like (defined by some combo of product usage/NPS/age for example) and then look for patterns in the product usage of those customers. Once patterns emerge, say, a customer uploads a list of contacts within the first three days, again, you want to push all customers to take similar action. Even better if you can segment customers based on use case and push them toward the feature usage most relevant to their business/vertical. Another area to focus KPIs for self-serve is on tier or package upgrades and add-ons. What features are we building that make sense on a higher tier of our product that we can leverage for upgrades in the future? Is it a subset of the feature or the entire feature?

Everyone is going to make new mistakes coming into a PM role depending on where they are starting from. For me, my biggest mistake was letting my own imposter syndrome take over. I had worked so hard to move from a CSM role into product and once it finally happened, I couldn't get rid of the voice in my head saying, "Wow you are so lucky they *let* you move into product, don't screw it up, because you definitely have no idea what you are doing!" While this was kind of true (I really didn't know what I was doing at the beginning), I should have trusted the fact that I would not have been giving this opportunity if my managers and peers didn't believe in me. I was unable to focus on the skills that got me here, like my deep understanding of our customers and their problems, and instead focused on the skills I needed to improve, like my technical understanding. Give yourself the patience and grace to know you aren't going to be good at all of it from the get-go, but be hungry and eager to learn. Which leads me to my next piece of advice; ask for help! There is nothing wrong with saying, "I don't know" or, "I don't understand." No one is going to expect to you know everything right away and asking for help ends up saving a lot of time and energy vs you trying to figure it out on your own. It can be hard to ask for help, for fear of looking "dumb" or at least feeling that way. It helped me to identify a few allies early on that were happy to walk me through things (slooooowly sometimes), because they understood the faster I learned, the better our team would be for it. The first engineering manager I worked with was a great example of this. He became the person I knew I could always ping to say, "Heyyyy can you explain this to me in more detail. I'm not quite getting it." It was such a relief to always know there was a friendly face to walk me through tough problems. Lastly, decision fatigue is a very real thing in product management, especially for new PMs. Never in my career had I been the end-all be-all for making decisions and now all of the sudden, I had engineers and designers and asking me for answers left and right! It took me a bit to realize it was ok to be wrong, as long as we had a direction to move in. Not every decision has to be the right one, but the longer you take to make it, the more the team slows down. So just do your best, measure the results and be ok with pivoting if you are wrong.

This varies by organization. Regardless of the size of your product team, you should have the expectations for each level of product well defined and socialized throughout the organization (typically APM, PM, SPM, Group or Principle PM, Director etc). Even if you are only a team of one, it helps to have these levels defined, especially if you hope to hire new team members in the future or you want to make a case for yourself down the road for a promotion. That being said, I take a number of factors into account. * Is this PM meeting or exceeding the expectations for their level? * Are they taking on some of the work/expectations of the level above them? * How impactful are the features they deliver and the problems they are solving for? * How are they regarded by their cross-functional peers? * Do they communicate effectively outward and upward? * Are they actively working to improve their skill set and seeking out feedback regularly? These are just a few examples of success metrics, and, as mentioned earlier, expectations will vary from org to org. On another note, if you are a PM hoping for a promotion, here are some things that have worked for me in the past: * Make sure you are aware of level expectations. If you aren't, ask your manager. If your manager doesn't have these defined, you should feel empowered to ask, at least for your current title and the title above you. * Once you know and understand those expectations, have clear and defined examples of how you exhibit them at your current level and potentially the level above. For items you don't have examples of, work with your manager to identify opportunities to lean into those areas. * Don't be afraid to toot your own horn. If/when you get kudos from team members, capture and save it, be it a slack message, and email or a shout out in a meeting.

Every KPI exercise should start by asking, "What are the direct business outcomes we hope to move the needle on with this intiative?" So often I see KPIs focused on something like pure adoption metrics. Ok great, we want people to adopt this feature but WHY do we want them to adopt it? * Do we think it will help reduce churn? * Do we think it will drive conversion? * Do we see a correlation between customers that adopt this feature and stay past the 30 day mark? * Is this feature a key part of our Aha moment? I find that a good measure of if a KPI is more than just a proxy is if it cuts across at least two areas of measurement. For example, looking not only at the customers that adopted that feature, but also their overall net retention. The more data you can can layer on to a KPI to help understand the business outcome it's driving, the stronger measurement it will be.

Bringing engineering into KPI discussions is a must for any Product Org, especially when we are considering key B2B business metrics like churn and retention. I think product managers can often get caught in the trap of only considering which new features are going to drive the business forward and excite new customers, but no business will survive on new customers alone. How are you keeping your current customers happy and satisfied with the product? This is where some important engineering-driven KPIs come in: 1. Uptime: Understanding uptime and the reliability of your product are a key component to determining if your customers will be satisfied with your product. If you experience frequent outages or incidents, customers will run out of patience and start to look for other solutions. 2. Load times: How responsive are our pages and how quickly do they load? This is especially relevant in a B2B context where customers are potentially wasting money or losing deals with every extra second they have to wait to perform a task in your platform. 3. Reliability: While this may sound similar to uptime, reliability needs to be measured in the context of the feature you own with engineering. For example, with an ESP, what % of time do my email sends complete within our SLA? 4. Defects or Support Escalations: We strive to keep our total number of defects below a certain threshold. Our hypothesis being that fewer defects indicates a more reliable product and likely, more satisfied customers that feel heard when they take the time to let us know something is wrong with the product.

Create forcing functions that will encourage KPI creation and analysis throughout the product life cycle. Here are some ways I've had success in doing so: * I've found OKR exercises to be incredibly helpful in orienting teams around KPIs. As you set those Objectives, you have to also understand what your key results are, which often requires KPI measurement. Once the team has landed on those, it can become a topic of discussion throughout the product lifecycle...how is this helping us hit our key results? (This can also be a helpful prioritization tool, but that is a topic for another AMA.) * Ensure that in every product brief, PMs and PMMs are answering the question "How are we measuring the success of this product and product launch?" By answering the question early on, it forces the team to think critically not only about why they are building this feature, but how they will know if they are right. * Create a regular cadence of reporting on the health of your product line or area of ownership that welcomes debate on the what, why and how of what is being measured. * Bring team members across the org into KPI discussions on a regular basis. A CSM might have an incredible insight on what is being measured as it relates to customer satisfaction. An engineer might elevate a health metric that could be leading to churn. A support rep might identify a canary in the coal mine as it relates to defect trends. This type of discussion gets the entire org invested in KPIs and keeps them top of mind.