Building better products with intentional experiments with FYI’s Hiten Shah
Customer Conversations
0:00
0:00

Full episode transcript -

0:0

Hello and welcome to the customer conversations podcast. Today I'm so excited to be joined by the incredible Heat. And Shah he It is a prolific SAS founder of companies like Kiss Metrics and Crazy AG. There's no working on F Y. I also runs product habits, tell other founders, developed the habits they need for success. Thanks so much for joining me. Thanks for having me. Course. Of course. I'm really excited to dive into all things products and specifically of how, uh, how customers influenced the products that we built. Um, so but maybe for for those who don't know, um,

I'm not sure there's too many of those people you can sort of share a little bit about what you're working on right now with the F. Y I and sort of how you have you got to this point. Yeah, We had my co founder Marie and I had a couple sort of failed attempts in the document space, and they were sort of like things we created because we thought they should exist where we didn't do enough early sort of validation, and the signs were good in a bunch of areas. But then we kept coming back to this one problem over and over again. And so at some point we just step back after those two failed attempts and said, Like What? What is it that we are missing? And what we were missing is solving a frequent, painful problem for people. And so these days I think about frequency, pain and urgency. And so, with F Y I.

What we do is we help you find your document no matter where they are. And that's either documents or files, whatever you wanna call it, so we'll help you find them. If they're on your computer will help you find them if they're in any cloud service and we do it in a way that's very different than just providing you with a search box. And so that's That's the short of it, Um, and the way we discovered it is by stepping back and saying, Well, how do we figure out what a frequent, urgent and painful sort of problem is? And also the layer on top of that that'll add, is in our case, we really wanted to build something that any human being on the planet that's connected to the Internet would need two years, not want. Tea is not could use but need to use.

And those words are very important. Just like with product copy. All that stuff positioning like words are important. Words are important. So what we did is we ask people what their number one challenge waas when it came to creating and sharing documents. We ask that in a specific way, too, because if we asked, What's your number one channels of documents? We might have got a completely kind of more narrow scope, right? Because some people create documents and are prolific document creators. Other people don't, but they all need to find documents no matter what. Right? Yeah,

so it turns out so we wanted to talk about creating chair. And so it turns out that finding document is the number one problem everybody has, and that's where the kind of start of F Y I kind of happened in its current form. And so I think, like it's like you're early on really trying to figure out how do we find it's like a problem discovery? How do we find the problem where it's salty, even if you have an idea That doesn't mean like an idea of a problem or even like any solution you have. So ideas, air just solutions to problems. That kind of one big sort of, um, repetitive thing I keep coming back to. Especially when people ask me about an idea like, you know, like it's a solution to a problem, right?

So let's go dive deeper. What is the problem that that solution solves? Or what are the potential problems that solution salt? And that's if someone starts with an idea, because often we start with an idea. We don't start with a problem, right? And eso you know, that's that's kind of I think, the first thing I would say which is when it comes to like being customer centric, um, and really paying attention to the world in a way where you can sort of change it right, build something, you change people's behavior or getting their workflow or whatever it is, you're sort of aspirations, are they?

It really has to do with, like finding the things that are worth solving for other people and making sure those things are sort of a problem that happens often enough is painful enough and ideally, also has some relatively medium to high level of urgency when they need to solve it. If it doesn't, that's OK. As long as it painful enough. Infrequent enough, right? Right. Yeah, that's it's really interesting. You don't have this framework for thinking through, you know, sort of very systematically. Um, no,

it is this a problem with spending time on? Is this something that we should, You know, this is a huge opportunity cost in in doing anything, right? Is this the right thing? I'm always curious in terms of sort of the starting point, you handsome attempts in the document space. I guess that sort of gave you a move from God, rails around the types of problems that you're interested in and working on. Who do you go to first when you're trying to sort of dive deeper and you mentioned the survey that you ran. I just try to understand some of the problems with in that space. Where do you go to first? Suddenly there's problems that may be so so it seem very similar on the surface, but actually quite nuanced once you get into different, different audiences are sort of different different groups of people.

