Building internal tools: A mindset shift for product people
It is a common pattern at many software companies: the customer-facing products and features are clean, polished, and thoughtfully designed, while behind the scenes, the people who sell, implement, and support customers struggle to get their work done.
Maybe they haven’t implemented good SaaS tools (e.g. they’re still using Excel as a CRM), or they are struggling with the stale and buggy internal tools your Product org slapped together seven years ago. By these, I mean home-baked utilities that your teams use to manage customer data, settings, and configurations.
It’s easy to treat the UX of such internal tools as an afterthought and rely on documentation and training to fill the gaps in what is, in truth, poor product quality. It’s often tempting to dedicate the best people and all of our time to work on customer-facing problems while leaving coworkers to fend for themselves.
This mindset is a mistake, one we’ve made at Rise before, and one we seek to correct. This article is a largely intact version of an internal document that defines a different mindset and a set of principles to follow. Let’s jump in.
Learning to love internal tools
Frequently, the source of internal tooling neglect is the lack of appreciation for their impact and value.
Melissa Perri, the author of Escaping the Build Trap: How Effective Product Management Creates Real Value, made this mistake early in her product career. She writes:
“My second product management job was overseeing the development of all the internal tools for the e-commerce company I have talked about throughout this book. [..] I thought that, because customers never saw our internal tools, the experience or design didn’t really matter. It was more about getting the functionality out there.
“A year of building with that mentality, and I had a pretty rude awakening. […] I was not satisfying my users’ problems. Actually, I was making their job more difficult.”
Once she realized the problem, she changed her approach, and amazing outcomes followed:
“I began approaching my work just as any other product manager with external users would. I wrote down their problem statements, did research with them, experimented around offerings, and started to deeply connect with the way they worked. […]
“When I started working this way, we saw a huge change. Our internal users were happier, and we reduced the churn of the employees in this position who had previously felt handicapped to do their job well. These people were also able to get more done, and the operating costs for our business went down as a result of not having to keep hiring at an incredible pace.”
Perri’s example is insightful, and I’ve had similar experiences myself over the course of my career. Today, our team tries to live by the following principles:
Realize that everything is customer-facing
You could divide the projects you work on into three categories:
- Customer-facing (e.g., New social sharing feature)
- Internal tooling (e.g., A home-baked invoicing utility for the Finance team)
- Technical (e.g., End-to-end tests)
While helpful at times, these distinctions fail to acknowledge that the quality of the internal tooling and even the technical infrastructure can profoundly impact your customers. The tools you build for your colleagues affect the customer experience and their relationship with your company and its products.
A company’s brand — read: its reputation — is nothing but the net total of all the promises it makes and the promises it keeps. As professionals, everything we do has a direct or indirect impact on our customers.
Great internal tools help us provide a consistent, high-quality customer experience in an efficient way.
For instance, think of using a drill to drive in screws instead of using a screwdriver. The former makes work go faster and smoother. On the other hand, imagine an internal utility that’s confusing to use. To help a customer get unstuck, a Customer Support Representative might use it, attempt a change, and inform the customer about it, only to leave them more frustrated because the change didn’t take effect as the Support rep expected.
Cultivate internal empathy
Beyond the customer-facing implications, the quality of your internal tools reflects on company morale, your department’s reputation, and your ability to drive positive change at your company.
It feels terrible knowing you’ve built something that makes others suffer through laborious tasks, work long hours, or even hate the work they do. This goes against our professional ethics as Product people.
Furthermore, if your internal systems are inefficient, you face resistance from other teams in driving the adoption of your new user-facing features. For example, if you need the Customer Success team’s help to implement a new feature for existing customers, you might not get it because the team is overwhelmed by other manual processes assigned to them. This stifles growth and product health.
Poor internal tooling can also lead to an increased need for support engineering, which siphons away your velocity and demotivates your engineering colleagues. Finally, the ignorance of internal users’ needs can lead to animosity between departments and seed a culture of negativity and antagonism.
Do it for the craft
If nothing else, as a craftsperson, you should commit to making every detail of your work count. As Steve Jobs famously said, “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall, and nobody will ever see it.”
Addressing common mental blocks
Let’s address the common thinking patterns that cause teams to deliver sub-par internal tools.
“This is low-value work.”
As discussed above, this belief stems from a lack of appreciation of the true value and impact of internal tooling. All I can ask is, please, reconsider.
“I don’t want to bother the designer.”
Their refrain is a frequent extension of our assessment of the value of our work to build tools for ourselves rather than the customers.
What people miss is that the designer wants to be bothered. The experience internal users have with the product matters to the designer just as much as the one the end-users have.
Moreover, for a designer to be effective, they need to understand how the product works end-to-end, and you do them and yourself a disservice when obscuring the “back of the cabinet” from their view.
Prioritizing internal tooling
When deciding to build new internal tools or to improve the existing ones, consider these factors:
First, a binary question: Can your team do the thing that needs to get done?
If they can’t, then frankly, you must do something. If they already can perform a task, then think about: a) How much time is spent performing this task per internal user per month? b) What is the monetary cost of that time? And c) What is the opportunity cost, and what are the tradeoffs?
Third, do you need a tool, or can the task be automated or eliminated?
Finally, should this feature be an internal tool or a user-facing one? Self-service features are more expensive upfront because they directly impact the user experience, are harder to do discovery for and get feedback on, and have more complex release considerations. But they can also be an investment that pays off over time, helping your end-users help themselves.
Designing better internal tools
The principles of good design apply here just as they do to your user-facing features.
Workflows vs utilities. Some internal tools should be weaved together into comprehensive workflows. For instance, to set up a new customer, you need to create their organization, configure their settings, import their data, all in that order. A well-designed workflow can make it easy for an internal user to know what to do next and avoid missing steps. On the other hand, other tools should be independently selected and applied under specific circumstances.
Good information architecture. Internal tools should be discoverable and organized in a way that makes sense to the end-user in the context of their work. Each utility should use relative sizing, spacing, and other design techniques to communicate the relationships between its components.
Good UI copy. Clear, concise descriptions that teach the user what the tools are meant to do and how they can be best used can go a long way.
Documentation and training. These are essential in helping your internal users adopt and take advantage of the tools you build. They are extra important for the people who will need to learn your products long after the initial release date. However, docs and training can become a crutch for a broken UX. “We’ll just host another training session” is the PM version of “We’ll fix it in post.”
Things people want. Finally, remember to involve your internal users in deciding what to build and how to build it. And once you’re done, get their feedback on what you’ve shipped. There’s no reason to skip the research, especially with how accessible the users are — you work together, after all.
There’s always more work to do than there is time to do it, and internal tools often fall into either the “not now” or the “hack it together” bucket. However, when you add up the customer impact and the business considerations, the case for better tooling is clear and, in my view, persuasive.
Leave a comment about your experiences working on internal tools and the lessons you’ve learned. And if someone you know needs a nudge in this area, feel free to point them here; I’ll take the heat ;).
Misha Abasov (tw: @mishaabasov) is the Director of Product at Rise, Canada’s first and only all-in-one people management platform. He writes about Product Management, UX Design, SaaS Startups, and Work.
