I am Paulo Caroli, the creator of Lean Inception, a collaborative workshop for aligning people and building the right product. In the past years, I got involved in many Data Mesh engagements.
I was never a Data Engineer nor a Data Scientist. In fact, I was a senior developer, although I have not been coding for a long time (nowadays I code markUp text for books and articles, a few excel macros and I keep a WordPress website; but this should not count). Despite not coding anymore, I have always been following up with the engineering practices for digital product development.
I really enjoy digital product development. In the beginning of my career, I used to look at the product from a technical perspective. As I progressed in my career (and my facilitation skills), I realised I should look at a digital product from three different angles: technology, User eXperience and business.
Then, suddenly, I was reading code and going technical again. I was really attracted to Data Mesh. But the non-technical parts of Data Mesh got me deeply involved with it.
Data Mesh, different from many other data paradigms, is not technology centric. Data Mesh approaches data from a people and process centric view and treats data as a product.
People and process. This is exactly where I focused my professional life! I started as a developer, then senior developer, then I changed my role to Agile coach; nowadays I say I am an expert inception facilitator. I live and breathe how to bring people together around a combination of agile processes and methodologies to deliver great products. In the last decade, I specialised myself on the beginning of agile teams, projects, and products: inception (or similar workshops).
Data as product, one of the pillars for Data Mesh is based on Product thinking. In 2011, I started working in a new inception style (which later I named Lean Inception). The Lean inception style has a fundamental change from the “traditional inception style”. The biggest fundamental change is that, similarly to Data Mesh, Lean inception is based on Product thinking, instead of project thinking.
Lean Inception is highly influenced by Lean StartUp and the concept of Minimum Viable Product (MVP). When experimenting with this new inception style, I deviated from traditional inceptions that were typically covering the overall project understanding, slicing, estimating, and planning.
Don’t take me wrong (specially if you like the traditional inceptions). We still need some sort of understanding, slicing, estimating, and planning. But, in Lean Inceptions, we do it differently. We align and strategise the product creation based on customer feedback and hypothesis validation via MVP and product increments. We have conversations about the product vision and align expectations for the MVP. And we plan how to get started and what we believe are the following increments or the next hypothesis to validate.
Data Mesh focuses on organisational change. Lean Inception is a method (one amongst many others) that helps drive organisational changes. Lean Inception provides agile teams with a good level of autonomy while aligned with the desired business outcomes.
Lean inception activities are flexible enough so they can work for a product team within an organisation that has nothing to do with Data Mesh, as well as for teams actively involved in a Data Mesh transformation. Typically, teams that deliver analytical use cases and build Data products, and enhance the data platform.
Data Mesh suggests a thin slicing approach for delivering value faster via Use Cases. Similarly, Lean Inception aims to align people about the MVP and the increments (thin slices). Both, Data Mesh and Lean Inception, advocate for incremental value delivery and fast validation of business outcomes.
The challenges for a Data Mesh transformation are huge. For example, the need to evolve the mesh along with the self-serve data platform. These are also common challenges faced on many Lean Inceptions. For example: inceptions for a product versus an inception for a platform. How to facilitate it? What should be the MVP for a platform team? I cover some of these thoughts in this article: Team topologies and MVP.
It is not my goal in this short article to cover all that I have been going through when facilitating many inceptions and while participating in many Data Mesh transformations. My main goal here is to bring this important point to your attention: A successful Data Mesh transformation requires lots of complementary skills. I am doing so in the context of workshops — such as discoveries and inceptions –and activities that help organisations on-boarding Data Mesh. I will be sharing more in future articles. Please bring your knowledge and skillset to this amazing community and let’s join forces on this movement.
