Going From 1 To 10: Figuring Out What To Build After Achieving Product-Market Fit

Yuhki Yamashita at UXDX Community: UK. Video: https://youtu.be/SjWxIDmnivM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A career spent after product-market fit

[00:00:04] Thank you UXDX for having me, and for everyone who's tuning in. I am going to be talking today about how to figure out what to build after achieving product market fit, and I call this going from one to ten as opposed to going from zero to one. We just heard a bunch of tips from Kathy on how to do remote work, and one tip I have is, if you have the deck that someone else is presenting on hand, it's really nice to have your own version so you can flip ahead or go back. So I posted this deck that I'm about to present at figma.com/@yuhki[?], so feel free to follow along there as well.

[00:00:49] So with that I'm going to go right in and tell you a little bit about myself and my journey around one to ten. In the startup world we often talk about that journey from zero to one, and it's often romanticized because it's actually really hard to go from zero to one, and very few people are able to take something from scratch and bring it to something that has product market fit. And while I would love to say that I would have spent a lot of time helping things go from zero to one, actually my entire career has been the point after that, after the product has found great product market fit.

[00:01:26] I started, right out of college, working on this product Hotmail. And while some could argue that this is a journey of one to zero, it was nevertheless a product with a lot of different users. This is something we realized when we were porting over Hotmail to outlook.com: there were about 400 million active accounts, so Hotmail was in fact a product that was far beyond product market fit by the time we'd switched it over.

[00:01:52] After Hotmail I moved over to YouTube, down from Seattle to the Bay Area, and I was responsible for the YouTube app on iOS. And at the time we had this really audacious goal to have one billion hours of YouTube watched every single day, and this seemed like a crazy goal at the time, but soon enough thereafter we hit this goal. And again, YouTube is an example of a product that is far beyond product market fit at this point.

[00:02:23] After YouTube I moved over to Uber and was responsible for the app for riders on Uber. And here too we were dealing with some really astronomical numbers: 10 million trips[?] worldwide, nearly a hundred million riders and eaters, millions of drivers. And then even most recently I moved over to Figma about a year ago, and at Figma we work on the tool for people to design collaboratively and in real-time. And even at Figma we have thousands of customers like Twitter, like Microsoft, like Google and Slack, who are relying on the tool to run their product design and development process. So Figma is maybe the closest example to one, but it's something that has already found product market fit.

[00:03:13] But despite being in these companies that have already gone past zero to one, I've been really lucky, because the leaders of these companies aren't just settling for going from one to two, they're really thinking about something much bigger. YouTube, the company had its eye on disrupting cable. Uber, it wasn't just about disrupting car ownership, it was about becoming the logistics platform for entire cities. And at Figma, we're not happy just to make the tool for designers, we actually want to make design accessible to absolutely everyone.

Who this talk is for

[00:03:47] So this is the journey I want to talk to you about today, that journey from one to ten, what to do after you've found product market fit. And in particular I want to talk a little bit about who specifically this talk is for. This talk is for people who work on products whose business is doing really well by every measure: by engagement, by revenue, user count. Your product is loved by many. I got some tweets about Figma a little while back, and my favorite one is actually on the bottom right, which is someone tweeting about how they're using Figma in their Tesla, on that screen at the front. And this is kind of the most classically San Franciscan thing you could ever imagine, and we hope to god that the driver was parked when they were using it. But it does give you a sense of the fandom that we often see.

[00:04:37] But it also has to be that your product is bursting at the seams a little bit. So this is a screenshot of the Uber app when I first arrived, and as you can see down here, it was literally bursting at the seams. This is a screenshot of, I believe, Chicago. They had a promotion of Uber Eats, UberRUSH was a courier service at the time, and a bunch of different products, and you literally couldn't add any more to this.

[00:05:02] And finally the requirement would be that your users still want more. Every single day we get a bunch of feature requests on Twitter and different forums for more functionality, a lot of feedback. And this is the dilemma that you have. If you have so much customer feedback, you have to decide what to do with it. Some of them become ideas to build, many of them are ideas you have to discard and say no to.

