Alex Hood, Asana - Unpacking the Product Toolkit - How to Run Amazing Product Reviews

I need some trash I want to talk to you about product reviews. How many folks here are an individual contributor or run a team where you have to go to a product review with somebody else in your company? Okay, couple folks. And then how many folks actually run product reviews, like you're a leader and you are kind of seeing how things are moving through the pipeline? Get a couple folks here. Well, what I'm hoping to do is to share with you a playbook, a toolkit that makes these product reviews that much more powerful. Done poorly, product reviews can be something that slows work down, creates lack of clarity, and actually disengages teams. Done well, it can be an enormously collaborative activity between a leader and teams. So let's dive in. The goal for how leaders engage and how teams work in a product review is really two things: how do you speed up process, like how do you be even leaner, and then how do you innovate that much faster? That's probably the shared goal of the team and the leader running a product review. But if you've ever participated in this kind of thing, there's a lot of reasons that this can go wrong. If anybody's participated in a product review where a ton hasn't worked out that well, shout out why that happened. Give a sense. Very shy people here. What's that? Yeah, okay, so maybe like trying to do too much, lack of clarity of what we're actually trying to accomplish. That's the most important. Anything else? Yeah, lots of opinions, right? Lots of opinions that might actually be grounded in something like a customer insight. That stinks. So yeah, when I kind of see product reviews fail, interactions between leaders and product teams fail, it's usually because there's a lack of clarity. And what that looks like is a breakdown because clarity really drives velocity and innovation. And I'm going to break that down into a few spots. In the product review done well, there's a lot of clarity on where the team is in that specific moment in time. Secondly, there's clarity on expectations between a leader and a team of what the leader is expecting walking into the room and what the team is expecting to show so that I can get a good decision to speed up their pace. There's clarity on fidelity: what the heck am I actually looking at, and is this raw thinking or is this the final product? There's lack of clarity around feedback and actions: if I do get a bunch of opinions, do I have to actually act on it or can I just ignore it? And then lastly, the clarity on what the leader's role is when they're actually running a product review. There's some things that make them go terribly, some things that make them go well. And I say all this from two perspectives. One is from the leader's perspective: you can drive velocity, you can create innovation collaborating with your team, and you can also build capability on your team because product reviews can be a fantastic coaching tool. But also if you're a person who has to present, if you're a person who is showing the CEO your stuff, this little toolkit that we're going to explain is a great way to set the stage, maybe even teach them how they should be interacting with you. You're creating your product. So I'm going to go into each of these. Clarity on where the team is. I've seen many times teams come in and they're really early, but some of the things that they show make a leader think that they're kind of further along, and there's a mismatch. There's all kind of questions that are like, 'Yeah, have you thought about this? Have you thought about this? Maybe solution, solution, solution.' But really the team is like just gotten some of their research started. So clarity on where the team is kind of matters. And this is the product sequence that we use at Asana. It's called the Double Diamond. Anybody ever heard of it before? It's human-centered design. And basically there's a couple cool things about it. First is you talk about the pains before the solutions. All good products start this way. Also, it's got some diverging lines and some converging lines, and those represent the efforts to go broad, understand pains really super well, and then go narrow to really narrow in on a specific pain point for a specific target customer you're going to solve well. Then go broad and brainstorm all possible solutions so you don't leave anything on the table, and then narrow in on an MVP or v1 that you ship and then iterate. But there's a lot of span in there, and you could have a mismatch that would make a product review really poorly if you're not clear. So I actually, for the longer projects that run on our team, maybe a six-month project, these are the times that teams check in with me. I want to see when they've figured out and worried about the pain, when they've identified a target customer, when they're in their spec as they're designing the product, and then I want to be the quality bar as they start to launch. Kind of seems like a bunch of things, but if you're talking about a six-month project, it's not really that many check-ins. And leaders on my team combine some of these sometimes. But the key here is that we have a shared language of where teams are. Teams sign up with me and they say, 'Hey, I'm at solutions kickoff right now.' Fantastic. I know exactly what that means. I'm going to share that with you. That's clarity on expectations for each place. Now that we've said we're in spec review or in design review, I set expectations. I publish ahead of time what I'm expecting teams to come in with. That makes for a very rich conversation, and it also teaches teams how to build good product because I've already articulated what the thinking is I expect from them. Now what that looks like is, hey, here's Asana. Does anybody use Asana here? Ah, hey, that's great to see. So here's Asana, just super quick. It's a tool for teams who are sick of tracking progress in spreadsheets and then going and counting noses on all the status of people and what they're doing, and then creating a spreadsheet or a PowerPoint slide about it, and then going to a status meeting that sucks, and then having to throw away all that work at the end because the status meeting and the PowerPoint is already out of date. Asana helps you understand who's doing what by when. It gives you a lot of clarity around all the pieces that are coming together for a project, and it's just a better way of running projects and how teams work together. So that's my Asana ad. Here's Asana. But you notice here these section headers. That's the spaces in the product toolkit that I laid out. And in each of these, I've pre-published the questions that I'm going to ask the team when they come in and see me. I've also published some tools and tactics, some templates that they could use, and I show previous examples of when teams have cranked it out of the park. It's now a learning tool for teams to do great work. So for example, you can see in the key questions that I published in each side of each one of these, and I'll go through them with just a touch of detail. Here's another tactic around really being clear around expectations. This is like the simplest, dumbest slide possible, but it's enormously powerful. Most teams get off the rails when building product because they forget what they signed up to do, or their team is misaligned around what they signed up to do, or there's a lack of clarity between them and the leader. The leader's mind might have moved on. So if you kind of start out with product review with something as easy as this, your one sentence: 'Imagine a world where your customer pain' — which to me is 'I am a blank who's trying to blank but can't because blank, which makes me feel blank' — compartmentalize customer pain point that's unique. Then a 'from to': what's our plan with some timelines, and then metric that we're going to move. I used to work in distributed development in Mountain View at Intuit. We had over RPMs and all of our engineers from Bangalore. It would warm my heart when I go to Bangalore and I'd actually see this printed out and sometimes laminated on engineers' desks, because it meant that they had real strong clarity on the most important things about a project. So super simple tool. So here's one that's filled out for this feature we just shipped last week called Workload. Let's talk a little bit more about that. All right, so discovery debrief. That's when a team has gone broad on the pains, and these are the questions that they know that I'll be asking about this research. Same when we've identified the target customer, these are the questions that they know I'll be asking, so it drives the conversation. Same with the solution kickoff: what is our vision, how are we starting to think about positioning? With a spec review: what are we going to ship in what order, what's it roughly going to look like? For a design review: what have we learned, what are the trade-offs and pitfalls in the user experience? And then for a launch review: how does this actually come together, what are the important things that we're leaving off the table, what didn't we ship that customers aren't going to be so happy about? And this is where I get to hold the quality bar for the teams. Did we really deliver on the things that we said we were going to deliver? So by pre-publishing the questions that I'm going to ask, I'm able to set the table around expectations along the whole product journey. Cool. All right, clarity on fidelity. There are some really amazing design tools out there that make things look really perfect even when they're not. Things like Figma, InDesign. Dan mentioned Balsamiq is a way to get around that because it makes your designs look on purpose cruddy. But most designers I know, they just want to work in the high-fidelity tools that they have, even if the thinking isn't high fidelity. So you get into a situation where your designer comes in, they just kind of knocked this out an hour before the meeting, but it's shown in super high fidelity. That causes a cognitive dissonance or disconnect between a leader and a team. So when we do design reviews, we first talk about the fidelity meter. The fidelity is like, 'Hey, how far along are you in the actual thinking, and then how good are these visuals? Should I be giving pixel-level feedback right now, or is this just kind of conceptual?' Okay, that helps. That's probably the strongest tool to make design reviews really, really fruitful. Clarity on feedback and actions. So when you're working with a team on product, there are a lot of opinions. There's a lot of opinions in the room, a lot of unanswered questions, places you want to nudge the teams, places where teams want to seek your advice. But sometimes the conversations are rich in the room, but it's really unclear what you should do afterwards. So here's the model that we use at Asana. It's called Do, Try, and Consider. Do means do. I use very few of those because it's top-down directive. Teams are closer to the customer pain than I am. Try is I really want you to try. I really want you to spend a couple hours thinking through this problem, and I want to hear back. And then consider is I've got this random idea, you can just follow up in Asana, hit me up with a task or a comment, and let me know if that idea is stupid, but spend two minutes on it. And by categorizing this feedback, these are the notes that we actually take inside of Asana for a launch review. It's very clear what the expectations are and what the follow-up is, and then I don't need to nag folks about how we actually completed the action items. It's really clear what the expectations are, and I can actually see all the work that's happening as a result of this time we shared together. Hey, you know, another part of this is the leader's role. The leader who is running a product review can waste a lot of time and energy on the team. So the leader has a pretty unique role in the room for a product review. The first thing I'd say is if you're a leader and you're really trying to engage, like how well did we deliver on this customer benefit that we were solving for, how great is the product, are we making the right decisions, you can very quickly run out of time by talking about process. So I wouldn't let any process stuff enter the room. Talk only about content. And in Asana, we do that because we track our high-level company objectives. There's ten of them, but then you can drill into what each product project team is actually working on. So here's our first experience, our new user experience team. They just update their OKRs, they update their plans inside Asana, and I read these, and then I don't have to ask where we are, and we can just dive in, talk about design, and not talk about how we can accelerate milestones. Know what I mean? The second thing is gardening. So I have a fairly, you know, for the Valley, a fairly large product team. We have about 25 designers, about 25 PMs, and we have a leadership level. What product reviews helped me do is build capability around leadership on the team. I call this gardening. So we have a product review, we take a look at the work. The work is the best evidence of how well the team is actually performing and functioning. And afterwards, we get together for 15 or 20 minutes. They're like, 'How did that actually go? Why was that designer not saying the same thing as the PM? What's the disconnect there? Why aren't we making a connection between this and this other thing that the company's doing? Why is this team working in a silo?' Gardening is how we work together as a team to group problem-solve, make teams more collaborative, and I can coach based on exactly what we just saw. So that what we call our pillar leads, the product leaders, are better able to coach their teams on the actual product deliverables. So we're able to do that by examining the body of work we just saw in the product review. Second is the product leader has a big role here in inspiring teams to do great work. And if a product team kind of walks out of a product review and they're not charged up, then the leader has failed. I know Steve Jobs had this mantra about being a super tough guy and swearing and making people feel bad. In my experience, that almost never works. That never just gets to a great result. Even if there are some things that we're missing that you expected, really your job is to put wind in the sails of teams. So it's like, 'Man, you're working on a really important customer problem, and the vision that you've got for your product is really, really inspiring. I'm personally inspired by it because I felt that pain point before. But I think there's a couple of things that are in our way of achieving the best we could possibly be. It seems like these couple of things about our design are as refined as they could be, and I'd love to get a couple more customer insights around how we're tackling this problem.' Instead of like, 'The design sucks and you guys don't know what you're talking about.' The inspiration point, I just, you know, that is a force multiplier for a leader who's running a product review to get teams to perform really well. So that's my view of how clarity of expectations, leadership role, process, what you should do in the room versus not, how they actually drive better results for customers. And this is our process that we use, but you know, you can have your own, and it's great to define what that actually is. I just wanted to share how this worked for a feature we just shipped on August 1st. It's called Workload. When we spun up this team, we said, 'Hey, create a tool for managers to be able to better distribute work across their teams.' And if the team had just gone and rocked on that, then we would have created a cruddy tool. But because we put pain before the solution, because we did some deep customer research, because we looked at the problem together in product review, we discovered some amazing things. Like, you know what? The biggest pain point isn't actually about the manager. It's about the employee. A bigger pain point than a manager not being able to distribute work is employee burnout. You know, 80% of employees, we sent a survey after we got some of these insights, felt burnt out in the last six months. And employees who are burnt out leave their jobs. Also, 93% of folks who we surveyed said that they're more efficient at their job than their peers. There's a lack of clarity and transparency across teams of who's doing what by when and how much output is actually being done. That's a big problem. That was a great discovery along the way. So that discovery made us design the feature differently than the first mandate. And then we actually in design reviews thought a lot about these waves. The UI here is articulated by how many tasks or how many hours people are working. And I wanted to work with the team. We just thought about the waves of life at work. You know, you've got times where you're having real struggles with work-life balance, then you've got troughs maybe where you're bored, you've got times where you're way decked out in terms of how much you could accomplish and other folks on your team aren't doing as much, and how that actually feels. And then we created a UI construct where a manager can drag and drop different tasks and validate and redistribute amongst their team, and the waves start to decrease in size of their peaks and troughs in the UI, solving the customer pain that we decided was the bigger pain around burnout. That all happened because we collaborated well in product reviews and we discovered these great things together, and we didn't waste a lot of time on process. So for me, great product reviews are really effective when you've got a process and you know what you're talking about each time. It's very clear what you expect as a leader, and when teams come in, they've done the rigorous thinking ahead of time so you can dive in. It's clear what fidelity you're actually looking at, which is a danger right now given the design tools that are out there. You're clear on expectations around feedback: do, try, consider. And then the leader is really clear on their role about using product reviews as a great way to coach and a great way to inspire. I'm open for questions. Thank you very, very much. I need some traction. You need some traction. Let's get some traction.