Developing a product comes with many challenges; these challenges are also different depending on the context of the product, B2B, B2C, or SAAS. Another dimension of product development is the end-user, the ones to whom you as PM aim to bring value. These consumers can be external or internal users. External customers are those that the business organization aspires to impact, ex: Netflix subscribers or consumers who use Klarna as a payment method. Internal customers are the people within the organization who use a particular product as a development tool to impact the external consumers. Developing a product targeted at internal customers presents different challenges than developing a product aimed at external customers.
The value exchange
External facing teams commonly follow a well-defined product development vision and a delivery strategy that is aligned with the overall business goals. Melissa Perri, defines this as “the value exchange context in her book The Build Trap.
This concept illustrates the relationship between the consumers and the business. Product teams shape their products to answer users’ demands, and in return, the end-user pays a determined sum that generates value for the business. This mechanism is very straightforward. Ex: Netflix users can consume as much content available in the catalog as they want, and in return, they pay a monthly subscription.
On the other hand, the value definition for internal consumers is more complicated and opaque. Firstly, there is no direct financial transaction between the internal teams and the service/product they build the same way as the product. The “contract” determines that product teams will use internal tooling as the only viable alternative to address their needs, and their productivity should increase. Productivity, the key metric for any internal team, can be hard to define and understand across the company.
Secondly, there is a lack of a clear connection between the internal-facing product and the business value exchange system. Teams working within this problem space seldomly see themselves connected to the product; they often operate as an island commonly known as the platform. The platform typically is not considered a product because internal users are not seen as consumers in the same way as external customers. This shortfall often reflects how internal teams interact with their “users” and vice-versa.
Talking to customers
Talking/listening to the customers is crucial for developing good products. This method is a fundamental part of continuous discovery. In my previous experience, I enjoyed taking part in user interviews. I would listen to the user researcher’s dialogue with our customers in another room. It was amazing to follow how they described their intentions and how they would use the product. We could then focus on finding the opportunities.
In my current experience, I also have two established structures of listening to the customers. One is the office hours. We offer a space for our customers to join us in sessions where we try to understand their pain points and provide our support. The second is the “classic” user-research interview where I listen to how our consumers perceive our product. These sessions are fundamental for me to understand our customers’ pains better.
Differences
The notable difference between these two experiences is, in my opinion, the approach/mindset of the participants. The interactions are tailored to problem space definition and opportunity discovery when talking to external customers. Internal customers, however, often come with solutions that they want and expect us to implement for them. While the product team strives to find out opportunities on the first occasion, on the second occurrence, the internal teams need to “put aside” users’ solutions and strive to map those “solutions” into the bigger picture of the team vision.
The PM and the team need to be mature enough not to fall into the trap of simply fulfilling what the users want. The team should have the ability to understand why someone is asking for a particular thing to be implemented, listen carefully to the customer, and aim to address the core issue. Then they must interiorize this point and see if it is something that only this customer wants or if it is something that would benefit more customers. PM and team need to be congruent enough to question what their product offers and see if the user’s request aligns with the team mission (some teams might have a vision on paper, but their offering is well off). Ideally, members of the internal-facing team should come from product teams where they are familiar with the product mindset or bring a UX to the team.
Alignment
Product teams aim to find solutions that address customers’ needs aligned with the business goals. They shape their product based on users’ demand and continuously look for opportunities to deliver value to end-users and stakeholders. For internal teams, these dynamics are often different. While it remains fundamentally true that they try to shape the product based on users’ and organizations’ needs, sometimes these needs do not align. Often there’s new access control, compliance, or deprecation that the organization needs to enforce across the board; these overheads can generate friction among users. Hence, the PM needs to generate a strategy that both implements the organizational requirements on the one hand and minimizes the generated friction on the other hand.
One more word
Developing internal-facing products raises different challenges from developing external-facing products. The development methodologies do not change; the core goal is to meet users’ needs and problems. Instead, one needs to adopt strategies that meet those challenges. Developing internal products introduces challenges that, in my opinion, are underestimated and often might be seen as pure engineering. Measuring the productivity and connecting it to business KPI would make it transparent for internal-facing teams to understand how their daily work contributes to the business exchange value. Hence the central challenge for the internal-facing team is to strive to connect their problem space to the bigger picture. They should mature their product to serve a more extensive scope than the niche they operate. Without this thread, it is hard for them to understand their impact on the product and, by proxy, the value to end-users.