< See all episodes

Building better products using intentional experiments with FYI’s Hiten Shah

Episode #

9

Show Notes

In this episode we're joined by Hiten Shah. Hiten is a prolific SaaS founder of companies including Kissmetrics and Crazy Egg and is now working on FYI. He also runs Product Habits to help other founders develop the habits they need for success. We discuss:

- His framework for identifying product ideas worth pursuing.
- How to identify what your customer really want.
- What Hiten has learned from David Cancel about different go to market strategies.
- Why continuous testing drives increased product value.

Resources

Product Habits

Building an MVP for FYI in 5 days


Connecting with Hiten

Reach out on Twitter

Sign up for FYI

Episode Transcript

Stuart Balcombe
Hello, and welcome to the Customer Conversations Podcast. Today I'm so excited to be joined by the incredible Hiten Shah. Hiten is a prolific SaaS founder of companies like Kissmetrics and Crazy Egg, and is now working on FYI. He also runs Product Habits to help other founders develop the habits they need for success. Hiten thanks so much for joining me.

Hiten Shah
Thanks for having me.

Stuart Balcombe
I'm really excited to dive into all things, products and specifically how customers influence the products that we build. So, but maybe for those who don't know well, I'm not sure there's too many of those people, if we can sort of share a little bit about what you're working on right now with FYI and sort of how you got to this point.

Hiten Shah
Yeah. My co-founder Marie and I had a couple sort of failed attempts in the document space and they were sort of 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 stepped back after those two failed attempts and said like, "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 FYI, what we do is, we help you find your document no matter where they are, and that's either documents or files, whatever you want to call it. So we'll help you find them if they're on your computer, we'll 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 the short of it.

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 I'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 to use, not want to use, not could use, but need to use. And those words are very important, just like with product copy, all that stuff, positioning, words are important, words are important. So what we did is we asked people what their number one challenge was when it came to creating and sharing documents. We asked that in a specific way to, because if we asked what's your number one challenge with documents, we might've 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?

So we wanted to talk about creating and sharing. And so it turns out that finding document is the number one problem everybody has. And that's where the kind of start of FYI kind of happened in its current form. And so I think 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 worth solving? 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 are just solutions to problems. That's kind of one big sort of repetitive thing I keep coming back to. Especially when people ask me about an idea, I'm 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 solves?" And that's, if someone starts with an idea, because often we start with an idea, we don't start with a problem.

And so that's kind of, I think the first thing I would say, which is when it comes to being customer-centric and really paying attention to the world in a way where you can sort of change it, right, build something new and change people's behavior or getting in their workflow or whatever it is your sort of aspirations are. I think it really has to do with 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 okay as long as it's painful enough and frequent enough.

Stuart Balcombe
Right. It's really interesting you sort of have this framework for thinking through, sort of very systematically, is this a problem worth spending time on, is this something that we should... this huge opportunity cost in doing anything right, is this the right thing? I'm always curious in terms of sort of the starting point. So you had some attempts in the document space, I guess that sort of gave you a, maybe some guardrails around the types of problems that you're interested in 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 just sort of try to understand some of the problems in that space. Where do you go to first? Because obviously there's problems that maybe sort of seem very similar on the surface, but are actually quite a nuance once you get into different audiences or sort of different groups of people.

Hiten Shah
It's a good question. I'd say that no matter what product you have, 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 alternatives. So, there's famous sayings that kind of keep popping up every week. It seems like where it's every software product replaces a spreadsheet, right?. Or some form of that keeps cropping up, it's popular every time it said. If you think about why that's said, though, I think you start figuring out kind of how sort of not formulaic, but how transparent 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 computers, not even when we got online was literally documents and spreadsheets, right? This is what started it all. Whether it's Lotus 1-2-3, WordPerfect back in the day, what have you, 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 to skew to be some form of a replacement to a spreadsheet. Even in the consumer world, you can kind of imagine people building spreadsheets for their personal stuff whether it's contacts or even planning their vacation or honestly planning their trip. Even Uber is some derivative form of that kind of thing. I only mentioned that because at the end of the day it's very rare to find a new problem, right?

