Product-led and Domain Driven Design - Introduction

What is the problem?

Many terminologies have shaped how to build complex software and align with business needs. If we evaluate the trend, software isn’t just a tool to achieve our objectives anymore but now they are taking a central role in business and evolving as digital products. Companies that provide this product as a service need to deal with immense complexity. How to shape their products determines how they grow in future. This isn't something new happening, only the realisation is seen as less adaptive. If we see companies who provide consultant services, their main objective is to deliver as clients demand. This mindset tends to overlook the market value and data-driven decisions while developing a product.

Primarily fuelled by clients’ visions, we end up seeing - kanban/scrum processes as the optimal solution for managing. This mindset easily overlooks the tradeoff between output and outcome. Let’s imagine a software company where developers are working 40 hours per week, they put immense effort into achieving what is planned. Luckily they can deliver on time but quickly realise the lack of correlation between their efforts and results. One may ask, what do I mean by "result" in this case? Results are collective outcomes needed to achieve success. Many companies, ship their products to the market and realise the adaptability within customers is unequivocally negligible. How this result can contribute to long-term scalability?

Having said that, I first want to make some points clear. Situations of various organisations may differ, and here we aren’t looking for a general solution for all. Instead, we should find solutions based on the needs and structure an organisation wants to shape itself. Here I'm interested in addressing the general process and the mindset an organisation undergo and if thankfully they realise early, they can prevent sinking the ship.

Let's compare the two ends

After reading two distinct books on how software/product is developed, one focusing on mindset and the other focusing on architecture. I realise there is a need to get them together in a blog post. If we look at the above diagram, a Product-led growth mindset demands to evolve product being a customer-centric application. Malissa Perri, in her book - The Build Trap argues about how organisations trap themselves in a vicious cycle of output and undermining outcomes. She gives relevant examples to elaborate on the several stages an organisation undergoes. For instance, the key performance index is calculated based on how many story points a team has completed. Ironically, the story point has no correlation with the business value it adds.

A lot of leaders within the organisation also make the mistake of treating their teams with similar standards used in the manufacturing process. Here the main issue is, that the software as a product requires ideation and vision to foresee how a functionality looks like. Instead, we started treating development similar to how the manufacturing industry works. In the manufacturing industry, with predefined standards in place and a focus on improving output, they rarely see the need for creativity. This is counterproductive while developing a product.

Let's compare the website navigation bar with a car door. Here the car door will always stay consistence regardless of the passenger’s height, weight and personality. But the navigation bar can differ based on the subscription plan, feature flag, custom selection options etc. Here the mass-produce mindset doesn't fit correctly just like the Kanban mindset borrowed from the manufacturing industry. The real pain becomes when the project is outsourced to a consultant company when for them the web application is really about mass production. It is critically important to onboard outsourcing companies as part of the product for long-term benefits.

That is why, a product-led growth mindset is very crucial to save companies from burning tremendous cash and prevent them from losing grip of the market's expectations and reality. Once this mindset is well established within the organisation, then concepts like Domain Driven Design flourish on top of it. It becomes easier for developers to ask critical questions to stakeholders to improve the visibility of the product and understand its expectations deeply. It is crucially important for developers to understand the requirements and how stakeholders envision them. It works as a safety net to make sure stakeholders know what successful results (KPIs) they are expecting. DDD allows developers to slice business complexity into manageable features that are distributed to several teams orderly. Developers and architects can make better decisions when they know clear context. For example, customers for sales don't mean the same customer attribute for the Customer Success team. Because the scope of customers for these two teams is different. One focuses on acquiring customers and the other focuses on maintaining them. These distinction helps developers to draw clear boundaries and maintain bounded context.

This is a general introduction to product-led and Domain-driven concepts. In the next blog, I'll go deep to address common mistakes the development team makes while seeing the agile process as a saviour.