Listen on these platforms
Brief summary
Full transcript
Alexey Boas: Hello, and welcome to Thoughtworks Technology podcast. My name is Alexey. I'm speaking from Sao Paulo in Brazil and I will be one of your hosts this time, together with Zhamak. Hello, Zhamak.
Zhamak Dehghani: Hi, Alexey. Hi, everyone. It's great to be here joining you from San Francisco.
Alexey: We're delighted to have once again Paulo Caroli here with us. Hello, Paulo. Would you mind briefly introduce yourself?
Paulo Caroli: Sure. Hey, Alexey. Hey, Zhamak. Pleasure to be here again with both of you. I'm Paulo Caroli, I am a principal consultant in Thoughtworks, that really like facilitating workshops. That's why I'm the author of Fun Retrospectives and the author of Lean Inception.
Alexey: Yes, I know that. I have been personally seeing Paulo facilitating inceptions for at least like 10 years of these. [chuckles] We're very, very lucky to have the opportunity to talk to you about Lean Inceptions. Thank you so much for being here with us.
Paulo: Oh, thank you for hosting me.
Alexey: Maybe we can start with the definition, Paulo. I know there's a book called Lean Inceptions, and I hear about them all the time, but maybe for the benefit of listeners who haven't heard about Lean Inceptions yet, could you talk a little bit briefly about what is a lean inception? How is it different from a regular inception? Maybe talk a little bit about the history there.
Paulo: Okay. I'll first start describing what is an inception? For me, inception is the perfect combination of design thinking and lean startup. It's a collaborative workshop to align a group of people about how do we get started, what is that minimum viable product towards an amazing business solution? That's lean inception in a nutshell. Now, I want to bring you to the history of inception as you told like you saw me running inceptions since a long time ago. I joined Thoughtworks in 2006. I was living in Silicon Valley in San Francisco when I joined Thoughtworks.
In 2000, I moved to US. When I moved to the US, I was attracted to OOPSLA conference, I met Kent Beck, and then I saw Martin Fowler. I started following what became the Agile methodology, that was quite interesting. Before going to US, I did my master thesis and mobile-oriented stuff. I did start even before reparation and define the process. Reparation and defined process simplified things and they create a five-phase approach. Everything started with a phase that they named inception. We're talking the '90s here.
Back then, the inception was that phase where you understand that you gathered the requirements, you start making the project decisions, and the release planning. That was what would go on inception. Even a little bit of the design phase from [unintelligible 00:03:06] would go on inception. When I got into US and we start having the Agile movement going on very strongly in US, especially in 2003, with Mike Cohn's book in User Stories. Suddenly, those inceptions shifted a little bit. We're like, "Oh, we're not going to do the whole requirements in the traditional waterfall way. Now, we want to understand all the user stories."
Then the inception shift putting the focus a little bit on the user, we would-- then I joined Thoughtworks in 2006. I can talk about the inceptions that were very well fought through and run in Thoughtworks, where we would go to the client, spend quite a few weeks in the client three or four weeks, understanding the business context, understanding their needs, going with the very strong technical approach, and writing everything as a bunch of user stories and do a release plan, and all the sprint planning.
I had the pleasure to work with Jeff Patton. He also brought the inceptions, the user-centric approach where, let's understand the users, let's understand the user journeys, and therefore, we'll make all the journeys to user stories. We'll do all of these and the inception then have an amazing plan of a one-year program of work with 200 user stories, 546 story points. Of course, I'm talking about not 2000 and [chuckles] years ago. In 2011, what happened is-- Well, I lived in US, I lived in… As a consultant, I would drive or stand with a client for four weeks, run inception, going back to my home base. We filed the backlog of user stories, it was fine. When I moved to Brazil, I got married and had a baby. This was in 2011. In Brazil, when I had just moved to Brazil, I would fly to US and spend three weeks on my client, running inception because I was an experienced inception facilitator and bring the project back to Brazil. When I had a baby, suddenly, I have a very strong constraint that I cannot stay far from home for more than a week.
By coincidence, on that year, Eric Ries had published his book Lean Startup. I lived in Silicon Valley, so I was following all the developments the things that were happening in Silicon Valley. When I read that book, the concept of minimum viable product was like, "Wow, that's all I needed." That's the perfect excuse to tell the client. That, "Hey, we're going to do inception in one week because we're focused on the MVP, not on the overall product," and then I'll do come back home sooner.
Of course, it was a mistake because, with all the inception activity, it would take more than a week to figure out, even for the MVP, the user stories have all the technical details. That constrain remain, so I kept on trying to make the inception fit in one week. I kept on trying to shift the focus from understanding the project duration, the user stories and put the focus on what is the minimal viable to help us validate if you're going in a good direction. A few years down the line, a recipe become really good and that's Lean Inception.
That's the collaborative workshop to align a group of people. When I talk about a group of people, three types of people comes to my mind, business people, user representatives, or UX, user experience people that don't see the needs of the users, and the technologists from that area that needs to produce a solution. Those three people that many times have different perspectives, they come together, they align, and together they figure out, "How do we get started?" It's not different, "Oh, what's the overall goal?"
We need to talk about the overall goal, the overall vision, but most important, how to get started? What is that very first step? What's the minimum viable to think, to help us validate if you're going in a good direction, to provide us learning to pivot and achieve great, amazing goals. That's the summary, history, and everything in Lean Inception.
Alexey: Wow, that's an amazing story, and also speaks to the impact children can have on the world. [laughs]
Paulo: Yes.
Alexey: Changing the techniques and it's brilliant because it speaks a lot to Agile values. What's the minimum that I have to lock in or to discover? We can learn more and building on that really makes a lot of sense.
Zhamak: Yes, just something occurred to me maybe for the audience, who can clarify. I've seen other methods around bootstrapping or validating the ideas like Google. I think, venture guys wrote the Sprint Book that you can validate ideas in a week. When you said the week, I went, "Oh, so how's this different from Sprint? Or is it's the same thing?" Do you have any thoughts on that, Paulo, to share?
Paulo: That's a really good question. It's very interesting that Jeff, Kent Beck, and myself were both on Silicon Valley on the same years. We did have the same influence. We'll talking about Agile development, we'll talk about design thinking, plans that was going on Silicon Valley on those years. Even by coincidence, we both worked at Google at the same time. Interesting enough, we're not on the same project by chance. We almost worked together. I'm glad that I did not work with him because we would have influenced each other and things would have merged.
He comes from the design perspective, he was a user-experience guy. I was a developer person. I was a consultant. I was close to continuous delivery. I was like, "Oh, we need to figure out things, so we start to develop." I want to shape things to help us understand what is the minimal that we have to build. Not exact figure out the user interface. From his perspective, he wants to get together and figure out what is that design, what is the prototype? The difference between INTP and the prototype, it's very big. Those are two very important concepts. With the NTP, I still have my hypothesis open. I'm talking about the minimal viable thing to validate something. Still, without the design of which prototype I'm going to do. When you talk about the prototype is, they do spend on design sprint. One week, they talk about the business, they open their options, they make some choices, and at the end of the week, you have one winning prototype. That prototype might be about overall product. On the lean inception, we spend one week, we'll look at three different perspectives, business, user experience, and technologies, and together have a plan for the minimal viable product.
They have different goals. The lean inception, usually, it invites different perspectives, the business, the user, and the technologies, and try to find the intersection. On the design sprint, you do have the role of a decision-maker because, as a design, you need to figure out and decide one set ahead. On the lean inception, you do not have decision-maker. You do not want to have a decision-maker because I want to hear the different opinions from the business perspective, the user experience perspective, and the technologies.
Therefore, there is no such a thing as a decision-maker. We look at different perspectives and only at the end of the week, we'll decide what is the MVP.
Zhamak: It's fascinating. I love that story. I didn't know the background there behind the originators of these two ideas and how close to you folks both worked in the same space would be brought a very different perspective as a UX person focusing on the UX and then delivery person focusing on the development. I suppose both of those techniques have a place, right? It depends where you are on the journey of product development without coming. You want to get, do you want to get a product?
The kick-starting building a product with a minimum viable product in mind or you're actually trying to prototype a particular solution or a particular design. Thank you for clarifying that.
Paulo: For example, in your case, you're the author of The Data Mesh, right? It's not about prototype, but we still need to get together and figure out what is the minimum thing that we can do to get started. On that specific case, it's hard to figure out a prototype. It's not about prototype, it's about understanding the user, the business, and the technologies, and figure out the MVP. For some products, design sprint's much better, let's go straight to the prototype. You need to understand both techniques and said, "Okay, what do I want here? A prototype or a plan for the MVP?"
Many times, we might run one design sprint to figure out what is the prototype and then what's the MVP? You have prototype of a bigger product, how do we get started? What's the minimum viable… or the other way around. You have a very complex situation, figure out what is the MVP, and then right after that, run a design sprint, figure out, what's the prototype for that MVP?
Alexey: You mentioned data mesh, and that's been on the back of my mind for a while because, in a previous conversation, you mentioned that you've been facilitating many inceptions for data mesh projects. I'd love to hear more. What's an inception for a data mesh project? How different is it? Actually, since we have Zhamak on the episode, I won't resist asking her for the benefit of listeners, maybe Zhamak, you could just briefly tell the listeners what is data mesh, and then we can hear from Paulo more about inceptions for data mesh projects.
Zhamak: Sure, happy to. I'm so excited to hear actually what Paulo is doing. I know he's working with a lot of clients and running inceptions. Data mesh is a socio-technical approaching, managing, accessing, sharing data for analytical use cases like machine learning models or reporting or everything in between at scale. It has elements of technology in terms of how do we architecture the data sharing solutions in a way that domain teams in a decentralized fashion can create those data sharing solutions, and can share the data, and can peer-to-peer consume the data.
It does have some technical concerns and also organizational concerns in terms of, who are the owners of the data? How do we distribute the ownership? How do we distribute the responsibility of governance? Its intention is to come up with an approach that scales out for trajectory that our companies and organizations are, which is more complex, more data, more diversity of the use cases. It has, at the heart of it, the things that you need to incept. Of course, there's organization change.
The things you need to incept are this idea of the unit to fix change of value, which is data as a product, data product, what are the domain-oriented data products you need to have? You need to have some inceptions around that considering your use cases. Then there's the self-serve platform capabilities to give autonomy to the domain teams to create these data products, you may want to have inception around and a platform capabilities, or just an inception around the whole thing, how the journey will look like, the transformation journey.
I'll just pass it to Paulo to just talk about, how do you incept such a beast? It is a multi-dimensional organization transformation concern.
Paulo: I'm just amazed. Data mesh is such an important thing. You simplified it. It is so complex and it was so hard, this data thing and the organization, and it's the people, the process, and the product aspect. You had put in such an easier way to digest, which makes my life easier as well. One magic thing you did, you said data as a product. You bring a lot of product thinking towards figure out. There is a thing here within the domain, the use case. You're going to have some data product.
Now that you have a data product, what is an inception? What shall I challenge this group of people on building the right products, on starting on a good path? You already have a group of people that want to figure out for that domain. They need to figure out a few data products. That's a perfect environment for, let's have a lean inception, so let's bring these people together. We understand-- if there is a box, what's the name of that box? When I think about that box, I want to think about the data product that's closer to the consumer.
We're talking about the consumer data product, not even the source data product. Now, we have to talk about the source data product as well, but focus on the consumer data product, the aggregated data products, and then you go following the rest of the inception. We put the focus on that consumer data product. What is the vision for that? Who is the person who's--? Many times, it's the internal person. It's someone from the business that's using. Then you go from there, what's the vision of the product? Who is it for?
The product vision from [unintelligible 00:17:00] who's there. We need you to give a name to this. Issa, what is it? It's aggregated products, the consumer data product, it's a source data product. You gave names. Before, we didn't have names for these. Now, it's clear. You go from there and then you follow the lean inception activities. The next activity, what it is, what it's not, what it does and does not do. We start having conversation. "Oh, this consumer data product does not do this. This belongs to the other domain." "It does this, it does not do that."
"Oh no, this is the source data product." Then it becomes more clear to know what is this customer data product, what is the source data products, what are things from other domains that should not be with us at all? Then you go in the personas, who are the personas involved on these? On the personas, you might talk about the consumers, but you might talk about the other side as well, where the persona is inputting data that's important. Then, you go to the other side of the source data product, where the journeys.
We're talking about real journeys. People go through a step by step to fulfill their needs. Let's talk about those. You might have to talk about different journeys from different people that go through that use case, which by the way, we're at other use case because if you're running a data mesh workshop, even before the inception, we already know the use case you're covering. Once you do all of these, you want to finish a slice, but even inside the finish slice from data mesh, you ask, what is the MVP? What is the minimum of that finish slice?
The very interesting thing that data mesh sometimes make the inception more difficult is that why will you evolve your data products on the mash, you need to evolve at the same time the data product, as well as the platform. That's the challenge. Whenever you're running a data mesh inception, you need to be very clear. Invite some of these platform people or the people that will be part of this platform team should be the domain inceptors. The one that they're building, aggregate, and consumer folks data products because they might need to request some new features for the platform.
Let it be like a pool system where the platform features, they're built in a order that fulfill the needs of their organization. Not the other way around, where we have a separate inceptor for the platform, built on a lot of things with the expectation that someone will use.
Zhamak: There's so much to unpack here, but I'm wondering because some of this concept could be quite abstract, like source data, product aggregation, and so on, is there a recent example, maybe anonymously you can share from a particular domain just to make the concept a bit more concrete in terms of who are the people that you invited? What were the data products that you incepted? What were some of the platform capabilities that you pulled? Is there a concise examples maybe to share, to make this a little bit more concrete?
Paulo: That's at the front. Who are the people? You need to invite the right people, of course. It's a simple one. Invite people in the domain, invite the consumers that use that, invite the business people that want to know the direction of that data product domain is taking. These are the right people because together, they'll figure out what's the strategy behind these. The platform team or the people that we will start shaping, the data mesh platform, those are very important. We're talking here about the governance as well because these will evolve along with the other domain data products.
They are either stakeholders, people that might not be in all the active with the inceptions, but they need to know what was the decisions on each of those data product team's inception. Some are, in inception terms, active team members that are close to the domain and the stakeholders. The platform people, for sure, their stakeholders of all data mesh inceptions that are going on. They might have a special inception for them because they might have to plan their platform as well, but they need to be cautious not to plan way too ahead of time.
Zhamak: I remember in one of the workshops we ran for one of our clients in terms of-- they are insurance provider client in North America, and we had to, as you said earlier, even before the workshop decide what use case we want to use to drive creation of these data products. At the time, we pick ML model or ML-driven use case around detecting if a patient is eligible to receive a particular prescription. Does the insurer approve that you can-- they are going to pay for the medication that you need?
Traditionally, these systems are built with rule-based decision-making. Because they give you a lot of false negatives, they say, "No, we're not going to pay for your medicine." That has huge consequences for people that require taking medication on a daily basis. This medication's usually very expensive. It's North America. I know that this might be a very North America-specific example.
We had stakeholders from department of business, business people that understand this process of RX, they call it here in the US, approval process for paying for medication for someone in advance of the doctor, writing the medication or at the time that they go to the pharmacy and they want to get the medication. We've brought those people, we articulated, as you said, the use case, what is this for? What are we trying to do?
Then we worked back, where we had to bring people that understood different domains that exist with the organization because the data that was fueling this use case, this machine learning model needed to bring the history of the patients, the actual characteristics of the prescriptions, and a whole lot of other data that will go into that machine learning to make a decision.
We have representative of the platform people so understand for getting this end to end use case to creating these data products, feeding them to this ML model, deploying them as a solution at the end of the day at the point of authorization of that medication, what are the platform needs that we have and pulling, as you said, those platform capabilities. It can be quite exciting, but also I can imagine it's-- I was exhausted. I probably slept two days after that. [chuckles] I'm curious how you feel after those inceptions because cognitively, it's quite difficult.
Paulo: It is. I go into inceptions as a facilitator. That's the key difference. It's very tiring in the inception. It is more tiring for you than for me because, as an experienced facilitator, I'm already used to it. I'm paying attention to everything. I know that you're thinking really hard to solve the problems. As a facilitator, I need to create the perfect environment. The people in the inception, they're thinking really hard to figure out the solution. As a facilitator, I need to save my energy to the next day, I need to be very clear with the instructions, and create a safe environment so everybody can collaborate.
It is tiring. I really like that. I pull off all energy from those environments. That's my trick. It's like talking to you here. I just love this. For me, this is my pleasure time, talking in a podcast with Alexey and Zhamak about inceptions and data mesh. For me, that's not work. It's almost like these inceptions for me. I gain so much energy from that [crosstalk].
Zhamak: That's how work should be, having fun and getting energy from your work. It's the right kind of work, Paulo. [chuckles]
Paulo: Exactly, exactly, yes. For the teams, the inception need to be lean because it is energy-consuming. You should go through inception for four or five days and that's it, and you don't need another inception for quite a few months. As a person, a team, you should not be on inception week after week. That doesn't make sense. Have inception, yes, awesome. Now, we have a plan, go work on the plan, build, measure, learn, build things, and then you go into your continuous delivery, and continuous discovery, and then you're fine.
Alexey: Paulo, apart from the energy required and all the complexity of managing different stakeholders, what is usually challenging for a lean inception? Now, you did talk about the one-week duration and it feels like a very strong constraint. I'm sure it gives people focus and it's quite interesting to drive real outcomes. What kinds of challenge does that bring? I can think of even logistical challenges like getting the right people, managing agendas, and also having a short time to create a safe environment, as you've mentioned bonding and relationship with people. Can you talk a little bit about challenges that come up often?
Paulo: Biggest challenge, one area which is really important is create a safe environment. As a facilitator, these are topmost priority. You cannot ask people to collaborate and expose different points of view, unless it is a safe environment. Number one priority for you as a facilitator, make sure you're creating, you're fostering, and you're paying attention that it is a safe environment. I want to say for second challenge, another very big challenge is the change of work culture style. We're very used to working, "Hey, here's my calendar, don't talk me, schedule a one-hour meeting with me."
We're not very used to, "Hey, let's stay in a room working for four hours and collaborate 20 people together." If you do this, you're like, "Okay, it's a get-together. We'll have pizza, celebrate, and that's it." We're not used to really collaborative work. That, for me, is the biggest challenge. For that reason, Jake Knapp's next book, my other book was like, "Oh, product backlog of--" and things related to inception. Jake Knapp's next book was Make Time.
This was his biggest challenge when he say, "Hey, let's get a group of people together for one week. We're going to have these amazing workshops, a collaborative workshop, has a lot of value, have a prototype at the end." Guess what? A lot of people pushing back, "Oh, I can't, I can't. Tell me what time should I--" "Oh, I'll show up on Wednesday from 2:00 to 4:00." I have the same challenge. When you go to a new organization, "What? One week? No, no way. Let me see the agenda. Oh, I see the name UX here. I'm going to come only to the session then I'll leave."
That for me, it's like, "Ah, come on." Interesting enough, in Brazil, I was living in Brazil and the book inception, the first version came out in 2014. I was running a lot of inception in Brazil, especially because of the kids. Whenever there was inception in Brazil, I'm like, "Yes, I can do it," because I could even be sleeping at home on that night. Five years later in Brazil, everybody's very familiar with inception. In Brazil, you have no problem going to organization say, "Hey, I need a week to run an inception."
Then, I moved to Spain and then the same problem that I had years ago in Brazil, it's here. Every single new organization that I go now remotely to a different country, to organize the first inception, "Oh, why do you need this? Oh, one week?" A lot of organizations, they want to work on the old PRD style, Product Requirement Document. They want you, as a consultant, "Oh, go talk to that person, then this other person, then this other person," and then create a backlog of work. "Oh, beautiful. You use a mural. Fine, talk to everybody, and then create your peer doing a mural."
I'm like, "No, no, no, that's not the case. We want to be together in the room." We align and together, we write down. Then, they're going to say, "Fine, talk to this business person, you want to know about personas, talk to this other person, the journey, talk with that person, then you derive a thing, and then talk to the engineers." I'm like, "Oh, no. You need a line team. You need to talk to everybody on the room at the same time to look at the product vision from the two perspectives, to talk about personas after have talked about the product vision and do a brainstorming, bring a lot of technical inputs. After be in the room, when we talk about the personas and their journeys and be in the room, when you understood the business and the product vision. It's very different. It's not I don't know. It's almost the old waterfall style, which one do one peaks and troughs over the water to the next one. Unfortunately, some organizations are still like this.
Zhamak: If I play the devil's advocate, you have the case of traditional requirement gathering, maybe a smaller group of people collaborate peer-to-peer and then some people are left out. That seems just fine. What would be the most important output or outcome that we will miss if we did this in a non-collaborative, not in the same room, not for a week together? What would be one thing that you think it's just incredibly important?
Paulo: The top most important that you will miss is the commitment and relationship between people. The artifact is the same. The end of Lean Inception is MVP campus, where you tell what's the MVP? How do you get start with it forward to expect result? I can create one by myself. The business person can create one by themselves, the technical person but there is no commitment. If myself as a business person create it, it might look beautiful, well-structured, strategic plan that I created by myself.
You have zero commitment from the other people and the relationship, you did not build it, and especially when you talk about MVP. MVP is something very small that you start with. Why did you start with this? What about the other 95% of things you're not building? Why this first? No one knows. When we used to talk about the overall plan, maybe in waterfall style, it's fine because I go to the room and then I talk about the overall plan, and talk about the whole pay cut big thing, the 100%.
Then people ask like, "Oh, yes, this is 98. This is 99. This is 75," but when you go and talk about the MVP and work with real situation vision development and pivoting and evolved based on usage learning, you start with something very small, 5%. Then you have a bunch of questions, "Why did you start from here? Why not from there and the other place?" If you made the plan on yourself, you're solo. There's no relationship, there's no team behind, there is no team commitment. That's the worst offender.
The artifact, if you only look at the picture as a result of inception, you could do collaboratively. You could do separate, each one to build up a piece. The artifact's result's the same, but the team commitment and the relationship you build, because you're part of it, it's not the same.
Zhamak: This intangible outcome that you talk about is so crucial at that point in time in the journey of that project or product because you're right at the beginning. Right at the beginning, you want to create that collaborative movement altogether, committing to this thing. It's just such a key moment in that journey. That intangible outcome, I can imagine how important it is.
Paulo: If you work with Lean Startup, one thing that you learn is you're going to pivot a lot but you're not by yourself. It's like I'm driving a car with five other people. When you pivot, everybody is going the same direction and we talk about teams here like data mesh. It's teams. It's not one person working by themselves. When you go to pivot, everybody is the same. Yes, we're pivoting here because we're together. We understand what you're chasing here.
If you did not have a lean inception and you want to pivot, each one want to pivot to a different direction. It's that concept is struggle on the team week by week, people fighting, pointing fingers, and going to different directions. Come on. Get it right from the beginning. Then we work as a team because we're going to pivot. Once we start digging further, you're going to realize, "Oh, that ML algorithm did not work. That data starts to fall like this, like that." That's the reality in the software industry.
It's not predictable and the market's not predictable and the users are not predictable. They change. The most important thing is the team. Let's start as a team. Let's have one team commitment and we want to pursue success. It's not that our MVP strategy is going to be amazing. We're going to be amazing as a team. We're going to pivot a lot. We're going to learn in the way and we're going to achieve into a successful solution.
Zhamak: I love that. I'm energized. Let's go do an inception.
Paulo: I'm very excited about this topic. That's why I spend sometimes quite a few meetings convincing the client and the organization, "Please, let me do the first one. Let me do one," and it's amazing because after the first one, the organization keeps on doing more. The first one is the one that I'll put more energy, convincing and sharing stories and everything because after you go through one, they look at the thing. It's like, "Wow, what happened to this thing? Why are they happy? What's going on here?" It's this happy team.
Alexey: Yes, it changes the people. That's my experience with inception. It has always been that people experience it. It's not about building something. It's not about even sharing information. It's about the experience the people go through and the people are different. Their relationship is different after that and therefore, their productivity is going to be different as well because all those intangibles you were talking to about that's really, really deep.
Paulo: Alexey, probably remembers, back in Brazil were fewer big projects going on and one big problem of work. The technology was worse but people were happier. The other sitting right next to it, cooler technology, more money involved, really cool market, and people were not happier. This is part of the reason because there were a lot of small teams that went through inception. They were together and they're pivoting, finger out, and they're happy. The other team like, "Yes, really cool technology," back then-- I won't name the technology, so people who remember which project we’re talking about.
Really cool stuff and a big failure and everybody stressed. Come on. Work has to be fun, has to be light, has to be enjoyable. We like success. As a developer, you want to be part of quick success.
Alexey: Absolutely, absolutely. Thank you so much for sharing all that wisdom, Paulo. Really, really insightful and inspiring as well. Maybe a final question. You talked about creating a safe space and you're such an experienced facilitator. Any facilitation tips that you would like to share with listeners or anyone sharing a similar process or for facilitating a lean inception.
Paulo: Yes, I have quite a few tips on facilitation. The biggest one is, if you've never facilitated, get the book, follow a recipe a few times. It took me years to figure out it's a good recipe. Do not get the book and say, "Oh, I'll start by changing it. I'll start by mixing this with that." No, follow that recipe three times. Once you're familiar with the recipe, go and change because right now, that's what I do. I go to a Data Mesh inception, I know the recipe, and then I change and I add the other activities and things like this but first get familiar with the basic recipe before changing it.
That's how we learn. It's Data Mesh. I was not involved with a Data Mesh. I'm like, let me read to know some acts, all her blog posts and it's like, "Wow, if she said those four pillars are important, let me follow it," and guess what? They were important that. I follow the Data Mesh recipe and it's amazing. The result is good. Do follow a recipe before you start changing it because whoever came up with it-- It's like Data Mesh. I'm sure Zhamak has been working on that direction for decades and then it's like, "Wow, I'm finally I'm able to simplify and explain this."
Do follow it because that person took years or decades to create it. After you understand it and grasp it, change it a little bit. That would be my advice. Follow. Like design sprint. If you need get together as a group and figure out a prototype, then that recipe is really good. You need to get together, know how to get started, and build, then the peer the first step towards a solution. Lean inception is really good. Do you need to map your user journey to user stories? Use your story mapping. Follow the recipes for the specific problem.
Alexey: That's great. Really, really insightful. Well, it's been an amazing conversation and great to have you with us, Paulo, but unfortunately, we're coming to the end of the episode. Thank you very much, Paulo, for sharing so many stories and learnings with us, and thank you all to listeners for joining and for listening.
Zhamak: Thanks, Paulo. That was great. I'm so excited to be part of one of your future inceptions, hopefully, sometime soon, and feel the magic.
Paulo: Yes, a data mesh inception, for sure, and I will do. Alexey, it's my constant pleasure talking and learning with you.
Alexey: Thank you so much. Bye. On the next episode, Rebecca Parsons and I will talk to Swapnil Deshpande and Prakash Subramaniam about NEO the Thoughtworks platform for developments. We'll discuss platform thinking and developing the platform, its features, its journey, and some of the next steps as well. I hope you join us for that conversation too.