Beware treating a product team like captive IT

WFH // august 20 2024

I live and breathe the "software business," as in, a company whose business is selling software and/or access to its software. It's an obvious statement, though, that in today's "software is eating the world" that pretty much all aspects of the modern enterprise are software enabled. And conjoined "tech" companies are becoming more the norm, and arguably are insanely valuable.

But I don't think "product management" at these companies means what I think it means for a "software business." I think PM exists in these companies (and even in IT), for sure, and has many of the same motions, but I think it has a different character relative to the highest value PM can deliver to a "software business" organization.

I'm coming off a call with a team that is a "product" team - and in this sense I include both PMs and Devs. They are supporting a team, internal to the company, that is providing a tech enabled service. The internal team considers itself "the customer" and in many senses they are "the customer." That said, in fact, they are not the ACTUAL customer because they do not write checks to the company. Beyond them, out in the market, is the actual customer of the company. The customer is the economic engine of the company, and the service team provides a service to the customer, in exchange for the monies. It's a basic point, I realize.

The danger emerges when teams don't have extreme clarity about what their products are, and who their customers are. Teams that don't think and speak clearly about this tend to dig in on internal use cases, and start automating things that maybe (probably?) don't need to be automated.

The need in this case is the economic performance of the company, relative to its actual $$$ paying customers. How do the end customers see the world? What do THEY consider valuable? What problems is the automation solving FOR THEM? Not for the internal team.

I recognize that teams mix and match tech to perform their jobs and it's commonplace that the line between internal-use and external use and monetization is blurry. See: eCommerce or CPQ or order management. Truly, teams have fuzzy edges and there is a give and take between internal and external. I'm not really talking about these situations. Usually here it's a matter of negotiating who does what, but there isn't much disagreement about who the customer is.

Internal automations ("make my job easier!"), however, are limitless. They are without limit, but they are not without diminishing return. Similar of course to external customers. Some things are just not WORTH doing. They are possible, but not worth it.

The heavy lifting of a PM team is to be that adjudication. What is WORTH doing? Not what is possible to do, but what is VALUABLE to do.

The danger manifests in these situations because PMs that focus internally, mostly, on "internal customers" (as an erstwhile captive IT team) get in a position of having to be the social bad guys. To say no to your colleagues is hard. Everyone wants to be a good contributor and this is a great instinct. AN AMAZING INSTINCT.

From an overall company perspective, though, you set your team up for failure and morale problems by allowing these meetings and motions to be the dominant working model. Like so many things, it's fine in moderation. When this becomes the EXPECTATION, your "software business" is going to be in for a rough rough road.

Why? Without clarity and precision in language, NO does not mean NO... "no" means escalate. When the product backlog is treated like a social contract or cultural norm inside the company, everything becomes a political problem, and actual value gets lost. The only customer that really really really matters is the end customer. The OUTSIDE customer. The market customer. The customer that pays your company.

PMs (to me anyway), rightly understood, focus on the market customer. They take input from stakeholders, and always have an eye on cost. But cost is not the primary driver. Value is the primary driver, and cost is a handbrake. It's something to weigh, but seldom is it THE REASON to invest in your roadmap.

Years ago I heard someone say that for a roadmap item you either needed "to make a dollar, or save three." That seems like a good heuristic.