 Hello and welcome everybody. To succeed as a product manager, one must be able to articulate their version of the future, establish shared understanding and rally the troops to get it done. So today I'm going to do a walkthrough of the product canvas and show you how to supercharge your squad to build and ship. I hope you will find something useful. My name is Christine Sue. I'm a product person who loves problems. Right now, I lead the international product team at Tulio, working out what it takes to offer truly localized products and experiences to our international customers. Previously, I was head of product at a startup called Novastone, an instant messaging platform for financial services. Before that, I spent over a decade in investment banks, building digital products for clients and productivity tools for sales. I have been fortunate enough to have worked in Sydney, Australia, Hong Kong and I'm now London based. I'm thrilled to be here today and thank you for tuning in. Here is our agenda for today. We'll start with why, then I'll go through a scenario. We'll then do a product canvas walkthrough. I'll give you tips on how to get the most value out of it before we wrap up. If you've been to my previous talk, you know I love studying with why. It's my favorite question. You are probably all too young to remember this, but my career started before product management was a thing. Now, some roles might have evolved over time, but the idea never gets old. This still gives me a chuckle every time. Have you ever played the telephone game or the Chinese whisper? It's a popular game building exercise where you line up in a room, the first person passes a message to the second person in line and it keeps getting passed on through a whisper. You find out at the end how that message has changed. The nature of the PM role requires you to be working with many other functions. Those in your squad, engineers, architects, UX designers, data analysts and those outside of your squad, sales and marketing, customer success, support, legal, finance, to name a few. With such a large service area, there is little surprise that communication is a core PM skill. When I talk to PMs earlier in their careers, there appears to be a bias towards honing their verbal communication on more narrowly presentation skills while written communication takes a back seat. In reality, PMs need to be well-rounded communicators to be successful and cannot just be a rockstar presenter who writes nothing down. Consider this scenario. You're working on a mobile app that lets users track and understand their carbon footprint. The app offers advice on how to minimize it by helping users change their habits. The app has just launched into beta with a set of core features. There have been many app downloads but you notice the big drop-off at the sign-up step. You dig in, you look at App Store reviews, you talk to a bunch of users, then you realize it is because your sign-up flow is funky. So users are easily discouraged and most of them just give up. You compare a few options to optimize that flow, research a bunch more to validate your thinking. In the end, you decide to add a Google sign-in option along with the existing user credential one. So you add a ticket in general with this subject. Integrate Google sign-in. Voila. You've written it down. You're done. Or are you? Adds backlog grooming. The UX designer asks, so why are we doing this? Are we replacing the existing sign-in option or keeping both? How might users discover the two options? Do we prefer one over another? Your engineer asks, can one user sign-up with both options? What happens if they do? Do we keep two profiles? With so many questions, you decide to discuss it over a meeting. At the meeting, you talk through the funnel drop-offs that you saw, the research you performed, the other options that you considered, and disqualified for XYZ reasons. You'll leave the meeting on the same page, feeling confident that this can be done in the current sprint. An hour after you leave the meeting, you start getting reports of app crashes. You drop what you were working on to troubleshoot and eventually find out there is a deadlock in the backend code. Your CEO has a demo with investors next week. So you have no choice but to prioritize the bug fix. The bug fix ends up taking three days, cutting it really close to the investor demo. Luckily, the demo goes well. Your CEO returns with loads of feature feedback and asks for them to be prioritized immediately. So again, you reach out for your tickets, but now you won't get to the Google ticket until three sprints later. Fast forward to five weeks later at Sprint Planning. The Google ticket gets picked up. It gets assigned to another engineer who wasn't at your earlier meeting. He asks the same questions. Only this time, you can't remember why you picked Google over Facebook sign-in. So, you tell him, let me get back to you. And then of course, since you walked out of that discussion, some other crisis happens and you never actually get a chance to look at the data again. All of a sudden, the quarter is over. You still haven't delivered anything that optimizes your sign-up flow. In fact, at this point, you're struggling to remember why you even created the Google ticket in the first place. Now, this was a made-up scenario, but one that sadly resembles a real life. There is actually a simple fix. Write it down. I trust you all work with brilliant professionals who are experts at their jobs, have high standards and like to be proud of their work. When you have a team like that, the best thing a PM can do is to provide context, make trade-off decisions, and then get out of their way. So builders can build. Trust me, you won't have time to be repeating the same information over and over and over again. You want to do everything really well once. This includes the signal you picked up from looking at your product metrics, the user research conversations you had, the market research you did to identify and compare options, and the reasoning behind your choice in the end. Writing just a single line in JIRA takes away all the hard work you put in. When you provide context, the work scales itself, and your team is empowered to make good decisions, even in your absence, because they understand why. This is where product canvas comes in, is a template I've used before. Let's go through the sections quickly. You will notice up top it says cross-functional canvas. Yes, that is a key point to highlight, because this canvas is for your whole squad, including PMs, designers, engineers. These green boxes are owned by the PM with inputs from UX and engineering, and they aim to answer the why and the what questions. Ticket reference is where your JIRA link goes, or whatever system you use. Sometimes, for one canvas, you might end up with more than one ticket. We use initiatives to articulate our high-level outcomes or goals. For the story I told, sign-up flow optimization to a conversion rate of X% might be what goes in there. User story, this should be pretty straightforward. It's your bread and butter. However, if you ever catch yourself writing, as a user, I want feature A so that I can use feature A. Please, just dot. That is wrong on so many levels. Usually, we are good at defining what is in scope, but sometimes it is more useful to call out explicitly what is out to make sure everyone has the same understanding. The currents and desires states give you a clear view over what's happening now and how you'd like it to function and look instead. So some heavy PM UX collaboration here. For the designs, it might simply be a Figma or a sketch link. The solutions section is to capture options considered, disqualified, and selected, and very crucially, the why. This is where your whole squad should contribute, acceptance criteria. This is so important and underrated. Think of them as how you would test. Acceptance criteria should be statements that, when tested, would result in a clear pass or fail state. For my app scenario, one I can think of is, given I am a logged out user, when I launch the app, then I am shown two sign-in options, Google and user credentials. Now, if you are working on an API, you might want to specify quantifiable metrics such as response time, throughput rate, uptime, et cetera. Documentation, of course. As a product leader, I always tell my team to consider how they tell our user about the bug fix, enhancement or feature, before they build it. If you can succinctly explain or articulate the user value in release notes format, please go back and think harder about why you're doing it at all. Now, user documentation can take many different forms, and it does not always mean writing one piece. If you are working on a B2B product, then a reasonable amount of user guide is typically expected by your customers. Now, if you're working on developer products, then high quality and complete documentation is essential. And if, in fact, differentiate you from your competition, the next sections, the blue boxes, are owned by your engineering team. These are questions that need to be answered at the technical analysis base. Now, the how. Your involvement here would be later, but still essential. I won't be going through these in detail. So, what does the workflow look like? How do you use the product canvas with your squad? The way I have used it with my team is that a product manager would lead, and they would fill out the template from the top. You don't need to fill in everything before asking for feedback within your team. As soon as you've written your user story and scope, get it reviewed. This is to ensure you've framed the problem and understood the why correctly before investing more time into solutioning. Now, taking this iterative approach may seem counterintuitive at first glance. It's just one sentence, you may think, but a well-framed problem is half the solution that one sentence can be a lot harder to write than you expect. It should make you think deeply and express accurately. If you fail to articulate the user value to appear, that's a pretty strong indication that you either don't understand the problem or it might not be a problem worth solving. Once the product section, i.e. the green boxes are all filled in, get it reviewed by your team. Be open-minded when discussing. I would also strongly recommend not making a selection for the solution too early, especially when you don't yet understand the effort involved. All possible solutions should be documented and you can knock down your order of preference, but resist committing yourself to a single one prematurely. The next step is something I truly enjoy. We call it Canvas Review. This is the first time your whole squad comes together and you as the PM present the product section to the audience. The floor is then open for questions, so be ready to provide answers. Even though you'll be talking through it live, share the Canvas ahead of time and ask that everyone review it before the session. That will save you time to set, having to set context, leaving more time for questions, debates, and decisions. By the end of the Canvas Review, you should leave with a clear sense of which solution is preferred with input from product, UX, and engineering. At this point, engineering should start their technical analysis. Another Canvas Review should take place at the end of that phase. This time led by the engineer. At the end, everyone should leave with answers to their questions and the team should have made the necessary decisions to start building. Review, debate, and decide together is the overarching theme here. After both Canvas Reviews, make sure you add the answers and decisions onto the Canvas so that they don't come up again later. Now, just a quick aside. In some agile teams, this whole process is wrapped into backlog grooming. While team ceremonies might differ, the intent is the same. So don't get hung up about terminology. Now, let's recall the scenario I shared earlier. Had you created a product Canvas and followed the process, you should not have to worry about context switching or priority reshuffles because your team should be able to pick it back up whenever with the full history. So, how do you get value out of the product Canvas? I want to reiterate the product Canvas I shared with you was a template. As with any template, the value is maximized only when it works for you, not the other way around. This template worked well when I led a cross-functional team building a SAS app, but needs some tweak in my current role, building a developer platform. Do not be constrained by the form. Tweak where you need to be. Just remember, this is a document owned by everyone in your squad, so get by in and consensus before you implement a change. Have those healthy debates with strong opinions held lightly. Remember this. To wrap things up, the takeaway from today's session are, 1. Write it down. 2. Review, debate and decide together. 3. Make it work for you, not the other way around. And that concludes everything I had to share today. I'd love to hear your thoughts and continue the conversation. So, hit me up on LinkedIn. Thank you for your time.