[00:05:28] And this is how I'm going to structure the talk today: talk a little bit about how customer feedback turns into a decision making process around how to decide which of them is important. If it's important you decide to build it, if it's not you just have to say no. And so the three parts of the talk: first is how do you decide which feedback is important in the first place? After you decide that some things are important, how do you get all these good ideas built, because surely there's too many things to build? And then probably the hardest part, how do you actually say no to your customers who are giving you these feedback requests, because most of the time you do have to say this?

Getting the feedback that goes unheard

[00:06:09] So I'm going to dive right in, first on how you decide which feedback is important. It's really tempting to just have this magical formula where you can pump some feature requests or feedback through and hope that it spits out something that tells you whether to work on it or not. And this is a good formula in terms of figuring out reach, impact, your confidence for that impact, and all divided by the level of effort, and use that to stack rank your products or your feature requests. But the reality is that it's not that simple, and I want to tell you a little bit about how to think about the broader picture.

[00:06:44] So my first tip, ironically, is actually to get more feedback, and specifically to seek out the feedback that's unheard. I was recently looking at the Uber app and trying to figure out how to give feedback, and it took me at least seven taps to get to a point where I could actually enter some custom feedback. I have no right to complain here because I was part of designing this, but it did remind me of how much work and effort it actually takes to get feedback. And whether that's in the form of a customer support ticket or whether it's in the form of a tweet, there's a lot of effort that's needed. I almost assume that for every piece of feedback a user gives you, there exists a hundred more that are never shared just because of the level of effort.

[00:07:29] And this is a perspective that we took at Uber when we were first working on the driver app redesign. And this was a challenging time for Uber, back in 2017 when we were embarking on what we called 180 Days of Change, because we had lost so much of our drivers' trust and we wanted to make sure that we could win it back. And as part of this, as we were doing a redesign and rethink of the driver experience, we did everything we can to collect feedback, especially the feedback that's unheard.

[00:08:02] So a few examples of what we did. We took drivers out for lunch, and other than being a casual setting, this turned out to be really effective because we brought groups of drivers together, and the kind of conversations that happen are often something like realizing that the issue that they thought was unique to them was something that was shared. And oftentimes what we found was drivers had feedback, were problems, but they thought they were more a reflection of how they used the product rather than being useful. And people related to this idea that, oh, you had that issue too, I thought it was my fault. And this clearly shows that this is a kind of feedback that no one would write in about, because they assumed that it was their own problem.

[00:08:38] Another thing we did was observe our users using the product in situ, and in our case this was riding along, sitting alongside the driver and observing them. And this is really important because there's a lot of things that go unspoken. As drivers are driving, things happen, there's things in their body language as they react to things, but also things are happening so fast, and it's quite dangerous, they don't have time to give feedback in that moment, or they forget about it by the time the trip's over.

[00:09:08] And one of the things we found from this particular method was the piece of feedback around app crashes versus app freezes. We found the surprising insight that drivers would rather the app crashed than the app freeze. And the reason for this was simple actually, which is that when an app crashes all you have to do is relaunch it, but when an app freezes you have to take your hand off the steering wheel and actually force quit the app and then relaunch it. And this helped us understand that we should be focused on freeze rates rather than crash rates, which is something that we changed our focus to, and that's something that we wouldn't have figured out if we hadn't been there and observed drivers.

[00:09:47] We even had these WhatsApp threads with a bunch of drivers, where drivers had direct connections with employees, and this is a really great way to get a lot of casual feedback and also get a lot of screenshots that were annotated. So whenever the drivers thought of something, they would send these along. So all these are really examples of ways in which you can go and collect feedback from your users and listen to those who aren't just part of the vocal minority.

Watching how users hack your product

[00:10:11] The second tip I have around this is paying special attention to not just the feedback that users are giving, but the ways in which they're behaving. Oftentimes users who really feel passionately about a problem actually hack your product in order to achieve their use cases. So I'll give you a small example. When you launch Figma it looks kind of like this, and you see an overview of all the files that you've recently touched. And in particular there's this thumbnail of what the file looks like, and the way that this is created is by taking the first page and we just fit all your designs into one screenshot and make it a thumbnail of the file.

[00:11:00] And one of the things you might notice is that this screenshot, this overview, if there are a hundred screens that you're designing in a file, then it's really hard to tell just from this thumbnail what this file is about. So this is actually not that helpful in deciding whether you need to open it or not. So one of the hacks that we started seeing users do was instead for them to split up this file in an unconventional and slightly inconvenient way, where page one was just a small design and page two was the entirety of the other designs. And what that results in is allowing users to create a thumbnail that looks like this, which is much more informative and much more beautiful.