Even in our world, finding documents has always been a problem. It's just worse now because there's more places to find documents. And it's always been a problem since WordPerfect, it's a problem, right? Even since written notes, actually, if you think about it that far. So I really go and look at fundamentally if alternatives exist, which they always do to everything you're doing, no matter what it is. How can we go as fast as possible, learn about what people think about these alternatives? Because that's really what's going to help inform and start helping us understand what the market looks like from a customer standpoint, not the market from a competitor standpoint, but from a customer standpoint, which is 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 them.

Stuart Balcombe
That totally makes sense. There's so much value in 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 do that sort of qualitative analysis because you have to beyond just they use it, they pay this for it, right? Because there's more to competition than just, this is cheaper than that, right?

Hiten Shah
That's right.

Stuart Balcombe
There's also a time and attention and effort like switching cost of using something new. I don't know if it's an original quote from David Cancel, but I know it's one of Drift's mantras, but innovate don't invent. The idea that there is nothing new and so just building on top of things that already exist.

Hiten Shah
Yeah. I think that that statement is a good reminder that everything's derivative of something that existed before. The root of that is more oriented around what I said though, right? Because people's definition for invention and innovation and all those things are very fuzzy, right? We don't know how to define those words. So to me it's pretty simple. It's whatever you're doing an alternative exists. Find that alternative and learn about that alternative. That's it. 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 because it's not the way I do product, right?

Hiten Shah
And that's very interesting because we all skewed towards what our sort of perception and perspective is on the way we think about creation, right? And I've seen his perspective and this is a 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's the right word. That is the right word. It's not invention. It's innovate, right? Because in the case of Drift, they copied what existed and then they completely diverged from it into some new category they created through a discovery process. That is very similar to the discovery process 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, to the point where everyone was like, "This is Intercom, right? Literally, and we'll use it because it's Intercom. That's why people used it early on to be honest. Now you look at those two businesses, they're not the same business.

Stuart Balcombe
They're nothing alike.

Hiten Shah
Right? That's a testament to David Cancel's 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 Egg from back in the day, it creates heat maps for 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 can make better, better. So if Drift is like, we're going to copy Intercom and learn and quickly figure it out, ours was more, we're going to 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 basically that he's used in this case is copy, build iterate from there, get to something unique. He still gets to something unique, which took me a while to really understand. The other methodology, which is my go-to, which I'm learning how not to make it my go-to because I think we should learn things that we're not comfortable with is actually go learn how to be different and how to innovate without even shipping something, right?

Stuart Balcombe
Right.

Hiten Shah
And a lot of it has to do with what are you skewed towards and what's faster for you, right? It's not about success or anything like that or one being better than the other. 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. 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 you're skewed and what you can do faster.

So if someone's trying to evaluate, should I build, should I do the David thing or should I do the Hiten thing it has to do with what are you better at and what can you do faster and where's your experience? So with him, his experience is building teams. If you were to ask me what David's the best at, I think he builds amazing teams and culture. If you look at what I'm better at, is I like to innovate and build something different, right? That's what I like to do in the first shot.

Stuart Balcombe
It's really interesting that we've come back to the same place which, is something I wanted to ask you about in general is at what point do you go from sort of abstract to concrete, right? At what point do you go from where analyzing the space, understanding customers to actually putting something in customer's hands that they can use and it's a very different kind of discovery, right? It's sort of, and I guess typically, even for companies that are, I mean, Superhuman is a good example of this, right? They built for a long time and relatively private, but with constant iteration from users before they sort of launched more publicly. But so it's sort of a, I guess it's a spectrum, right? At what point do you go from we know enough about this problem and what we think the solution looks like to actually build the thing that is going to move us to the next step. And I guess that's really the goal, right? It's just moving forwards.

Hiten Shah
Yeah. And both methodologies require that thinking, right? In Drift's case it's, at what point do we start differentiating, right? I mean, that involves at what point... the answer really is at what point are we right at that point of 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 FYI, we kept hearing that the search boxes and the search experience inside of Google Drive and Confluence, and then other products on the market that people were using Dropbox even just sucks. We can't find anything through search.

So we're like, "Wait, hold on." So this idea of a unified search box has been tried before. It has failed more times than it's succeeded. It's 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 millions of users or hundreds of thousands of companies or whatever. And so we built a search box really, really fast. We built it in five days from start to finish. It was actually three days shipped it internally, iterated on the interface for two days and we wanted to learn, number one, does a search box get used to find documents across tools because we didn't know. We didn't know ourselves. We had hypotheses, but we didn't know all the companies had died by then.

