 Hello everyone, I'm Gabriel and I'm a Group Product Manager for Bookend.com and today I will be presenting some ideas and experiences we have had when developing platform products. I want to thank the products school for the opportunity to have this space and share some experiences with you and yeah feel free to connect via LinkedIn if you are interested. So I bet you have never heard about technical depth, non-functional requirements, velocity or reliability and performance and you have never struggled with these kind of things having slow velocity or low reliability for products that you have built and then understanding how to address this while delivering functionality. So today what I want to share with you is over a period of two years we have been dealing with these situations and we have developed some strategies when building this security platform at Booking that have resulted us to have some benefits along the way. What I say we is because I didn't develop this alone. This is a constant work with team members, team leads, engineer managers, engineers. We have tried different things together, documented the benefits, adjusted and continue to operate so we can find out what works for us and we have been learning over time. The idea here is that if you can get some of these ideas and use it to understand how to address your particular challenges maybe you don't have to take two years to achieve this but in less time. Again every challenge is specific to your context and circumstances but who knows maybe some of these can help you to navigate your own challenges. My name is Gabriel. Again I'm Group Product Manager at Booking.com. I've been there for three years. I've been in the product management area for more than five or eight years. Don't remember now. I have a technical background, electronics engineering and I'm really happy to work on platform oriented products that enable developers or analysts and security engineers to achieve their objectives. So the problem we're going to be looking today when working on platforms is very important to have to clearly determine the return of investment. So if we have a negative return of investment because the users of the platform don't trust it and there is low adoption we are in trouble. Having low adoption means that we cannot rely on the network effects of the platform. The more users the platform has the more return of investments there is because the value is distributed across multiple teams. The root cause of this sometimes is focus on delivering fast functionality and trying to please multiple stakeholders, users, multiple teams, management while sacrificing quality. This then results in velocity degradation and losing the capacity to adjust the platform to continue evolving it to satisfy more problems or maintain its current guarantees and therefore reduce its utilization and facing out. Without booking we wanted to understand how to avoid this but let's go back a little bit to platforms and non-functional requirements or quality characteristics. Today the platform we're going to dissect is going to be the transport ship. The transport ship is a platform for maritime commerce. It can be used by companies to move goods from one place to another. And the platform has several kinds of systems. It has navigation systems that allows the ship to be routed to different areas. It has cargo systems that allow the ship to transport frozen goods or liquids or dangerous materials and to distribute it properly to utilize the space better. And it has propulsion systems that is very straightforward. So let's talk about the quality characteristics. You may have heard this as non-functional characteristics, non-functional requirements and there are many kinds of quality characteristics out there. Some of the most known ones are in the screen, security, maintainability, reliability, performance. I like to refer and to use as a reference the ISO 2500010. There you have a list of quality attributes and sub-characteristics that you can use as a reference. But every team, every product will define what is more important for them. So let's put these two together. So we continue with our ship. We have the navigation systems. For example, it is important for the navigation system to be reliable, to be secure so it cannot be tampered, to be extensible so we can build more on top of it and then make the ship able to navigate across other kind of routes. It has to be maintainable. It has a good usability, therefore allowing the operator to reduce the amount of error, for example, they can input there. And similar to the cargo systems and propulsion systems, as you see, the quality characteristics can be different for the different areas of the platform. However, working on quality characteristics is not going to increase the capability of the platform at a functional level. This is very important to distinguish. Increasing functionality could be, for example, making sure that the ship can navigate through bad weather or at night. This means that maybe the navigation systems have to be extended. Radar has to be set up, lights needs to be put across the ship. This is separate from the quality characteristics. Quality characteristics keeps the current functionality, but makes it work better. For example, a calculator that can produce the result in seconds versus a calculator that can produce the result in minutes. They both produce the correct result, this is the functionality. But each one of them do it in a different amount of time. This is performance. So this is an example of quality characteristic. So let's talk about the challenge again. Remember, having a sustainable platform development so we don't fall into the velocity degradation. Our structure at booking initially was the classical team approach. We have three teams, navigation team, propulsion and cargo team. Each one has a group of developers, a product manager, a team lead, and each one has its own concern. However, we try to create value through delivering outcomes that impact the business. For example, we have the increase revenue by 15% by having the capability to route the ship through bad weather routes. This is something that will impact both navigation and propulsion teams. In order to achieve this, we need to align their backlogs and therefore guarantee that they both align and work together and then produce each one's part so we can deliver this outcome and the ship is able to navigate through bad weather routes. Anyway, outcome oriented backlogs is a topic that is very well documented and discussed in the Silicon Valley product group and I recommend a book that is called Inspired by Marty Gagan, the founder of Silicon Valley product group is an awesome reference to read. We're not going to enter into details about outcome roadmaps here, but I just want to present that this has a challenge. Takeholders wants us to deliver functionality fast. It's difficult to align teams. So in the end, we favor functionality development over quality characteristics, maintenance and development. We create knowledge silos by having teams distributed across different areas. And there may be a problem with motivation of team members. Imagine that one of these teams contains components that are very boring to work with. Team members feel they are stuck there. They have to maintain these kind of systems that are always breaking. It's an old technology, not easy to evolve. So this creates team rotation, knowledge departure, and a lot sort of issues. In summary, and very summarized way, we lean towards delivering fast functionality, creating quality depth. This creates a problem that we have issues to fix constantly, which steals time from development functionality. This is a vicious cycle. It continues to increase, the number of issues steals time from development, and therefore we see velocity degrading. So we thought, okay, what can we do about it? Some new approach, different approach, let's think out of the box. So we said, okay, let's reorganize our teams. Let's refocus on this problem from a different perspective. We created this concept or attempted to use this concept of micro teams or, as we called it, task forces. Task forces mean that all team members are part of the same team. We are the platform team. Navigation propulsion and cargo systems are part of the ship of the same platform. All the team members contribute to all of these systems. But not at the same time and all the time. We identify the outcomes that we want to achieve, and we form a particular task force with the required amount of team members and the skills and also the motivation from the team members to work on this area, and therefore allow them to solve the problem within the fine set of constraints. So for example, we create here three task forces, one for each outcome or maybe two task forces and then we leave the other outcome in the backlog. What improvement did we see here? Now we have one team, there is alignment. Everybody understands this is a ship, it's not navigation systems or cargo systems or propulsion systems, it's a whole ship and we have an impact on the business. We can think about outcomes. We can work focused, so increased focus on delivering this outcome, regardless of which components we are addressing. We don't have backlogs to align. We have increased motivation because we are learning and contributing in different components. So yes, there may be components that are very difficult to contribute towards, but I'm not working all the time the whole year on these components, I'm shifting. However this created some other problems. We identified that the ship, yes, it has to be extended. We want to continue to evolve the platform and work towards achieving outcomes, business outcomes, but we have to keep the ship running. The ship, and in this case, needs to interoperate with other ecosystems, and these ecosystems may be changing. So interoperability is important, libraries that we use change. We need to make small adjustments. There are concerns regarding high availability, vulnerabilities, business continuity. There are drills happening like data center outages. This requires our team to dedicate some time. The whole team was distributed across task forces. Therefore, we didn't have focus on this, and this started to still focus from the task forces, therefore reducing one of the improvements we achieved. So we said, okay, what else can we do? How can we organize to this? And this is our second attempt. We introduced the concept of continuous operations in addition to task forces. We discussed together as a team and we said, okay, let's try something. Let's put a person that or a couple of persons that for a week or a particular period of time that you decide is going to be working only on these small tasks to guarantee continuous operations of the platform. While the rest of the people continues to work on task forces, focusing their time there, focusing their attention. And then we have, yeah, we have all the benefits of the task force and also we can guarantee that the platform continues to operate. However, we found out that these challenges sometimes are bigger than what maybe one or two persons can handle in a particular amount of time. Also, the platform has multiple components and not all the components are entirely known by one or two persons the whole time. So now these persons needed to, it was very hard to be on this weak rotation to consume the continuous operations backlog. And the team didn't start to look at this in not a very nice way. Nobody wanted to be in this rotation. Although everyone understood that this is beneficial. So we needed to say, okay, what can we do about this? Let's think of, this is in a span of months and maybe years. What can we do? The third part of the attempt is to create bases and do basekeeping. Okay, what does this mean? Maybe we're now going back to the classical team approach where a base is a team and holds certain components and has members that are dedicated to work on these components. But no, we made a complete turn and now we have a different mentality. We have a different mindset. Bases owns components. The component distribution and how we achieve something balanced is something that is outside of this conversation. It can be a complete different topic. But think about, we have these three bases. Navigation base, propulsion base, cargo base that has an administrative function. Base members report to the base lead or the team lead similar to the classical team approach. But now they also are owners of these components but not on the functional development, not on the functional evolution. Bases are responsible for the quality characteristics of these components and they have a backlog as well. They have a quality characteristics backlog or quality outcomes, right? Let's see how this is combined with everything else. While a person is not part of a base, sorry, while a person is not part of a task force, they are working on their base, on the base tasks, on quality outcomes and small tasks that needs to be addressed constantly that come from this task that we're not able to be addressed immediately by the continuous operation person on rotation. This continuous operation rotation continues to be there. It continues to address some small tasks that can be handled within hours. But now it serves as well as a triage layer. It can send tasks to be dealt by the specific base that owns this component for things that maybe are not urgent and are more complex. In addition, every base member can participate in task forces and task forces will be contributing, will be working with components that are across multiple bases because their task is to achieve an outcome that requires some functional development, some evolution to increase capabilities of the platform, same outcomes that we have said before. So for example, there is a task force that wants to achieve outcome one, the revenue increase by routing through bad weather. This requires two touch components on the navigation base and the propulsion base. And this of course can be dealt with by team base members from the three bases, based on their interest, based on their skills and based on the complexity of the problem. Whenever the task is done, the outcome is delivered, this task force is disbanded and the team members return to their own base and continue working on their backlog and maybe part of a new task force later on. So what did we achieve with this? Now we have, with task forces, we reduce silos. We have more focus and motivation because team members can work with other team members, other base members. They can increase their knowledge in a particular technology. They can just work in something that is more interesting for them as well, that are not the components their own, is refreshing as well. They can share knowledge. The bases, instead, create more ownership for these components. We know who can handle specific incidents on the platform. We have a grasp on the quality of these components. We increase the knowledge and understand what academic part needs to be studied in order to guarantee that we can continue to evolve these bases and these technologies and these components by creating sense of ownership. And finally, the operations rotation, which continues to be very relevant now, is a task that is more relaxing in a sense. Assesses information, assesses tasks that need to be performed, understand these tasks can be performed immediately, so not to remove still focus from bases or task forces and creates a triage, so tasks that require more complexity, more specific knowledge, but are not urgent, can be addressed by the bases themselves, keeping our users happy with the delivery guarantees, the quality levels, and functionality development. So putting all together how this operates with us. Remember, base members are in a base until they participate in a task force. When the task force finishes, they return to the same base and continue working on the base backlog. The task force lead is the keeper of this backlog. They guarantee that some time is dedicated to the base for base keeping purposes, adjusting the quality characteristics, achieving quality outcomes, and they together work with the product managers to identify, based on a particular set of time, a quarter or a semester, how we are going to deal with both worlds, how much time are we going to dedicate in a semester on a quarter for base keeping, and how much time we're going to dedicate for task forces. In our case, for example, every semester we decide, every, for example, for H1 in 2022, we're going to use every four weeks, we're going to use one whole week for base keeping. This is everyone stop doing what they're doing in the task forces and go that week to their bases and work in the base's backlog. After that week finishes, they return to the task forces. Some members that are not part of a task force at the time continue working in the base, but this gives some afterburn, let's say, to the base keeping assert every period of time. Product managers understand which outcomes we are going to be delivering. Task forces are working on these outcomes and they know some time from this semester is going to be dedicated for base keeping, so they can adjust the estimations. So this way, again, what we achieve? Sustainable velocity. We have task forces to dedicate on capabilities, evolution and functional characteristics, bases to guarantee a certain level of ownership and increased quality characteristics management and the operations to guarantee that the delivery guarantees, sorry, to guarantee that we can provide the users with some assurance that the ship will continue to operate constantly regardless of what happens in the context situation in the ecosystem. So here it is, a very summarized version of everything put together. As you see, each base has defined their own, the most important quality characteristics from their perspective. Navigation, for example, very important reliability, security extensibility, maintainability and usability. Cargo, for example, has other concerns. They are concerned about safety, resource utilization efficiency and interoperability. And for example, propulsion base is working on a particular outcome, quality outcome, to increase the profit in 2% by having better fuel efficiency in their propulsion systems, increasing the fuel efficiency by 10%. This will give the business a 2% increase in profits. This is entirely quality characteristic, non-functional. Task forces, on the other hand, are guaranteed that we can navigate through bad weather by evolving navigation and propulsion systems or maybe increase our market share by consuming other kind of products like dangerous liquids. Therefore cargo systems need to be addressed, but also this has an impact in propulsion and navigations because of compliance, and therefore these systems need to be evolved. As you see, everything put together resembles the classical team approach, but it's a complete different mentality that has allowed us to have less uncertainty on dedicating time to quality characteristics and therefore guaranteeing that we can continue to evolve the platform sustainably over time. Again, another recommendation. There is another book that is like a sequel to Inspired that is called Empowered, also by Marty Kagan. And Marty Kagan in this case talks about this kind of organization, how to guarantee that each member of the team is empowered to deliver the whole capacity they have in their role. Very interesting read as well. And this is the end. Thank you very much. Maybe it was too fast, but probably you'll be able to rewind and see it again some of the parts. I hope it has been interesting, not too boring, and that you can use this as a reference foot for thought to maybe have new ideas on how to address some of these challenges that we're constantly facing when developing platforms. Thank you very much and hope to see you around. Bye-bye.