Yeah, so, um, it's a good question. I'd say that, like, no matter what product you have, the there's always alternatives to it. So where we like to go first is what some people would call competitive research. And what we like to do is look at and understand what people's impressions are of the alternative. So, you know, there's like famous sayings like that kind of keep popping up every like, weak. It seems like where it's like, you know,

every software product replaces a spreadsheet, right? For some, some form of that keeps cropping up its popular every time it's said. If you think about why. That said, though, I think you start figuring out kind of how sort of not formulate, but how transparent, like people's thinking kind of ends up being. So it started with the fact that one of the first productivity sort of concepts as we got computer is not even when we got online was literally documents and spreadsheets, right? This is what started it all, whether it's Lotus 123 word perfect back in the day, What have you like? You know there were precursors to excel Excel is not the only initial sort of pull and stuff,

and people don't even probably remember Microsoft access, right? So software solutions tend Teoh skew to be some form of a replacement to a spreadsheet, even the consumer world. You can kind of imagine people building spreadsheets for their personal stuff, like whether it's contacts or even like planning their vacation or honestly planning their trip and number. Even uber is some directive forum of that kind of thing. I only mention that because at the end of the day, like there, it's very rare to find a new problem, right? Right, Like even in our world, finding document has always been a problem. It's just worse now because there's more places. It's always been a problem since word perfect.

It's a problem, Um, even since written notes, actually, if you think about it that far, so I really go and look at fundamentally. If alternatives exists, which they always do, took everything you're doing no matter what, it is hot. What? How can we go as fast as possible? Learn about what people think about these alternatives because that's really what's gonna help inform and start start helping us understand what the market looks like from a customer standpoint, not the market from a competitors standpoint. But from a customer standpoint, which is like this nuance,

people don't talk about enough. In my opinion, I don't look at competitors because I want to know what they're doing. I look at competitors because I want to know what customers think about that, right? Right? Yeah, that totally makes sense of so much value in, like, review mining or looking at just going and having a conversation with somebody who uses something else. And I think it's particularly interesting to that sort of qualitative analysis, because you can't you have to go beyond, like, just they use it. They pay this for it right? Because it's more competition than just,

you know, This is cheaper than that, right? There's also, in time and attention an effort like switching cast of, of using something new. Um, it's this. I think it's I don't know if it's an original quote from David Cancel, but I know it's one of threats, mantras, but innovate don't invent right the idea that there is nothing new and so it just building on top of things that already exist. Yeah, I think that that statement is a good reminder that everything's different derivative of something that existed before. The root of that is more oriented around. What I said,

though, right? Like it's not because, like, people's definition for invention and innovation and all those things are very like fuzzy right? We don't know how to define those words said To me, it's pretty simple. It's like whatever you're doing, an alternative exists. Find that alternative and learn about that alternative. That's it, like it's pretty basic right that way. We're not getting into innovation invention. The reason is, if David were here, him and I would have a big debate about those two words,

right? And I think it's a very valid way of thinking about it. But it's also culturally how they do things because of the way they run their business because of the way they do product, which, frankly speaking, I've learned a lot from cause. It's not the way I do product right, and that's very interesting because we all skewed towards what are sort of perception and perspective is on the way. We think about, um, creation, right and I've seen his perspective and is very good topic actually. So I'm glad you brought up the quote because there's two perspectives on this. There's a perspective that's like we should copy what exists and innovate later, or we should go innovate first. And I use the word innovate because that that's the right word.

That is the right word. It's not invention. It's innovate, right? Because in the case of drift, like they copied what existed and then they completely diverged from it into some new category they created through a discovery process that is very summer to the discovery process. And we just talked about. But they didn't do the discovery process before they actually shipped to market in a massive way. Their first launch made them look like intercom, right to the point where everyone was like This is intercom literally and will use it because it's inter cop. That's why people used it early on, to be honest. Now you look at you, look at those two businesses. They're not the same. Doesn't like right,

