Profile photo
rimas silkaitis

Case Practice: Enterprise Customer Product Judgment

If you lead product managers in B2B or enterprise software, one of the hardest things to teach is judgment under commercial pressure. It is relatively easy to coach someone on writing a PRD, running discovery interviews, or slicing a roadmap. It is much harder to give them repeated practice with the messier questions: when a large customer asks for something important, how much do you bend? When sales pushes for a commitment, who decides? When the business model depends on long, relationship-heavy deals, how do you keep the product from turning into a pile of one-off work?

That is why I like using business-school cases with product teams. They let you rehearse the hard calls without spending real money or disappointing actual customers. One case that works especially well for this is Product Development at OPOWER, written by Thomas R. Eisenmann and Alison Berkley Wagonfeld for Harvard Business School.

I am not going to reproduce the case here. That would defeat the point. What I do want to do is explain why this particular scenario is useful if you are trying to sharpen a team’s enterprise product instincts.

Why this case is a strong training ground

From the public description alone, the setup is already familiar to anyone who has worked in enterprise software. OPOWER sold software and services to utility companies, and its product organization had to respond to customer requests while also protecting a coherent roadmap. The case centers on a product leader who has to decide how much influence clients should have over product development and how the company should structure decision-making around those requests.

That is an unusually good practice scenario because it forces a team to wrestle with several enterprise realities at once:

  1. The buyer is not the end user. OPOWER operated in a B2B setting where the paying customer and the downstream user were not the same person. That alone changes product work. Teams have to reason across procurement, executive sponsors, operators, and end-user outcomes rather than pretending there is a single clean “customer voice.”

  2. Revenue pressure is immediate, product costs are delayed. A sales request often arrives with a number attached to it. The cost shows up later in roadmap drag, support burden, implementation complexity, and product sprawl. This is exactly the kind of tradeoff PMs need to learn to spot before it becomes visible in the P&L.

  3. Customization is not a binary choice. Teams often talk as if the choice is “say yes” or “say no.” In practice, the real work is in finding the middle: configurable patterns, sequencing, commercial packaging, pilots, services-led work, or a deliberate strategic exception. A good discussion of this case quickly exposes whether a team can generate options instead of collapsing into slogans.

  4. Org design matters as much as product taste. The question is not only what to build. It is also who gets to decide, what evidence counts, how escalations work, and how product and sales share accountability. Enterprise product failures are often governance failures wearing a product costume.

  5. It surfaces whether your team understands product strategy in a B2B context. A lot of product advice is written for self-serve SaaS. This case is useful because it forces people to work in a world with contracts, strategic accounts, implementation concerns, and uneven customer power.

What skills this case helps teams practice

The best case discussions are not about guessing what happened next. They are about exposing how your team reasons. With this one, I would use the exercise to look for a few specific muscles.

Commercial judgment

Can the team distinguish between a loud request and a strategically important one? Do they know how to evaluate account value beyond headline revenue? Can they talk clearly about retention, expansion potential, reference value, market signal, and precedent risk?

Product boundary-setting

Can they define what belongs in the core product versus what should stay in services, implementation, or partner work? This sounds simple until real money is on the table.

Cross-functional decision-making

Do they understand how product, sales, customer success, and executives should work through these conflicts? Strong PMs do not just have opinions on the feature. They know what decision process prevents the same argument from repeating every quarter.

Pattern recognition

Can they convert a single customer request into a more general product hypothesis? Enterprise teams get into trouble when they treat every request as unique. They also get into trouble when they assume every request is broadly representative. This case is good for testing whether people can tell the difference.

Strategic communication

Even a good decision can fail if the team cannot explain it. In discussing this case, I would expect PMs to articulate not only what they would do, but how they would communicate the decision to sales, leadership, and the customer.

How I would frame the exercise

If I were facilitating this with a team, I would make the goal explicit: this is not a debate about whether customers matter. Of course they do. The real question is how an enterprise company should absorb customer input without letting its product strategy get hijacked by its most forceful accounts.

I would also tell the group to avoid fake purity. In enterprise software, “never build custom work” is usually as unserious as “always do what sales asks.” The point of the exercise is to practice informed tradeoffs.

Facilitator questions

These are the questions I would use to drive the discussion:

Start with the problem

  1. What is the actual decision that needs to be made here?
  2. What makes this a product problem instead of only a sales or delivery problem?
  3. Which stakeholders matter most in this scenario, and where do their incentives diverge?

Pressure-test the request

  1. What would make a customer request strategically important rather than merely urgent?
  2. What evidence would you want before agreeing to build something for a major account?
  3. How would you tell whether this request reflects a broader market need or a single customer’s local preference?
  4. What hidden costs should be included when evaluating a custom request?

Explore the option set

  1. What are the real options besides a simple yes or no?
  2. Could this be solved with configuration, packaging, services, process changes, or sequencing rather than net-new product work?
  3. If you were going to make an exception, what conditions would justify it?
  4. What kind of requests should the company reject on principle?

Examine product strategy

  1. What does saying yes to this request teach the organization about its product strategy?
  2. What precedent does the decision create for future deals?
  3. At what point does responsiveness become roadmap fragmentation?
  4. How should the company define the boundary between a platform capability and a customer-specific feature?

Examine operating model

  1. Who should have decision rights when sales and product disagree?
  2. What forum or mechanism should exist to evaluate these requests consistently?
  3. What metrics would you track to see whether customer-driven work is helping or hurting the business?
  4. How should incentives be designed so that sales and product are not working at cross purposes?

Bring it back to your own team

  1. Where in our current product do we already see versions of this problem?
  2. Which of our existing customers have disproportionate influence, and is that healthy?
  3. Where have we confused revenue opportunity with product strategy?
  4. If we ran our intake process better, what decisions would become easier?

Why this is worth doing with a team

The value of a case like this is not that it hands you a universal rule. It does the opposite. It shows your team that enterprise product management is often about controlled inconsistency: creating principles strong enough to guide decisions, but flexible enough to handle strategic exceptions without losing the plot.

That is exactly the kind of judgment teams need if they want to build serious B2B products. They need practice recognizing when a request is a wedge into a market, when it is a trap disguised as ARR, and when the real issue is not the feature at all but the company’s lack of decision discipline.

If you want to run a session on enterprise product craft, this case is a strong candidate because it forces the room to confront the tension that defines so much of B2B product work: serving customers well without becoming a custom shop.

If you want the broader argument for using cases to develop product teams, I wrote that up in Cultivating Product Management Teams with the Case Method: Why Practice Makes Insight.