[00:11:38] So this led us to understand that users really care about how their design is represented, to help them understand which files to open in the first place. And this is something that we've productized afterwards, because we realized it was so important to users.

[00:11:57] Another bigger example is this one, where it was a group of designers and engineers up in Seattle who created this product called Figma Plus. And note this is nothing, not officially made by Figma. It was basically just a wrapper around Figma to allow people to build extensions on top of it, kind of Chrome extension style, and things like a lot of different features that Figma didn't offer. Jackie and his team made a framework to allow people to build on top of Figma. And it's pretty crazy because Jackie and his team, they all have full-time jobs, and yet during the nights and weekends they created this thing because they felt so passionately that these problems needed to be solved.

[00:12:37] Thankfully we were in parallel working on an official way to build plugins, and so by the time we launched we were able to partner with Jackie directly to showcase some of the use cases that he had initially built unofficially and now officially. But it was a really great signal for us because we could tell that users really wanted this, because they're spending so much time doing it. So that was a little bit about user product hacks.

Features as currency, and insights as strategy

[00:13:01] The next tip is about this idea that it's really important to translate feature requests into problems, but also to recognize features as currency. So this is a little bit like PM 101 here, but when your users give you a feature request, of course you have to back out the problem. And the reason backing out the underlying user problem is important is because once you understand that user problem you can actually come up with a bunch of different alternative solutions, and maybe one of them is better than the feature request that was originally given. So that's why this process is important.

[00:13:35] But it is also important to remember that, in my experience, when a lot of consumers are trying to make a choice between products, features are still their currency. We found that Uber drivers might choose Uber over Lyft or vice versa because of that one feature. So this is all to say, not to over index on that, but to remember that features are a form of currency used for comparison. And in fact users will never give you credit for having to find the right user problem. What they want to see is a solution that they can relate to.

[00:14:10] And then the last thing around deciding what's important is really understanding that user feedback isn't the only input. The question of whether you decide whether user feedback is important to act on is really a question of strategy, and my philosophy on strategy is that strategy always begins with insights. And in particular this is my framework around insights. There are many different types of insights. There are insights around your customer, one of which is their existing users' needs, which is sourced probably by the feedback that you're getting from your users. But there's also prospective user needs, and there's also behaviors of users that you're seeing in your data, and that all comprises customer insights.

[00:14:53] But beyond customer insights there's business insights about your revenue opportunities, growth leverage, cost drivers, and even outside of that the macro environment insights, like industry trends and what your competitors are doing. And this collectively is the set of insights that you want to be acting on. And the user feedback that you're getting is an important part, but one of many.

Code isn't the only way to build

[00:15:13] All right, so we talked a little bit about how to decide what's important to act on, and chances are you decide a bunch of things are really important and you probably don't have the resources to build all of them. So the following are some tips on how to get all that done.

[00:15:32] And the first thing is a lesson I learned at Uber, which is to remember that code isn't the only way to build. Uber is a tech company but at the same time they have a world-class ops organization, and the ops team takes this perspective that their tools for building are actually SQL queries and email. So when we were working on Uber Pool, someone had the idea that it could be cool if we get passengers to actually walk to main corridors of the city to basically save everyone some time. So the hypothesis was, if everyone walked a little to a common avenue, if you will, then there would be fewer detours for everyone, it would be much more efficient.

[00:16:11] And while the product team was trying to figure out how to make that work within the product and how they would implement the back end for it, the ops team just sent this targeted email and they just sent it to riders and promised them lower average wait times if they walked over to Polk Street. And while we eventually productized this properly, this gave us a lot of initial signal around demand, or things that weren't working, or routes that were most effective. And it was a really nice way to accelerate product development.

[00:16:41] Another example I really like is this one. So Uber has this feature where if you order an UberX but we actually find an Uber Pool that can get there just as fast, because you're the last in first out, so that was the kind of internal name, LIFO, last in first out, then we would give you the opportunity to take a discount and get onto the Uber Pool ride. The hypothesis being that people are choosing UberX not because they don't want to share the ride but because they don't like the detour.

