TUI Modular Web Architecture

Digital Products at Scale

In e-commerce, digital solutions must constantly adapt to competition, markets and customer demands. Therefore, it makes sense to treat software as digital products with a lifecycle. You have probably heard of this and related terms like “product ownership”. But they are often misunderstood, so let’s have a look at what they actually mean.

Let’s start with a definition. In a nutshell,

A digital product is a software solution to a business concern within a bounded context. It manifests as a distinguishable and deliverable software artifact and can be interacted with through interfaces – either a user interface (UI) or an application programming interface (API). A digital product can be composed of modules which themselves are digital products in their own rights.

To understand this a bit better, let’s develop a few thoughts here:

What is a “Product”?

The word “product” has two meanings here: First, it refers to the products which we are selling to our customers. Second, it refers to the artifacts that the software development produces. Following this logic, agile teams should ideally be set up as “product teams”, in that they take end-to-end responsibility for a software product.

The digital product is not necessarily identical with the entire digital customer experience, such as a website. Distinct parts of a website, e.g. microservices and micro-frontends, can be products of their own rights, as long as they have an independent delivery cycle. In fact, it makes sense to split large technology ecosystems into autonomous products.

Projects vs. Products

IT solutions are often developed as projects with fixed goals and budgets. Such upfront-planned projects tend to run waterfall-like, and can, in principle, react to new requirements only between milestones. In such projects, agile (i.e. adaptive and implicitely unpredictable) development is virtually impossible.

  • A digital project is a one-off activity, aimed at reaching a particular, value-driven goal, often with a fixed budget in terms of time and resources. After the goal is reached, the project usually goes into maintenance.

  • A digital product, however, is a “infinite” value-driven undertaking, meaning that there is no “end state”. Instead the product is being continuously improved.

What's interesting are the implications: The difference is not the budget or the time - you can achieve similar value with similar resources following either paradigm. The main difference is that a digital project strategy is usually predictive, wheras a digital product strategy is adaptive or explorative.

For more insights on this, we recommend reading the whitepaper on the journey from project to product.

Minimum Viable Product (MVP)

Even if building a digital product is a theoretically infinite undertaking, at some point we need to bring something in front of the customer. When is right time for this? The answer is: As early as possible. Not “when we are feature complete”, and not “as soon as we outperform the competition”. But really: As soon as there's something that could give you feedback.

This is why a digital product often starts as a Minimum Viable Product.

Let’s take, for example, a campaign landing page: What does it need? The product teaser and a link to the actual product page (or an “add to cart” button). Does it need to have a newsletter subscription box from day one? Does it have to be translated to all languages? No. You can do this later, and in the meantime bring the bare minimum page to a relevant audience. Yes, overall turnover and the conversion rate will not be great, and you’re missing some opportunities. But if you compare that to not having anything at all for another month, it’s much more valuable.

So, get the good stuff out as early as possible. And set up your processes and priorities to reap those opportunities as early as possible: Reduce the number of meetings to discuss this. Make heavy use of existing resources in your company and on the web. Postpone all features that are not immediately necessary to fulfill the primary purpose of the product.

Keep in mind: Whatever fancy stuff you’re building, it does not exist for the customer until they see it. In the meantime, your competitors will be on the market, show their brand and place their products in the mind of your customer.

Product Composition

Almost all digital products are composed from smaller components which in themselves are digital products. Even something small and semingly monolithic such as a mobile app consists of libraries, font files, icons etc. which usually are provided by other teams or even external suppliers, often Open Source projects. Own code and third-party modules are integrated into a higher-order solution.

Think of a car: It is undeniably one product from the customer’s perspective, but it is produced from hundreds of smaller products. Certainly the manufacturer builds the engine, but the battery and the wheels are third-party products. The car exists of dozens of building blocks which again are composed of smaller modules.

Bigger digital products, such as an enterprise sales platform cannot be delivered as one monolithic artefact anymore. Instead, multiple teams contribute isolated digital products, such as microservices or microfrontends, to a huge ecosystem of loosely coupled services. Each of these services is a digital product, and delivering them independently makes it easier to maintain the overall digital product. Rather than at build-time (like the libraries baked into a mobile app), they are integrated at run-time, through network-based, often asynchronous communication.

Continuous Delivery

