How does the product manager role change when you’re focused on enterprise customers vs mid-market and SMB?

 In the broadest sense, the role of the product manager doesn't change. The customer profile changes, the buying patterns change, and the routes to market change. The core PM responsibilities don't necessarily change.

However, many of those customer changes have an impact on how the PM does their job.

For example, enterprises often separate the end user (the person who wants to use your product), the decision maker (often someone higher in the user's reporting chain), and the economic buyer (usually in a purchasing department). These are all stakeholders, and they all deserve attention from the PM.

Then there's the famous Request For Proposal. With all of those stakeholders in the purchase, everyone feels better when there's a structured approach to comparing alternatives and choosing a winner. The RFP is the tool of choice for almost every enterprise, and the RFP can make or break a product's success. It deserves its own discussion, but the point is that RFPs influence buying decisions, so RFPs deserve PM attention.

In terms of routes to market, enterprises see more of resellers, system integrators, and direct sales reps than self-serve marketplaces (of course, there's plenty of buying on a credit card, too). So your product pricing, cost structures, and selling approach may need to accommodate a more layered channel.

Finally, the relative number of enterprise customers (few) compared to mid-market (many) and SMB customers (MANY) usually means a PM can spend focused time with enterprises.

BTW, mid-market can take on some of these characteristics; depends on the customer and industry.

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

A product usually graduates from the SMB mid-market customers to larger enterprise customers as it stabilises. Larger enterprises usually look for reference implementations before committing, which usually makes the overall sale that much harder. Some key features that usually cut across product modules that make a product enterprise-grade are:

• As employee roles & responsibilities tend to be defined in larger orgs, they usually look for granular and flexible user access controls and permissions that mimic their organisation hierarchy - This is also a great monetisation opportunity with larger enterprises 
• Especially in a SaaS model deployed on the cloud, enterprises usually hate surprises/changes - and tend to look for ways to test changes before they apply - An isolated and production equivalent Sandbox environment to experiment is preferred
• For high-volume SaaS products, compartmentalisation/isolation of traffic surges that are guaranteed, backed by SLAs 
• Robust data security and data retention model that is both transparent and the policies documented and certified
• Periodic security audits & certifications that prove platform stability and adherence to industry best practices 

Many of these donot usually apply to SMB / longtail who primarily focus on quick onboarding, rapid turnaround on setup and usage.

I agree with the comments from other responses. There are a few additional items I would add:

Additional requirements / taxes

When targetting larger enterprises (and some certain vertical in the small/medium space), there will be additional requirements you will need to address. These are not necessarily linked to your product's value itself, but just items that are table stakes to get into the customer. A simple example is security, which though not something to be ignored for within consumer space, goes to the next level in terms of expectations from enterprises. This in turn leads to specific set of security requirements you will need to be aware of (e.g. role based access as a simple example, let alone more focus during security team reviews on data residency / data access etc).

Gathering feedback / customer responses

It has been mentioned in other posts that your customer audience will be different. This is true, but it also means that there is a great opportunity to have direct relationships with your key enterprise customers, as there are generally less of them, compared to medium/small. Additionally the weight you can put on a few customers input can be increased. Therefore though can still use traditional mechanisms around tracking user activity etc, it is very advisable to have a customer advisory council, or lean on account managers to provide strong customer input.

Sales team motivation

This is a key area that I believe is different for enterprise, in that the sales team motivation has to be understood. Typically enterprise sales are a few big whales that sales team focus on, and their commisions are very linked to. This can mean that the sales team put extra focus on any immediate sale or renewal blocker (say for upcoming quarter) vs medium or long term strategy. As a PM its important to understand not only what are good customer requirements (that apply broadly or strategic sale), and when to potentially say no to a request to not randomize the team / roadmap too much.