So there wasn't as much research to do, except that, "Hey people, I tried 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 itemized format. 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 we'll probably look for a very long time in FYI until we learn something new. Between the world... 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 this 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 shortcut key or really fast search and things like. But really most of the time, people don't think of typing in a box to find a document. They just don't, they don't know what the title is, especially if they didn't title it right?

Stuart Balcombe
I was about to say that. Right.

Hiten Shah
And we already had all those fundamental learnings before we built a search box. We already knew that. So we were not excited about building a search box. We also didn't want to 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 is build something and then do something completely different after. But that's again, I learned it from him. He's very good at that. He's done that repeatedly. 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 like a more 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. And our whole interface maps to every single one of those behaviors.

Now we did about 52 interviews early on or 51 interviews early on to learn what behaviors people have when it comes to finding documents. So we even asked those people, what's your number one challenge. And when people said, "Hey, finding documents is my number one challenge," in those interviews, we ask them, "Hey, tell us a story or the story of the last time..." Actually we didn't even ask for story although from a product standpoint, conceptually we're looking for stories. We actually asked them, "Tell us about the last time you had to find a document of what happened." And they would tell us, and that's 50 versions of that story, if not more, right? And that taught us that five to seven behaviors people have when they find documents and 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?

It's funny this was like two years ago now and everything we learned nobody's really solved it yet. We're still working on it. We have a bunch of work to do, we've solved certain aspects of it, but there's more to do. And the world does change every about three to six months and then you start seeing those changes if you look back like every 18 to 24 months or so. But 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 difficulties they had. In fact, we did that recently and have added features to our product that oriented around not just finding, but also sharing. And we solve a lot of the problems with sharing too, which is essentially one way to share.

Right now there's so many different ways to share all those modals when you try to hit the share button, look very different, right? And nobody knows how to share and permissioning 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 you use. And so those are some of the things we're doubling down on now, but they were all from the same style of discovery.

Stuart Balcombe
That's really interesting that you did sort of that number of interviews and you really distills down to you find common patterns relatively quickly. I mean, not that 50 interviews is insignificant time investment, but that's not a huge number of patterns to build.

Hiten Shah
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 a huge criteria for us starting out. Doesn't mean we reach everyone right away because I think that's a journey, but it has to be something that when I say that problem, or I say the value prop of FYI at the core, people are like, "Huh, okay. I have the problem." And that's checkmark one done, right? And that's consistent. It's not even 9 out of 10 people, it's like 99% of people. Some people are super, super organized within that 1%, but even then when I tell them, "Well, what about all the times people ask you for a document?" And they're like, "Oh yeah." So there's some aspect of it that's really painful to people.

Stuart Balcombe
Yeah. The one thing that I haven't had talked about so much, which is really interesting that you brought up as one of your sort of core criteria is frequency. That's something that is, I guess, rings true when you're doing these interviews, it's much easier for people to recall stories, to tell you about their experience sharing or finding documents if it was something that they did yesterday or today, or even if it was maybe a week ago, right? But if it's a problem that you don't run into more often than once a month or something that becomes much harder to solve.

Hiten Shah
That's right. So 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 to worry about it, is to basically have 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 on.

Stuart Balcombe
Right, right. Well, I have sort of two final, or two questions for you, which is sort of opposite sides of the same coin I guess. One is like, as FYI, gets bigger, I know you have experience with this in previous business as well, how do you sort of maintain that closeness with the customer? What are some of those sort of processes or I guess how do you build a culture around staying close to the customer that allows you to continue to iterate and continue to hear these stories?

Hiten Shah
For us, it's just making sure that when we... We treat new features like new products. They need engagement, they need retention, they need activation energy for people to actually use them. So one of the things we do is really focus on our interface and making sure that when we build something, we're really learning about how people are using the interface. I think that once you have something you can easily get into the sort of world where even if you don't have 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, how do we stay in people's workflow? How are we additive to it? So when we wanted to add sharing into FYI, we really wanted to figure out, 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 engineering time was 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 called 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 to 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 feature 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 people clicked it, we actually just asked them, what do you expect to happen? And we track the whole interaction. How many document items are viewed total, how many people hover on a document item, how many people hover on that plus button, how many people click that plus button and then obviously how many people respond to our question? We didn't really care about the response to our question, like the count, what we cared there was 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 it out or that sort of interaction and all that wouldn't have mattered. So in some ways it's like there's a infinite number of tools in terms of, in your tool belt to get feedback. The one that I find most valuable is when we do research to really identify what's the right next thing to do. And the right next thing for us was finding and sharing are 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 going to need to go on our interface and it needs to go in our interface in a high usage area. If you're not seeing documents in our product, you're not using our product, right? So then the high area is like the documents.