right? That's a testament to David. Cancel strategy right the way I think about things and have historically done them and this is why I've learned a lot from David is like with my business crazy act from back in the day create heat maps where people are clicking on a page that wasn't a let's go copy something that exists That was more like Let's go make something we know we could make better Better So if drift is like we're gonna copy intercom and learn and you know quickly, like, figure it out ours was more like we're gonna go figure out something unique and original on the first shot and figure out what that needs to be. The process of discovery is different. So the process David uses is is build is basically that he's used in this case is copy, build iterated from their get to something unique. He still gets to something unique, which took me a while to really understand the other methodology, which is my my go to which, you know, I'm learning how not to make it my go to because I think we should learn things that you know we're not comfortable with is actually go learn how to be different and how to innovate without even shipping something right and a lot of it has to do with what are you? What were you skewed towards? And what's faster for you, right?

It's not about success or anything like that or one being better another. In fact, I'm trying to learn his way because I think that there's a tremendous amount of value in doing it the way he does not to say that the way I typically have done it in my career, so to speak. Our journey is worse. I think it's and it's not even market centric. That's the funny thing. It doesn't matter what market you're in. It matters what way your skewed and what you can do faster. So if someone trying to evaluate should I build, should I do the David thing, or should I do the heating thing? It has to do with What are you better at and what can you do faster? And what's your Where's your experience? So with him, his experiences building teams If you were to ask me what David,

what David's the best at? I think he builds amazing teams and culture. If you look at what I'm better at, you know is I like to innovate and build something different, right? And that's what I like to do in the first shot. Yeah, it's really interesting. We this was really asked us to have a question. We would come back to the same place which something I wanted to ask about ask you about in general is like, At what point do you go from sort of abstract to concrete, right? At what point do you go from? We're analyzing the space analyzed, like understanding customers to actually putting something in customers hands that they can use. And you get a very different kind of discovery,

right? It's sort of I am, I guess, typically even for companies that I mean superhumans a good example of this, right? Like they built for a long time and relatively private, but with constant adoration from uses before they sort of launch more publicly. But it's sort of Ah, it's a spectrum, right? Like at what point do you go from when we know enough about this problem? Will this what we think? The solution looks like to actually build the thing that is going to get us move us to the next step. I guess that's really the goal, right? it's just moving.

Moving for it. Yes, both methodologies require that thinking right in drifts case, it's like at what point do we start different trading? Right, right? I mean, that involves at what point? The answer really is. At what point are we right at that point of like being bored of hearing the same things over and over again? So when you can predict what that next customer call is going to be about, that's like almost too late. But about right, if you can time it of when you actually shift gears and do something else. So at F Y I, we kept hearing that the search box is in the search experience inside of Google Drive in confluence and other products on the market that people were using.

Dropbox even just sucks like we can't find anything through search. You're like, Wait, hold on. So this idea of a unified search box has been tried before. It has failed more times than it succeeded, never really succeeded. It's either failed or been acquired, which you could call it success, but not from a change the world standpoint. If you want to kind of mess around like that which is, like, you know, millions of users or hundreds of thousands of companies or whatever. Um and so we built a search box really, really fast.

We built it in five days from start to finish. Um, it was actually three days. Ship did internally iterated on the interface for two days, and we want to learn number wine. Does a search box get used to find documents across tools? Because that we didn't know. We don't know ourselves. We had hypotheses, but we didn't. All the comings had died, so there wasn't as much research to do except that Hey, people try to solve the problem. And there were some issues, but we couldn't tell what the issues were, so we built it.

That was one thing we want to learn. Second thing we want to learn is what is the format of showing documents that would be most useful to people. So this is like itemize former, because no matter what we build, we need to show document whether it's a search box or something else. We need to show document. So, in fact, what we learned in those listings still stays with us today. It's still very similar to how the document listings look and will probably look for a very long time in F Y. I. Until we learn something new between the world, you know, people's perceptions would change, which is not likely to happen. So we learned how to display documents in order for people to parse them and understand them and find them.

And then the third thing we wanted to learn was really oriented around is even by this, a solution from a value proposition standpoint, valid enough that people will give us feedback on it and use it. So we learned that search doesn't get high engagement or retention without a lot of tricks, like a short cut key, or stay really fast surge and things like that. But really, most of the time, people don't think of typing in a box to find the document. They just don't They don't know what the title is. A entitles advance to say right can we already had all those fundamental learnings before we built a search box already knew that, so we were not excited about building a search, but we also didn't want a waste time like we did in the other two products and build something nobody wanted to use because that's bad. Obviously, that's objectively bad if you're trying to build a business. So that's how we thought about it.

