Rena Mashintchian

Generally, the sales team should focus on selling what’s already on the truck. However, if there are gaps that are deemed deal blockers for customers, one of the most important considerations is whether the feature being requested fits with the product strategy and is broadly applicable beyond the customer requesting it. If it is, then it’s more of a matter of timing. If it doesn’t, then no matter how large the deal is, PMs should be empowered to push back and say no to the request. However painful it may be to potentially lose a deal, the alternative of building something not in line with the product strategy could end up derailing the product altogether and costing you a lot more than the deal was worth. Press hard with account teams to understand if the blocking feature is the only thing holding a customer back from signing a deal. Oftentimes, a single feature is not the only gap. Also, avoid building a new feature for a prospect. Ensure the customer is committed before you commit. In my experience, things oftentimes don’t need to be built before a customer signs, but customers will expect to understand the product roadmap tied to the requested feature.

In general, I am not a proponent of building custom solutions for a single customer. However, if there’s a large customer who wants something that will serve the broader customer base, then we’ll consider it and prioritize it accordingly. Once you ship something, it’s out there in the wild forever (until you sunset it). And it’s tough to sunset things since someone will end up using it and relying on it. So, product managers need to be extremely prudent with their decisions about what makes it into the product. And they need to be able to stand up and say no if the request being made is not right for the product, no matter how large or important the customer requesting the feature is. In the case where a customer feature request doesn’t fit in line with our product direction, I’d suggest working closely with the account team and customer to really understand the problem they are aiming to solve to see if there are alternative approaches that can be used to meet the same need.

PMs are responsible for defining a winning product and rallying a team to deliver it. It’s one of the roles that requires a large breadth of skills, as PMs sit at the center of technology, business and design. Below are key traits that I look for when hiring a PM. Beyond these skills, cultural fit and passion/excitement for the role are also important considerations. Note that while it’s a bonus to have enterprise PM experience, it’s certainly not a requirement. * Intellectual ability - Ability to synthesize information, solve big hairy problems, make the right tradeoffs, and understand how to build a winning product strategy and execute on it. * Exceptional communication - Effective communication is essential in every facet of a PM’s job. They should be able to effectively cater communications/content to any audience (e.g. C-level, engineers, customers, etc) to bring transparency and clarity to stakeholders. * Ability to lead, influence and collaborate - In order to rally a team to build and launch a product, PMs need to collaborate effectively with a myriad of teams (e.g. engineering, design, business development, marketing, sales, legal, security, etc), lead teams towards a common vision, and influence and inspire teams to reach a common goal. * Customer centricity - PMs need to deeply understand and empathize with customers in order to figure out their pain points and how best to solve them. In the enterprise space, PMs should also understand the different user personas we need to serve, e.g. the buyers who purchase the products, the administrators who administer the products on behalf of their users, and the end users who use the products to get their job done. * Technical chops - While PMs don’t require a CS degree, they should understand the technical aspects well enough to credibly speak with engineers, understand and weigh in on technology tradeoffs, and be able to communicate technical details to customers and stakeholders. * Ability to be strategic and tactical - They should be able to define the big picture and execute to it and know when to zoom in and zoom out. * Product intuition - They should understand the ingredients needed to build a winning product. * Hunger, curiosity, and grit - These attributes will fuel someone to learn quickly, grow, think outside the box, and overcome when things get challenging.

In my mind, we are always selling to a customer. It starts with the initial sale, when we move an organization from a prospect to a customer. Once they become a customer, our goal is to ensure they continue to renew their contract with us. And not only do we want them to renew, but we also want to upsell them to additional products and services. Throughout the various stages, PMs should be there to support account teams as needed, especially around handling customer objections. It’s very beneficial to establish strong relationships with the sales team and strategize with them on how your skills and expertise can be leveraged to move a deal/customer relationship forward. Setting up prep calls with account teams ahead of customer calls is always invaluable to this effect as well. Here are some more ways PMs can support the sales team on deals: * Evangelizing the product - PMs serve as the source of truth for the product. PMs can speak to the vision and roadmap, be the domain and product expert, engage in customer feedback sessions, and really help customers understand how this product can benefit their organization and use cases. * Feature requests - Customers will also have new feature requests, some of which are nice to haves and some of which are considered blockers. PMs will be engaged to discuss these, and may be more heavily involved when blocking features are identified that customers want commitments on before moving forward on a deal. PMs are also the ones that should hold the line when feature requests don’t align with the product strategy. * Customer escalations - Escalations can include gap features that are needed to close a deal, product features that don’t work as expected, or a heinous bug that greatly impacts users. Whatever the reason, how a PM handles these tough situations and manages the relationship with the customer can make a big impact on the customer relationship and their satisfaction with the product and your company overall.

Enterprise vs. mid-market vs. SMB customers are typically defined based on the number of employees in the organization and its revenue. Regardless of the organization size, many of the core PM activities are similar. However, there are some key differences I’ve experienced that are worth noting. PMs should keep these in mind and factor them in as they build out their product and release plans. Build for all segments Typically, you’ll have a small number of very large enterprise customers and a very large number of smaller customers. The largest enterprises also usually contain a lionshare of the user base, draw in the largest account values, and have the most strategic relationships at the executive level. Because of this, the focus may sometimes be heavily weighted towards these enterprise accounts and you may tend to over rotate on serving their needs above other segments. Remember, though, that your product should serve all segments and prioritize your feedback and requests accordingly. Speed of adoption varies based on segment Smaller organizations tend to be more nimble when it comes to accepting/rolling out new products, features, or releases. Because they are smaller, the change management effort is typically smaller, the product validation effort is usually faster, and they are typically more willing to roll out releases on a faster cadence as compared to enterprise customers. Enterprise customers, on the other hand, tend to take more time. It’s not uncommon for enterprises that tightly control change management to wait several months after a build is released to production before they are willing to deploy it within their organization. Early testing and validation of features varies based on segment * Larger organizations may be reluctant to participate in pre-release product betas, which are typically the best path for product teams to get early feedback on if the product meets users’ needs. Their product feedback may not come until the feature is actually released and users can start using it. * In larger organizations, it may also be harder to find the right users who can validate the product/features. * On the plus side, larger organizations provide a greater diversity of use cases given the large number of users. Therefore, customer research on and beta participation by SMB customers may require a larger volume to cover the breadth of use cases of a single large enterprise. Based on these differences, here are some of the things you may need to do differently as a PM: * Define different approaches for customer research based on org segment * Plan out different test and validation strategies based on segment * Define different deployment strategies to accommodate feature and release adoption based on the needs of the org segment