Your company deserves better: Designing great in-house software

Excluding the product perspective from the beginning does not save money.

After working on several in-house products at large tech companies, I’ve seen firsthand how challenging it can be—from managing skeptical stakeholders to ensuring the satisfaction of users/colleagues. Let me start with a personal experience: I once met people at a conference who were doing similar work to my team’s. As we discussed our challenges and aspirations, some of them expressed disappointment with their "shitty" internal tools. That triggered my curiosity… so I inquired.

They expressed frustration because their companies opted to create their own software and ultimately failed to address their needs as users. The development teams behind these tools had overlooked the users, focusing instead on achieving feature parity with existing alternatives. It was evident that these teams lacked a user-centric approach. These were large organizations, comparable to mine, with thousands of employees and millions of users. They had the resources to create useful internal tools, but something went wrong. What exactly?

This article is aimed at both managers and experienced product professionals. You’ll find suggested solutions for the three most common challenges my team and I encountered – they worked for us, and they might work for you too.

Some people don’t see the need for product-focused roles when launching a new in-house project. It’s a widespread belief that a team of engineers is all it takes to create an appropriate work tool, overlooking the importance of user advocates who can identify potential issues during the ideation and development stages. However, I believe this approach often leads to problems down the line. These issues become clear when users struggle to navigate the tool or fail to see its value. At that point, additional resources are unexpectedly required for training and creating detailed documentation.

The good news is that your company’s UX professionals and product managers likely already have a solid understanding of your domain—make the most of that. If you’re in a position to influence and bring people into the fold of your new project, don’t hesitate. However, keep two things in mind:

Most non-engineers in our company, Adevinta, receive training in Data and Machine Learning, which provides us with a solid understanding from a business perspective. I’ve facilitated multiple workshops where product professionals played a crucial role in identifying opportunities. Their blend of domain knowledge and unique skill sets has been invaluable in these sessions.

A snapshot from a recent workshop. (Credit: author)

Therefore, I recommend factoring in all necessary roles—not just engineering—when deciding whether to buy or build software. The cost of ending up with software that doesn’t meet your company’s needs is often far greater and realised too late. A common scenario: consider the excessive documentation required to explain a confusing feature, all because UX expertise was overlooked during development.

It’s likely your company already involves designers and researchers in building software. Apply the same approach to internal users as you would to external ones by addressing their needs and pain points. For instance, if your company develops an HR tool, you’re probably conducting user research with HR professionals. Similarly, if you’re building a tool to enhance CI/CD monitoring, involve your DevOps and QA engineers in the process. A bonus I’ve observed time and again is the enthusiastic, grateful colleague who appreciates being included in evaluating new features. Don’t hesitate to seek their time and feedback.

Adopting a product mindset from the start delivers significant benefits. Begin your project with a user-centric approach to prevent unnecessary costs and spare users from frustration later on.

Convincing teams to adopt a user-centric approach in this context is, in my view, straightforward. Consider the following: you’re competing with companies that might develop their own tools without involving UX. Instead of mimicking their approach, use the opportunity to gain an edge over them. Remember the example I started this article with, their frustration towards the tools they need to work with. Your competitors could be in that situation.

Which company's employees will be more efficient in their work? The ones with tools designed to meet their specific needs, or the ones without such tools? In my previous HR software company example, competitors’ continuous delivery may perform worse than yours because you took the time to address your DevOps team’s monitoring needs. Multiply this advantage across every internal tool, impacting critical metrics like Lead Time or Change Failure Rate. That's the potential productivity edge you can have over your competition. 

Having the right tools at work can unlock new levels of productivity. (Credit: Freepik.com)

Additionally, you could think of well-designed internal software as an employee benefit. As you attract talent by choosing the right languages and tools for your engineers, you also support your internal users by creating in-house tools that feel polished and ready for the market. When you invest in tools that employees actually enjoy using, you’re showing them that you value their experience—especially those who have no choice but to work with these tools.

I’ve been part of teams working hard so that internal software not only matches the features of market tools but also provides a solid user experience. It wasn’t always like that, but over time, user satisfaction ratings proved that the extra effort pays off.

Let me expand on this further in my next point.

I’ve encountered this mindset several times. Change their minds by moving the conversation from abstract ideas like beauty to anything measurable. Define ways to measure your product’s success, the same way if it was going out in the market. You’ll have ways to capture KPIs, and users you can learn from. Lack of measurable impact is one of the main sources of frustration for UX professionals. Take the chance to do it right.

For example: consider running a survey about your work tools. These surveys are inexpensive to conduct and can provide valuable insights if done properly. They can help you identify which tools employees love and why. You’ll likely uncover hidden frustrations with certain software—not just because of its appearance, but due to its usability. Hard-to-use software lowers productivity, reducing the value delivered to the company. Pay attention to user feedback and take action to address their pain points. Moreover: follow-up surveys and productivity metrics such as Average Task Time can help determine whether your changes are moving in the right direction.

Over 100 colleagues have been involved in user interviews. This one with the ever-inspiring Maria Farrés. (Credit: Author)

In early 2024, we ran that kind of survey at Adevinta. The feedback we gathered from internal users was crucial in shaping our roadmap for future improvements. Each team received actionable insights that directly influenced their priorities, helping us focus on what to work on next. 

Be ready to gather evidence thanks to product KPIs and user input.

I firmly believe there’s immense untapped value in applying customer-centric techniques to building in-house software. By making your colleagues and employees more efficient, you not only improve business outcomes but also foster happier, more engaged people. Give them the tools they deserve by involving UX professionals and product managers from the very beginning.