Defining product

An important part of any digital transformation is the change from traditional IT and business departments into multi-disciplinary product teams.  This change unlocks improved speed-to-market and better customer and commercial outcomes.

However…this is not an easy change for big organisations to make.

Because big organisations are, by their nature, very big and very organised, there structures and ways of working are complex. And product practices that work well in a 50-person SaaS startup tend to break when faced with multi-channel, multi-national, multi-departmental structures.

Some well-known approaches and methodologies seek to manage this complexity by adding bureaucracy into the product function. However, we believe that rather than manage the complexity, you should remove it. And the big secret to removing this complexity is to be really sharp in your definition of product.

Defining product as a concept

At the heart of the ‘big organisation’ product problem is the fact that it can be very difficult to simply pin-point what product is.

Even our two most commonly used definitions are abstract, (and even using dual definitions is a bit awkward…although, to be fair, we use them in different contexts for different reasons):

• Products are offerings that deliver user value, or facilitate the delivery of value.

• Products are collections of capabilities.

And in order to understand this duality, you need to understand how we design product taxonomies (i.e. the design of product structures within an organisation).

At a structural level, a product should consist of 2 things:

• An asset (i.e. the thing of value); and

• A ‘service domain’ that provides access to the asset (i.e. the set of capabilities linked to that value).

(The parallel to the two definitions should be fairly obvious: a product is made of two different things).

Defining products in reality

So far, so good (hopefully!). But the acid test for any budding product architect (i.e. a designer of product taxonomies) is when they try to do it for real in a business.

Firstly, the product architect will need to identify the assets (i.e. things of value) within the organisation that you can build products around. But agreeing where an organisation’s intrinsic value exists is tricky.

For example:

• If you are a grocery business, is the product:

  • The basket of groceries (that the customer actually buys);

  • The home delivery service (that provides access to the basket of groceries that the customer actually buys); or

  • The mobile app (that allows consumers to avail of the e-commerce service that provides access to the basket of groceries that the customer actually buys)?

• If you are an insurance business, is the product:

  • The life insurance policy (that the customer actually buys);

  • The claims handling service (that allows the customer to use the policy that they actually buy); or

  • The mobile app (that allows the customer to access the claims handling service that allows them to use the policy that they actually buy)?

Properly exploring this problem can be brain-busting, introducing concepts like propositions, services, systems, and more. And organisations often struggle to wrap their heads around it. After all, product architect rarely needs to be a full time role in any organisation, and product teams can therefore struggle to design a good taxonomy that just works.

Across numerous projects with organisations of all sizes, we see this problem manifest in the same set of challenges time after time. Solving these common challenges is a critical function that we perform for our partner brands.

Challenge 1: Recognising the need for product structures

If product is such an awkward thing to define, it can be hard for big organisations to even get out of the starting blocks. So helping management ‘get’ product is often the first challenge that we have to deal with.

Conventional process-led business structures have been designed to optimise business activities.  However, this can:

• Lead to sub-optimal user experiences (due to a priority on process rather than experience).

• Create rigid business practices that cannot readily adapt to changes in context.

• Create monolithic line of business IT systems that are hard to change.

• Enforce strict sequences of business events that can reduce the organisation’s ability for ad hoc collaboration and creativity.

A product architecture offers several advantages:

• Encapsulated products that can be changed independently.

• No “strict sequences of business events”, but instead products that can work together to trigger events in any sequence.

• All information, assets and outcomes are uniquely assignable to a single responsible business entity.

(And given our focus on customer experience, we would be remiss not to mention that a product setup is inherently more suited to the orchestration of customer journeys than process-led structures.)

Challenge 2: Building a good product taxonomy

A product taxonomy defines the atomic units of ‘product’ within an organisation, and the relationships between them. A good product taxonomy adheres to a set of good design principles, and enables the full range of aspirational time-to-market and quality benefits.

When faced with the challenge of designing a product taxonomy however, inexperienced leaders can tend to design them as an evolution of existing structures.  However, traditional organisational structures and monolithic IT architectures provide a very muddy starting point for designing a product taxonomy, and often the resulting design breaks multiple of the above principles. This inhibits the effectiveness of the product function and can lead to failure.

Challenge 3: Setting product at the right altitude

Often, it is simply too hard for organisations to fully transform into business-wide product structures, and it is only the IT department that changes. This approach just ends up managing IT in a slightly different way and doesn’t allow the new product function to own business outcomes any more than it did before. In reality it does the same job as the old IT department did.

The real benefit of product organisations is realised when product is elevated to a higher altitude. This means that each product will contain more than tech, and instead be responsible for consumer or business outcomes at the service altitude (e.g. cost, satisfaction) or proposition altitude (e.g. adoption, revenue, attention). In some cases it is possible for product structures to scale up to the business model altitude.

Challenge 4: Ignoring the importance of behaviours, across the enterprise

The fourth and final common problem that we find in failed product transformations is that the behaviours of the people involved aren’t right. Whilst this is mainly the domain of our MadeFor colleagues, we know behavioural problems when we see them:

• Siloed teams;

• Order-taking product managers;

• Micro-managing executives;

• Solutionising;

• Poor communication and transparency;

• Incomplete or dishonest communication;

• Short-termism;

• A lack of critical thinking; and

• Many, many more examples.

Overcoming these behaviours is challenging and takes time. However, one approach that can help solve a number of the bad behaviours above is to apply the no-one ever tells you how principle. This helps product managers resist seagull executives and solutionising operations teams, and encourages critical thinking and original ideas.

Challenge 5: Being constrained by legacy architectures

Monolithic legacy systems (mainframes, aging ERPs, etc.) are the most common complaint we hear from product teams in our partner brands. How can we make a small multidisciplinary team responsible for customer and business outcomes when they can’t control their own tech.

In this case, there is often no quick fix to address the sluggish development cycles and functional inter-dependencies inherent in monolothic architectures. Ultimately we believe that 9 times out of 10, a Service Oriented Architecture is best suited to a product style way of working, but accept this can take some time.

In the meantime, our recommendation is to logically break-up monoliths into ‘ownable’ units (based on items of value and service domains as above) and treat those parts of the monolith as belonging individual product teams. During the time it takes to physically separate these logical units, it will be necessary to align across product teams, and have someone responsible for maintaining the coherence of the monolith. This will be a bit clunky, but it is a far better option than expanding a product team to cover the entire monolith (which would essentially create a system team, which is an old-school IT department construct).

Fixing the problems

Veriteer specialises in helping our partner brands build systemically good product functions. We have effective approaches for overcoming all of the challenges above (and many more), so if they sound familiar, please reach out.