While customer-facing features get the front page buzz, we don't talk as much about the quiet workhorses that often power businesses behind the scenes: internal tools. Internal tooling may not be a part of your company's external UI, but it's often hugely important to the overall customer UX, supporting the operational efficiencies and insights that ultimately deliver customer value.
Developing internal solutions differs from developing core product, however, as who you build for influences how you build. A broad customer base making buying decisions about your service and brand is a very different audience to teammates inside your company who share your mission. This nuance has tactical implications, and understanding them can be valuable in guiding your tech strategy. In this post I share my insights on these differences to help inform product and technical leads on teams that manage both.
Building for Customers vs. Teammates
One advantage of building for an internal audience is direct and close communication with your users, which generally correlates to better solutions to the right problems. Relative to external products, internal tooling initiatives can and should be surer bets. You’re able to clearly observe the inefficiencies, risks, and needs of your own organization, and validate the impact new tools will have. Contrast this with building a new B2B product, where you'd need to identify and pitch decision makers on your solution against their existing alternatives - all with the overhead of navigating external business relationships. When building internally, your users are teammates who are known, easy to find, and usually quite willing to openly discuss the inefficiencies in their work processes.
This internal communication advantage exists during research and validation as well as throughout development and support. Product iterations are faster when users are a chat message away and eager to give feedback. The quickest hot-fixes I’ve seen have come from encouraging engineers to collaborate closely with teammates using tools we support. With external customers, feedback cycles will always have administrative and communication friction. In contrast, the speed of upgrades to your internal toolset can be close to the time it takes for you to communicate with your team.
"Product iterations are faster when users are a chat message away and eager to give feedback."
When building internally, you also get to leverage the focus of limiting constraints. Your users are generally knowledgeable, trusted, and adaptable employees of your company, and you can tailor requirements based on these assumptions. For example, there's often fewer needs in areas such as experimentation, multi-browser and device support, localization, content and marketing, or fraud and legal risk reviews. While there are still new considerations, such as data and access auditing, in general scope can be reduced, which means greater focus on the key problems to be solved.
Different constraints also change the relative importance of priorities. One example is how function greatly outweighs form for this class of products. If you've used a few internal tools before you probably know this: their primary purpose is not to convey a brand or experience but to provide a solution, which means visual design and UX are often secondary concerns. Internal tool builders can lean into the flexibility afforded by this fact in a number of ways, such as leveraging prebuilt UI components or substituting advanced or more intuitive functionality with supplemental documentation. Teammates receiving new tools are a more amenable audience than external customers expecting a certain level of polish from the products they pay for.
"..function greatly outweighs form for this class of products.. and internal tool builders can lean into the flexibility afforded by this."
There's greater debate on whether this flexibility should extend to the technical side, with some advocating that internal tools should be developed exactly the same as their external counterparts. Personally I disagree, though I lean towards agility when it comes to product roadmap trade-offs between customer features and tooling investments. All development activity and practices come with costs, and these should be weighed against both the expected value upsides and the risk and impact of potential downsides. Given how this equation can differ significantly between internal and external products, I don’t believe all development practices and standards (e.g uptime requirements, deployment schedules, integration testing, outage protocols, etc) need be applied uniformly across the two. My rule of thumb: maintain clear standards, but set them in accordance to the real impact on the business.
Technical considerations for internal development also differ in the classic “build vs. buy” decision of developing software in-house or leveraging third-party platforms. My principle here is to focus the majority of your limited in-house development talent on high complexity areas where you need the most flexibility and innovation. These are most commonly spaces adjacent to the unpredictable external world. In practice, a large portion of internal tooling needs involve basic displaying, connecting, and modifying of data, and this commonality makes third-party platforms particularly viable. No/low-code tools are well suited to this area, as they can offer a compelling balance of pre-built functionality and customizability. By specializing in solving a class of problems, these platforms provide teams with significant benefits in terms of development time and ease of maintenance.
"..third-party platforms (especially /low-code tools) are particularly well suited to this category."
The common thread across all these areas of internal tool development is the opportunity for increased development speed. In my view, teams that embrace the differences of internal development and refine their product and engineering strategies to reflect them stand to gain significantly in development efficiency.
Internal Tooling Culture
Let's talk about the people side of internal tooling. It's generally recognized that compared to customer facing products, excitement around internal tools can be harder to cultivate. Counteracting this begins with your tech team's culture - specifically, encouraging one that celebrates the value of all tech that drives the business forward, regardless of whether it shows up in an app used by friends or other employees. Just like external facing features, the impact of tooling projects should be clear and quantifiable, and recognition should be awarded to their contributors.
It's also helpful to recognize the types of contributors well suited for this area. In engineering, I've found that great internal tool developers are typically more user-centric and value driven, interested in solving problems for people. They're independent and more breadth-oriented, as the work typically requires spanning across not only technologies (tool development is often full-stack and integration heavy) but also across roles, as there's greater need to flex into product, design and data work. Remembering these traits can help you get the right people in positions to do great internal work.
"Internal tooling projects are opportunities to support and build relationships with other functions."
Lastly, a non-obvious but noteworthy benefit of internal tooling projects is that they can help build cross-functional team empathy and camaraderie. Strong tech teams strive to stay in tune with the broader business and organization, a goal that gets increasingly challenging as a company scales up. Internal tooling projects are opportunities to support and build relationships with other functions, offering chances to collaborate beyond bug reports and feature requests. They educate and remind devs and designers that the features they build impact not only customers, but the teammates who sell, analyze, and support the product as wells. Building effective tools requires connecting with people to understand their problems, and when developing internally the benefit of this compounds in both business and team value.
Internal Tooling and Your Tech Strategy
Recognizing the value of internal facing tech and embracing the differences in building it can help inform how you make technical investments. When starting any new product initiative, two sets of users should always be kept in mind: external customers using the product, and internal employees supporting it.
The question that naturally follows is: how do you prioritize development between the two? Internal tooling needs are largely dependent on a team's size and product scale (and there's never a one-size-fits-all recommendation for roadmap prioritization), but I’ll share a few insights from personal experience that might be useful to team leads facing this question.
The key is understanding and defining where the value from internal technical investments comes from. While customer facing features are often measured in revenue or engagement growth, internal products more commonly deliver value through time and resources saved. In cases where the benefits go directly to the tech team, the ROI can be clear. For example, tooling that automates manual procedures normally handled by developers can be measured in engineering hours saved, which translates to future development time on product features.
"..internal products more commonly deliver value through time and resources saved."
Often, however, the value of internal tooling is to other non-tech functions in the business, such as operations, marketing, sales, or customer support. Building the right solutions and evaluating impact in these cases requires working closely with stakeholders in those areas, oftentimes bringing them in as advocates and partners, and sharing their target KPI’s.
In some cases, particularly at larger companies, the potential value of internal tooling products can be hidden in inefficiencies or risks dispersed across an organization. While not a major pain point for a single role or employee, the impact of these tools, or the potential cost of their absence, can be significant in aggregate. Examples here include multi-step workflows with dependencies that can be streamlined, or manual operations performed by multiple parties that could benefit from standardization. Identifying the need and value in these cases requires taking a holistic view of the systems and workflows an organization runs on.
"hidden in inefficiencies or risks dispersed across an organization.. the potential cost of the absence of certain tools can be significant in aggregate."
I also recommend looking for opportunities where internal tools can be not only time-savers, but value unlockers. These are often solutions where tech can be leveraged to augment the output of another function, usually through integrations with your core product and data. Some examples include enabling ops to set up experiments, marketers to deploy intelligent campaigns, sales to discover new leads, or customer success to monitor client health. I saw many of these types of internal initiatives at Uber, and believe that a significant contributor to the company's success was a tech strategy that put emphasis on empowering a driven global ops team with technology that enabled them to execute with autonomy and efficiency.
"..tech can be leveraged to augment the output of another function.. through integrations with your core product and data."
Lastly, I’ve also found that internal tooling can actually be utilized tactically in serving external product experiences as well. A simple example in B2B is building low-volume features as "by-request only", using tooling to support configuration for select customers instead of investing in a full self-service product flow. With this approach, internal tooling isn't always an "either-or" trade-off against core product functionality - you can utilize it as part of your solution toolkit for solving user problems.
Concluding
Companies that purposefully leverage technology to drive their business forward know that there's more than meets the eye. At the end of the day, building a great product for external customers is an exercise in combining the skills of talented people with effective technology solutions. Developing internal tools is practice in understanding and bringing those two together.
