Lessons learned about internal products

Working in a product team of one of our clients at Thoughtworks Brasil for over a year, I was able to gather a list of valuable lessons about a very specific type of product: the internal products. For the sake of definition and for a better understanding of this article, I will refer to an internal product as a digital product that an organization does not offer for external users, and which is generally used to support the various internal activities of the referred business. This type of product can be a software that the organization has built internally, or some customized software configured by them.

 

These products are often built to optimize processes and/or scale the business operation, satisfying the organization's internal users' needs or allowing the organization to meet the final customer's needs. Understanding these peculiarities and the aspects of applying a product culture in the management and development of these internal products was essential to drive enhancements in deliveries and the entire ecosystem in which the product was inserted.

 

 

Lesson learned #1: Product culture also matters on the inside 

 

In a not-so-distant past, most of the tools used internally in organizations were often called "back-office systems". Currently, many companies adopt the idea of ​​naming them as internal products, but this shift of nomenclature does not always mean incorporating an effective product culture to develop them.

 

Internal products may have some specific characteristics such as: dependencies and integrations with other internal products, functionalities focused only on the operation and not on the user's experience, dependencies on data and internal processes, etc. In many cases, this type of product is often developed without a well-defined process or by project teams that are not always dedicated exclusively to solving users' problems, or in engagements that have a predefined scope and an end date.

 

In my experience, I realized that thinking about strategy, product vision and setting short and medium-term goals, bringing tools and frameworks from the product management to day-to-day is essential for internal products. And this strategy contributes not only to the evolution of the product itself, but also to the quality of the delivery as we start looking at what we are building holistically, by incorporating the product culture and using data for better decision making. Over time, it can also influence the vision of all the people involved in delivering valuable solutions to optimize the business operation and solve user problems.

 

 

Lesson learned #2: The relationship of the internal product team with the user is closer

 

The relationship of the internal product team with users is one of the main differences when comparing B2C or B2B product teams. When building products for our colleagues, the proximity and ease of daily contact can be a very positive point. This implies having a direct communication channel to carry out user research, interviews, usability tests, validations, and receive feedback or suggestions for improvements and new features.

 

On the other hand, this super proximity can also be a disadvantage, like when some requests or feedback come to the team as "top-down" requests. Therefore, it is important for the team to learn how to manage the expectations created around each request, idea, or feedback shared by the user. The primary learning here is that having almost daily touch bases with our users does not mean that we should take their pain and needs less seriously than we would if they were external users. However, this also requires a great sense of prioritization, so that top-down requests do not trample on or impact the product's long-term goals and key results.

 

It is also critical to consider that even though the users are in the same corporate environment as the product team, they are not our teammates. In other words, they will not always understand the team's pain points, issues and possible delays in launching the internal product features. Therefore, it is necessary to be very careful with this relationship and be even more intentional in delivering value to these users who are so close to the team.

 

 

Lesson learned #3: Success can be measured through process optimization

 

In most cases, the main goal of an internal product is to optimize the company's operation and make it easier for employees to run day-to-day tasks and processes. However, measuring the success of that goal is not a straightforward task when you are also challenged to connect it to a business goal. Even if it is away from the internal product context, it is important to measure the impact of this product on the business and on the lives of end customers.

 

Most of the metrics that an internal product team needs to pay attention to will be related to how much the product was able to improve the performance of the employees on a given task, or how long the product supported to reduce the execution of a complex internal process, or how much has the user's experience improved a given operation that they need to perform daily. The key point is to understand how all this optimization can reduce costs or increase business revenue in general, leverage sales, retain people, or reduce the efforts in a given task, allowing people to take on other roles or responsibilities. A possible solution to this challenge is to intentionally connect the product OKRs to the business indicators or KPIs, so that the team will be able to focus on the correct metrics and redirect efforts to the right features, thus creating the expected impact.

 

Therefore, while B2B and B2C products generally focus on measuring user retention and satisfaction, internal products should focus on process optimization and task success. That is, the team should measure results to understand if the product is evolving the company's operation and simplifying daily tasks and processes as a means of meeting a business goal, even if indirectly.

 

 

Lesson learned #4: User experience matters

 

It is very difficult to find an internal solution with a good interface and a good user experience when looking at the old back-office systems with a project mindset. A common scenario for internal products is when the team starts to meet a ton of users' requirements and requests resulting in a bunch of features mounting on top of each other until the product becomes a large cluster of features. Instead of fulfilling its role of optimizing tasks, the product ends up making the user's life much more complex.

 

This is a hazardous situation, as satisfying the user does not mean fulfilling all their requests. When the team starts to focus exclusively on the number of deliveries that add new features required by the user, without identifying and validating the real problem, the user experience ends up in the background. By falling into this trap, it is common to see several internal products out there with no usability or with bad user experiences.

 

User experience is a key factor in the product's success. So it is not enough if someone on the product team offers a specific training to users on how to use a newly released feature, if the user doesn't understand it on their own or can't complete the job-to-be-done using the product daily. Therefore, the lesson here is that the user experience also matters, and it is not just about having a product with a beautiful interface, but rather delivering the best possible experience to optimize the work by solving user's real problems.

 

 

Lesson learned #5: Change management is our go-to-market

 

Go-to-market strategies define how a company will launch its product in a specific market, it seeks to understand the target audience, understand other existing products and how sales can be optimized, in order to plan how to launch a product in the market. This type of strategy doesn't work on internal products simply because we don't have a market. As mentioned before, internal products are not offered for sale to external users. But then, how do our releases happen?

 

It is in this scenario, a very important role comes into play in the internal product team, which needs to be focused on managing changes. Internal products are constantly creating initiatives to improve user performance - and that leads to change. Often, the user needs to completely change the way they perform a task or enhance an internal process according to the new reality. Change management starts by getting to know the internal audience, understanding how those people already perform processes and finding the best way to optimize the current work with the adoption of a new product or new functionality.

 

This role can often be performed by the product manager or by someone dedicated exclusively to the task of managing changes, planning releases, and making users adapt as best as possible to new features or product enhancements. An important learning that I had is that change management tasks like these do not need to happen only when communicating releases or training for new features. This can take place from the discovery phase. It is very important that the people focused on change management and adoption are involved in the ideation of ​​new features and problem solving, as they will have powerful insights on how to make the adapting process less painful for the users.

 

 

Conclusion

 

Making this shift from project mindset to product mindset is not always an easy task. As consultants, we are responsible for influencing and bringing the best practices to our clients, and this is an even more complex mission. Many of the learnings listed here were enabled by collaboration with the client to implement product culture. Thinking of internal products as a specific type of product, with its particularities and challenges, applying specific management techniques and frameworks is the best way to ensure product success.

 

Make sure that users are heard in the best possible way, that their feedback is taken and prioritized in accordance with the business strategy, as well as ensuring that the experience will not be impacted or overlooked against top-down requirements and focusing on effective management of changes aimed at optimizing the organization's operation and maximizing business value were the most important lessons learned from this engagement.