So then we figured out where to put a treatment there and we would've kept testing that treatment until it worked and worked meaning a 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 like they said what we wanted them to say, which is, "I think by clicking this, I get to share," right? So 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 continue to be a learning organization and continue that effort 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. And 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 the things you have to solve? And that's where the sort of early stage style research and customer interviews and all that can be really helpful.

Stuart Balcombe
Yeah, it's fascinating. And I agree that that sort of not that it doesn't seem to be the norm at least you almost start with the metric and come backwards rather than, we're going to do this thing and hopefully this impacts this metric, right?

Hiten Shah
Yeah. No way. If it doesn't impact the metric, why are we doing it? If we can learn whether it's going to impact the metric or not, before we actually go spend a lot of time and effort on it, great, we should do that, right? And it's also like, the debate should be not about how it should feel or how it should look, the debate should be actually be about what's the right thing to work on, right? And then once you get that debate, then it's like, "Okay, 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 feature debates. What I don't see enough of also is ideation around how fast can we learn whether this is correct, or this is the correct way to hit our goals, or the best way.

Stuart Balcombe
Which and I guess that becomes, or I guess in theory becomes easier as you have more engagement. So if you start with that you have sort of a broader base to test where the broader base to the people to get that feedback from. So I guess that sort of ties into my first question, which was like, where do you start, right? If you're currently not working back from a metric, if you're currently sort of unsure what to build next, what's the very first thing that you would look at?

Hiten Shah
If you already have a product. The first thing I'd look at is where's 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 because 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 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 or the next add on or whatever you want to 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's already used a lot with whatever you add to it.

So I think that's another thing I don't see enough conversation about or discussion, and also execution, which is, people tend to add tabs or add areas. The thing is they don't think about how are people going to get to those areas and the way people tend to get to areas like that, is two ways, one customer success. Someone's teaching you about those areas, right? Or freaking tooltips. Don't get me started on tooltips please. The second way, which is more effective is they come from another area that's already the highest usage.

Stuart Balcombe
Right. Where they already were. Interesting. This is fascinating. I feel like I've been schooled here on everything products. So I guess to wrap it up, if, we talked about sort of where to go if you, or where to start, if you already have a product, where to start if you are brand new. What's the one piece of advice that you would give people when it sort of comes to all of this, right, in terms of, I think you mentioned customer-centric earlier, and it's talked about a lot that there's... customer-centric is a good thing to be... What is the one piece of advice that you would give people to help them be more... to actually be more customer-centric?

Hiten Shah
Just realize that 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 an 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 trying to solve the problem, but they're trying to solve a problem. So I think the way to really be very customer-centric is realize that everything you do is just a solution to a problem. An idea is actually a solution to a problem. The root cause... not even cause but the root intention behind an idea is to solve someone's problem. If that's the case, then in everything you do try to identify the problem you're solving. And then you'd probably realize that there's not actually that many things to focus on.

There's a lot of work to do always in product, but there's not that many things to focus on because you don't want to start solving new problems until you're 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 of it 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 there kind of in concentric circles. You don't hop over to another problem to solve, unless 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 the intention be an idea is a problem, and finding those is really important. And then really doubling down on the core as much as possible is the key when you add features.

Stuart Balcombe
Amazing, well, thanks so much for doing this. Where can people go to, I know you're everywhere on the internet. Where should people go to learn more about you to find more of your work and what you're up to?

Hiten Shah
My Twitter account, @hnshah. That's probably the best place. And then I have a newsletter called Product Habits that you mentioned earlier, which is @producthabits.com. I write it with my co-founder, Marie, and we're probably going to go back to something we did when we first started FYI, but didn't have the time to do until more recently now, as we built up the team, we were just focused on building up the team, is basically talking more about what we learned on product and sharing it.

Stuart Balcombe
Amazing. Thanks so much for joining me.

Hiten Shah
Thanks for having me.

New episodes released every week

Subscribe and get every new episode in your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
No spam, guaranteed. 😁