 Hi everyone. I will be talking about platform-based product development today and it'll be a brief introduction to the world of product managing platform products. Platform business is an incredibly rich area, starting from business models, platform strategy to the brass tacks of system architecture and design. But for this talk, I will focus on some tools and a framework that we can use to build platform features. Before I go into the details of the project, I will introduce myself. I'm Nithin. I live in San Francisco area. I'm father to Runa, a three-year-old girl who loves Spider-Man villains like Dr. Octopus and Venom. And I work as a principal product manager of web platforms at Atlassian. And our team is responsible for orchestrating the servers that host our marketing properties. We build tools for our scientists and developers to make the work so easier. I love travel graphic novels and particularly the work of French-Canadian graphic novelists named Guy Delio. And before we had Runa, I used to recreate brutalist buildings using Lego architecture studio and hope to get back to it at some point. Any great product usually has its root in unmet potential in the market. A lot of them start as solutions to problems and or as a hypothesis. But what makes platform products different? In my opinion, not much. Only the plays differ. And that's why I'm going to propose using the same frameworks that we use for traditional product development. And since our brains may only hold three or four things in our conscious memory, I will keep the strategic platform place to these three plays, which I think are important. One, identify the unmet need. Two, provide value creation as a service. Three, standardize processes so the value creation can happen at scale. So how do we identify unmet need? Platform strategy as a business model is something that is becoming ubiquitous. Every product has a platform strategy because of the potential created by large scale systems already in place, like web technologies or mobile ecosystems. But what tools can we use to uncover these needs? We often use this phrase on our team from pipes to platform. But what does that mean? How do we anticipate the needs and limitations of the customers we are serving? You must have by now heard it many times that our customers know what they want, but they often don't know what they need. The simple answer is research. We ask, we observe, and that leads us to the problem. The building blocks of a platform feature is deeply embedded in customer needs. They say platform PMs are not close to the customers, but that is a myth. So for example, the CDN and Edge network that Netflix has designed, essentially a platform feature, so we can watch content on congested networks on our mobile devices. Nothing can be farther from the truth that platform teams are not close to the customer problem. As PMs, we play the role of an ethnographer and experience life as our customers, so we deeply understand the problem domain. And this is a start of what I call the journey to product discovery. If you're familiar with agile and storytelling, this will resonate. We write scenarios. And what I mean by that is that we write and describe the action that our customers take or use in context. Our analysis from our research and observing current practices will give us a context to fully flesh out a scenario. Like in the movie business, they say, write what you know. The first step is to know. And this problem scenario as a technique helps us zero in on the problem area, find challenges, tasks, actors, and the root concept. It helps us identify the vision, rationales, stakeholders, and starting assumptions. One can use any number of methods. For instance, here is a storyboard that illustrates how Joe always finds himself late to meetings and how several individually insufficient factors causes failure to reach our time. These are minor factors, but in sequence they lead to a catastrophic result for Joe. So I will walk through a couple of example scenarios and how we can use them to identify the building blocks to find unmet needs. The goal is to evaluate the problem at a higher level of abstraction and express it like a story. So here's an example of a problem scenario. This is a little verbose, and most of these scenarios are pretty dense, so bear with me. Ron knew a site reliability engineer gets paced during the deployment of a web application. On investigating the logs, he sees a mini outage during the deployment, but certain users to the website were served an error message. This was a third time in a week that the monitoring service paged him during the deployment. He is anxious about the application's health and notices many errors in the logs, but these errors did not stop the application from getting built and deployed. There was an unusual number of errors in the logs, and there was no pattern to them. His immediate concern was to stop these outages. He suspects that the internal errors are causing outages during deployment. So be as detailed as you can be, paint a picture that will yield a rich set of building blocks. So here you see his mental state and the goal, which is to stop outages and the task, which is deploying the application. You see some artifacts like logs and task flows like the monitoring service identifying the outage and paging the engineer. In the next slide, this shows some of the announcements of weather events in different parts of the world where our offices are located. This is an introduction to a problem scenario that I will use as an example to flesh out a root concept. So here you see, you can see that there's typhoons in Manila causing power interruptions, fires in Northern California disrupting travel to the office, and these are only a small set of events that have disrupted operations at different locations. Just in the past three years, we've had six major negative events and I will use this problem to illustrate the problem scenario and then the steps we take. So here's a scenario for the disaster. A massive earthquake strikes the city of San Francisco. The Bay Area headquarters of a tech company located in the city is badly damaged and there is a power outage. The secondary systems have not come on and there's chaos all over. The incident managers on site in San Francisco cannot access any of the systems because of the damage to the networking infrastructure. The incident managers in Austin, Texas get notified of the disruption when multiple systems go down. In Austin, the incident managers send a notification to the mobile devices of all employees in San Francisco to confirm their safety. The systems do not log any responses. It has been 24 hours and still no answer from San Francisco personnel. The off steam in Austin waits for emergency responders and are glued to the TV. So those scenarios give us a rich abstraction of the problem and from here we set out to uncover critical information about actors, systems, experiences by creating, by using the problem scenario and creating the visual narrative. Frameworks like this, the journey map are beneficial and it helps in identifying who's doing what, thinking what, feeling what and using what tools and what touch points and the place they operate in, the time it takes. So you can build a very rich tapestry of and create this visual narrative and use it to summarize key insights and highlight areas of significant opportunity. A journey map is, you know, you probably are familiar with this and it's frequently used to improve customer journeys and reduce friction and it's associated with usability and interaction design. But workshopping your problem domain with engineering teams and design teams using these frameworks can provide an incredible amount of information and uncover insights. You should wholeheartedly adopt these frameworks on platform teams. So after parsing the problem scenario and creating a journey map, the following needs were identified. Mission critical systems need to have redundancy, a tool to coordinate and manage an incident. And but both these needs can be met with existing infrastructure. But the needs that were unmet are providing accurate and timely information to the employees and determining the whereabouts of missing employees and visitors and coordinating with local emergency response organizations. And this is this is evident because, you know, the primary infrastructure, the networking infrastructure is down because of a disaster. There is no way employees can hook into the internet backbone because it's just not operational. So that is a huge gap. And this is how we identify like the key missing pieces of functionality and that would, you know, make our employees life easier. And so from here, we can develop a rough design where we identify all the actors, internal and external systems and envision the flow of information to and fro from the system. So here's a root concept or concept of operations. The system meets the needs identified. In case of power and network loss, the incident manager on site in this instance, San Francisco cannot use a command and control. But the incident managers in Austin get notified of the disruption when multiple systems go down same scenario. The incident manager there in Austin sent a notification to all employees and to confirm the safety and simultaneously they send a message to the deployable mobile Wi-Fi service and to set it up in a predetermined area and the employees congregate around the mobile service for power and connect to Wi-Fi to access internal systems and the system logs the responses of the safety. So we've met the unmet need. For this exercise, there are four main subsystems that were envisioned. The command and control tool, which is a main situational awareness software, the mobile unit, which is a locale specific power generator that also provides temporary Wi-Fi access to the employees. The redundant data infrastructure is the replicated infrastructure that provides backup for command and control application and the wireless mesh subsystem, which provides an off-grid networking functionality for employees to be able to send and receive text messages and their geographic coordinates in case they are unable to use the regular networking infrastructure. In a sense, we have allocated those needs to these subsystems. Now here is where you will start to use the platform plays. We have a concept, but can we provide a way for other value creators to expand and extend functionality on top of the system? For instance, can we make it so that the ecosystem's participants see the value and produce and contribute? Here is where you get into the design phase and analyze what services will enable multiple participants in the ecosystem to interact. Here is the block diagram for the command and control software. Here the components within the command and control software are the event listener, which is a queuing service that listens to alerts and updates and sends it to the console software. And infrastructure monitoring software that receives health checks from the listener, parses it and sends it to the database. Alert configuration module to configure the thresholds for alerts. The geolocation parser that parses the stream of geolocation data received from the employees and sends it to the mapping software. Monitoring database which stores all the data collected. The mapping software is a visual display of the location of employees. The console software interfaces with the command and control operators. Web service that interfaces with external applications like the wireless mesh application and the communication service which interfaces with a chat tool. You can identify as many components as possible in this phase and figure out how data or information passes from one component to another. Here is an opportunity where we can design and plan for a system that can enable other participants to build features. What data can be transformed to provide meaningful information to the users of the system. Here is where you can start thinking about your API design and what services you want to expose so they can be exponential feature development given an opportunity. And coming to value creation at scale. This is the harder part. We moved to the prototyping phase from the design phase but we don't know if our hypothesis is right at an early stage. We haven't received feedback or don't have a signal from the market or the users. In this case, an approach to building where we standardize and modularize features would help keep the ecosystem open irrespective of the signals that we receive. And the general rule of thumb is loosely coupled. Don't make something that can be only used in one context. So creating microservices and standardizing some services like authentication, user onboarding, search and content and visioning them as services instead of features help keep these ecosystems scalable. It is a quicker path to value. We are designing and building inherently complex systems. We are combining digital and physical worlds into a unified experience. It is not about how we place our buttons in our apps or how we personalize experiences but how we envision entire ecosystems. It's more like science fiction world building that we are doing as platform designers. There's a great book, Sliven by Design. I highly recommend it. It talks about how we can make positive changes in how we eat by designing our physical spaces like our kitchens and restaurants. There are other examples out there where devices like wearables can motivate you to walk more. So when we design solutions, the intent is for changing behaviors for use cases. But at the same time, we have to relinquish control. For instance, the off-grid mobile internet solution is intended for disasters but finds a solution like a secondary use as a temporary network for events. How it operates within the ecosystem and how it evolves might be completely against the original idea but you have to be okay with that. Sometimes that is the true unmet need. And here, the goal is for the design is to enable capability and prevent our users from struggling. And that should be our not star that we should always try to reduce that cognitive load on the participants in our product universe and we have to make their lives easier. So what? And why should we care? It is because this is how we meant paradigms for the future. There are many flavors of problem and there might be something that you're struggling with now and could use a solution like that one product that your company has acquired who have written their code in Sumerian or a blackout because of fires, too much load on your application making it incredibly slow. Finding relevant communication where you've been tagged on Slack. Every day we deal with thousands of frustrations but find workarounds. But remember their opportunities to shape behaviors. To that end, we're constantly asking ourselves and reminding ourselves of opportunities. How do we automate this thing? How can we make this process faster and more efficient? How do we increase confidence in the data we are collecting? How do we make our sites faster and more performant? How do we better diagnose problems? So there are countless opportunities but what do we build? Where do we invest our time? That is the heart of our jobs as product managers to determine our investment strategy. Where do we invest our time? All the ethnographic research, problem scenarios, mapping, prototyping, it provides us with data to say, yes, we want to invest in this capability or sometimes it's not as straightforward. So we rely on running pilots or experiments. The only way you'll find any signal is by getting feedback and it takes a lot of effort but that effort is worth its weight in silver. So now what? It's really all about behaviors. When it comes down to the future and about systems and how it's designing our lives and our ecosystems, the behavioral changes is what we have to focus on and behavioral changes occur in a series of stages. Motivation is required for the focus, effort and energy needed for our customers to move through the stages of product adoption and usage and we have to facilitate these behavioral changes. Just building tools is not enough when motivating participants to realize value is key. Here is where you as a PM play the role of a coach, a trainer, develop these intrinsic motivations for our users. You have to become a salesman, a mean creator, a friend, a support engineer and through that journey, you will uncover more unmet needs and that is a continuing cycle. So before I leave, I want you to try these three things. Create a problem scenario and use that scenario to map a journey and create a concept of operations to meet those unmet needs and finally pick a product or software or device that you use and reflect on how it has changed the way you behave. If nothing, at least start thinking of your day and interactions as you go through your workday or your day and imagine your interactions as scenarios and start finding those negative feelings attached to those tasks and that will get you into the habit of using problem scenarios and with that, thank you all for your time and you can connect with me on my LinkedIn. My handle is Nipin Raghunath and all the best with those problems.