From time to time, I work with customers and prospects where both business and IT representatives are present. I love these sessions because they provide insights into both sides of the company. And, you guessed it right, they're far from easy. If you've spent enough time with these groups separately, you've probably sensed that while both ultimately want their company to succeed, each has a quite different perspective on how to get there and what's actually required for success.

Product Management, the Context

The business team (sales, delivery, operations) typically wants to move as quickly as possible, respond to market challenges and customer expectations, and be very flexible - sometimes overly so - in catering to customer demands. This is especially noticeable in the business segment. Such velocity and flexibility come at a cost, which, surprisingly, is often paid by other business units.

The IT team, meanwhile, aims to enable the business to do everything we just discussed, but in a controlled and manageable way. We've seen many examples of business and solution architectures becoming so complex and subject to uncontrolled changes that they eventually become unsustainable to support and operate. Then, five years later, the company selects a new platform and starts from square one.

Going back to the sessions when both business operations and IT teams are in the room - if there is some tension or unresolved questions - they surfaces up very quickly. An important note is that it is not a bad sign. It just brings up the topics, capabilities and challenges that really have to be discovered and discussed. One of such topics that pops up on almost every project I supported is how to efficiently manage product catalogs to make the company more flexible and innovative.

Here's a typical request I hear from business teams: "We want to be able to make changes to the catalog configuration ourselves without necessarily asking the IT team. Can your software support this?"

It's a reasonable ask when you think about it. In highly dynamic and competitive industries like telecommunications and media, the ability to quickly adjust processes and products is an extremely valuable differentiator. If a competitor can do it faster, simpler, cheaper, or better, it can create a huge competitive advantage in certain market segments. For context, it's already normal for business teams to manage data in their systems and applications:

• Sales teams create accounts, contacts, and opportunities in CRM applications

• Marketing teams craft appealing campaigns in marketing automation applications

• Support teams manage knowledge databases

All of this happens without IT involvement (except for initial setup). The big question is: why don't we use the same approach for product catalogs? Why don't we let business teams make changes to the product catalog in the same way? After all, it's just data.

The Catalog-Driven Revolution

If you expect an answer in the next paragraph, you may be a little disappointed. Before answering the question, we need to make a little maneuver to first understand why this question is asked at the first place and why it is so important for the business team.

Quite a number of IT applications are not really catalog-driven. There is a lot of legacy literally everywhere unless you are a relatively young digital-by-design service provider or a virtual network operator. Change to such systems and applications often require (often very) specialized knowledge and skills that available only in the company IT (or some external company which makes the situation even worse). Thus changes takes a lot of time (and often a lot of money). So often we heard stories about a supposedly small adjustment takes 6 months or longer. Then we look under the hood and say “Oh, that’s why. Bad but makes sense”

Then catalog-driven applications took the stage. That was a fundamental shift aimed to dramatically reduce the need for highly-specialized skills to make changes to the processes. Instead of redefining (developing) the business logic in your applications you can now make changes to the catalog definitions and leave the run-time applications as-is. The caveat here is that, while this was a massive improvement, there is still a number of places where development (IT) is still required

With the catalog-driven architecture, there is a bulk of changes that do not require specialized (development) skills anymore. In a modern catalog management software (such as Salesforce, ServiceNow, Netcracker, Amdocs, Hansen, etc.) you can create product definitions, characteristics, promotions, pricing without writing a line of code. This is a commodity capability nowadays. How cool would it be to let the business do these changes themselves with no or very limited involvement of the IT team. This would let the business to respond to the market demands so much quicker!

A fellow IT architect at this moment would raise a hand and say something like “Well, hold on a second. Indeed, you don’t need to be a developer anymore to make changes to the product catalog. But you still need to know what to create (and what not create) in the catalog because now we have a lot of catalog-driven applications. The cost of mistake is quite high”. And he will be right. This is roughly the reason why modern catalog management software technically can be used by the business team but the IT team generally does not allow to do this. Speed and flexibility is great but in case of accidents the accountability is still with the IT team. Think of it as a risk mitigation strategy.

