An Introduction to Internal Product Management

aka "Building Great First Party Tools"

The practice of product management consists of identifying your customer, understanding their needs, surfacing constraints for a solution, and then crafting delightful experiences to satisfy those needs within constraints. It has been recognized for some time that enterprise products are meaningfully different than consumer ones - but what if there were a third PM role: that of the internal PM?

A consumer application is refreshingly straightforward - your buyer is your user. If they like what you made, they will pay you money for it, or at least click on the ads in the product. Analytics can give you crisp engagement scores and polls and recommending behavior can measure sentiment. Viral loops allow you to compound your user growth with user growth, and a diverse array of mature channels exist for paid acquisition. It’s a hits business where winners take all and the audience can be highly fickle, to say nothing of brutally fast-moving competition that will poach your best features and your best engineers or just steal your brand and design outright.

Enterprise applications are a different beast: your buyers may never use the product at all! Crafting a product such that it meets a buyer’s requirements (often unstated) can be a challenge - plus performing custom integrations, offering on-site sales engineering and support, and having to re-sell the solution every year or so to earn a contract renewal. Hell, most startups choke to death on the 18 month sales cycle! It can make the consumer world of a three-line Stripe integration that puts cash in your merchant account the next day pretty tempting. But then again, you won’t find many consumers that can cut you a seven figure check for your solution, either.

But at a lot of companies, there are needs to build products that are internal to the company, with no particular interest or plan to make such tools available - either as open source or as paid new lines of work product - outside. These products typically have little to no visual design, usability, or polish because the customers are all internal. Getting good product managers to work on such internal tools can be challenging - certainly if you’re looking to directly impact the daily experiences of millions or billions of people one simply can’t get that exposure building internal tools.

But an internal PM has its own distinctive advantages (and disadvantages!) over either consumer or enterprise PMs. First of all, you have an eminently accessible customer: your coworkers! It’s easy to spend time with them, observe their use of the tool, and get very honest and detailed answers about how their business is going. You can calendar time with them and call them any time. Conversely, if you screw something up, your users know where you sit. This keeps you accountable to the customer - an internal PM should be able to know their customer deeper than other PMs.

An internal PM also has an opportunity to meaningfully impact the daily working lives of the hundreds or even thousands of internal users of their tool. And the work you can do as a PM for internal tools is often deeply transformative, since you might be the first product manager the product has even seen. So you may find yourself able to make dramatic forward progress very quickly as an internal PM. And it can be very satisfying to be "on the same team" as your customer and have them know that you're doing everything you can to help them and not just trying to make a quick sale.

When creating products primarily used by a singular partner org internally, you may find it works best to have a program manager (PGM) from that org to represent the customer, help you collect business problems being faced by the customer and help prioritize by impact to the business. Ideally this individual should be empowered to make decisions for the org on direction.

Inputs from the PGM are often done via a BRD - a Business Requirements Document. This document poses the problem being faced, describing the current process or flow, what's wrong with it, and illustrates the impact of solving the problem with specific examples and measured data. This document doesn't have to be highly formal to be useful, but a fantastic BRD will include well-specified constraints around what a solution would need to look like. Sometimes just taking a short video of a very obviously broken process can serve as the meat of a BRD! The BRD should not attempt to actually specify the solution.

If you're a product manager in an environment where BRDs are produced by a PGM, don't forget that a BRD is not meant to replace actual customer contact. Product management success revolves around understanding and empathizing with your customer, which comes from surface area contact. The BRD is a good starting point for this by using the PGM's quantitative and qualitative descriptions of a problem. The product manager should then perform their own investigation to validate the given requirements and understand the customer's needs. You'll also need to check business impact with Finance, getting approvals and inputs from Legal, Privacy, HR, Marketing, and Engineering. But most of all, you'll need to connect with customers.

Wherever your customers are, there you should go. Just as in consumer product management it's critical to "Get out of the building!" In my case, I run product for Google's datacenter software team so, unsurprisingly, many of our customers are in Google datacenters, which are not in Silicon Valley. This means a fair amount of travel to connect with folks, interview them, and shadow their work. Most customers really appreciate when a PM takes the time to visit with them to understand their problems. I try to supplement in-person visits with video chat sessions with individual users (not just managers).