And so, in a way, we did do the David Cancel approach, which has built something and then do something completely different after, you know. But that's again. I learned it from him like he's very good at that. He's done that repeatedly, Um, and then he builds the teams, right? So in our case, we built it. We learned a ton, and we realized that we would have to invent something that feels life, Taymor intuitive,

sort of natural way to find documents that's based on how people find them. Naturally, they ask other people, they go in the tools they browse what's been sort of recently worked on things like that. In our whole interface, maps toe every single one of those behaviors. Now we did about 52 interviews early on 51 interviews early on toe learn what behaviors people have when it comes to finding documents. So we even ask those people what's your number one challenge? And when people said, hey, finding documents is my number one challenge. In those interviews, we asked them Hate, tell us a story or the story of the last time, actually reading asked for story, although from a product standpoint,

conceptually like we're looking for stories, we actually asked them, Tell us about the last time you had to find a document what happened and they would tell us. And that's 50 versions of that story, if not more right, And that taught us the like 5 to 7 behaviors people have when they find document that gave us everything we needed. And then we kept Iterating our interface until it mapped to what we heard. And we still continue to do that right there. Still, it's funny. This was like two years ago now, and everything we learn. Nobody's really solved it like we're still working on it. We have a we have a bunch of work to do. We've solved certain aspects of it, but there's more more to do,

and the world does change, you know, every about 3 to 6 months, and then you start seeing those changes if you look back like every 18 24 months or so but like, you know, right now, the way we think about discovery is always about stories. And so if we wanted to discover the issues with sharing documents, we would ask people for stories around. Last time they shared documents. What difficult is that? In fact, we did that recently, um, and have added features to our product that oriented around not just finding, but also sharing.

And we solved a lot of the problems with sharing to which is essentially one way to share. Right now, there's so many different ways to share all those models when you try to hit the share button look very different, right? And nobody knows how to share and permission and all that. Some of the things we've done, as we've built out our team features, is basically figure out how to provide you with one way to share. That's across all the tools years. And so those are some of the things we're doubling down on now. But they were all from the same style of discovery. Hey, it's really interesting that it's you know you do so that number of interviews and you really distills down to you find common patterns relatively quickly. I mean, not that 50 interviews is insignificant. Uh,

time investment. But, um, you know, that's not a huge number of patterns to build. Usually it happens with a dozen. And for us, the reason it worked is because of the first thing I said, which is before going into this, we had a criteria. This has to be something that everyone needs. Everyone on the Internet could use it. That's like a huge, like criteria for us. Starting out doesn't mean we reach everyone right away, because I think that's a journey.

But like, it has to be something that when I say that problem where I say the value probably why I had the core people like, huh? Okay, yeah, I have the problem. And that's like check Mark one, like, done right. And that's consistent. Like don't even nine out of 10 people is like 99% of people. Some people are super, super organized and in that 1%. But even then, when I tell them Well, what about all the times people ask you for a document?

They're like, Oh, yeah. So there's some aspect of it that's really painful to people. Yeah, The one thing that I haven't had talked about so much, which is really interesting you brought up is one of yours. Of course, criteria is frequency. Um, that's something that is against rings true and the when you're doing these interviews. It's much, much easier for people to recall stories to tell you about their experience sharing or finding documents. If it was something that we did, you know yesterday or today, or even if it was maybe a week ago,

right? But it is a problem you don't run into no more often than once a month or something that becomes much much out of the cell for us. That's right toe frequency understanding, frequency of behavior around. The problem you're trying to solve is a leading indicator to retention. So that's really the kind of business reason toe, like worry about it is to basically have ah, understanding of how often the behavior is happening because that understanding itself will hitch help you figure out what is it that is worthy of working, right? Right. Well, I have a sort of 22 final off two questions for you, which is sort of opposite sides of the same same client. I guess one is like, as you know, as if why I get bigger.

And I have, uh, experience of this in previous business as well. How do you sort of maintain that closeness with the customer? What are some of the sort of processes? Are you know, uh, I guess how do you build a culture around staying close to the customer? Um, that allows you to continue to reiterate and continue toe to hear these stories. Yeah, for us, it's just making sure that when we way, we treat new features like new product, they need engagement. They need retention.