The Two-Speed Architecture

Now, this doesn’t mean that only IT should be able to make changes for the business. Quite contrary. At this moment it would make a lot of sense to break the changes in groups - those that may be done by business directly and those that absolutely require the IT team to be involved. This is an essential step towards creating a business architecture where we can move both fast (or at least faster) and safe (or at least faster). Some smart people may refer to it as “two-speed architecture” with two types of changes:

• Fast changes: usually in the area of customer engagement. For example, customer marketing, changes to product appearance (names, descriptions, images), new promotions introduction, price adjustments, etc. This is where the business has to be fast. This is where the risk from making a mistake is not catastrophic. This is where we typically suggest to let the business teams to take the lead. An important caveat here is that the IT team will still need to support these changes because product catalog configuration, even if made by the business, will need to become a part of the DevOps process - which is today still owned and managed exclusively by the IT team. We also recommend creating a special (purpose-built) user experience to simplify the change management process for the business teams. The simpler the tools - the less the chance to make a mistake

• Slow changes: these changes typically have a significant impact on major business operations, or the changes introducing something brand new. Think about bringing a substantially new capability to your product portfolio (e.g. extending your portfolio with offerings from a partner). Or introducing a substantially new pricing model that you have not used before. This is where we always insist on the IT team to be in charge. Not only because the IT team usually still have all the necessary knowledge and skills to implement the change but also to make sure the overall ownership for this change remain fully within the IT team (especially if something goes wrong)

Let me give you a couple of examples of fast and slow changes that I’ve seen in the field.

Fast changes

• Changing customer-facing properties (name, description, images, etc.) of existing product offerings

• Changing pricing (values) for existing product offerings

• Introducing new promotions following already adopted/supported patterns

• Introducing new product offerings and their components following already adopted/supported patterns

• Some changes to business rules that only involve changes to values but not to the business logic

• In general, changes that involve changes only to values but not to the business logic

• In general, changes that have little to no potential risk to break or impact business processes (this is up to the IT team judgement)

Slow changes

• Adding or removing values for product offerings and specifications

• Introducing a new pricing pattern

• Introducing a new product, component or portfolio

• Usually, changes to business rules (eligibility, availability, compatibility, etc.)

• Any changes related to order fulfillment

• Any changes related to system integrations

• Any changes that can have an impact on billing or other applications or processes

• Any changes that have a potential risk to break or impact business processes

Note that this categorization is provided for reference only. This is where you need to facilitate a conversation between the business and IT teams and see which changes can be added to the bucket of fast changes depending on the current business and IT architecture, system capabilities and company culture in general. If you have experience with other use cases and situations - please reach out to me, I would be happy to learn from your experience.

Is My Change Fast or Slow?

The last thing to add here is a quick set of guardrails or checks that can help you to decide either a particular product catalog change is a fast change or a slow change (based on the definitions above)

• Purpose-built tools are available for business users - a good candidate for fast changes

• Changes in values (name, description, image, price point) but not structure or modelling pattern - again, a good candidate for fast changes

• Introducing a new product modelling pattern (something net new for your business) - always goes to the bucket of slow changes

• Anything related to order management - straight to the bucket of slow changes

• If not sure - put it in the bucket of slow changes, better safe than sorry

Final Remark

It is worth making a very important remark here: product catalog configuration (all these product definitions, product relationships, characteristics, discounts, rules, etc.) are still a part of IT configuration management process. In simple terms, every product or price point definition, regardless of either it is created by the business or the IT team, have to be exported from the catalog management application and made a part of a code repository (and then later on be integrated into an established DevOps process). So, do you want it or not, the IT team will always be a part of the process. But if you manage to automate the process, this involvement will be as invisible as possible.

Conclusion

Now you have it. The business team can make the changes they really care about. Meanwhile, the IT team remains in control of the product catalog configuration. The company overall now able to respond to market challenges and customer expectations, be more flexible in catering to customer demands. All without hurting interests of any company unit.