Internal products don’t require internal customers
As part of moving from projects to products, one of the topics I’ve been wrestling with is how to think about customers vs. users when…
As part of moving from projects to products, one of the topics I’ve been wrestling with is how to think about customers vs. users when organizations are having products that are external facing (customer) vs. internal products,
Some of this may appear theoretical, or even philosophical at times but organizations need to understand how they tell the two apart and how they effectively manage the two.
From the outside, you may say — why does this topic even matter, what is wrong with treating users as customers inside of your organization. Isn’t it good to be customer centric, even if the customer is internal? The issue there is the conflation of users vs. customers. Depending on the type of products, they can be the same or quite different people with differing needs.
I ran polls in LinkedIn and Twitter to see what others thought on the topic and whilst there was a trend to one direction, it wasn’t a landslide.
One of the things that came through quite clearly is really having a strong / unambiguous definition of customer and once you have that, the whole conversation becomes easier to navigate.
Observations
Customers have a choice, they pay for the products and services
Users are people who use things
Customers can be an individual (end customers) or an organization (businesses / government / non-profit)
You can have distinct types of customers and users, so things aren’t as clear cut. This is where personas and jobs to be done can be helpful. A simple example could be an online commerce platform which can have buyers and sellers. They are both users, they are also both customers — they may just see the platform and it’s feature as separate products.
Internal Products
When moving to product, getting into the product mindset, and building up a product capability it is natural for the pendulum to swing too far on each extreme by thinking everyone is a customer because customer centricity is all the rage.
Some argue that products should only be customer facing and anything used internally should be treated as a shared service or platform. That makes some sense, but it does make things more confusing for people without customers.
Depending on how your organization is set up you may have an approach where your internal products and services are charged within your organization to a consuming business. This makes things muddier, because an organization is paying for the product or service, but they can’t just pick up and move to a new product. This leaves the non-customers with limited options and this impacts the culture and behavior of the product teams.
By now you are familiar with the customer vendor antipattern, so this type of behavior is not new. The ‘business’ pay the bill, so unless you want your funding to be cut, you need to deliver on their demands. This does not help the relationship, it acts as a disincentive for the teams. It makes the teams focus on features, rather than maintainability and potentially new opportunities / other user groups. This paying non-customer is holding the team ransom through the funding model. This is one way to end up with feature bloat and piles of technical debt.
The use of terms like requirement and demand have not helped with regards to a healthy relationship between engineering, product, and users. If you throw in terms like stakeholders, consumers, sponsors you end up with such a large group of people with opinions that don’t really have equal footing in the product.
This is further exacerbated when you have monolithic systems that support multiple types of users (e.g. an ERP system) — they all think they own the product and therefore don’t care about the other users as result so what happens if you end up with separate prioritization meetings because none of the stakeholders care about each other's needs.
An extreme example of this is regulatory needs, where the users / non-customers don’t get any direct value out of the changes. These changes often consume most of the teams capacity for a considerable amount of time.
Ironically, the value is to the organization rather than the users. Often keeping the company in business in the goal rather than pleasing the users looking for a new feature. This is one area where a buy over a build approach can help, as long as both you and the vendor can keep up (you can’t take advantage of the latest versions if you are many versions behind).
What about the real customer
Whilst all these elements are important for internal products, having a clear view of the actual client is often missing from the conversation. Organizations not aligned to the real customer, often forget the ‘why are we doing this’. They have taken liberties and say things like they are the CEO of the product — that is often a little too far when having the best internal product makes little sense if the overall company isn’t able to offer a compelling product to the real customers.
Internal platforms / products should be aim to be good enough, but not so good that they derail the focus of the organization. Product managers should aim to offer a compelling solution for their users, but not at the expense of the end customer. If an internal product becomes so good, that it really is differentiating, then you should consider commercializing or open sourcing it.
Unless the product being built is generating revenue or differentiating for the organization, then I’d think twice about building the internal product from scratch. This is a humbling discussion, it requires a little humility. If someone wants to build an internal product from scratch, they should make sure there is no cost effective alternative in the market. As a general rule if a team wants to build something from scratch for an internal product, I’d challenge them to open source it to see just how serious they are, Open Source has a way of getting people to think clearly as they can often be embarrassed about the quality of their code, tests, or documentation. If the teams genuinely want to build something and they are open to open sourcing, then you win either way.
A typical anti-pattern is when a smart executive, with a technical background thinks they can design a solution that will meet needs of many groups of people without even proving the business value first.
Another example is when people think they can build a better, faster, cheaper product that is already at the commodity in the market.
This points to the buy vs build conversation. If you are in the domain of back office / shared service type functions e.g. finance, compliance, human resources etc. It is questionable how building a product from scratch in a non differentiating area makes sense for a company.
If you were in a finance domain looking to consolidate multiple accounting ledgers, you would be either considering buying an off-the-shelf solution e.g. SAP / Oracle or building your own from scratch. Given that companies like Microsoft and Google don’t build their own financial ledgers, you really should think about where you want to focus your efforts and value. Accounting requirements and standards exist in every country and they change often enough that maintaining a data model that works for such complicated needs is not a trivial exercise. I’m intrigued to see if a domain driven design approach makes sense for financial accounting at a global / enterprise scale then transactions often require double entry book keeping / immutability style processing to meet the needs of regulators and auditors who are well versed in what to look for.
An often-overlooked topic is the organizational impact on buying decisions e.g. buying a COTS (Commercial of the Shelf) product. There’s typically a large focus on a Christmas list of functional and non-functional requirements where multiple vendors have a bake-off to get the highest score to proceed to purpose and implementation.
I don’t envy the position these companies are put in; they are faced with often unusual asks that are free of context and therefore put people in strange situations that often result in making commitments to make a sale happen without understanding if the requirements are complementary to the product or only going to make it bloat.
Whilst a lot of focus is put on the product meeting the organization's needs, not a lot of through is put on the underlying skills, capabilities and learning required to effectively get value out of the product. The decision to buy is often seen as a way of leveraging commoditized capabilities that are not differentiating for the organization but may be mission critical or simply useful. I buy into that thought but not at the expense of the organization being able to interact with the product and exploit value from it.
I often see people buying expensive pieces of software and only using 10% and therefore introducing multiple competing products into the company's ecosystem. That often drives the enterprise architects wild.
If you aren’t thinking about the skills and capabilities, you need to fully leverage the product you are buying off the shelf you are leaving value on the table and risking having dependencies on other organizations to provide you with expertise. That means paying for the software and the skills to use it, that sounds like double the cost if you aren’t careful.
Equally challenging, is moving from a commercial product offering to home built solution — especially if the people are going to be the same. They often have different skillsets and focus, they may have done a lot more integration work vs building and architecting a solution from scratch, let alone all the technical practices needed to ensure the organization is able to maintain the solution longer term.
I’ve personally seen this happen in multiple directions and I’m not convinced there is a clear ‘best practice’, but the approach used to make such decisions is certainly one I do appreciate. That is the Purpose Based Alignment Model from the book Stand Back and Deliver that helps you understand your options based on a scale of differentiation vs criticality.
Summary
There is value in taking time to understand who is paying for the products your teams are building / deploying. Treating your users like customers can be helpful in terms of understanding their needs but it should be done in the context of the wider organizations strategy and needs.