When the Customer Is Your Colleague: Product Managing Internal Applications

If you’ve never managed an internal application before, it can feel like you’ve left calmer seas and sailed into a choppy ocean that requires a different set of skills to navigate.

Manosai Eerabathini has spent his last two years exploring those waters while product managing internal apps at Google, including a content management system for their marketing department. Here are a few of the ways he said internal PMing diverges from consumer-facing projects, and his best advice for managing these unique situations.

Leverage soft skills to manage internal stakeholder confidence

While the customers and users of external apps reside in their own offices, sometimes an ocean away, it’s a different story for stakeholders for internal apps. They could be sitting just a few feet, a building floor, or an instant message away.

These are people with whom you will need to maintain healthy working relationships in the future, while at the same time delivering what they need and gently pushing back on certain aspects of their request(s). “This is not just ‘I’m working on this feature for the next six months.’ This is the partnership with my primary stakeholder for the next five years,” Eerabathini said. “I can’t just burn the bridge on one feature because I don’t want to do what they’re asking of me.”

And, it’s not uncommon for internal stakeholders to expect the product they’re asking for to be built more or less how they asked, even though the best PMs know product design should be focused on solving underlying problems, not churning out predetermined solutions.

“There’s always a little translation going on between the stakeholder and the PM and/or the broader product team where we’re interpreting what they’re asking for as a description of a more general problem, even though it’s coming in the form of an explicit ask,” Eerabathini said. “You still get this with externally-facing PMing, but it’s a bit more removed.”

These dynamics make the process for building and launching internal products much messier than the typical external product launch. Cutting scope and making trade-offs on your roadmap become even more challenging, and there’s an extra-high premium on leaning into the softer skills of product management, like diplomacy and relationship-building. 

Fostering a collaborative atmosphere around internal builds can go a long way here, Eerabathini said. He likes to set up cross-functional “SWAT teams” composed of a variety of stakeholders early in the process, so that synchronous, high-touch relationships can start to form from the outset. Taking this route can secure some early wins for your team by making the stakeholder feel more invested and included during the development process.

“Find champions or partners who can be advocates for what you’re building within the organization you’re building it for,” he said. “They can represent your roadmap and your trade-offs to the rest of their teammates and the larger user base. That becomes a multiplier effect of investing in really a key stakeholder being on our team and feeling like we’re on the same journey together.”

Once the team is formed, getting the cadence of meetings and their level of detail right is critical. Daily or weekly standups with your partners from the stakeholder org should be more tactically detailed, and they should be passing information to leadership on their team. That way, everyone’s homework will have been done before the larger project review meetings, allowing those to focus more on the bigger picture and ensuring alignment on the current direction and expected outcome. 

“It’s all about inspiring confidence with your stakeholder,” Eerabathini said.

Testing your product is tougher for internal apps, too. Unlike with external products, there’s often no “large” market to cast your MVP out into and let customers validate or invalidate the product decisions you made. There may be a small group of internal organizational stakeholders—perhaps even just one person—who will have to sign off on the product you present to them. A stakeholder who decides to block you at this point could introduce significant delays to your product launch, but hopefully, you’ll have headed off any surprises with your cross-functional team and some beta testing with a small group of trusted users.

“You have a lot more to lose if you burn the bridge or don’t sustain high confidence with your stakeholder, because when it comes time to launch, go to market, and pick up users, you could get stonewalled,” Eerabathini said. “It’s your job to be navigating for that possibility from the very beginning and not simply going rogue and hoping that they’ll still support you when it’s time to launch and get people to adopt it.”

Lead with qualitative data

Measuring the success of an internal product can prove tricky, too. Some of the traditional metrics around product adoption and success, like active users, feature adoption, and product engagement, are often not sufficient as standalone metrics since those who will be expected to adopt your product may not have had any choice in the matter. 

That will muddy your data. What looks like a fully adopted app with high usage may not actually be telling the full story of product success in the internal context. Because these apps typically have fewer users, it’s also harder to look at the data in aggregate and draw statistically significant insights. It’s entirely plausible that employees might be using the app for hours each day but having a totally miserable experience.

Here, Eerabathini said, is where the script flips from what’s typically seen in external PMing: Qualitative data around satisfaction and happiness, like NPS and CSAT obtained through in-app surveys or one-on-one conversations, becomes an even more telling signal than only quantitative data.  

This qualitative data then serves as an anchor point for starting to use the quantitative data to drill into strategic or feature level decisions and carry out the standard product troubleshooting that you’d apply to any external product.

“That may be the biggest difference. Surveying and regularly talking to your users is something that should be one of the first things you do,” he said. “These are techniques for PMing in general, but probably more readily at your disposal and more often used in the internal context.”

Internal PMs also have another data source that they can tie in: broader company metrics, like employee retention. Users might not be able to churn from your app, for instance, but they can certainly churn from your organization if they despise the tools you’re asking them to use. Using this data in this way can raise red flags that need to be explored and addressed, even if a few degrees removed from your direct product.

Fight the fires, but don’t lose sight of the end goal

Internal products are built to solve the immediate problems and needs of the organization, which means the process of building them can more easily devolve into a purely reactive process without a clear vision for the long term than that for building external apps.

“In an ideal world, you create a beautiful path where you’re able to fight fires and contribute to the vision at the same time,” Eerabathini said. “In the internal context, you have to make hard trade-offs around features and things that the business is asking for because it’s such a high enough priority. The thing is on fire, you just have to do it.”

But, focusing too much on the grand plan and letting the immediate needs go by the wayside means the house might burn down while you’re searching for the right hose. To Eerabathini, getting caught between these two extremes is a recipe for failure. 

“I’m constantly navigating both of those failure modes, where you’re either overwhelmed by the noise or you’re off in fantasyland thinking about a really cool vision that will never see the light of day,” Eerabathini said.

His solution? Every time you discuss or present a product or feature launch, tell its story, compellingly, as one act in a much larger play. “Those stories and those narratives give people something to anchor on and give people a very concrete grasp of what we’re trying to accomplish and visualize that,” he said.

That ensures all of the fires are extinguished, while everyone still keeps an eye on the end goal.

Keep these considerations in mind, and you’ll soon find your internal product management ship will be doing far more cruising than capsizing.