[00:17:08] But when we first implemented this, what we did is design a screen like this, which asks you if you want to take a shared ride or not. And then what happened when people said yes, join a shared ride, is, in the back end we did nothing. We just sent in the UberX anyway, and then at the end of the day the ops team would run a query to figure out who had said yes, share a ride, and just issue them a refund. And this was a way for us to quickly get an idea of what the demand was like, but also to experiment with what kind of pricing incentives would work to compel users to actually take Uber Pool instead. So again, this is not the way you can build all products, but part of what takes time in building products is validating the idea in the first place and iterating on it, and there are many other tools available for you to do that.

Your users, and your competitors, can build for you

[00:17:58] The second tip here is that not only can you build it, your users can build it for you too. One of the things about Figma is we still lack some of these basic features like spell check and bullet point lists, and it's painful for me to say that, but at the same time the reality is there's so much we have to do and this always ends up getting deprioritized. One of the things we realized was, what if we could build a platform that could enable people to build these kinds of features in the first place?

[00:18:31] So as I said earlier, we had published this mechanism for creating plugins on our platform, and our hypothesis, or our principle, was that if you can code a web page with basic HTML or JavaScript you can go and build a plugin, and we wanted to make it as simple as possible. And one of the things after we launched we found was that people did in fact create the spell checker plugin and the bullet point plugin, and these remain some of the most used plugins today.

[00:18:59] And we even found some other use cases. This one is a favorite of mine, called Mapsicle, and it allows you to just quickly insert a map into a Figma file inline. And this streamlines the workflow of opening up Google Maps, panning around, screenshotting, and maybe if you made a mistake you have to go in and edit it again. But this is exactly the kind of feature that's super powerful but we would never build, because it's so bespoke. And this is what we saw the ecosystem do. Since our launch about eight, nine months ago, we've had over 500 plugins of various different use cases, and the way I like to think about this retrospectively is that we were able to crowdsource our feature development.

[00:19:41] And the last tip I have on this front is that not only can your users build for you, your competitors can build for you too. And this is deliberately a little bit provocative, but this is something that I learned when I was at Uber. When you think about competitors it's really easy to fear them, even though you're supposed to say that competition is good and it's great for all of us. In a day-to-day way it's actually hard to internalize that. But if you instead think about your competitors as another R&D arm that's able to run experiments on your behalf, it's a pretty liberating thought.

[00:20:16] And that's what we did at Uber. Oftentimes Lyft would be ahead of us in shipping some features, like they were ahead of us in shipping scheduled rides or subscriptions. And while that can be alarming and create a lot of urgency, it was really nice for us to be able to see how they were implementing this, because there's a lot of choices you have to make, and at least by seeing how things are evolving in their products we were able to learn from it and adapt when we brought out our own versions. And these are just as, if not more, effective than our own experiments.

[00:20:50] And this isn't to say that Lyft did this alone[?]. We tested a bunch of things, thrown pickups[?] and things like shuttles, and Lyft followed suit, and so this is a mutual thing. I will say one of the most interesting things about this was when we observed that Lyft had run an experiment and then a month later they shut it down, and that was a really strong signal for us that maybe something about that didn't work and we shouldn't pursue it either. So this is all to say, again, this is not a way you can build products, but in terms of validating a lot of these concepts, your competitors can help you out in this way as well.

How to say no

[00:21:25] And then the last thing I want to talk about is possibly the most difficult part of all this, which is the reality that a lot of the feature requests that you get you have to say no to, and this will be for the majority of feature requests. And being, myself, Japanese, I can only empathize with how hard it is to actually say no. Saying no is so hard for Japanese people, but the governor of Tokyo, Shintaro Ishihara, actually wrote a book called The Japan That Can Say No, which is this rallying cry that Japan as a nation can in fact say no.

[00:21:59] And actually one of my favorite business phrases in Japanese is this one, "my own mechanic and those from us"[?], which in English approximately translates to, we'll optimistically consider this. And this is a response you'd give when someone in a business context asks you for something, but in reality what this actually just means is, sorry, no, we can't do this. It's code for that. And this is not me advocating for you going back to users and telling them that you'll optimistically consider every feature request you get, but this is rather acknowledging how hard it is. Entire nations find it really hard to say no, so it is in fact something that we all can empathize with.

