D Matthew Landry

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 start thinking about a model to trade off product vision, addressable market expansion, competitive threats, technical debt, quality & reliability, scaling bottlenecks, and so on. The question you'll ask is: What can the team work on today that maximizes short term opportunity without hobbling long term viability?

Product priorities more often resemble a Bayesian decision network than a flow chart.

Rule of thumb: don't build before they buy. If this whale wants something specific, they should put skin the game, either through a services/customization contract or a purchase contract contingent on a feature delivery.

Of course, there's a lot of nuance to a situation like this. 

Maybe there's an obvious gap in the product offering that the competition universally satisfies. It's probably something already on your backlog, and so you know it will unlock multiple incremental sales opportunities by developing it. (Just be careful not to overestimate the ROI on that development; assume the whale deal falls through.)

The more dangerous trap to avoid is mistaking noncommital interest from someone inside that enterprise for a promise to buy. Enterprises have many stakeholders (known and unknown) and even more competing agendas. There are likely multiple reasons that they're not ready to buy, and it's easy to focus on one obvious thing. But it's not the only thing.

If there's really just one thing holding the enterprise back from an otherwise enthusiastic purchase, you and your account team can likely come up with commercial terms to get the deal over the line today with the product on the truck, and a structured agreement to enhance it tomorrow.

Taking for granted a baseline of solid product management fundamentals and team simpatico, I feel the following play an outsize role in determining success in the enterprise:

• Skeptical curiosity
• Strong opinions, weakly held
• Speaking and presentation skills, in front of senior execs & audiences
• Ability to simplify and explain technical concepts
• Interest in customers' industries and their end customers
• Empathy for the sales team and how they sell
• Familiarity with routes to market and channel ecosystems
• Awareness of how all teams contribute to product delivery
• Financial understanding of how the business operates

Tactically, product managers can set the patterns that define successful customer accounts (e.g., via beta testing, early wins, clearly described use cases, &c.), engage with key customers to form lasting business relationships, and amplify the key customer problems.

This is why customers love to speak with PMs. What's best for the customer is what's best for the product, so PMs are seen as sources of truth. The PM will listen for problems, won't egregiously oversell the product, and speak to roadmap direction with authority.

Organizationally, product managers help Sales the most with honesty, empathy, and frequent engagement.

 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.

 Entry-level product managers for an enterprise product line tend to come in from two paths: technical background, and business background.

Those with a stronger technical background might come from another part of the business, such as technical marketing or solution/sales engineering. They make up for a relative lack of experience in product strategy with deeper knowledge of product specifics (or demonstrated ability to learn), understanding of the industry & market (or demonstrated ability ...), and hours on the clock sitting with customers to listen and problem solve.

Entry level PMs coming in with a business background might have just finished an undergrad with a blend of technical and economics coursework, or may have completed an MBA program undertaken to support a career change. This candidate potentially has more analytical tools and structured approaches to understanding product strategy, while they have less practical experience with the product, industry, and customers.

The recruiting assignments (if any) and interviewing discussions are tailored to these different backgrounds. 

For the technical candidate, I would look for traits that indicate an affinity to picking up the product strategy. What strengths/weaknesses/opportunities have you observed in the offering? Which customers would you go to for research purposes and why? Which competitor do you most admire and what would you do about them? I'd also screen out one very common motivator: becoming a PM to control the engineers. 

For the business-oriented background, I'm looking for someone who is hypothesis and data driven: If they don't understand the product and market, will they ask thoughtful questions and validate assumptions to become an expert? Do they have a sense of sales channels and cost structures, and what tradeoffs might matter when bringing the product to market?

 Regardless of background, I'm looking for enthusiasm and intrinsic motivation so the new PM can dive in to learn about everything and everyone. Then they're ready to help form a product vision and catalyze development & adoption.

 The impact that a product manager has depends much more on the type of product team and its role in the company than on the product's market (B2B, B2C, SMB, mid-market, enterprise, &c).

Even for a miniscule aspect of a product, the PM has an opportunity for tremendous impact when they have responsibility for the full lifecycle and access to the end customer/user. They will be able to generate real insights, solve real problems, and deliver real value.

The best product management teams deliberately organize themselves to ensure maximum responsibility and access, even as individual PM scopes may narrow as the team grows.

"Custom infrastructure platform" is nearly an oxymoron. :-) Anyway, it doesn't sound like a product; products are offered for sale to a market.

A "custom infrastructure platform" is very likely an internal project. It will have organizational stakeholders, clearly defined objectives (be very cautious here!), and a budget based on a (likely inflated) forecasted operating outcome. A project or program manager will be responsible for delivery here, and they partner closely with a technical architect who designs the system to spec. 

While there are certainly aspects of project management overlapping with product management, it is a distinct discipline worthy of its own AMA!