How to Build Better Internal Tools

The unsung heroes of the product world are the product managers and teams who work on internal tooling and non-customer facing parts of the product stack. Sure, internal tools aren’t necessarily the sexiest thing to be working on, but plenty of product teams do. And for good reason.

The value of internal admin tools

Why do we bother with admin tools? Admin tools actually play a fundamental part in the value chain.

Without customer service tools, customers cannot be served properly.
Without an invoice management / payment system, payment records can’t be checked.
Without reporting tools, product performance can’t be monitored.

Value delivery is product management.

In some organisations, a single product team will be 100% dedicated to supporting internal admin tools and in others a significant proportion of time is spent on them. But it’s rare that any attention is given to those teams who build these types of products. So we thought, why not spend a bit of time collating some ideas and guidance on how to build better internal products?

1. Treat your internal tools with love

At Uber, every employee is a customer. In a post describing how they set themselves up for success, they explain that the products they build internally are for Uber employees. And Uber employees are treated as customers.

As a global company, Uber employees rely on a host of tools and technologies to enhance our platform and support our millions of daily customers. Our IT Engineering team (IT Eng) develops and maintains the systems and services that let the rest of the company do its work. For IT Eng, every Uber employee is a customer.

The first principle to follow when building internal products is to treat your internal tools with love. Yes, they’re not customer facing and yes, very few people will ultimately see these tools, but internal tools still deserve some love and respect.

Whilst you can certainly live with an internal tool that hasn’t been through the same degree of product discovery process as your customer-facing products, willful neglect of internal tools can lead to more serious problems further down the line.

2. Re-use existing components

Component-oriented thinking isn’t just for your core product, though. Once components are built for your product, think of the ways you can repurpose the components you’ve built for your customer-facing product inside your internal facing product.

Using shared code repositories and component libraries will make this a lot easier.

Examples of components that are likely to be strong candidates for repurposing in your internal tools include:

• Tables
• Search functionality
• Filters
• Forms
• Buttons

There’s no reason why some of these same components can’t be shared across your internal and external products. And in doing so, you’ll cut down the initial development time and maintenance of the components required in building your internal product.

3. Conduct user testing with stakeholders

Users of your internal tools are still users. Yes, you probably can’t justify kicking off an entire product discovery process just for your internal products if you are part of a team that’s also responsible for customer-facing products. But, if you’re a product manager working solely on internal tools, user testing with real users can form a critical part of the discovery process.

If your internal tool is built for customer service teams, visiting the team impacted to get an idea of their requirements is an essential part of the process for product managers working on internal facing products. Show your internal users initial prototypes and get deep into their problems.

Become the stakeholder

One of the most effective ways of building the right products for internal stakeholders is to actually become the stakeholder. What does that mean?

Well, if you’re building a product for your sales teams, try becoming the sales person for the day by attending meetings and taking sales calls using the tools that currently exist. There’s no better way to understand the problems your stakeholders face than to experience the problem yourself.

Invite your UX designers along for the ride, too. Armed with your field experience, you’ll be much better at crafting solutions that solve genuine problems. Since you’ll have experienced the problems first hand.

Before you release a new update to an internal tool, involve the stakeholders the tool impacts, too. For important releases, get stakeholders involved in the QA part of the product development process. It might seem a little OTT but stakeholders will usually be more than willing – and happy – to test new features before they go live. The feature has, after all, been built for them.

4. Create tools which help improve product delivery

The team at Intercom developed an internal tool called Hustle:

We built an internal tool called Hustle to keep track of goals. As well as goals, it pulls in our roadmap via the Trello API, and pulls in a summary of our open bugs via Github’s API. The main thing to understand here is that teams set weekly goals and are held accountable to them.

Hustle helps product teams stay on track by allowing them to set themselves weekly team goals. And it demonstrates the impact internal tools can make, not just on stakeholders and their needs, but on the product delivery process itself.

Internal tooling hack days

A powerful way to shift people’s minds towards understanding the value of internal tools is to build tools which help the product delivery process. Yes, we don’t all have the luxury that larger companies like Intercom might enjoy for developing custom built software to meet our needs, but most organisations have some time for hack days where developers can put their skills on display and build things in a short period of time.

To give your hack days a focused objective, try challenging your team to use hack days to come up with ideas for new internal tools which can be used to help improve the product development process.

5. Consolidate across departments where possible

Siloed, disparate sets of tools can cause unnecessary overhead. Where possible, collaborate with colleagues in other departments to understand if they too could make use of some of the internal tools you have.

Legal and privacy might have similar requirements to customer service, for example, due to data protection law enforcement.

Perhaps you don’t need both a sales and finance tool.

Maybe the call logging transcript functionality from the customer service tool could also be repurposed for user research teams.

The jobs to be done framework can be a neat way to approach internal tool consolidation. Armed with a consolidated list of jobs, you can start to think about how to share and repurpose existing tools across departments, rather than building tools for specific teams and needs as and when they arise.

6. Commercialise internal tools

Amazon’s AWS famously started as an internal tool before going on to become one of Amazon’s biggest cash cows. Ruby on Rails and the React framework were both developed for internal purposes, too.

If you’ve shown your internal products the love they deserve, and your internal users are clearly getting value from using them, there may be opportunities to commercialise your internal tools into something you could offer to the wider market.

Commercialising an internal product is often met with resistance. And that’s understandable, since it likely requires some strategic directional shift into a territory or space that you weren’t necessarily already operating in. Larger businesses are perhaps better equipped to do this since they have the resources required to double down efforts into tangential bets. Smaller startups don’t have that luxury and risk spreading themselves too thinly.

7. Take security seriously

Twitter’s hacking scandal, where high profile accounts were hacked into, reportedly happened due to security failures with their employee tools.

When we position internally facing products as the unloved step children of our lineup, the consequences can be dramatic. Security teams are typically (and rightly) obsessed with the prevention of customer-facing problems. Data leakages, hacking, password vulnerabilities are all top of the agenda for modern product teams. But we usually approach them with our consumer-facing products in mind. Failure to apply the same tight security standards to our internal products can create loopholes for malicious attacks so it pays to take security seriously for both internal and externally facing tools.

Striking a balance between internal and externally facing products

Whilst it’s good practice to show a lot of love to your internal tools, one response to the call to love your internal products as much as your external products might be ‘don’t you think I’ve not got enough to do without the added burden of producing an entire new stack of products?! I’m up to my eye balls as it is. To create internal facing products using the same high standards as external products isn’t just unrealistic, it’s a waste of our time.’

And that’s fair.

The amount of love and attention you can give to your internal products is, to some extent, correlated with the capacity you and your organisation have to build them. Larger organisations can afford to dedicate entire teams to building internal products. Smaller startups don’t have such luxuries. But, even if you don’t have entire teams at your disposal who can focus solely on internal facing products, if you show them as much love as you can, build them in smart ways without duplicating effort and invest in critical areas like security, you might just save yourself some time in the long run, and create some unique opportunities for new product development in the future.