[00:22:34] But my tip around here is just to not be afraid to share process. Sometimes if you're a little bit more vulnerable in the open, you can win a lot of your users' empathy, and it softens the blow in saying no. And the way I like to think about this is to think about the different ways in which you can treat your users. So one extreme is to treat them as a stat, and when someone comes in with a feature request you basically tell them, hey, sorry, only 0.01 percent of our customers have your problem. And while this might be sound product thinking if you're talking internally, no customer wants to hear this. They don't want to be reduced to a stat, their need is still important to them, and this leaves a really bad aftertaste.

[00:23:19] The other extreme of this is to treat your customer as king, and this is actually a phrase used often, and you tell them that every feature request is a brilliant idea and you'll get going and build it right away[?]. But the reality is that you can't do that, you're over promising and you're going to erode trust eventually as well.

[00:23:40] So where you have to win, I believe, is somewhere in between, is to treat them as an equal, as a peer. And if you can make them feel like they're respected but also bring them along for the journey and an understanding of your decision making process, then they can really feel like they were heard and understand where you're coming from.

[00:23:59] And so, ways in which we do this at Figma: a lot of our designers like to talk about the process behind all the features that we build. And so Marcin[?] here is a designer and he recently tweeted about all the things that went into a recent feature launch, and this helped people understand that even the smallest of features have a lot of fine details, and build a little bit more empathy for building these things, as simple as they seemed on the surface. And our product leader at the company[?] tweeted a little bit about our product development process, and this was a really well-received tweet, and one of the reasons for this was that in the eyes of our customer the team building this was humanized and all of a sudden we are building a lot of empathy.

[00:24:44] And I'll give you a more practical example. Sometimes you're in a sales conversation and you have someone giving you a lot of feature requests, and there are different ways in which this conversation can unfold. So the bad example is this one, where someone asks you, when are you building feature X, and you say, we're not prioritizing that at the moment but we'll put it on our backlog. Right, that's like classic PM speak. It allows a possibility that you'll get to it later but it's basically saying no, we're not doing that. But the problem with this response is it just opens you up to other types of feature requests. What about feature Y, feature Z? And you're going to give the same response over and over again, and it'll seem kind of like a black box. It feels robotic and really hard to relate to.

[00:25:29] So then what I see a lot of people do is do something a tiny bit better, which is, when people ask you, when are you building feature X, yeah, this is another classic PM trick, you say, well, interesting, tell me a little bit more about your problem and why you want that feature. And so the customer opens up and tells you all the reasons, and at the end of it you're still saying, well, thanks, that's helpful context, but we're still not prioritizing it at the moment, we'll put it in our backlog. So the customer feels like you were able to understand a little bit, but at the end of the day you're not really reacting to them in the way that they want.

[00:26:02] And still what I found successful is a conversation that looks like this, and this is something I've done with a lot of Figma customers. When they ask, when are you building feature X, be just upfront with them and say, we're not planning to build that right now, but let me share our priorities and framework for how we make our decisions, and would love your feedback on it. And I've been surprised, oftentimes they've come back and said, I see, oh yeah, definitely, prioritize that other stuff first, maybe let's talk about my feature later, but I get those priorities, that makes sense to me. Or if that outcome is that they disagree with your prioritization framework, that's exactly the kind of thing you want feedback on.

[00:26:45] Because the whole purpose of this is actually to just elevate the conversation from individual features to the prioritization and framework, or the philosophy. And this is really important because if you're always talking at the level of features it's an endless conversation, right? They'll just continue to talk about different features and you'll never be able to proceed. You need to be able to talk about something a little bit higher level.

[00:27:06] But also, as much as I said earlier that features are a form of currency, at the end of the day you don't want to be getting into a state where you're in a feature battle with your competitors, because it's really impossible to always have more features than your competitors. And what customers are really buying is your philosophy, your prioritization framework and the team. And if you can convince them that those things are sound, those are the reasons that they actually are purchasing your product, over individual features. So that's why leveling this conversation is important.

[00:27:36] So in summary, this is my talk, thinking a little bit about how to decide which feedback is important in the first place, some tips on how you get all those things built, and a tip around how you say no. And again, this talk is available in the Figma community, it's actually a Figma file, so feel free to use it, remix it however you like. And I'd love to hear your questions and feedback. Thank you again for tuning in.