 Hi everyone, I'm Christiana Sagupta. I'm a product lead at Compass. Today I'll be talking about moving from vision to experience. A little bit about me is I've worked at a few different stages of companies, early stage, growth stage and Fortune 100. I've also worked across different types of external customers from Fintech to small business tools, to communication and lead gen, and for internal customers, I've also worked on platforms for APIs, data sources, and ML models. To get into the discussion topic for today, the problem statement I'm going after is, at your best as a PM, you're trying to build the most impactful things for your company. But this is inherently hard because it's difficult to figure out what that problem is, and I'll categorize that as a quality problem. Secondly, it's difficult to bring in your stakeholders. They're along for the journey and helping you co-create a solution, so you're not just a one-man team. This also helps when you run into roadblocks or new obstacles that you didn't anticipate. You've now got people along for the ride who are committed to solving a problem for their product, not your product because they were part of that solutioning and problem definition process. So at every step of the product process, you can see that there's a quality problem, which largely is, if you're going after a big problem, depending on just yourself to figure out what that problem is, what the solution is, how to scope it down, how to deliver it efficiently, and then what to do next. That's a lot of load on just one person, and it's unlikely with the very big problem that you'll be able to rely on just one person. The second problem in the product process is that if you don't have a clear way to go through this process to make decisions, then you're going to have a lot of opinion wrangling. You'll have a lot of opinions, no clear criteria moving forward, and so people will lose confidence in the decisions that are made and in many cases, they'll disagree with them. So these are the problems for solving impactful products. What do you do about it? Well, for the quality, it's pretty obvious which is, you tap into the knowledge of the people that know the problem best, and those that are really good at solutioning. That includes design, engineering, data science operations, it can also include customer support, since they're often seeing these frontline problems with customers. On the consensus side, there's a similar solution which is, you need to facilitate getting people aligned and bought into the decisions that are made. If you solve these problems, the quality and consensus problem, you can really go after the big impactful problems, and have a team dynamic that helps you overcome the inevitable obstacles. Two of the greatest guys in product talk about this. Marty Kagan talks largely about the quality issue, and how engineers as one example of a stakeholder and collaboration group can really make your quality much higher, and Shreya's though she talks about the quality piece, but he also talks indirectly about the consensus piece making you the facilitator of a great discussion, so people understand what's being done and why. These are the high-level things that should be done. What do you actually do? How do you operationalize these? The four key components that I'm going to talk about, and this is one way to do this, but you may find a better way. These are things that have worked for me. You're providing as a PM to get that quality and consensus, a logical sequence so people understand how one decision flows to the next, clear decision-making criteria for the key decisions. These can be amended, but you at least are coming with the initial material, so people understand why they picked A versus B. Third, you're bringing the data to guide these decisions, and this is important because it's your job to make sure the decisions are right, and you need to marshal all the resources you can get to help the group make decisions on what to do. Finally, you're doing this through collaboration sessions. It can be async, it can be at the same time as well, virtual in-person, but you are making these collaboration sessions work so you make informed decisions. With these four components, you can already see there's going to be some trade-offs, there may be some pitfalls here, so I'll call them out. You are still accountable even with more participation for the decisions that are made. The buck still stops with you, but that's probably why you want this job. You want the ownership. Second, even though you've got people who you can bring into this process, they've got day jobs and they need to figure out what they can contribute very quickly, and you need to make that very clear, and it takes some reps to get good at this, but this collaboration process has to be efficient, otherwise it'll be a huge time suck, and your end result may not actually be any better than if you've done it yourself. Third, you'll hear many product leaders talk about this, but consensus is usually a myth. You should try to get a good group of the key decision-makers aligned to the approach that you're taking, but you can't satisfy everyone. However, there's a spectrum here. Instead of just jamming through what you think should be done and maybe getting one key stakeholder to sign off, but everyone else disagrees, if at least you bring them into this process, you'll probably satisfy at least a few of them, and even those that you don't will understand how you came to your decision. And finally, this is a lot of work for you. The distinction is that it's work upfront before you've spent a lot of money on scarce resources like engineering and data science, but as a result, you do less work and less expensive things on the backend by addressing the pain points, solutions, the lean MVP upfront. This also helps you avoid a lot of the politicking that often drives product decisions, where you just listen to the person who's got the highest title or who's got the loudest voice. Instead here, there's other rationale for why you make certain decisions. So with those caveats, what are the benefits of this? Better problem definition. You'll understand what problem you're trying to solve for what customer in better resolution than if you just done it yourself. You'll also have better solutions because you've got people who are really good at solutioning. You should be as well, but you've got a lot of help in the form of design and engineering, as well as customer support and ops that might have had these ideas from working with customers and hearing about these pain points for years. Third, you've got buy-in from your collaborators because they're part of the problem definition solutioning process. Instead of them saying, well, I told you this was a problem, you didn't listen to me, we just decided to do whatever you wanted to do. When something goes wrong, now they're part of that process and they feel more ownership and they support the decisions. Maybe not all of them, maybe not fully, but in that spectrum, a lot closer to what you want. And finally, this process gets your team and you get it the key thing for any product team, which is you've got to constantly solve problems collaboratively. If you rely on one person, that single point of failure for all the decisions, all the solutioning, it's probably not a big enough problem and you're probably not solving it well. By practicing this method to do the initial problem definition, solutioning and delivery, you're gonna get good at that thing that you've got to do continuously. It's a cycle. And what should this feel like for you and your team? Instead of looking like one guy's in the corner doing all the work and when things don't work out, he's frustrated because he feels like it's all on him. Meanwhile, the rest of his team is standing there waiting for the ball, wondering why they're not being given the opportunity to shine. Instead, you can do what MJ did, which is put the onus, not just on himself, involve others in the process, let them develop their skills. You've got to have good teammates, of course, but if you share some of this process and hitting the winning shot in some cases, you can win a lot more because now you've got fewer single points of failure. You've got more people involved and most importantly, you've got a team. This is a team sport. However, remember in the caveat section that you are still the pusher, the orchestrator, the conductor. You have also got to do the work because you're often relying on them, engineering, design, data science, to do really hard things. You've got to do the work that shows them that they should have confidence in what you're doing, the decisions that you're making. There's a lot of work for you to do and if you don't show that you're doing that work to that level, they're gonna be less invested to do their work. All right, so let's get into the overall process and I'm going to drill deeper on each of these five phases but high level at every one of these phases, we'll talk about what the goal is. For example, in phase one, picking a problem to solve, then we'll get into the process which is the second key thing you're bringing is the process here and the decision-making criteria. Next, we'll get into what you're bringing. What are you bringing to this step? It's usually data. And finally, how do you facilitate these collaboration sessions? So this format gets into the key things that you're doing which is a clear process, decision-making criteria, bringing data and then making it easy for others to give their input by creating collaboration sessions. So keep in mind that this is one process. These are some deliverables, these are some criteria and these are some facilitation sessions. You can pick whichever ones work for your team but you should have at the core of what you're doing these four things. And by doing this, the high level goal is get higher quality by bringing others into the decision-making with data that you're bringing to the discussion. Align them on the approach. Not all of them, not every time but more so than if you done it all yourself and show your thinking. So even if you make the wrong decision people understand why after the fact and they feel ownership to help solve it. Okay, so phase one is about picking a problem to solve. And here an overview is that there's a process and a decision-making criteria. In this case, it's a journey map with pain points so we know what problems customers have and how we can solve them potentially. And then how we prioritize it. So there's two key collaboration sessions here. There's a journey map process where you're going through the customer journey and identifying the pain points. And secondly, there's a ROI calculation so you can prioritize these pain points. And what you're bringing to the journey map is you're bringing through customer interviews, surveys, actual customer usage, market research, some kind of data backing, what those steps are, what those pain points are. And in the collaboration session, you're editing that, you're letting others create their version and combine it. And in the likely ROI session, you're bringing the key thing of product that you can figure out in this value versus effort which is what's the direct business value. And in the session, you'll go and you'll edit that initial draft that you have of the ROI for different pain points that you prioritize. So let's get into the first collaboration session. This is about the customer journey map and pain points. Again, what you're bringing is the data to say, here's the journey that I believe most of our customers have and here's the pain points and here's some data points to inform how I came to this. So you're bringing this prepared journey map and a workshop script so others can then participate and to blow out what you would actually do in a session. In this example, this is about grocery shopping based on customer usage, based on market research, based on some surveys and some actual qualitative analysis. You can give an hypothesis for what the steps are and what customers are feeling, what their pain points are. And during the session, others through sticky notes, it can be a literally a Google Word doc where you're doing this. Mural and Mural are great whiteboarding tools that let people collaborate. You'll let others see what you put out there and the data points you're using to inform that. They can create their own journey map in their own section. You can combine it or they can directly contribute to yours. You can have a voting system, Mural has that built in. You can create an easy voting system on a Google doc otherwise. And then finally, you come to some consensus. Now this isn't easy, it takes practice but there's a lot of facilitation sessions and guides that you can lean on to make this process easier. Once you've got these pain points then the next collaboration opportunity is about likely ROI. And here, likely ROI is one way to prioritize pain points and what you're bringing to this is your reasoning for why one pain point is more valuable to solve than others. And specifically the piece that you're contributing that's your job and a few others will have the level of expertise or the responsibility to do this is the direct value that you're creating. If we look at what likely ROI is with some ways to classify value versus effort, you're bringing the direct product value. You're also likely bringing in this example for real estate agents, if your problem is that real estate agents don't have enough leads, one potential way to solve that is recommending directly to them who those leads are. But you've got to figure out first what is the alignment with the company strategy? Because even if a project has high direct business value, if it's misaligned with the company strategy, for example, if your company does not wanna provide leads to agents because it makes less money, if instead they want to qualify those leads and give the highest quality leads to those agents for increased price, then you're gonna be running at odds with the company strategy. And as a PM, one of your key things is to look up and make sure that what you're doing doesn't conflict with the overall company strategy. So that's the judgment call that you should be able to make and the direct product value is something that you can also try to quantify with some assumptions, some kind of model, you bring this to the equation. And even if it's not a dollar value, if it's a high, medium, low categorization, that's helpful. And for value, you can also think more broadly in this group discussion about other value. For example, if you're using data for this solution, is that data potentially reusable for another type of product that the company has? Or if you're building a component like a payment system for this, is that reusable for something else that the company can do? So you've got that broader view to allow you to quantify value in a way that's different from the other stakeholders. Then you've got the likelihood of success. And this is a judgment call as a team that you have to make. You've got to lean on your product intuition. You can also lean on your operations teams, as well as your designers to figure out, will customers actually have this pain point solved or is it too difficult to solve? And then you can give some high, medium, low ranking of that likelihood. That's why it's a likely ROI. You don't know what the ROI is, but you're making some prediction about how likely you are to realize this value. And on the investment, this is where your partners are really coming to this session and adding a lot of value. On the engineering side, they've got estimates in their head for what will it take to build the data required for this and the front end, even if you don't have mocks at this phase, you can usually classify it as high, medium, low. And on the data science side, if there's some kind of prediction that needs to be made, your data scientists can think at this early phase, even about the level of effort because they might have solved adjacent problems. And at the end of this, you're classifying each potential pain point that you're solving with some ROI categorization. It can be high, medium, low. It can be more in depth or less in depth, but it gives you some way to prioritize your pain points. So now we've gotten out of the problem definition and pain point step. We've identified a main pain point to go and solve. And we're figuring out what's the goal? How do we know if we've solved this pain point? And here we can use the North Star metric. Again, it's one way to look at how we measure the problem that we're trying to solve and if we've solved it effectively. But the North Star metric in this case is a useful framework. And there is a inbuilt collaboration session here, which is a session to bring data as the PM, help people really hone in on the value you're providing to your customers and then jointly figure out what is that North Star metric? And again, into an example here for Spotify. Spotify at the beginning had a general problem that they wanted to solve, which was that people didn't have access to music they wanted to listen to easily and affordably. And they were thinking about the North Star metric. So even though the long-term goal they had was to make money, to get revenue from monthly subscriptions, that wasn't their North Star metric. That's a lagging indicator and it doesn't represent the value to customers that's the value of the business. The North Star metric, which they could see initially soon after the product was launched was, is this solving the core problem of customers? Which is to listen to music they like easily and time spent is one way to capture that value. So that's a North Star metric. What you bring to this discussion is that customer empathy piece, thinking about the value you're providing in the customer's own words. And make sure you validate that with the rest of the team in this session. The next piece is the input metrics. And here it really helps to have other people involved in this process because the input metrics are how you impact the North Star metric. And you may not know all different ways to impact that but engineers and data scientists are usually really good at thinking about those kinds of things. So I found those groups especially valuable. And if you're thinking about input metrics as you're facilitating this session, North Star has a few categories of things that can help guide you but you can create your own categories. In this case, three ways to categorize the input metrics that are impacting the North Star metric are usage that's the engagement piece, breath, how many people are using it and then the frequency of engagement. So if you can impact those three things, those are the variables that will impact the North Star metric, which is the dependent variable time spent listening. So in this session again, you're bringing the data but you're letting others ideate with you on how you define your North Star metric and then how you influence it with these input metrics. So now you've got a goal with the metric and some input metrics that you can actually impact. You're ready to get started on the solutioning now. And the solutioning phase is a lot more in depth. It can be done quickly, but there's a few steps here. You can skip some of them but your solution might not directly fit the pain point that you wanna solve. So this step, the solutioning step starts off with looking at those input metrics. For example, in the Spotify example, if they wanted to change the frequency of engagement, that was the dependent variable they wanna change because that's what will impact ultimate minutes spent listening to music. Well, then your job with your solution is to figure out how to move that input metric. How do we make people engage with the product more often? And there's lots of solutions. You can do it through in-app experiences. You can do it through notifications. You can do it through text. There's different ways to solve that problem but you need to have a hypothesis that you can test that says, if I do X, Y, which is the input metric, we'll move and you should do that with data. So your job at this first step that we'll get into is to bring the data high level. Once you've gotten past those hypotheses, you actually prioritize them, then you will pick one that you think has the most impact and is feasible to test. You'll create a journey for what that experience looks like to solve that problem and move to sketches. So that's the overall goal of solutioning and let's get into the collaboration sessions specifically. So the first session is about creating hypotheses that are testable that move those input metrics. And what you're bringing to this is some ideas about what those are. So in this session, you can see that as a PM, you've got user research, you've got some industry data and the business analysis, you've got some user data potentially in the data analysis piece and you're bringing some guesses about how you can move this input metric. So in this example, you've got a decision made by customers on what type of account to apply for. And there's lots of different user research saying why customers are applying for the wrong account. Ultimately, as a PM in this case, you've brought a few different hypotheses and the one that you settle on as a team based on the data is that if we make the eligibility instead of a long form that people read and then self-select which account to actually apply for, if instead we make that interactive and make it a question and answer format, then people will have higher precision in choosing the right account. So that's a hypothesis about how to move this metric of people applying for the right account. But you don't wanna just come with one hypothesis, you wanna come with many and that's where this session benefits from you having some ideas, but then showing the core data you're using to make these hypotheses so others can add theirs to it. And Mirol has great session on this, Miro does as well, but there's a lot of different ways to do this. Now that you've got these hypotheses, you gotta translate it to an experience. So here's where the journey map again comes into play and you're bringing to this journey map. For example, if you're saying that you wanna interactive question and answer format or in this example here, we've got coffee, making sure you've got coffee orders that others can benefit from in your office. The future state journey map here is something that ties into your hypothesis. In this copy example, that hypothesis is that if you notify people 15 minutes before you go to get coffee and you give them a small time window to reply in, you can get a lot of people responding. They'll become used to that type of interaction through a text and notification app. So that's a hypothesis that you've got and now you've gotta translate it to a journey and what you're bringing to this session, the future state journey map is ideas about what this looks like. So that can be from the words of customers that you've heard. It can be from frontline support that have had this idea before. It can be from a similar experience on similar apps or a completely different app that solves a similar problem in a way that you think is ingenious. So you're bringing some ideas about what this future state journey could be like, but just as we did with the initial journey with pain points, others can look at your data and create their own future state journey. And in this session, you can then come together and pick the overall journey that you think is the highest likelihood of solving that pain point and testing that hypothesis. So now you've got the journey, the next step to make this something that you can actually deliver is what this looks like. And here you can start with lo-fi sketches. Some PMs feel nervous about this. They feel like it's something that should be totally owned by the designer and you can do it that way, but again, to add value to bring something that others can then riff off of, it's helpful to look at that hypothesis, look at that future state journey, and then create some sketches, look at other apps that have had the same experience, think about improvements to it, but something as simple as paper sketches that you take a picture of can be what primes this discussion. And in the collaboration session now, you've just got a lo-fi sketch, others can sketch themselves, they can modify your sketch if you have some interactive tool, and then you agree on what this actual experience is gonna look like. So now we've gotten out of our solution phase, we've got a sketch of what this looks like, but we need to create some requirements for it. And that's one of the key things that PMs do, we don't need to get into requirements in great depth, but the collaboration piece here is that you're coming with a set of queer requirements, you're taking that sketch and thinking about, well, how do I operationalize this? What is needed in terms of performance? How many users am I actually rolling this out to? What do I need in terms of latency? How quickly do they need to see the data that we're giving them? All of the key things that you have in a requirement doc. And the collaborations part of this is that you're then working not just with your engineers, but your designers and potentially your data scientists to say, okay, here's the requirements, how much time will it take me? And here there's a push and pull, many people do this completely async. And I find that's not really helpful because you wanna go back and forth. If the level of effort is too high, you need to go back and say, okay, how can I pair down the requirements in ways that'll shave time off design and development, but still test my key hypothesis and still enable that future state journey. What's the least that I have to do to test that hypothesis and enable that journey? So I'm solving the pain point. And then you should go back and pair it with this paired down requirements doc. See how much time that shapes off. And if you can do that synchronously in a collaboration session, you can get to that really quickly, but it does take some practice. So now you've got your MVP defined with a level of effort and some kind of sequencing. What do you decide to do next? And this is the final phase. And you'll see this is a cycle. We're gonna keep testing hypotheses. We're gonna keep delivering something that tests those in the weanest way possible. We're gonna get feedback. And that's what this step is about. It's about getting that feedback. And here you bring a lot of value. You're gonna bring that qualitative feedback to understand the why customers are doing things. You're gonna bring that quantitative feedback. What are customers doing? You're gonna bring usage data. You're gonna bring some industry comps, all the things that help you make this decision about, did I prove my hypothesis or not? And up front, you'll have some success criteria for saying that the hypothesis was proven or not that goes in your requirements doc. Once you have the data, you need to make this decision. It will be a judgment call in those cases and not clear and resounding. You can have a couple of different iterations. If it's clear, the hypothesis was wrong and either your solution wasn't the right solution or somewhere in the journey, you've got the steps wrong. You need to go back, see if you need to revise your experience or see if you need to revise your hypothesis. And in some cases, you may find that we can't move this input metric with this hypothesis. We need to either select a different input metric or a completely different hypothesis. That's if things don't go as you expected. If things are going swimmingly and you've hit all the success criteria to exit out of this phase and skill, you still wanna go back to that future state journey map and make sure that when you scale this to more users and you've gotten out of this pilot stage where there might be higher expectations, the journey is more refined and you might need to change that future state journey which then changes your sketches and your requirements or you may find that you need to scale operational staff. You need to basically make a judgment call about how does this product need to change if I scale it and then you repeat that process over and over again. So these five phases defining a problem, finding a solution, figuring out how to test that solution, building that MVP and then using the feedback we get from the test to make a decision on what to do next, you're gonna keep repeating that in some way throughout the entire product process for any product. And so at this phase, you're still doing all the collaboration sessions but go back to the previous sections to see exactly what those are. So in summary, the problem we're going after that this discussion was about was building the most impactful things and addressing two of the biggest challenges for doing this which is the quality piece, problem definition, solutioning, designing a lean MVP, delivering it. And then consensus, bringing people along for the ride and making sure that they're part of this process. So even if they don't agree with it, they understand why it was made and they feel some sense of ownership. In some cases, they may even be a big part of that solution and problem definition. And one solution here was to bring other people into it so you get higher quality and more consensus. There may be other ways to do it but I think this really hits on the key things that PMs bring which is logical decision-making, a sequence of actions that lead to a result that people have confidence in. Decision-making criteria, each of those key points when you can go in a couple of different directions. The third piece, the data to make sure you've got good decisions that are made that people have confidence in. And finally, the facilitation skill bringing all these different stakeholders in to make informed decisions and doing that efficiently. None of this is easy as said, but it's worth it. And it hits that core thing that great product teams have which is problem solving at speed. And the problems you solve can get much harder and harder as you build up this core skill. Thanks for your time. Look forward to your comments and suggestions and please connect with me on LinkedIn. Thanks.