They need activation energy for people to actually like use them. So one of the things we do is really focused on our interface and making sure that when we build something, we're really learning about how people are using the interface, anything that they want to have, something you can easily get into the sort of world where, even if you don't have, like, a large team or something, people are debating what to do and what to put in there. But what you really need to think about is like, how do we How do we stay in people's workflow? How do we How are we additive to it? So when we wanted ad sharing and theft by I, we really wanted to figure out where is the right logical what are the right logical places to start and put it that are actually able to be done in 40 hours or less of engineering time. So about a week of entry time is actually 30 20 to 30 if you think about developer productivity. So basically something that takes a week of engineering time is how we sort of narrow it down.

The reason I mentioned that we actually call them step ones. So we try to think of what's a step one for this, and it always has to be able to be done within five days of engineering effort. And for us, there's probably like a number of days of planning and stuff like that beforehand and product work. But engineering effort needs to be clamped down toe like a very small chunk, right? And so again, the reason I mentioned that is we work backwards from that intention. So then everything we do around sort of understanding customers is about understanding what the right step one starting point is for that future we want to build. And how can we do that with a learning mindset? So when we were adding sharing to the product, we basically created a fake button that was a plus button on any item, any document that you see in the interface and when they when people clicked it, we actually just asked them, What do you expect to happen?

And we tracked the whole interaction. How many document items are viewed? Total? How many people hover on the document item? How many people hover on that plus button? How many people click the plus button? And then, obviously, like how many people respond to our question? We don't really care about the response to a question. What we like. The count will be cared. There will is about what did they say? Because if that plus button didn't cause them to think about sharing, and that wasn't the majority of what people said, then building building it out or that sort of interaction and all that would have mattered.

So in some ways it's like there's a infinite number of tools, like in terms of in your tool belt to get feed. That the one that I find most valuable is when we do research to really identify, like, what's the right next thing to do? And the right next thing for us was finding and sharing our very related so sharing made sense. So if sharing makes sense, then what's the fastest way we can learn about sharing? Well, sharing is gonna go need to go in our interface and in these going our interface in the high usage area. You know, if you're not seeing documents in our product or product, you're not using your product, right? So that the high area is like the documents. So then we figured out where to put a treatment there,

and we would have kept testing that treatment until it worked and worked. Meaning, Ah, high enough percentage of people found it high enough percentage of people clicked on it and kind of had a certain expectation with it. Or, you know, like they said, what we what we wanted them to say, Which is this? I think I'm gonna I think by clicking this, I get to share, right, so that's that's sort of the logic there. So it's like, Look, this tool around the interface was useful in helping us learn that much more and can continue to be a learning organization and continue that effort out.

You know, like in addition to what we would do if we were just starting out originally with customer interviews and surveys. Now we have product and we have an interface, and we can go play around with that and use that to learn and get feedback, too. So that's the uncommon method, I would say, but definitely something folks have talked about. But it's very uncommon for companies to do that. Ah, and we we like to do that. Once we really are convicted on, we have to solve this and that's the key. How do you identify it? The things you have to solve. And that's where the sort of early stage style research and customer interviews and all that could be really helpful.

Yeah, it's fascinating, and I agree that that's certainly nothing doesn't seem to be the norm, at least that you almost start with the metric and come backwards rather than you know we're gonna do this thing and hopefully this impacts this metric anyway. If it doesn't impact the metric, why are we doing it? If we could, whether it's gonna impact the metric or not before we actually go, spend a lot of time and effort on it, great. Like we should do that right? And it's also like the debate should be not about like you know how it should feel or how it should look. The debate should be, actually be about what's the right thing toe workout, right? And then once you get that debate,

then it's like, OK, how should we? How can we figure out how to learn the fastest? So I see a lot of brainstorming meetings around ideation and things like that and future debates. What I don't see enough of also is like ideation around. How fast can we learn whether this is correct or this is the correct way to hit our goals? The bank, which and I guess that becomes or theory becomes easier as you have more engagement. So if you start with that, you have sort of a broader base to test with border base to people to get that feedback from because it sort of ties in the back first question, which was like, Where do you start? Right? Like if you're you're currently not not working back from a metric If you're currently, um,

