Julie Zhuo: recommendation

Transcript context

…Something I also wanted to get your advice on. It's something that a lot of founders, especially, and even PMs come to me around is product review meetings and designer meetings, and I know you've run many, and so, I wanted to get your thoughts of just how should companies structure product review meetings or designer meetings, who should be in the room, how should they be set up. Any advice for folks that are trying to figure that out? I really believe that it's never a bad thing, it's always a better thing to have more feedback. Right? And so, often, I think you don't necessarily want to be like, "Oh, we have the one review meeting and that's the one in which we get everyone's opinions out and we make all these decisions, and then we're done." I think about product and feedback as just the more, the better. Right? And most people, again, everyone, especially with design, has an opinion to some degree, and so, all opinions are valid because they are a true opinion. The question is how do you then prioritize, how do you figure out what it is that you should do because we also can't... It isn't successful to try and do things by consensus. You're never going to get a group of people, smart people to agree about what is absolutely the best design. So, one principle is, okay, great. If you're going to have feedback on the product, more is better. Try and have different sessions with different groups of people. I would advise a designer, "Hey, go in, actually do a critique with a design audience, but go and then show this to the people who are most directly working on the product because they're going to have a different set of knowledge, but then go and see if you can find some people outside of your direct team who don't have as much bias on just knowing exactly how things work and then show them the user experience, and then go and actually see if you can find a group of target customers for who we're actually going to launch, and then run some user research sessions and get feedback. "They all are going to be valuable. They all might contradict each other to some degree, but the right answer isn't because we don't like disagreement, let's just go with one and then ignore the others. Everyone is going to have something to contribute to the product because everyone has that different perspective. So, again, lots of sessions, lots of user review sessions, awesome. Okay, but then there is an important job which is the synthesis of all of that feedback and a way of understanding what really matters. The way that I often think about this is we have to be absolutely clear on who is that target audience and what is the most important problem that we're trying to solve for them. Right? So, if you can get every group to align on this is who it is. Again, go and paint that very clear picture of the person, the problem, what it is that we're trying to help them with, and then what is most important. What is the job? I really love the jobs to be done for it, but what's the job that this particular feature or product is going to fulfill for that person? p them with, and then what is most important. What is the job? I really love the jobs to be done for it, but what's the job that this particular feature or product is going to fulfill for that person? Then it makes it easier for us to then start to categorize different buckets of feedback because the first thing that's most important to address is, well, is this thing actually valuable, is this solving the problem?, is it doing the job correctly, and if a lot of other stuff below is bad, but this is good, then we can move on to kind of the next most important thing. But if all the other stuff is maybe even good or interesting, but this is not there, then we should just actually disregard all the other stuff until we are quite certain that we've gotten the core value, we understand the user, this in some sense is addressing the core pain. And then once we do that, then let's focus on the next layer which I think about as ease of use. Right? So, okay, cool. We've figured out that we validated, this thing is valuable. It does solve the job. Now, is it easy to use? Are people confused? Are they getting hung up somewhere? Is it just really slow, so no one can use it because it just takes 10 seconds to load each time? Ease of use is just about can people access the value in a really great manner. That's the next most important bucket. And then finally, if it is valuable, it's easy to use, then I think we get into is it joyful to use, is it pleasurable, does it really exceed expectations, and I think that is the bar that we should aim for whenever we are creating products. Here, you might have debates about colors, or aesthetic properties, or animation and delight, and all of the other things that just make it that much more enjoyable and surprising and wonderful for the core audience. But you don't want to just focus on that and then lose, okay, actually, this thing wasn't valuable and it loaded in 10 seconds. Who cares about how great was the animation when the thing doesn't even load? So, I think there's a work to do to try and actually help the different pieces of feedback get synthesized so we understand what bucket they are and we can have the right order of prioritization to make sure we tackle the most important things first.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.