Internal tools are first-class citizens:
Internal tools get a bad rap. Many PMs find them to be “entry-level work” not worthy of their time and devoid of the magic and flash of consumer-facing products. The reality is, however, that high internal efficiency is a core aspect of a healthy company and a hallmark of a strong culture.
Growth is only possible when the team and products can support the scale of the user base. Without efficiency, you will create poor experiences for customers, drag down your product’s performance, and kill team morale (especially on customer-facing teams). With efficiency, doors open. Teams can then focus on key initiatives and you’ll get pulled less and less to deal with fires.
This guide covers how to maximize your time working with these tools.
A practical approach to building internal tools
I follow a basic framework for tackling internal tool projects composed of five steps:
Understand the problem and feel the pain yourself
Get your team to learn what you’ve learned
Find the right path for the solution
Execute with quality
Celebrate the improvement
1. Understand the problem and feel the pain yourself:
Quantitative Understanding:
The key question to understand with internal tooling is “What is the tangible value of solving this problem?”. If you understand the answer to this question very well, the solution will be easy to find. To answer this question you need to find the metric-based representation of the problem’s impact.
For Example:
Let’s say your company requires each new customer to be manually set up, and this setup is complex and time-consuming which results in customers not being set up within a reasonable time frame.
Here you can measure the impact of this problem in a few different ways:
The total support time spent getting customers set up.
The number of days that it takes the average customer to get set up.
The percentage of customers being set up outside a reasonable time frame.
Ticket and call volumes from customers due to set-up delays.
Sentiment scores from customers who experienced this issue.
By creating a problem value statement that is metric-based all stakeholders can more easily align on the problem to be solved. This can create focus in your discussions as well as allow you to better understand how a proposed solution could impact the metric.
Not every problem can be reduced to a metric, many problems also have multiple value adds if solved, and some problems have immeasurable value. However, being capable of measuring a problem’s value in a clear way can make a huge difference in your approach and ability to focus.
Qualitative Understanding:
Sometimes PMs get overfocused on metrics as these can provide comfort to analytical-type individuals. However, a quantitative understanding of the problem is only a partial understanding. To truly understand the issue you need to experience it first-hand.
Here I look to do a few things:
Understand how the team feels and thinks about the problem.
Get the perspective on the issue from stakeholders. In particular, talk to the individual team members facing the issue every day, their manager, and your manager. Find the misunderstandings and the overlaps, and understand how different people feel about the issue and why they feel that way. This will give you a clear understanding of your organization’s perspectives on the issue which can help you understand expectations and better navigate those expectations.
If each stakeholder has a totally different understanding and evaluation of the problem to be solved, you’ll end up experiencing a lot of friction in the process as stakeholders may not understand why you’re going down a specific solution path.
Understand how the internal team is hoping the issue gets solved:
9 times out of 10 if you’re getting an ask on internal efficiency it’ll come prescribed as a specific feature that an internal team needs.
While user-driven feature requests are many times not useful, internal team-driven requests can sometimes break this rule. In organizations that don’t invest much in internal efficiency you’ll often find that team leads will have created their own solutions to these problems in lots of clever, and sometimes not so clever, ways. This can help you fastrack your understanding of the problem and its solution.
Don’t take the solution as gospel but don’t dismiss it outright. I’ve found with internal tooling that the average prescribed solution has tended to be a pretty good possible solution (although mileage may vary for you).
Understand the problem yourself by experiencing it first-hand.
Upon taking all the feedback, you have to do the work yourself. There’s no better way to get your own opinion on the issue than living a day in the shoes of those dealing with it.
Ask to take on the responsibility of one of the team members for a specific process or join a ride-along.
See the problem for yourself and more importantly, feel the pain for yourself. This very hands-on experience will make the problem more tangible in your mind.
2. Get your team to learn what you’ve learned:
Depending on how your development process runs, you may have more or less of an opening to bring in other stakeholders. In the right environment, you can have most, if not the whole, development teams participate in the discovery process and gradually iterate on the problem through cycles of learning, building, testing/validating. However, I’ve found this to be exceptionally hard at most startups and in most cultures due to lack of time, process, skill, or all three together.
If you’re in a more waterfall-type process, remember that you can bring your findings to the team as you’re consolidating them, while first-hand experience is best, a steady series of updates and documentation can help someone be more integrated in discovery even if they can’t participate directly.
Another thing I like to do for these kinds of projects is to have the development team go through a simulated exercise that has them doing the work that the internal team is suffering through. Giving your development team first-hand experience of the issue and layering context to that experience makes the problem to be solved really tangible and gives them a direct relationship with that problem. This sets everyone up for a more effective discovery process and allows them to return to the exercise experience for guidance.
The key thing to achieve is to ensure the team understands the problem they’re solving to a similar degree as you do. If you’ve achieved this you’ll find that the outcome you and the team will deliver will in many cases be 10x what you’d get if only you understood the problem deeply.
3. Find the right path for the solution:
To find the right path you need to ensure that you’re properly weighing the variables of the problem and evaluating possible solutions accordingly. There are a few things you can do here:
Challenge assumptions, deconstruct and reconstruct your understanding of the problem:
Try to identify and deconstruct any assumptions that are being made about the problem and about a possible solution. Ask yourself
“What are we relying on to be true? Is that actually true”
“How do we make this problem completely disappear”
“What’s the 20% solution that delivers the most value”
“What’s the ideal solution to this problem”
I’ve found that pushing my thinking to extremes and challenging assumptions has yielded better solutions not because you end up building the extreme, you almost never do so, but because this type of thinking often helps cut through group thoughts, biases, and assumptions resulting in a clearer focus on the parts of the problem that add the most value.
Don’t worry about straying too far off course, it’s easy to get back on track if you understand the problem to be solved. But note that most teams tend to avoid challenging lines of thinking and intense discussions out of fear of conflict. Better solutions come from productive creative conflict, pushing the team’s thinking to challenge assumptions can help you do this in a positive way.
Test your solution hypothesis with the internal team, simulate it, and try to break it:
As you’re concepting the solution, bring in the internal team for feedback. Internal teams are the best kinds of users because most of the time you can bring them in as often as you’d like and they’ll spend as much time testing and talking to you as you need. Keep them in the loop at a minimum but consider taking advantage of their time and having them challenge the solution path you’re working through.
Once you have a clear path, try to simulate what the workflow would look like with it in place. If you can’t simulate it, run through the solution step by step with the internal team instead and evaluate how it performs or how the internal team would expect it to perform.
As much as you can, try to challenge the path you’re thinking of taking and try to make it fail. Look to find ways it could fail, and try to identify flaws by questioning it under different scenarios. If your path makes its way through, you probably have something that will work in the real world.
Go back to your problem’s key metric and evaluate how your solution would impact it:
For every internal efficiency project, I try to also put together a projection of what the world will look like with the solution in it. Go back to your initial quantitative metric for the problem and ask yourself “What is my expectation of the impact our proposed solution would have on the problem?” Putting together an estimate forces you to think through the value you’re solving for and the value you think you can capture. This type of calculation can help you refine your strategy and thinking around the problem.
Consider build, buy, change process, sunset, customer-facing options:
It’s very easy to fall into the trap of always solving problems by building, but remember building is one of many options to solve a challenge:
Building: Ask yourself also if what you’re trying to solve is core to what you do or secondary (but still a requirement). Building isn’t a one-time cost, it presents a continual need to support and maintain what you’ve built as well as added complexity to your system. If you're building, ensure you understand the commitment involved and have determined it’s worth it over all other options.
Buy: If something is not core to what you do and requires a high degree of expertise and maintenance, then buying may be a better path. Third-party solutions can be the right choice in situations where there are clear market solutions and where the problem to be solved is not core to your business.
Change/sunset process: There are cases where you can change the process in such a way that much of the problem disappears. This isn’t very common but can be the case if the original process had a core assumption that you’ve proven to be untrue. If this is the case, sometimes you can work with the internal team to shift the process in a way where the problem you’re trying to solve essentially disappears.
Make the solution customer-facing instead: While this can be a tougher sell, in some cases you can delegate part of the problem to the customer or position the solution in a way where the problem is removed via customer behavior. Consider if the problem you’re solving is actually just a symptom of a problem with how your product works for users and if a better end-user solution would mitigate the issue.
Ensure everyone is rowing in the same direction:
Ensure that everyone who is a stakeholder in the project is bought in on your solution path and understands the reasoning behind it.
Building buy-in will reduce the amount of friction you will feel during the project’s execution. If stakeholders don’t understand or believe in your proposed solution they’re likely to try to course-correct it which can lead to disruptions and tension.
With internal tooling, internal buy-in is very important because internal teams have more of a say in product decisions than regular customers do (or at least are capable of communicating their thoughts and feelings directly). Before anything gets built, make sure the internal team is bought in as this will make the partnership smoother and more productive.
4. Execute with Quality
To ensure that your solution is the best it can be there are a few things to keep in mind when executing that make a big difference:
Test for real scenarios.
Don’t just test and audit like a robot, think about how the tool will be used by your team and try to simulate it.
If possible bring in the team for stress testing. Realistic testing will often find issues that pure auditing will not.
Get the internal team to be hands-on.
Getting stakeholders to try out your solution in a testing environment early can uncover issues with your implementation. As development occurs, keep the internal team in the loop and provide them with visibility into the project as this will help catch issues but also increase morale.
Use realistic data and volume (stress test as much as you can).
Don’t just test for an optimal scenario, make it as realistic as possible and test for extremes.
It’s easy to miss something because you’re testing with data that was convenient. Ask yourself, what does the worst real-world scenario look like, now imagine it’s twice as bad. Test with the date from that imagined scenario.
Also, ensure that your team members are testing with different data sets, it’s easy to miss issues when everyone is working with the same data.
Don’t throw your solution into the wild at the wrong time.
Whatever you do, don’t try to rush a tool at the last minute to support a workflow. Tools need iteration and are generally never perfect on the first release.
Give teams time to ease up to the tool. Don’t go live on the worst week of the year. Shipping at the wrong time can create a strain on teams and decrease morale.
Build some padding in your roadmap for follow-ups.
It’s tough for some internal tools to be fully tested without having real-world usage. Give yourself some space after release for iteration and for addressing any issues found in the wild.
Be realistic and honest about what you can and can’t get done.
It’s normal in any project to be constrained in terms of the investment you can make. Acknowledge that you won’t be able to solve every problem and be honest with internal teams about this.
That being said, don’t lose perspective on the value you can create and how it’ll affect that team. Focus on that value and keep that focus during the development process.
Build support materials and documentation to ensure the solution is understood.
This applies to any kind of work but it is especially important for internal tooling. You should ensure that you have clear documentation explaining what the internal tool was built for as well as what it does, and how it does it.
Try to be as detailed and technical as possible in your documentation. Without documentation, the likelihood of forgetting key details about the tool is high which can lead to issues down the line.
Have a clear tracking plan around your metric to learn about how your solution is performing:
Before going live ensure that you have a way to understand if the solution you’re putting in place is effectively addressing the problem.
Understanding the solution’s real-world impact on the problem’s metric can help show you how to improve the solution and validate if you made the right decisions and assumptions in your process.
5. Celebrate the improvement:
Building internal tools is a highly collaborative, highly personal endeavor as the tools you’re building affect the internal team’s daily lives. Ensure that wins with internal tooling are recognized and come back to the value they’re delivering. Praise those who participated in making the tool better both on your team and on the internal team who will be using it.
Over time you’ll find that the internal team will be energized from the tooling and your working relationship will grow stronger. Remember that while projects like this can sometimes be draining, they often mean a lot to those who benefit from them.
Ultimately you’re trying to create valuable products for people, internal tooling may have a small audience in many cases, but the work you’re doing optimizes those people’s work lives and helps your business grow.