I'm sure what to build next. What's the very first thing that you would would look at? Purity have a product? The first thing I'd look at is where is the most usage? So what part of the product what gets the most usage? What are people doing the most with your product? That's the key, cause you won't. Logically, you won't get adoption for whatever you're doing if you don't pick that area, and it's likely if that area is high usage, that's the area you're gonna. You should improve the most and double down on it. Instead of trying to figure out how to add all these other features and stuff, figure out where the highest usage is because where the highest usages is also where the biggest opportunity is to build the next feature for the next add on or whatever you wanna call it. It's also the best place to make improvements because you get results faster,

but also you are guaranteed to have some level of natural adoption because it already used a lot with whatever you add to it. So I think that's another thing. I don't see enough conversation about our discussion along and also like execution, which is like people tend to add tabs or add areas. The thing is, they don't think about how are people gonna get to those areas. And the way people tend to get to areas like that, There's two ways. One customer success. Someone's teaching you about those areas. Right or frickin tool tips Don't get started, please. Um, the second way, which is more effective, is they come from another area that's already the highest usage,

right? Well, we already were. Yeah, yeah. And trusting. Yeah, this is fascinating. I feel like I'm I've been schooled here on everything price. So I guess to wrap it up like if. And we feel special, if you know where to go, if you want to start, if you already have a product, what's that brand new like, What's the biggest thing?

Um, the people. What's the 11 piece of advice you would give people when it comes to all of this, right. Like in terms of you mentioning customer centric Elia, and it's talked about a lot. Um, that does custom centric is a good thing to be like, What is the one piece of advice that you would give people to help them be, Actually, be more customers? Um, I just realized that whatever, whatever ideas you and your team have are still just ideas. And everybody, with their ideas,

is trying to solve some kind of problem, even if they don't know it. So even if you have like a executive and they're really harping on a certain feature, which is very common, they're trying to solve a problem. They might not know it. They might not realize they're turning home problem, but they're trying to solve a problem. So I think like the way to really be very customer centric is realized that everything you do is just a solution to a problem. An idea is actually a solution to a problem. The route caught the route not even caused, but like the root intention behind an idea is to solve someone's problems. If that's the case, then like in everything you do, try to identify the problem you're solving, and then you'd probably realise that like there's not actually that many things to focus on.

There's a lot of work to do always in product, but like there's not that many things to focus on because the problem You don't want to start solving new problems until your damn sure that the existing problem that you're solving is solved as best as possible compared to any possible alternative a customer has. When you start thinking about like that, your whole world changes. You start doubling down on what you're already good at and what your solution already solves for, and then you expand out from their kind of in concentric circles. You don't hop over to another problem to solve unless, like, you know, you sort of don't have that mentality. So the mentality of problem solving the mentality of finding the sort of intention behind an idea and intention be an idea is a problem, and finding those isn't really important. And then really, doubling down on the core as much as possible is the key. Um, when you add features,

amazing what? Thanks so much for doing that. Say, where can people go to? I know you're you're everywhere on the Internet. Where should people go to? Ah, a lot more about you to find more of your your work and what you're up to You. Yeah, my Twitter accounts, HN Shaw Agent. Shh. That's probably the best place. And then I have a newsletter called Product Habits that you mentioned earlier, which is a product habits dot com. I write it with my co founder,

Marie, and we're probably gonna go back to something we did when we first started at four I but didn't have the time to do until more recently. Now, as we built up the team were just focused on building up the team. Um is basically talking more about, like what we learned on product and sharing it amazing. Well, thanks so much for joining me. Thanks

34:31

for having me customer conversations. Podcast is brought to you by the team and learn by learn why integrates with all of your customer facing tools to organize feedback and extract actionable insights? Empower your team to start growing your bottom line today with insights from qualitative data powered by learn Why find out more at either learn why dot com or by emailing our team at sales, learn why dot com Thanks for listening to this episode of the customer conversations podcast. If you or someone you know has expertise in growth, marketing or product, please have them reach out to either Sean or Stewart to learn more about becoming the guest on our show.

powered by SmashNotes