The Pattern of Software Products
In the past 16 years, there were tons of software products (or called applications) that came into our life. For example, the utility applications show the usage of electricity and water, the bank applications manage our assets, the communication applications connect us in different ways. All the applications show a pattern that a simple product normally has a very clear goal to serve a group of users (also called a user segment) who have the shared needs (requirements). At the same time, not all features of a product are used by all users, many features are only used by a small portion of users in the user segment. More interestingly, some of the products provide services that can be used in other products to serve different users with the same needs, not just functionally such as taking payments (PayPal), but also technically such as high availability (Cloud providers).
In this article, I’m going to explore the pattern described above and how it can be applied to a large digital organisation.
Term: product in this article means software product
The Pattern
Types of Software Products
A base product targets a clear user segment. It has essential features that are good enough to solve some major problems for its users. These features are normally listed on the landing page and are very obvious to its users.
Product add-ons are additional features that solve the special needs for a part of its users, such as the cheques function in an online banking application. Unlike the essential features, the add-ons are normally found in the secondary menu.
A new product is normally created for a new user segment. This leads to many different products that serve different users with different needs.
Integrated services are considered as another type of product, which can be used as an external integration across multiple different user segments to fulfil common needs such as payments.
In a Large Digital Organisation
Usually, there are more than one products in a large digital organisation. For the customers in the same user segment who share the same needs, we serve them with the same product. For the special needs of some customers, we build add-ons that are charged separately from the main product.
For the customers in different user segments, we build other products to solve their needs because adding an additional segment of users to an existing product would not only make the main functions confusing, which damages the user experience, but also significantly increase the complexity of the product, which slows down the delivery.
At the last, the platform services (as integrated services) are provided for the common needs of its customers. They are also products that have two types of users, the first one is the internal users who set the services up to be ready for the customers, the second one is the customers who get value from them. There are four types of products in platform services:
- Shared product features: they are services that are integrated with products and used directly by customers. So the design of these services needs to be aligned with other products. They are also different from organisation to organisation.
- Services that support sales of products: they are the common capacities for selling products, like marketing, customer management, and billing customers. They should enable the product teams to focus on increasing the competitiveness of the product features instead of how to sell them.
- Infrastructure that supports products to build and run: it solves some common non-functional requirements such as security, service availability, application changeability (CI/CD tools).
- A data platform that supports better decision making: they are tools and services for product people and executives to collect data and create reports for insights.
Evolution of Products (the journey from small to large)
A product is normally created at the beginning of the company found. As time goes, it gains more and more customers by completing the base product and building more add-ons. When it reaches the bottleneck, the company starts to seek other opportunities to grow. It starts to build the second product as well as the platform services which help to speed up the process of building more products. Then more products are built or acquired afterwards. So over time, the number of products and the size of platform services is increased like this:
The platform services are only built when the ROI (Return on investment) is worth it, so it wouldn’t be built at the beginning. I’ll explain more in my next blog.
Build Delivery Teams around the Products
Products teams (also called stream-aligned teams) are responsible to deliver products that solve the customer needs. They are the reasons the company exits, they are also the key to win customers from competitors. Thus, it is very important to keep them focused and scalable.
Platform teams are responsible to provide integrated services for the common needs of the customers, not the internal users. Serving customers better should be the common goal across the entire organisation, every service provided by any team should be aligned to that goal. Treating the internal requirements more important than customers’ would cause some big problems. Here are some examples:
- Spending a lot of effort on unnecessary complexity such as build and maintain a beautiful UI for the onboarding process of an internal integration which could be done by just uploading a csv file to S3. I call this the illusion of runtime flexibility.
- The customer value might be conflicted with the internal customers’ value, like enabling customers for self-services vs enabling the sales team to sell more to customers.
Thus, we should only build services for the customers. It is important to keep the mindset in platform teams, which I don’t see often. Even the teams who maintain the tools for engineering practices (such as CI/CD) should also follow the principle because good engineering practices are about quality and speed of delivery, they are also of interest to customers. This means only providing tools might not be good enough, they also need to guild the good engineering practices of the users (of the tools).
By the way, team topologies mention another two types of teams, the complicated subsystem team and enabling team. They can be part of the product teams or platform teams depends on whether they serve one product or multiple products.
So at the end, as products evolve over time, the team structure in a large organisation would look like this:
Summary
The pattern of software products categorises the software products by the user segment and commonality of their needs. It could be transformed into a product strategy for a large digital organisation and arrange teams around the different types of products. The customers of the organisation are the only customers for all types of products, including platform services. The product teams and platform teams should work together to target the best experience for the customers, meanwhile, reduce the waste of unnecessary complexity built for the internal users.