After you’ve delivered your MVP, you can incrementally add new features and improvements to your digital product. For this to work, your software development process, and the tooling, need to be laid out for a practice called “Continuous Delivery”. (In fact, we would speak of “Continuous Integration and Continuous Delivery”, but let’s skip the integration part for now.)

Continuous Delivery means that your team can deliver improvements as often as possible. Ideally, whenever something is ready, it can be deployed live. This implies that overhead on top of the bare implementation must be reduced at all stages. There are several tools and practices to do this:

First and foremost: Automation.

  • Software testing must be automated as much as possible. For every manual activity, ask yourself, can we automate this? And the answer is more often than not: Yes! And while there is some overhead to the initial setup, you will save resources in the long run.
  • Building the software and deploying it to a runtime environment needs to be automated as well. No manual steps should be needed here at all.
  • Even the setup of infrastructure is automated these days. With “Infrastrucure as Code” (IaC), not only the initial setup but also the inevitable changes over the lifecycle of a product are written in code. This is not only very convenient, but is also helpful in case of outages, when you can restore your live environment with the push of a button.

Second, you will want to optimise your workflows.

  • Reduce the amount of meetings, and the number of people, to discuss details.
  • Introduce the concepts of product ownership, autonomy and end-to-end responsibility (see below). This will reduce the number of dependencies.
  • Instead of prioritising and designing by gut feeling, form a hypothesis about the value of a feature, and define metrics of how to prove or disprove it.
  • As mentioned earlier, make use of existing resources in your company and on the web.

On the organisational level, there are several major enablers as well:

  • The organisation must trust the development teams and their product owners. Of course, the foundation of this trust must be diligent work, but the more teams can work autonomously and can own their decisions, the better.
  • The architecture of the platform, the ecosystem your digital product is a part of, needs to be laid out for autonomous digital products as yours. This means that these products must be loosely coupled

Product Ownership, Autonomy and End-to-end Responsibility

Digital Products are owned by a team, usually a handful of developers a product owner and potentially a few other roles. The emphasis here is on the ownership: If a development team is driven by somebody who only cares about features to be delivered, the product will not flourish. It will become a vehicle for random features and often disregarding consistency or technical quality. The people who develop and maintain the digital product must also be in the driver’s seat for the strategic direction.

The role of the Product Owner (PO) is especially important. This person (and ideally really just one person) must be obsessed with the value of the product, rather than thinking about the implementation and technical delivery. All user requirements will be defined and prioritised by this person. Stakeholders to the product, even if they are direct managers, should not interfere with the product roadmap directly, but instead set strategic objectives.

It follows that product ownership implies a good amount of autonomy of such a product team. This autonomy can best be achieved by removing unnecessary dependencies, both technical and organisational ones. Technical dependencies are those that require the use of certain environments, tools, libraries, services or infrastructure. Some dependencies are useful, because they add significant value with little impediment. Others are obstructive in that they add little value, but the more impediment. Sometimes, however, it is difficult to get rid of them anyway as there is no alternative.

Ownership of a product comes with a few responsibilities as well. To really own a product and be able to autonomously develop it, a team must take care of the entire lifecycle. This starts with business analysis and ideation, continues with UI/UX design and solution architecture, goes on to implementation and testing and will finally be deployed and operated. The team needs to take care of all these activities, this is why we say a digital product team must be cross-functional.

Value Streams and Contracts

In a large ecosystem with potentially dozens or even hundreds of digital products it is important to organise how these products interact.

First, it’s a good idea to align the business product with the digital products into a “Vertical”, meaning that the organisation and workflows are driven by customer product concerns first — rather than by technical or, say, geographical concerns. This is very different from traditional IT systems that are built in layers such as UI, frontend, backend, database, infrastructure. This implies that you will have a production chain, much like a traditional supply chain, where producers and their consumers sit along a “value stream”.

In such a value stream, product owners collaborate with their upstream and downstream neighbours: If a provider of a service knows that they need data or capabilities from an upstream resource, they will form a contract with the supplying team to make sure they can deliver their product as early as possible and not being blocked by an upstream dependency.

Contract, in this context, refers to an agreement of capabilities, interfaces (APIs) and service level NFRs. Forming an explicit contract is crucial: only then can a product rely on upstream solution and does not have to care about their internals.

Ideally, they take the Minimum Viable Product approach, meaning that they ask the inventory provider to deliver the essential features a.s.a.p. first and only then incrementally improve them, based on market feedback and other metrics.