Customer-facing products are usually a product company’s crown jewels. They look and feel great, which tends to be the result of an end-to-end process. Personas, canvases, journey maps, lo-fi and hi-fi prototypes — you name it. How about internal-facing products, the ones we build for our own coworkers? What does usually happen?
An engineer is given a week to generate a clunky backoffice directly from the database, using the default Bootstrap template. Sounds familiar to you? If it does, you might also be familiar with the household excuse.
“It’s just internal, right?”
Yeah, sure, it’s just internal…
- …until it degrades your customers’ experience, because a customer-enabling manual process becomes slower, ineffective, and more frustrating for both your customers and your coworkers who are trying to serve them.
- …or until this frustration drives the users so mad that it becomes a PR nightmare for the company.
- …or until someone screws up big time, like that time a bad UI was one of the ingredients contributing to someone sending an emergency missile threat alert to over a million people in Hawaii.
These examples show bad internal products can become customer-facing problems. Not so internal anymore, uh? The other way around, good internal products can help your coworkers achieve great things for your customers. This equally true whether they’re front-end tools or platforms with APIs.
So it’s fair to also call these “customer-enabling products”. What I’ll share with you today are learnings from 6 years doing product in both customer-facing and customer-enabling products. I hope these learnings and my personal view convince you that managing internal-facing products can indeed be as fun and fulfilling as managing customer-facing ones.
I’ll start with a contentious question.
Is it fair to call internal-facing products “products”?
Well let’s ask ourselves a few questions.
- Aren’t they valuable?
Don’t they achieve business goals in exchange for delivering value to the end user? - Don’t they have to be usable?
Don’t they resort to technology to deliver (and not hinder) a user experience that matches their Job To Be Done? - Doesn’t building and maintaining them have to be feasible,
both technologically and financially?
Re-use with appropriate attribution.
Internal-Facing Product: Vision & Strategy
So if we have an existing (or potential) internal-facing product, we must frame its role by having a clear vision and strategy for it. But we can’t be naive: these do not exist in a void. You need to establish how this internal-facing product is an ingredient in the business strategy towards the company’s vision.
Re-use with appropriate attribution.
If the company has clear goals for a certain time frame, and KPIs that indicate progress towards that goal, that’s already a good start. The product org should also articulate what are each product’s set of KPIs that show progress in contributing to the company’s goals. These should mirror in some way the vision for that product and, as a result, the mission of the team behind that product for a significant time period.
Your objectives for shorter time periods should be more tangible, and for the sake of argument let’s consider you use quarterly OKRs for that. Regardless of your product discovery & delivery process, the capabilities coming out of it need to aim at moving those OKRs forward.
In this manner:
- for each feature you launch or are working on, or
- for each experiment you run,
you should be able to establish your golden thread all the way up to the company’s overarching goal. For customer-facing products the golden thread tends to be more intuitive for most people. So it’s particularly important to establish this connection for internal-facing products. It’s one of the first things I’ve ensured is in place when I joined product teams. Speaking of teams…
Product Team
If an internal-facing product is a product, it needs to have a product team. And a product team needs to have all the skills needed to autonomously pursue the product’s mission. If we’re talking about a tool, this means proper user experience design capabilities. The team also needs to be together and hold its mission for long enough to really make a difference.
If we’re talking about a platform, this is equally true. The user experience of a developer integrating onto a platform is not a trivial matter. For a platform, I find that having a technical writer in the team makes a big difference to this user experience. In my current team, one of our weak spots when I joined was our platform’s documentation. It was scarce, and written from the point of view of those developing the platform (not on the platform). This meant using it properly required a lot of back and forth between teams. After we launched a user-centric documentation, this back and forth dramatically subsided. This meant:
- more focus for the team developing the platform, and
- more autonomy and efficiency to those using the platform.
Outcome over output
Finally, everyone in the team, regardless of their function, needs to think of themselves as a product person: “outcome over output”. Of course the output needs to be there. But we must build the product together with the customer’s and the users’ needs front and center — not just to build more stuff for the sake of building. You’ll hardly ever afford the same people, budget, time as customer-facing products, so you must be careful where you spend it.
The golden thread we just saw helps a lot in this regard. As an extreme example, in one of these internal-facing product teams, we once had a great impact with something as simple as colour-coding a number on a dashboard. Everyone was happy about it, because what mattered was that we had a positive impact on the users in a way that benefited the business. Which leads us to the users of your internal-facing product.
Users
It’s usually said of these products that they have a “captive user base”. That’s probably the main reason behind the “it’s just internal” excuse to under-resource internal-facing products. There’s a general feeling that these users don’t have an option. That they’ll settle for whatever piece of garbage you give them. Turns out that’s not true.
If your product doesn’t fit their needs, they will use something else. They will either:
- use your product in ways you didn’t intend it to, or
- ditch your product (or a part of it) in favour of whatever is within their reach that takes their pains away. (It’s often an Excel spreadsheet.)
This shows one obvious thing: that your users are only human. And because they’re human, you need to treat them as such. Internal-facing tools are often linked to measuring and improving the performance of people on a certain manual process. As a product manager, you can’t shun the responsibility to draw a red line between
- business objectives, and
- treating people unfairly or unethically with your product to achieve them.
Meet them!
As we’ve seen, the users of your internal-facing products tend to be your coworkers. In normal circumstances, they’re likely to be one floor away from your desk, so you really don’t have a great excuse not to meet them.
Of course they might not be there: they might be coworkers in another location, or an outsourcing partner. In that case it’s worth it getting help from your manager to back the expense of going to meet them where they are. And it’s not just you and your design buddy. Encourage the engineers to join you too. When I joined the Service Platform team at Onfido, the engineers had only gotten third-hand insights about the users. A few engineers joined me and Design in spending a week in India by our users’ side, and it completely changed our perception. That trip accelerated the ability for the product team to have an impact on the company that vastly exceeded the cost of the trip.
Of course times are different right now, with the pandemic and all, so we need to adapt accordingly. But the bottom line is: as PMs we need to be doing whatever we can to listen and observe our users in the environment in which they use our product. And there’s no excuse to not do this for an internal-facing product.
Stakeholders
Besides your users, you might have more stakeholders than you think. Let’s look at them along the “Interest” axis of the classic Power vs Interest matrix.
High-interest stakeholders
High-interest stakeholders range from:
- the more powerful ones (such as the top brass of the functions or units directly impacted by your product — a.k.a. your users’ bosses), to
- the less powerful ones (alas, your users).
The more powerful ones tend to try and manage your product for you. But all your high interest stakeholders are potential allies. Your users can be champions of your product, and influence the way their bosses see your product. Their bosses can, in turn, exert influence to get your product the attention and resources you need. They’re almost as vested in the success of your product as you are. That’s why it may seem like they want to own it, and try to give direct orders to the product team.
Understanding this opens up a path to manage these stakeholders. Get to know them well, and protect the team by exposing it to them. Invite them to co-create the product with you. Bring them in to join the team when you’re kicking off a major initiative, or refining key backlog items. On the one hand, you have to gain from their domain knowledge and experience. On the other hand, you show you’re taking their needs into account. By scratching their itch on your terms, you can avoid them trying to scratch it on their terms alone. This also builds trust, which helps protect the team’s autonomy.
Prioritisation
Another source of tension with high-interest stakeholders is priorities, especially if you have multiple stakeholders with competing ones. Here’s what has helped me in the past that you can use too. First, make prioritisation discussions objective. Remember that golden thread? You can use it to elevate prioritisation discussions from whether feature A goes before feature B to which outcome is more important.
And because that golden thread leads to measurable arguments, you can use objective data to get to an answer. Data shouldn’t be the sole driver of your prioritisation decisions, feeding a magical mathematical formula to prioritise. Objective doesn’t mean scientific, but data should inform your decisions. When you inevitably have to say “not now” to a stakeholder you can back it up objectively. Stakeholders tend to react well when you show that you know what you’re doing while giving them clear expectations, even if they’re not happy with them.
Low-interest stakeholders
Quite the oxymoron, uh? “If they’re stakeholders, why aren’t they interested?”, you may ask. Or “If they’re not interested, what stake do they hold?”. The key here is that we’re talking about relative interest.
Your CEO is probably the best example of a high-power, low-interest stakeholder. It’s not that they don’t care about your product—it’s just that they have a gazillion things they could care about. Your product, even if it’s a revenue-generating one, can be of relative low interest for them in the whole grand scheme of things.
Another type of low-interest stakeholder is someone who competes for budget and headcount with you. They couldn’t care less about your product. But they sure could use one of the engineers you have working on something that’s “just internal”! They don’t have the power to grab them but they can influence those who have it (who are also among your low-interest stakeholders).
The two key aspects that matter in dealing with all these low-interest stakeholders are visibility and credibility. Customer-facing products are visible by default (with help from marketing), and their credibility is directly observable in the company’s top line. With an internal-facing product, you need to work harder for these.
You need to blow your own trumpet. Make the work of the team visible far and wide, while also highlighting its impact on the company. It’s never too much to use the golden thread again, and objectively show that what you’re doing matters to the company.
Key takeaways on internal-facing product management
Internal-facing products can be externally visible, particularly when things go wrong. When they don’t, good internal-facing products can bring great things for your customers, so they shouldn’t be managed like second-class citizens — but rather with the same product mindset as customer-facing products. They’re customer-enabling products.
- They need a vision and strategy clearly linking execution to the company’s goals — the golden thread. They need a product team with all the right skills, who need to be focused on outcomes over output because they’re bound to be resourced more frugally than customer-facing teams.
- Don’t think of your users as hostages of your product. Treat them fairly and ethically, and use your access to them to discover and deliver the product they need.
- Build a collaborative relationship with your stakeholders based on objective and transparent decisions, especially your high-interest stakeholders such as your users and their bosses. Blow your own trumpet far and wide, to give visibility and credibility to the product and the team.
With these ingredients, you’ll find that managing internal-facing products can indeed be as fun and fulfilling as managing customer-facing ones. They’re really just B2B products where the two Bs happen to be the same.
This post represents my individual professional opinion on this subject, not that of any company I work (or have worked) at/for on this subject area.