Some folks will have specific proposals they may want you to agree to; but as you would with consumer UX Research, you want to focus on listening and understanding what pain points are behind any specific product requests you are given. If a customer says "I need you to add a button that does [X] over here!" the right answer is not "Yes" or "No", it is "can you tell me more about what you're trying to do?" Keep asking questions, even if they feel like dumb questions, until you have a clear understanding of what they're trying to get done and why it's frustrating them. Even if there is already a way to get done in the product what they want to get done, it's the product's fault they couldn't find it - be slow to blame the user!

Specific customer suggestions might be a good idea or not, but customer pain points are always legitimate. Pain is the food of a good product manager; it can be stewed on, savored, and shared as motivation for everyone involved to solve real problems. At Google we often encapsulate these simple flows as Critical User Journeys, which take the form "As a [JOB_ROLE], I want to [DESIRED_ACTION] because [UNDERLYING_MOTIVATION]."

With the constraints in hand, the PM's job is to synthesize a solution that optimally meets constraints and solves the customer's problem. The proposed solution is then put into a PRD and presented to the PGM and Engineering to validate.

It's important to emphasize that rapid iterations around circulating these documents is important; the PRD shouldn't be a long and formal affair that gets blessed once and then never changed - it should start out very short and casual and circulated as a "sniff test", feedback incorporated, and rinse-and-repeat. This ensures that time will not be wasted formally exploring a concept that you could have known was a terrible idea if only you had bothered to ask ${PERSON}. For larger proposed changes, it can be helpful to integrate "paper prototypes" or other lightweight mocks to get a feel for what kinds of flows are likely to work or not before beginning actual engineering. This is actually an area where third party design talent can be usefully applied to help make visually concrete intended flows.

The Tech Lead (TL) then works with the PM and their engineering team to scope out an engineering Design Document (DD) that spells out the engineering architecture of what needs to be built; software engineers then reference the PRD to understand the overall direction and motivation of the program and the DD to understand the technical implementation plan. It's important that the people building the software actually understand and have empathy for their users! It's a common mistake to try and shield engineers from a customer - instead, not only showing them the analyses and vision but also helping get them physically alongside customers to shadow them and "feel their pain" is a critical part of ensuring what gets built will be right for the user.

As the software is getting built, sometimes in two-week sprints if using an Agile/Scrum methodology, the customer should be given visibility as to what's getting built. Although frustrating, it's not uncommon that it becomes clear that the agreed on thing to build is not the right thing to build only as it's getting built. Discovering this as soon as possible to course-correct will help minimize wasted time.

Once the product is ready for broad customer use, it can sometimes be helpful to have a User Acceptance Test to have the PGM verify that the as-built software matches up with the PRD and does indeed satisfy the issues that were raised in the BRD. Sometimes it can be helpful to have a formal "launch" where a broad panel of cross-functional stakeholders is notified of imminent intent to actually roll out a large change.

Once this is done, the PGM's task will be to drive rollout of the solution to the customer base with any required communication. Ideally, there are a beta group of customers to which software updates can be continuously deployed so as to get actual customer usage feedback before full deployment. The PM should assist with writing any needed documentation but can also make use of a tech writing team if they have available bandwidth.

Once out in the wild, it's the product manager's job to monitor the success of the product by both observing implicit signals (like product usage) and explicit signals (such as via surveys, feedback, and feature requests). Customers should be given a straightforward way to report bugs to the engineering team and expect a reasonably timely triage.

To help build customer communications, a "thirty day active" mailing list should be created that allows for announcements and user discussions among users of a tool. Letting folks know of forthcoming changes via both email and in-product is desirable; when a change rolls out, not only should active users get an email about it, these changes should be visually highlighted within the product with links to know more. When significantly changing the user interface, allowing early users to opt-in and then as the program matures allowing users to opt-out (but fill out a form describing why) can be useful for surfacing blocking concerns.

Lastly, don't forget to celebrate accomplishments! As an internal product manager one of the useful things you can do is to map the team's actions to business impact and to crisply define that, which can be helpful for team calibrations and promotions. As the PM it's your job to broadcast wins - especially wins with metrics - to the larger org and make your team look good. And remember: if the product didn't work well, it's your fault; if the product landed great, you failed to screw things up!

Are you interested in helping us deploy impossibly large quantities of cutting-edge computer technology? We're hiring internal product managers! Contact [email protected] with your resume and interest and let me know you read this article!