Paul Yokota, Director of Product at Animoto, discusses the role of intuition in product management, how to balance data with vision, and how to communicate decisions to key stakeholders.
Here are the highlights:
And here's the transcript:
Paul Yokota: I originally started out, actually, on the marketing side. My first job in tech was called a copywriter blogger. Nowadays, we would call that role kind of a content marketer. That's really what I was doing, but it wasn't called that at the time. And then I sort of through that process learned more and more about certain aspects of marketing, especially around SCO. I was in small startup at the time, and when we got to the point where it made sense for us to start having product managers, I had been, having spent a lot of time in the SCO world, which is kind of a marketing discipline that has one foot in the creative side and one foot in the technology side. I had been working with engineers on some of the technology requirements for that. It made sense and our CEO asking me if I'd like to step in that role, and that's where I first discovered product.
It's been something that's been a really great fit for me. I really enjoy the aspect of having a role that is fulfilling creatively and fulfilling from the analytical side as well, so I really appreciated the left brain, right brain split in the work that I do.
Mike Fishbein: I believe Paul is the first guest we've had on the show who began his career in content marketing. I wonder if and how that's played into his focus on intuition.
Paul Yokota: The way that I think about it, product intuition really has three components and those are empathy, taste, and experience. In terms of empathy, this is a word that get thrown around a lot, and I think a lot of times what we take that to mean is empathy is putting yourself in the role of the user of your product, such that you can kind of understand or anticipate how they're going to react to a feature that you put in front of them, and whether they'll be able to understand it, or whatnot, based on the context they have.
True empathy, from a product intuition perspective, really requires to go a level deeper, and that's really understand what your users goals are. There are a couple of different angles to look at the product and one of that is, what are your goals as a company and the person that's creating this product. There's also the goals of your user, and in reality it'll probably be several different types of users that are gonna have slightly different goals.
If you have a good product, there's gonna be a lot of overlap there, but there are ways in which those don't completely overlap. If you don't take the time to really understand what those are and aren't, then you don't really have the opportunity to be thoughtful and intentional about which choices and trade-offs you're making, versus against things that are your user's goals versus things that are your specific goals.
The way I think about it is, if you don't have those two pictures completely in your mind, it's kind of like trying to put together a puzzle with half the pieces just removed at random, whereas if you have both of those perspectives, then you can see all the pieces and you still might not choose to build everything. You still might only choose to put together half the puzzle and meet only certain of your user's goals that are aligned with what you're doing as a business, but at least you can put together ones that all fit together, rather than trying to force together things and having holes and things like that.
On top of that, I think the next component of product intuition is taste. I think we're all kind of familiar with the phrase that, "Design is not just how it looks, it's how it works." In some cases, there's a tendency in product to devise too far to the other end of that. I think that there really is things that you need to think through from [inaudible 00:04:32] point of view when it comes to product, and I think that really does have effects, both in terms of not just the understandability of your product, and whether users are gonna notice things and whether they're primary or secondary. But also, so what is the emotional impact or the emotional state that you're creating through the product in the way it's designed. I think a lot of times this gets raised in terms of delight or the interaction design layer, but I think it's really important for somebody to be able to have, as an input, to product intuition.
Then, finally, the third is experience. That's really in many ways being able to take those first two and build them up over time. Product intuition is not something that's innate. It's not something that you were either born with or you are born without, it's something that is a skill and as a result, it's something that you can build up your ability to do it over time.
Mike Fishbein: Paul emphasizes the increasingly popular perspective of the customer's job. What are they trying to accomplish with the product you're building? Until you know that, it's incredibly difficult to shape value, he says. What role does data play into this framework, and what are its limitations?
Paul Yokota: First of all, I just wanna make it clear that I don't think product intuition is in opposition to being data informed or using data to make decisions. I think it's another tool in the tool belt that should be used thoughtfully and in concert with data and metrics.
For example, creating a new product or a new feature, even if you've done all your homework and you really understand what the use and need is, there's actually quite a few different ways that you could choose to implement that, and even if you're gonna be testing it, choosing what the first thing or things that you're gonna be testing are, is a decision point.
I think having that product intuition that you can apply at that stage is something that allows you to avoid getting into analysis paralysis where you're either trying to do everything or trying to look at every possible option, and really gives you a heuristic for something that you can use to narrow down the options, and at least give you something to start from. It's very compatible with a lean approach to product development where it gives you a good starting point for something that you can build and then learn and iterate off of.
Mike Fishbein: Data is an invaluable component to the decision-making process, but it's not always possible to have all inputs needed to make a decision. That's where using intuition becomes important.
Paul Yokota: I think data and the intuition side will continue to fold on top of each other throughout the whole process of product development. I think once you have a product that's out in the market, and you have, for example, a signal that you're getting from the data that says maybe this feature isn't working so well for users, the data will give you the what is happening, but it won't give you the why. There's a lot that you need to do to get to that, in terms of getting complete picture of your user that will allow you to have that product intuition. You can't have that empathy if you're not watching your users try and use your product. You can't do it if you're not talking to your customers. Those are things that are requirements to be able to develop that skill, but having that skill in place and growing that over the course of fulfilling that set of user's needs, will give you the ability to take signals and turn them into solutions.
Mike Fishbein: Let's talk about how this intuition is developed over time. Presumably, there's a lot of customer interaction and many data points that go into forming it.
Paul Yokota: I think there's a number of types of data that are really important. For most products, there's specific usage metrics, so how much is this particular feature in your product getting used? Is that correlated with later product success, however that's defined in your product? There's also financial metrics that you'll need to pay attention to depending on what kind of model, whether it's a SaaS model or an e-commerce model, or whatever product you have that you're working on. Then, I think that there's data that's more qualitative that you look at as well, which is, for example, as I do customer interviews, I also sort of track what particular types of things come up repeatedly, just so I don't have an anecdotal memory of that, but I'm actually have sort of qualitative/quantitative view on, "Hey, this is the thing that's coming up the most unprompted from users." I think that's really an important type of metric to capture as well.
I think one good example of using data to inform this whole process is, a couple of years ago I was working on a mobile app called Mosaic, which is just a simple app to create photo books, at my last company. One of the things that you can do there is you pick your photos, you could've rearranged the order of your photos, and then you can simply just order your book. One thing we were hearing a lot from users is that they'd like to rearrange the order of their photos, which is one of the features that's available. We looked in the data and we saw that although this feature was available to them, very, very few people were actually using it.
This was a signal that was both sort of like quantitative and qualitative. It didn't tell us why this was happening, and where the product intuition part comes in, and where the empathy really needed to get applied was, we came to realize that the stage at which we were letting users rearrange their photos, that wasn't a goal of theirs at that point. We were coupling it to the selection of photos, so they were in a mindset of just choosing what would be the content of the book, but they didn't realize that they wanted to change the order of it until they actually saw the preview of the book and which phots would be across from each other on the same two-page spread and things like that. So that's the point where their goal became, "I want the order of these photos to be correct."
By taking that signal from the data and applying the product intuition, we were ale to move that feature into a place where it made more sense for the user and what their goals were at a specific point in the flow.
We took that and when there's a feature with low users, there's a lot of different options that you can do with it. You can do things like make it more prominent. You can just kind of decide, maybe, it isn't important at and get it out the way. It's really important to collect all the different types of information that you can about that to figure out what you think is the best way to move forward. Even through collecting all those signals, there's not gonna be some very clear path of like, "This is exactly what you should do." You need to have the ability to synthesize that, apply the experience that you've gained through knowing your customers, and really be able to come up with a solution.
What we ended up doing in that case was not just make it more prominent, but actually move it to a different step in the flow and actually make it its own step in the flow. We realized that users being able to rearrange the photos and have them in the correct order in their book was, actually, a critical thing to whether their book was good enough for them to purchase or not. So we made that something that the user had to do in between selecting their photos and getting to actually ordering it.
Mike Fishbein: Once a product manager has combined data and intuition to make a decision, how do they communicate to the team? Intuition seems like it wouldn't hold up in an argument to stakeholders and team members.
Paul Yokota: I think there's a couple key ways to keep the team on board and really believing in the mission that you're doing. I think there's ... having really clarity around where it is that we're trying to go, and to the extent that you can explain that in terms of we're really fulfilling goals that users have, that we can validate that we have, that we've heard from them, that we know that this is actually what they're trying to achieve, that's really something that people will be able to resonate with and will get behind. I think it's a lot harder to sell like, okay, users kinda wanna do this, but we have this slightly different version of it that we wanna encourage them to do, or limit them in such a way that they'll do, and I think that when you're delivering "This is what users want, and we're gonna get there. As a result, we're gonna be successful as a product," I think that's really great. I think what underlies that is really being able to back that up with what you know.
Product intuition isn't just something that gets pulled out of thin air. It's built up over exposure to your users, over conversation with your users, over watching your users and looking at the data that your users are generating in your product. That's where a lot of that comes from and so to the extent that if there's questions you've kind of done your homework and can answer those questions and know what it is that we've heard from users and like, "Yeah, I've talked to three users a week. Two of them always say this thing and always bring up this thing." Those kinds of things really make it clear what the mission is, that it's achievable, and that if we do what we're setting out to do then that will be a success for the product.
Mike Fishbein: Earlier, Paul stated that product intuition isn't something one is born with but is, instead, a learned trait. I asked him to explain how a product manager should go about acquiring it.
Paul Yokota: I think there's a couple things. One is just spend a lot of time with your users and finding out what your users are trying to do. I really encourage everybody to talk to their customers on a regular basis. I think it's really important to have just some kind of standing cadence for when you're talking to customers. There's a saying, "What gets scheduled get done," and it's really easy with all the things that are on our product manager's plate to let that slip and let it become a lower priority, especially at certain times when things are really busy and you're getting ready for a launch, or it's the holiday season and that's really an important time for your business.
Scheduling time to talk to users, I think, not just doing user research but being first person involved in that. Earlier in my career I would do a lot of running the usability tests myself. In my current company, we're lucky to have a great UX team that takes the lead on that, but I like to participate in the sessions when I can and for all of the usability sessions, not just look at the roll-up in the report and the findings, but actually watch the recordings myself. I think there's a lot of color and a lot of nuance that you get from actually hearing users describing their experience trying to use your product.
I think the other thing is to be very thoughtful about the experiences that you're experiencing as a user of products. I think all of us are using products constantly on a daily basis, and I think there's a lot that you can learn by taking a step back occasionally and putting on your PM hat and evaluating how is this product meeting my goals, what have they done well, what have they not done well, and using that as just more experience that you can use to build up your own product intuition.
Mike Fishbein: At the end of the day, talking to customers regularly is the first and most important step to developing intuition. Next up is the benchmark. Let's see hall Paul reflects on the next series of questions we ask all interviewees to ask themselves.
Paul Yokota: How do I eat my own dog food?
I think it's really important to follow all those practices that I talked about in terms of talking to your customers, participating in usability, but I think one example of where that's come into practice for me was at Animoto, our product is a video creation. So, there's things that you can put into that, photos, videos, and songs. We heard from a lot of users that they wanted to have more than one song in their video, so we added this concept of multi-song. But what that ended up causing was a situation where users would try to preview their video, having added a song but not put any photos or videos into it, so it was sort of this empty song state.
Originally, we rolled it out as this very conservative type of approach where it's like, hey, you're kind of in this weird state, go resolve it. You can remove the song, you can add stuff to the song, but it doesn't seem like you finished what you were doing, so we're not gonna show you a preview until you resolve that. That was really kind of a weird state for you to be in and through a number of channels, both quantitative and qualitative feedback, we found that maybe this isn't the right approach. So, we really took a step back and thought, "What is the users goal at this moment?" And it's really not making sure that their project isn't messed up or whatever. They really just wanted to see a preview of their video at that moment, so rather than having this long path where they have to go resolve something elsewhere in the UI and come back, we added a simple alert that says, "Hey, it seems like you have this empty song. We're gonna remove it from your preview." They click "okay", and with one click they're into watching their preview and still giving them the option to say, "No, I think I wanna go mess around with my video a bit more." But for the majority case like helping the user meet their goal as quickly as possible.
How do I get out of the office?
I think that there's a number of things. One is I'm a big believer in scheduling time for customer interviews. I like to have a block every Tuesday afternoon where that's when I'm talking to customer and by having that as a standing block, it actually makes it easier to schedule, which I think as a little tip is one of the things that tends to keep people from doing customer interviews, is that the scheduling of it is just really hard to get to. There's a lot of back-and-forths. Having that as a standing block gives you an easier way to make sure that you're doing it both from making time and space for it, and from the schedule with the people you're talking to point of view.
Another great thing is to make sure you're having regular communication with the other teams within your company that are talking to users on a regular basis. This could be your customer support team, if you have a sales team in your organization, really hearing from all the different angles, all the different teams within your company that are talking to customers through different lenses at different points in that customer's experience and really getting as much exposure to that as you can.
What am I reading right now?
I'm actually reading a book called The Advantage, and this is not directly about product, but is about organizational health and some of the things that leaders within organizations can do to make sure that organizational health is promoted and why that's so important and some of the benefits that you can get as a result.
A recurring product management nightmare that I have would be to wake up in the morning and realize that there's some kind of looming deadline that's been missed. I think as more of us have moved to lean and agile methodologies, we've kind of grown wary of deadlines to a great extent. Sometimes there's just things that have logistical reasons why they need to get done by a certain time. But I think my nightmare would be not being prepared and not having the plan in place to really address that properly.
Mike Fishbein: Listeners can find out more about Paul at paulyokota.com or at Paul_Yokota on Twitter. That's out show. Until next time, this is Mike Fishbein from Alpha.