Lessons learned from building Internal Tools
Since joining the Onfido team last year, I’ve been focused on developing and improving our internal tools.
It’s been incredible to see the solutions we’ve developed improve the daily lives of colleagues as well as boost the underlying performance of our service.
Below I’ve written about a few of my key learnings that will hopefully prove useful for other product managers responsible for their company’s internal tools.
What are Internal Tools?
Internal tools can be any internally-facing software developed by a company to support internal operations. These might be bespoke technical tools, platforms and libraries built to increase the productivity of other product teams, or CRUD interfaces that enable customer support to resolve support queries. These tools are highly tailored to a business and are built when there isn’t a cost-efficient solution with the required features available on the market.
Specifically, the internal tools at Onfido help power our business critical operations and include tools that support the manual processing of information as well as client configuration, user management and authorisation.
Getting started
Stepping into any new product management role can be challenging as you tend not to have the full context to effectively prioritise. Often people start spec’ing away and building things just to get something delivered ASAP. This may keep people happy in the short-term but if you want to make a significant impact, you need to understand the problem in the wider business context. Working on Internal Tools should be no different, you need to understand the problems and opportunities at the high level.
To get a good grasp of the business context it’s important to take a step back and get to know your stakeholders. Find out who you need to engage with to understand the wider business priorities. Once you know who they are, find out what they do, what’s important to them, what are their goals for this quarter, next quarter and the rest of the year. Find out how each of their teams uses internal tools and then find out who the members of these teams are (after all, these are your end users).
Once you’ve done this, you should have a clear map of your stakeholders, and a good sense of their priorities, initiatives and biggest bugbears. You can use this information along with the business and product strategy to set the wider context with the product development team and start to build your backlog of initiatives.
Oh, and be sure to meet regularly with your stakeholders! Things move quickly in a growing company and your backlog will need to reflect changes in priorities. Keep it transparent with your stakeholders and seek regular feedback.
Get to know your users
Internally-facing products often suffer from poor UX and UI. This may have been justified as “cost-efficient” in the short term, but for your colleagues who need to use sub-optimal tools daily, it can be extremely frustrating. You wouldn’t choose a tool that was difficult to use — so why build one?
Take the opportunity to test new solutions with your users. There’s not really an excuse not to, and if you don’t, you’re going to run out of places to hide pretty fast.
When we’re working on improving an existing tool which is key to daily processes, a good amount of time is spent shadowing and talking to the person who will be using it in order to develop a deep understanding of the existing process and where their frustrations lie. At this point we are looking for unnecessary cognitive overhead, user pain-points and how power users carry out the process. Following this, we will create an empathy map to highlight areas for improvement from a user’s perspective.
Once we’ve defined the problems clearly and we are in the solutions phase, we create click-through prototypes which we test with our users and quickly iterate on. This helps to discover the optimal UX for a process and expose any gaps in requirements. Once we move to code, we continue user testing before and after the release to ensure what we’ve created is not only effective but highly usable.
Get to the root of the problem
Product requests come thick and fast for internal tools. This likely means that you won’t be short of suggested solutions as well. It is your responsibility to strip back the solutions and get to the heart of the original problem. At Onfido, we make use of a number of discovery techniques including 5 Whys, empathy maps and jobs-to-be-done. We combine this with user-shadowing, interviews and problem framing workshops to dig deeply into the root of a problem and properly define it before we start to come up with solutions.
For the bigger initiatives at least, this should be a team effort. This means engineers as well as product designers taking part in the problem analysis and definition stages, along with any relevant users and stakeholders. This helps to build a shared understanding among the team and leads nicely into the solutions phase which should be an equally collaborative effort.
Shield your team
There are many factors which can inhibit a team from delivering effectively and here isn’t the place to touch on all of them. One factor which may be more relevant to Internal Tools product teams is the risk of disturbance or interruptions. What do I mean by this? This is where members of a product team are requested to investigate, fix or carry out tasks which have not come through the appropriate prioritisation process and therefore sit outside the scope of an upcoming release.
This is not unique to internal product teams but as the barriers of communication are much lower (your users and stakeholders may be in the same building), these teams are particularly susceptible to this challenge. If nothing is done, the product team will struggle to gather momentum as members are distracted and lose focus on core deliverables, inevitably slowing development and missing deadlines.
At Onfido, we overcame this challenge by working closely with our Tech Support and Service Delivery teams to establish a clear process for capturing issues and requests relating to Internal Tools. This was documented and communicated throughout Onfido along with an escalation matrix defining what to do when an issue is raised based on the level of priority and product domain.
In order for such processes to work, it is essential to have a mutual respect and a shared understanding with the wider team of how your team builds and delivers software. This, along with a formal process clearly defining protocol, will help keep the product team focused on doing what they do best — delivering value to the company.
Over to you
Granted, internal product managers don’t face all the same challenges as external ones. Your users aren’t going to abandon you anytime soon or write a bad review (at least publicly). On the other hand, internal PMs face a slightly different set of product-related challenges and their own unique set of KPIs which they must deliver against.
That’s why internal software must be product managed properly. It’s far too easy for it to fall victim to the broken windows theory where poor design becomes the norm and best practice gets ignored. You should also consider the possibility that your internal products may one day be commercialised and become customer facing.
By having a product team, a roadmap and a vision for your internal products, hopefully you can stay competitive, scale effectively and drive value for your business. As a PM for such products, it’s your responsibility to avoid the common pitfalls, shield your engineering team and engage with your stakeholders and users to deliver high-performing, highly usable tools.
