Applying Product Management to "Internal Products" can be a bit strange. Sometimes it feels a bit like trying to make a square peg fit into a round hole. Having observed lots of organisations (mostly large, some small) struggle with aspects of this, it's something I've been mulling over for years now. Earlier this month I caught up with John Cutler at Oredev Conference in Sweden, where he gave a talk about Product Thinking for Internal Teams. We had a follow up chat on the topic this morning, which forced me to crystallise some of my observations.It's quite possible that I'm missing something here. If none of this resonates with you, that's cool, just ignore me. As always, context is king. YMMV. Or, as Blondie puts it: "Every gun has its tune."
There's a lot of good stuff that comes from applying some version of "Product Management" to the software you build for people inside your organisation to use. Probably the most compelling positive is where it acts as a catalyst to break out of the old way of doing things. One of the main drivers of this isn't just that it's a different term (although that helps), it's that we are specifically giving people the permission to take a different focus. When the tools and technologies we provide for internal usage are developed and supported by "I.T." they tend to be treated as an order-taker by the rest of the organisation. This is what I want, just hurry up and give it to me.Calling it "Product Management" however casts the net wider. It gives those teams the permission and encouragement they sometimes need to get beyond just the tech that they are building, or the requirements they are asked to deliver. They can instead look at the overall process or experience, do the necessary research to understand the pain points from a wider perspective and change tack to discovering and developing much more valuable, holistic improvements. Sometimes that involves software, but it may actually only be a small part of the change. As one of the Internal Product Managers I know said recently, "It's not just digitising forms." Yes!I also see a lot of examples of taking the principles of Product Management and figuring out how to make that relevant to the development of internal products. There's lots of good work being done in this way, and that is something to encourage and celebrate.
A lot of the stuff you read and hear about Product Management comes from startups or products that have very clear feedback loops with customers (especially from the SAAS products world). As a result, you hear a lot of insistence that you have to be "customer focused" or even the slightly exhausting sounding "customer-obsessed". You'll also find lots of references to Customer Research, Product Market Fit, and the like. These are all good things. To be considered a product, of course you need a customer.The problem is that for Internal Products it's often not at all clear who the customer is, or even if what is being developed really is a Product. Are we selling this thing? Is the customer the person paying for it? Or, is the customer the person that uses it? What does Product Market Fit mean when there isn't really a marketplace? What if the only people who use it are developers? Or finance? Basically, it can get quite confusing quite quickly.I have a fairly simple bright-line test for identifying the Customer (see thread, for more on this) :
To be a Customer you have to:a) have a Choiceb) Exchange something of value.
If you can't answer yes to both of these questions, are they really a customer? Does this really matter? Well, yes, it kinda does if you're going to be obsessing about these people! At the very least, we should be able to say what a customer isn't, surely?My bright-line test above is based on considering it from a Signal to Noise Ratio perspective. When people don't have a choice, their use of your product has very little signal in it. If they have to use it, is it any good? Have we created something of value to them? It's hard to tell, because they don't get to choose. For instance, I've seen loads of examples of corporate I.T. shoving Sharepoint down the throats of employees, even though it's despised by most. (Friends don't let friends use Sharepoint.)And even if they do have a choice, if they're not exchanging anything of value, then likewise, their decision to hire your product to get a job done is likely to be noisy. If the most they are willing to pay is their investment in time learning and using it, the question you have to ask yourself is: are you really solving a problem that is worth solving? How would you know?The reason this matters so much is that I've seen lots of teams (especially in larger organisations) waste a lot of time developing stuff that it turns out nobody wants. I don't think the teams enjoyed doing that. It's a ginormous waste of peoples time and talent. It matters to have teams feel like they are doing valuable work.
It's not just about the risk of developing products that turn out to be worthless. There's at least limited downside there. A limited amount of money wasted. A limited number of people who have wasted their time and talent. There's another risk however that could possibly lead to an existential crisis for the whole company. Losing a small(-ish) bet is one thing. A risk that involves the potential for total loss or ruin of the organisation is another entirely. This risk may not seem like an urgent thing, and we may ignore these potential side-effects, but those effects are there, and they can be deadly.
In my view, the most dangerous thing an organisation can do is to
. The primary job of companies is to create new customers. To survive, you also need to keep those customers. Yes, there's such a thing as negative churn, where you let some low-value customers go, by not serving them, and sell more to existing customers. Ostensibly, negative churn is a good thing. But for any of you who have read "The Innovators' Dilemma" you can maybe spot the problem brewing here. We're at risk of over serving, fleeing upmarket and leaving a soft underbelly exposed for a new entrant to come in and eat us from underneath with a product that is initially inferior, but through sustaining innovations improves over time and eventually kills the incumbent.In short: the word Customer is one that is worth protecting. If we don't protect it – if we allow everyone who is forced to use our product to be called customers– then we risk losing sight of and watering down the term. It's very hard to maintain a "customer focus" when anyone and everyone is a customer, including colleagues internal to the organisation who have no choice and aren't exchanging anything of value.There are other issues as well, like the drift back toward the bad old days of I.T. as an order-taker, because "the customer is always right". Which if you refer to colleagues as "customer" that's exactly what you'll encourage. This is somewhat ironic given what I've said earlier about "The Good". Where this gets really screwy though is when the thing you're developing has the potential, or even the express purpose of removing a set of manual steps, currently being carried out by your "customer". You can't refer to people as "Internal Customer" one minute, only to put dozens of them out of a job the next minute. To my mind, the terminology being employed lacks integrity when used in this context. It's a lie.
I get it though: Product Management is the hot new thing. Everyone's gotta be doing it, so in order to not exclude anyone, we have to bend the concepts and terms in order to shoehorn everything in. There's huge pressure for those involved in leading development of software for internal use to conform to this. We're too busy twisting ourselves into pretzels to even ask how this applies in this context, or whether it makes sense. Gotta conform!
Aside: This reminds me of watching kids play soccer. They all swarm around wherever the ball goes, in a tight group rather than spreading out and passing to each other. To some extent, Product Management is just the latest in a series of hot new things that everyone is chasing around the field. We've had "Agile Transformations" in the early noughties, then "DevOps" and "Digital" became the new hotness a few years back, and we've all observed the kids chasing SOA, Containers, Cloud and Big Data and the hot mess that is "Scaled Agile". Now we're onto Machine Learning/AI, Kubernetes, Microservices and AR/VR. It's not that these things are bad or wrong, it's the lack of critical thinking that I observe in the chasing of them. There's very little situational awareness and an awful lot of FOMO, buzzword bingo and all too often just a renaming/rebadging of the old thing.
Maybe we just need to stop trying to force-fit this stuff? Perhaps instead we do the work required to figure out how it might fit in our context, whether the terms make sense or not, and how it might be made relevant instead of cargo cult style adoptions?We could maybe even allow more than one or two "plays" in the playbook? That instead of all being "offense" focused, maybe we need a few different "defense" plays. And maybe around that we can have some training, coaching, dieticians and psychology, so that we're not quite so mono-focused and fragile. At the very least, we should have some reinterpretations of those plays to suit the playing field we happen to be on, no?This reason this matters is so that teams that don't have a direct link to the customer can be treated as equals in the system, rather than a poor cousin of those other teams who do have that. Maybe we don't all have to be on Offense, you know? Maybe a bit of situational awareness, and diversity in focus and approach is actually a better way to play and win whichever game you're playing?I don't know what the name of these different "plays" might be. Maybe you should think about it in your context? I quite liked how at Starbucks they referred to employees as "Partners". Would Partner instead of Customer for internal products do it? Why is User focus not considered good enough for internal products? And (shock horror!) maybe it's NOT a product that we're developing, maybe it's a Service? Maybe it's a Platform? Maybe the thing that we're trying to improve is really the Experience for internal users?Service Designer? Platform Manager? Experience Designer? Partner Services Designer? Actors, Users, Stakeholders, Partners, Colleagues, Coworkers, Agents, Systems... I'm sure there are loads of possibilities.And instead of being "Customer focused" or even obsessed, maybe we can just be problem focused? Or even problem obsessed if you really want to feel that strongly about it? Or partner focused? Or people focused? That these problems are being felt by our colleagues rather than customers shouldn't necessarily make them any less valuable to the organisation. If by reducing the pain, or addressing the needs of our colleagues we can all do a better job of addressing customer needs, that can be incredibly valuable. It can even be a force multiplier. Hey, maybe that's another way to think about it: "Force Multipliers"?
No, not at all! There's
of good principles and thinking in Product Management. Rather than recreating all of the specific implementations of what others have done, think carefully about how those principles apply
. This is especially important when the thing you're developing is for internal use only. Not everything we develop is a "Product", and we don't all have to be "Product Managers". In particular, we should really be careful –protective even– about who we refer to as "Customer", lest we forget...
Get the latest posts delivered right to your inbox.