Blog post

Who is the Customer of my Product?

By Bill Swanton | August 10, 2017 | 0 Comments

One of the most powerful aspects of treating applications like products is customer focus.  Instead of the team seeing its job as implementing Tasks 212 to 245 of Project QRT, they suddenly realize there is a customer for their work and their job is to keep that customer happy by delivering exactly the right functionality.  Customer focus leads to customer intimacy as the team learns about the customer and what they are trying to do.  Ideally it also helps the team be more creative in satisfying the customer need.

For a customer or associate facing application, such as a mobile app or website, the identity of the customer is usually straightforward.  It is a particular type of user in a well defined role doing a well defined task.  If too many roles and tasks are jumbled into the customer definition, the result may be unwieldy, intuitive, and unusable software.  A clear focus is needed when defining product and customers.

Who is customer

But we don’t just have applications directly used by a consumer.  For example, a bank may have a mobile app, website, ATM kiosk, and teller system, all calling on the same back end platform to do core banking transactions.  It may also have additional transaction systems and common customer identity systems used by these products.  In between may be an API management layer that wraps the back ends and provides consistent APIs to the product or feature teams.

Many enterprises have adopted the product model for these back end platforms as well.  The platform team’s customer is defined as the feature teams or API team that relies on their functionality.  The platform team product owner needs to gather the services and APIs needed by the product teams, prioritize them in the backlog and deliver.  By keeping the platform team focused on its customer, need for extensive top down project management is greatly reduced.

Some coordination is still required.  Product managers across feature teams and platform teams may help facilitate the discussion and sequencing of backlogs to deal with dependencies and competing priorities.  Architects may facilitate planning of technical stories to deal with non-functional requirements consistently across teams.

Like in a physical supply chain, linking each group in a supplier/consumer relationship simplifies planning and operation for delivering the product.  In both cases each group can focus on keeping their customer happy and the result for the end user should be the best possible product.

Leave a Comment