Gia:

Hey everyone. Welcome back. If this is your first time joining us, then welcome to Forget the Funnel. We recently sat down with Hiten Shah. You may know Hiten from one of the many SaaS companies he's founded over the years, including Crazy Egg, KISSmetrics and most recently FYI. Throughout the process of launching FYI, from first conceiving the idea through publicly launching the product and now running a team of 16, Hiten and his co-founder, Marie, have been very transparent about their process of conducting audience and user research to inform product development and go-to-market strategy. Naturally, as advocates of customer led growth, Claire and I were eager to sit down with Hiten and discuss their process.

Claire:

This interview with Hiten covers a ton of ground starting with the two products he and Marie had launched, and shut down, that led them to discover a real pain that finally we're solving with FYI. That's when the conversation really gets interesting, because we then dive into details, including how the team segments FYI customers at the individual and team level, how they gather data and learn from customers in the background, how they centralize their research data and make it easy to access the nuggets of insight and how customer insights are communicated to their designers and engineers and brought to market as new features.

Claire:

Let's jump into the interview. If you have any questions or comments you'd like to discuss, we would love to hear from you. You can find us on Twitter or email us anytime at us at forgetthefunnel.com. Right, so Hiten, thank you so much for joining us today. First off, really excited to be chatting with you. Probably, I think the easiest place to start is probably at the beginning of your journey of working on FYI. From the start of that journey you and your co-founder, Marie, I know have been very public about relying on audience and on customer research to validate the opportunity for the product and build excitement around it and then launch to a really eager market.

Claire:

I'd be really curious, if you're able to, to hear any examples of what you did differently in this process as compared to conceptualizing and launching previous products, because of course we know this is not like your first product to market.

Hiten:

Yeah. Well, first thanks for having me. The short answer to the question which I will give is basically, I think that as time has gone on since I first started on the internet in 2003, people have become more and more picky about the software that they decide to use. I say you specifically, I think it's definitely a landscape right now in software specifically where people are willing to sign up for products pretty easily, pretty quickly. The barrier to entry on that, someone signing up is pretty low. We don't need to go for demos in most products or we have, even if we have to sign up for a demo, we have lots of videos, lots of reviews to look at, lots of things that we can actually go explore as buyers or users, whatever way you want to call it. I prefer customers, so let's just say customers.

Hiten:

When you think about it like that, the... when we started FYI a couple of years ago, Marie and I really thought through like, "Okay, we have an ability to..." I mean, one, we value this stuff, and by the stuff meaning, we value the idea of getting things right before you write a single line of code. I feel a little dated saying that because I haven't heard it said in a while, but I used to say it all the time before. I feel like it's kind of, either it's a norm or people forgot it. I mean, it goes either way. What we decided to do was, we had this audience that I actually started as my personal newsletter. One of the first things, earliest things we did is we rebranded it and we called it Product Habits.

Hiten:

It used to be called SaaS Weekly, and it was Hiten's Newsletter. That was just something where I would send 10 ish links every week on a Monday and just show you the things that I was reading the week before, and that I found interesting and tell you more about them, and hopefully that helps you find good stuff because I happen to be good at finding good stuff. We took that list and then we converted it over to a brand called Product Habits with the idea that we are going to teach people product development by doing it ourselves, and in that process, we're going to hold ourselves accountable to extremely high bar because, if we have to teach people it, while we're doing it and we share what we're doing, then we'll just be more likely to find something that's worthy of pursuing.

Hiten:

That was the concept and the idea. Early on, we decided to really... after a couple failed attempts before we did that, we decided to basically double down on identifying the biggest problem in the market that we're going after, so the biggest challenges that people have. That's really what kicked off. That was the thought process behind it and what really kicked off, but we started doing that, I think you watched us do a couple years ago.

Claire:

To dig into that for just a minute, were there some other problems that you identified that seemed like potentially a good route to take? I mean, obviously since then you have chosen the direction of FYI, but you made a comment about failed products and I'm curious what other problem areas you noticed that maybe you had some interest in that that didn't end up actually being that big of an opportunity?

Hiten:

Yeah, so we had two ideas. One was, we thought we might raise a fund and become investors, I was already investing a bunch and Maria and I were talking to a lot of startups and stuff and we both are in the Bay area. That helped obviously because this is like startup Mecca or whatever. We were talking to a bunch of these companies and what we realized is, we wanted to find the problem they had, and the biggest challenge that most founders have is actually fundraising. It doesn't really matter what stage of business they're in, typically that's the problem. Even when a company goes public, fundraising is still a problem because you have the public markets, things like that.

Hiten:

We decided to build a product in that market. What we missed out on when we went after that product and I'll explain what it was, but is basically, there's a few things that we got wrong. We got the pain right, which is they have a problem with fundraising. I don't think we dug in enough to understand that the problem was more so oriented around things like, should their business be funded or not? That's a emotional, psychological like those are things that software can't exactly touch. Maybe some assessment or quiz or... even consulting I don't think can solve that because it's like, if somebody wants to raise money, they want to raise money. That's just what their mindset is.

Hiten:

We didn't get the psychology right. We didn't really get a lot of those things right in terms of, understanding and going deeper down and really figuring out before we built a product, what the deal was with people and their behaviors. What the product that ended up being... that failed was, we let you upload your pitch deck and then gave you a way to let other people comment on it, and other people meaning advisors and folks like that. We launched it actually, well, we put in an early access, we helped somewhere in the range of a thousand plus people build their pitch decks, whether with the tool or even us helping them, because we wanted to be experts on pitch decks and fundraising and stuff like that. We became experts on that, I guess. We built a whole... we even did workshops for a few incubators and we went like whole-hog so to speak on going after it.

Hiten:

Then we realized that we really got the market size wrong. I think the market size was the biggest problem. What I mean by that is yeah, there's all these problems around the behavior, the emotion, the psychology, but a lot of times those things can be solved for if the market's big enough, because there's some percentage of people that are large enough audience that wouldn't have that problem. Wouldn't have that, "Oh, I should," the psychological problem of, "I need... I want to raise money even though the business I have isn't right." The market was just small. It's not actually that large when it comes to fundraising and providing a tool to help people get feedback on their pitch decks. That was one idea.

Hiten:

Then, I get in trouble for this one, but we took that product thing and I said, "Hey, let's copy and paste it." What that means is we took it, the code and then we copied and pasted it, which really wasn't well, what happened and built something else. That something else had... I think we skipped a few steps there and this is just, I think it's one of the things I would point out, one of the biggest lessons over time for me is, it's super easy to skip steps in the process of learning about customers and learning about how people behave and what they do. We skipped some steps because we were just... because I said copy and paste it, which never really works out apparently. We took the product and said, "Okay, well, there's this thing called SlideShare that exists and people are not happy with it." We did a little bit of research to figure out what they weren't happy about.

Hiten:

We thought we had an idea, and so we started building something and what we ended up building actually had a great ProductCon launch for a number of reasons and all that. It ended up being this thing called Draftsend. It was draftsend.com. What it did is, it let you upload a PDF, that's where the copy and paste part comes in. But here's where it gets different, we let you record audio as you went through the PDF and then you got a player, the player wasn't a video player, but it looked like one and it just moved through the slides as you were talking but it looked like a video. It was really cool. It turns out that market is not big enough either. Big enough, meaning the thing I'm convinced about is either you go for a really big market size or you know the niche you're going after, and it's very narrow.

Hiten:

Anything in the middle ends up being a slog of some kind that tends not to be too worth it. With Draftsend, the barrier to people activating in the funnel and with the product, was really high because you had to know what PDF you wanted to upload. It had to be something you needed to record right now. Then you had to sit there and record it. Then when you add complexities like audio and recording and uploading through, with bandwidth and all this stuff, even though with all these complexities that would be fine if they were worth solving. Even at FYI, we have complexities, they're just... it's worth solving, and we make sure they are worth solving.

Hiten:

Those were the two failed products. Thanks for asking. It's always great to talk about failure. Then I'll tell you real quick the transition, I'm sure you'll have some questions. The transition came when we actually stepped back, did a bunch of this thing called a relative preference survey on the Draftsend customers. What we learned is that, their number one sort of most painful challenge was actually organizing their PDFs, not what we were trying to do, we just let them upload them and share them and all that kind of stuff. As a result, we actually... that was the big a-ha moment of research that made us just step all the way back and say, "Okay, well, why don't we find out the number one challenge people have with basically creating and sharing documents." We made a survey, sent that out to the list and I'd say the rest is history, but you haven't heard the history, so the rest is history.

Claire:

There's so much more history depending on how deeply you can go into it.

Hiten:

That's right.

Claire:

Super interesting that the a-ha moment for FYI came from realizing that the market for Draftsend wasn't going to make sense.

Hiten:

Yup.

Claire:

I'd be curious then, well, from probably some assumptions, but I would definitely leave this to you, but from some assumptions it sounds like that survey validated that the problem of creating and organizing docs was something that was... was it pretty obvious that like, oh, this is a way bigger problem?

Hiten:

Yup.

Claire:

Survey results?

Hiten:

Yeah, very obvious that like 80, 90, 95%, some really high percentage of people said, actually finding documents was their number one problem. The challenge even up to a couple of years ago was just becoming prevalent and the reason for that is, there's files on your desktop, there's files in every cloud service you use. I mean, I'm not just talking about the usual suspects, like if you use G Suite, you have Google Docs and you have Google Drive and you have all those things, but also you have Dropbox, that's still a usual suspect, you have Box, you have OneDrive. You might just be using one of them, totally fair, except that you're likely using Microsoft or Google for email, and then you tack on something else.

Hiten:

But here's where it gets interesting, almost every tool you use in SaaS that's productivity oriented, whether it's Trello, Asana, Basecamp, or any of those, they let you upload stuff. They let you add an attachment. That's not even counting all the links that you put in those tools to documents and so that your ability to find them... and let's not even talk about email attachments, because then you have a whole set of documents, and that's in the cloud too technically. It turns out that the number one problem was related to the fact that now there's all these places where there are documents and files.

Claire:

I can attest to that, being someone who works across multiple contracts.

Gia:

A huge market to I'm sure.

Claire:

Right. Right.

Hiten:

I mean, we had people that said, that we talked to that were planning their wedding and they have this problem, all the way to people in public companies that are like, "Oh, this problem."

‍

How the FYI team gathers data in the background, to learn from customers while keeping the user experience simple

Claire:

Right. Super horizontal in a breadth of use cases. I want to jump forward in time for a second. You shared some really, really interesting steps involved on the journey to prototyping or coming up with the idea for FYI. As someone who's been on the Product Habits list for quite a while, I remember watching it take shape and I remember the launch of it. I want to fast forward to today actually, and understand a little bit about how you and the team continued to work on the product. I'm super curious if there are any standard ways or ongoing ways that you and the team go about continuing to gather and pull insights from customers on a regular basis that you could talk a little bit about.

Hiten:

Yeah. I mean, to us, all these things are input, so there's an almost unlimited amount of inputs you can have about the customer, whether it's, I'll go to an extreme and say, okay, when they sign up, we go ping Clearbit and go to just find out more about whatever we can that Clearbit has about them. That helps a ton with segmentation. We'll know their title, we'll know things about them without asking them as long as they gave us their email, obviously. That's an input that most folks who are doing research don't think about. If you're just in marketing or just in product, you might think about it. But the holistic view of this customer is really important to us. That's one that, like I said, just doesn't get mentioned enough in my opinion, but it helps a lot with segmentation and things like that.

‍

How FYI segments their customers at the individual and team level, and what user behaviors they look for

Hiten:

Two is another obvious one, which is like basically obvious, but not as utilized as I hope people do in the future is, so the quantitative side of it. Being able to know who did what, how far they got but down to the who, and also down to the organization. There's an organization view of data where if you have a B2B product and it's focused on companies and multiple people in a company can use it, you want to be able to see what everyone in the company is doing. There might be certain milestones that are actually collective milestones, not necessarily for an individual. It's basically like how many people, a good example of that is, how many people from this organization have signed up? You'd be surprised how many folks don't know that about their product.

Hiten:

We make sure that at least our database is instrumented or our analytics, if necessary is instrumented in such a way where we can get down to companies, but also people, but also companies and as much detail as we can get on like, what have they been doing? Because that's really the start of a lot of our sort of, I would call it proactive research processes. Because then we can be like, "Okay, how many people fit these criteria that have signed up for FYI but never performed a search?" We're not just a search product, we have an interface that helps you find documents, but search is still a component of our product. If we knew that and we would ask people, "Why haven't you performed a search?" We can email them and just ask them with a single question.

Hiten:

The next strategy that I'm a really big fan of is, sending very short emails with a single question that people can reply to. We found that that has the highest response rate compared to almost any other, well, basically any other strategy you could use. Then we actually take those, paste all the responses into a Google Doc and then go analyze it and go through that whole research sort of process. These are a few examples, but we do whatever we can. I mean, right now we have... right, right now we have a set of features for teams, and so we're just individually onboarding people into it, even off of literally three or four onboardings when we first started, we have a roadmap of three, four improvements that we need to make. Then it's the debate of, do we just onboard more people now or do we wait until those improvements happen?

Hiten:

If we keep onboarding people, we'll probably then keep learning the same things, and they might not have as good of an experience as the people once we hit the new features. In some ways we've paused on some aspects of that. Sometimes we'll pause even on research and things like that and go another route. There's another route that we went recently because of that, where we paused on the onboardings in order to get some of these improvements in as soon as possible, because we think that the feedback will be different once we have those improvements, because we base the improvements on feedback. Before we turn on onboarding again, we're going to go study certain types of teams inside of a company and the documents they use and what are they exposed to. Because we believe that these collaborative solutions that are out there, a lot of them we connect to and growing, we connect to like 25 plus tools today. They have... it's like a multiplayer mode that happens in these tools.

Hiten:

We want to understand more about how does that happen across documents? What type of documents are these teams creating? How often are they creating them? What's the urgency around some of the documents, someone reviewing them? Just getting really granular about behavior has been something that we didn't do in the past, let's say 10, even 15 years ago that I think is a necessity now. One of those things is the learning from the fundraising tool. It was called Dogo D-O-G-O. The lesson from that was, if we don't get deeper into the behavior of understanding exactly how people are doing things, what the frequency is, what the urgency is of some of those things, what the pain is, we end up basically losing out on learnings that might actually greatly impact our ability to execute and our ability to build a product that people love.

Claire:

You mentioned early in your answer, segmentation and using Clearbit to help with segmentation, and what you're describing right now is various... how people are using the product. I'm wondering, where do those two intersect? Do you segment new signups based on use case? Do you segment them based on something else? Because it sounded like teams became a really big focus for you. How right now are you breaking your customers up into groups, and do you do that based on company size or is it use case? Which ways are you slicing and dicing this?

Hiten:

I think a lot of it has to do with the product you're creating. For us, the product we're creating, the natural obvious way it will spread inside an organization is within a team first, before it goes in between teams, and then hopefully over time before it goes in between companies. Because documents go all those ways, they're also very personal. There's personal documents, there's documents that you shared with your team, some people or all the people. Then there's documents you share with folks outside your team, some people or the whole company in some cases or another whole team. Like, all sales assets that marketing creates, tend to be shared with every sales person. The way we think about it at our company today is team by team, and really like marketing teams, product teams, sales teams, finance teams.

Claire:

That makes sense.

Hiten:

Leadership team is another team that we would call a team because they have the same behavior. We've just been studying those behaviors. A lot of times, what we'll also do is go look at the tools that these teams are already using that are in our case collaborative. Because that's... collaboration is really what we're focused on now with our product, which is helping people collaborate better, helping them find stuff better, helping them share it, helping them see what's happening at work. Those are the kinds of things that we heard from people who are using our product that they want more of from us, and that our product already was doing for them.

Hiten:

You could say that like someone comes in and they have a use case, or you could say... and that's reasonable, but without having the lens for us of what team they're on, we're not necessarily able to as appropriately service them. We don't ask them this right now on the website, our onboarding is very... I just heard a compliment about it yesterday where, the person was telling... he has multiple teams, apparently multiple products he's telling them to copy our onboarding or make it that good. That's fine, but I still think it sucks like I should. But we don't do anything like ask you what team you're on or what use cases you have. We don't do any of that yet.

Hiten:

One of the reasons is with a horizontal product, when you do that, if you miss a use case or you miss a team, then people bounce. We happen to have a product where we connect a bunch of tools and then your information is visible to you right away. Within onboarding, you're able to see as much of your stuff as we can pull up for you in our interface. Keeping it horizontal is important but then, to your question about segmentation, the segmentation for us today happens more behind the scenes when we're doing research, like what type of teams, what type of titles or groups of people from marketing sales, product, finance, whatever, have the highest retention with our product and why do they have that retention? Why is retention so high?

Hiten:

Part of it is having hypotheses on why the retention is so high if it is, or why it's so low, if it is. For example, I was surprised that certain types of teams just didn't have the highest... the retention that I thought they would. Well, it turns out that those teams are starting to use more specialized apps and we don't connect to those apps today. If we don't connect to enough of the surface area of where your stuff lives, then obviously you're not going to be as retained as a team, as a certain type of person in the company. These kinds of insights we wouldn't have gotten, if we weren't segmenting using Clearbit to start. Because we don't ask these people, are they a marketer or whatever?

Hiten:

I find it interesting because I just signed up for a new Airtable account the other day and they're asking me a lot of questions on onboarding. A lot, meaning like four or five. It's cool, all of them have the emoji, the dropdowns and they're very cute. But, they asked me four or five questions, they even asked me my company size. I don't have a problem with that. I don't think it's a bad or a good idea. I'm sure there's a reason they do that, I just find it fascinating that companies do that. Not because I think they should have the info or anything, it's just you wouldn't have thought of doing that 10 years ago. Let's put it that way. That just goes to the point of understanding segments, understanding if it's use case is great, understanding use case is super important.

Hiten:

For example, I'll bet with a product like BaseCamp or a product like even Asana possibly, but probably more like BaseCamp, the use cases are more important than the teams. Are you trying to use BaseCamp with your clients, or are you trying to use BaseCamp with your own company? Based on that, they don't do anything in the product for me necessarily, but now they know.

Gia:

I was going to say, 10 years ago, marketers probably would have done that.

Hiten:

Totally.

Gia:

But they would have done it only to get somebody to be considered like market qualified or something and for a list, but would have nothing to do with actually activating within a product. As opposed to with Typeform, oh sorry, you didn't say Typeform, you said Airtable-

Hiten:

Airtable, yeah.

Gia:

... you would expect, okay, now they're going to cater my onboarding in some way, shape or form. Did they? I recently also onboarded into Airtable and I don't remember.

Hiten:

They dropped me on a screen that had a bunch of bases already there that were templates and they call them bases, but they are sheets or whatever.

Gia:

Because they probably identify...

Hiten:

They did do it. They did do it, but there was a lot and they didn't do anything else after that.

Gia:

Right. Interesting.

Hiten:

But I'm hypercritical. I think they did a good job.

Gia:

It might be enough for them, right?

Hiten:

That’s right.

Gia:

Their biggest barrier might've been the overwhelm of the blank screen and just to get them the basics of what they need and it'll all make sense. Maybe it actually has done its job, but...

Hiten:

That's right.

Claire:

I'm curious how early in the process of onboarding new users into FYI, I'm curious how early you realized that the need to group users by team became an obvious necessity. Because, this was a while ago, but I was working with a company at one point where the style of adoption was really, really similar. It's individual usage and then it typically expands within its team, and then if things go well then it expands to another team and another team and another team. In the early stages of this project a major issue that we had was that, the way that user data had been set up, there was no way on the back end of the product to link users who were part of the same team, which creates all kinds of issues and really-

Gia:

It's so common.

Gia:

Right. Right. Then your hands are tied in terms of communication, monetization, there's so much that creates so many issues down the line. I'm curious at what point you and the team realized like, "Oh, this is a big deal. We better make sure we have this right from here on out.”

Hiten:

We got a little lucky with that because we don't let you sign up with an email address. You have to sign up by signing up with Google. Now we have Microsoft and we have Slack sign up and all that. But because of that, we're keying in on the domain itself, and we focus on that. Also, because of the way our product works, the system knows who you collaborate with and what documents they have access to that you also have either created or have access to. We had to... we got lucky because we were forced to build those things into the product itself because of what the product is.

Hiten:

A lot of other companies don't have that, like at Draftsend we didn't do that. We didn't build that in. If we were to go down that route, we would have had to figure out how to build that in. In some ways I want to say some people make it really complicated because a simple way to start would be you just look at what the domain is of the person and you get about 80% coverage that way. Because most of the other things are edge cases or personal accounts.

Claire:

Yeah, it is very fortuitous that the nature of FYI forces that-

Hiten:

That's right.

‍

How FYI centralizes their research data and make it easy to access the "nuggets" of insight

Claire:

... cue in. You made a comment that with regards to some of the methods that are very effective for collecting customer data, like sending a one question email for example, a lot of the work of then documenting that, is things as simple as like putting answers into a Google Doc. I'm curious, so I know that with teams I've worked with, this becomes a problem all the time. I think you may have even written about it at some point in the past, if I recall correctly. Do you have any way, whether it's well thought out or whether it's just like a scrappy solution for now, do you have any way for the team to consolidate or keep in one place or that customer insight or is it still pretty spread throughout the organization at this point?

Hiten:

We used to have a shit ton of Google Sheets and Google Docs and then I created one day because again, I'm good at finding stuff and FYI is supposed to help you with that, yes I know, I found all the research we did and put it in what I call the catalog. The catalog was just a Google Doc and that was before some of the FYI features. Now we put it in FYI in a bunch of ways. We did that and that made it easier to just know that this is all the research we've done and then I categorize a little bit. I think that's the classic solution. That means that every time we create... do some research, whether it's a survey that goes straight into a Typeform or from a Typeform to a Google sheet and then we do an analysis and there's a document related to it, we end up with like three or four documents.

Hiten:

What we decided to do is, we recently created an Airtable base. We're big fans of Airtable now, because of the connectivity between the different sheets that they have there. An example would be this one has customer, we call it sessions for what the actual individual call or survey result or whatever it was, those are sessions. Then there's nuggets. Nuggets are basically insights from it, so when we... after we analyze, we put them in there. Then we have what we call studies. Studies are basically each like thing, whether it's onboarding that we're doing right now, early access onboarding our first batch or the feedback form from our... we have a feedback form in the app or Drift because we use Drift, or we got on a demo call or even Twitter.

Hiten:

Those are studies and really those are like equivalent of inputs or channels where we get feedback from or things that we're deliberately doing proactively like studies. Then all this stuff is connected together in Airtable and it makes it really easy to be able to see the data in all kinds of different ways. Excuse me. That's what we've decided to do. It's been tremendously helpful because now, every time we have a new study, it just goes in there and then if there's a link to like the planning or process, there's just a document that's linked and then the documents are there. We felt like we wanted to create a process that was for us instead of a process that is dictated by a tool.

Hiten:

Because we know there's a bunch of tools out there now that supposedly help you do this and I say, supposedly, because the typical model is you take a spreadsheet and then you turn it into a SaaS product. That's cool but then I've got to buy into the structure in your spreadsheet in order to like your SaaS product, but I don't know what spreadsheet you use. Then I look at your SaaS product, I'm like, "Holy crap. That's not how I want to do it." Then now, I build a SaaS product to solve that same problem and that's how we have so much SaaS. But, Airtable has definitely helped cut that crap out because these items link together. In the customer base, there is an ability to choose which study it was. It's just like a dropdown, we can just pick what study was it and then all of a sudden, it's just connected to the other table and things get populated and they start working. It's not hard stuff to set up.

Gia:

This is so fascinating to me because I actually... I recorded yesterday a note to self about how to organize this stuff for us, Claire. FYI.

Hiten:

Real quick.

Gia:

Yeah.

Hiten:

Real quick. Zapier has a great... I don't know what they call it, but Zapier has a great one for their user research studies that I would just copy and then go modify. It is amazing. Anyway, please continue.

Gia:

Well, no, I was just thinking that the... I think sort of maybe synonymous with your study would be the lens that I tend to go towards, which is like, which milestone in the customer experience are we solving for? Similar how you would have said, we're doing a study regarding onboarding then I would put that under the category of whatever the stage for the first or the second stage of evaluation and any learning or insight. I like how they're all individual responses, that's probably... I can't imagine the size of that document, it must be huge. But I find that, that's a really interesting lens of the study, what we were... a very specific thing we were solving for. I think one additional lens I would probably add would be customer experience stage, whatever stage of the customer experience-

Hiten:

Love that.

Gia:

... that we're solving for. Also, because the reason for that or the reason why it also gets a bit complicated in my mind, which is why I haven't fully fleshed this out yet, is that a lot of times in a study you'll learn stuff about multiple stages because depending on what you're asking or if it's an interview and you get just nuggets, so to speak from different sort of stages of the customer experience that you could potentially solve for either now or later, they're just like to knowing where to house that stuff for when you need it. Yeah, just in my mind, like slicing it by where it is most applicable to helping the customer achieve value is the lens that I would apply to it. But I like study because it's very similar just with the subtly different... It's more like a goal oriented.

Hiten:

It's amazing. We're actually really excited to continue using this method.

Gia:

Cool. We will track that down and make sure that we include it in the show notes for sure.

Hiten:

Awesome.

Gia:

I would love to ask about team and what the makeup of the team is and who are the ones conducting the research and responsible for the projects, who are the ones who are on the receiving end that implement? What does it look like inside the team? I don't know much about the structure of the FYI team so that's what I'm curious to dig into, which is in line with the next question anyway.

Hiten:

I don't know much about the structure either, just kidding. My personal thesis and some folks on my team are forced to share this thesis unfortunately is, more people, more problems. I even did a tweet yesterday that was interesting, which was like, it just popped in my head but it's like, most people think of growing a business and they think of... this wasn't a tweet, it was just my idea, but think of hiring people, so growth equals hiring. I'll start there but where I'll go real quickly is, we have Marie and myself and then we have a third person who's sort of a growth product manager, that's the label we gave him. He's relatively junior, but we wanted him to help us just think through a lot of the different things around growth for our business, while also we build products, so he does things between marketing and product.

‍

How customer insights are communicated to their designers & engineers, and brought to market as new features

Hiten:

There's three of us and then there's a designer. Then there's also another designer that we use sometimes, because I've worked with him for 16 years and he works on a bunch of stuff, but just yeah, that's a very special relationship I have. I value design really highly and I also value the fact that we design things extremely fast with very few design resources, on purpose. Because the one area that I've seen businesses blow out and then slow down, besides engineering, which isn't really slowing down if you're doing it right, is actually design. I think that most companies have more designers than they need. That's just my opinion. It's literally four of us, the designer is pushing pixels. Period.

Hiten:

What I mean by that is he doesn't do research. He is, I would say, early to mid in his career as a designer, if you want to call it that. I mean, I've worked with a lot of designers so I'm just giving a perspective there. What he's best at is rapid iteration of ideas, usually not his ideas. Again, I'm being specific about some of these people on purpose, because I think you have to build team based on the people you have until you can build a team based on the people you need. Those are two very different things. The gentleman I've worked with for 16 years, I can give him a problem, very high level in like half page briefs of design stuff and it gets cranked out and I have a whole product if I want, all designed, all done, no questions asked, you just on it. But I've been working with them for a long time, he knows how that flow works.

Hiten:

That's different than this designer who's our head designer at FYI, where we give him ideas. Some of the best ways to work with him is actually, we'll been doing this more once we figure this out, but it's basically, we'll go learn something in research, and we'll literally get on a hangout with him and he'll design right in front of us. Usually it's even like 70, 80% to 90% polished and done, and we can go user test again or go do whatever the next step is. For us, everything being rapid is really important. Marie, myself and our growth PM all do research, and that's just the way we do it and that's whatever research you want to talk about, it can be user testing. It can be interviews. It can be surveys. It can be competitor research, if you want to call it that where you analyze... we do that a lot.

Hiten:

We'll see something pop up or be like, "Oh, that old company, old whatever has this feature, we didn't realize it." Then we go study the feature somehow. Whether it's mentioned in competitor, in review sites or whatever, because we just want to understand what the customers are dealing with. It's not to look at the competitor, it's to look at... it's to understand the customer better by looking at how they feel about those features that the competitors have. Team's really small on that side and outside of us four, I'm trying to think, so that's designer, growth PM, and two of us founders. I've got a shit you not moment, so just give me a second. I think everyone else is engineering. Everyone else writes code, and there's about 12, 13 people right now, we've done a bunch of hiring recently. That's the makeup.

Hiten:

All those folks and I know you're probably going to ask this, so I'll just go after it, all those folks tend to get the information when we write tickets, when we write the specific thing that I haven't really shared before that we just came up with a few months ago, which is this idea that we've been stumbling about on what to label it and how to do it. We used to call it something else and we haven't shared more about this, I don't know if we will, but it's called Step Ones. Literally, everything starts with a step one document. That document is about a page to two pages and it's what kicks off a discussion with engineering. It's the way we communicate about a new feature iteration whatever with engineering. The reason we call it step one is, it's too easy to have a spec that has step 50 in it. One all the way to 50.

Hiten:

We're like, "Wait, that's great. We did a bunch of research. We learned a bunch of stuff. Now we have a whole feature in mind, but that feature if you built all of it, you have an unknown amount of time that it's going to take." All step ones we do, have to be built within a week. That's it. That's the way we think about it. The step one concept, plus the constraint of one week, those two things end up making... they end up being the asset that's created based on any research we do or any ideas we have and that includes prototypes or designs in those step ones of what the step one is. There's rarely lots of designs in there of what step 20 is. There might be designs of what step two and three might be, but again, I say might because again, you get the thing in front of customers and everything you thought usually goes to hell. It's like, "Go throw that shit away. There's all this other crap that really matters."

Hiten:

When you do step ones, you allow yourself the room to figure out, was step 10 supposed to be step two or was step, I don't know, 50 step two? Because those are very different ways of thinking about what you need to do in order to produce something that really matters and that really gets adoption, engagement, hits the mark with customers. For us, I know you asked about team, we keep the team small but it's really about the asset because that asset that we create, is what leads to all the rest of it getting done. Without that, things don't get done.

Gia:

There's so many directions I want to go.

Gia:

One is engineering and how you pursue the step one type projects. Another question I have is more on the marketing and growth and awareness side of things, just out of genuine curiosity. But on the step one thing for a second, and I am being conscious of time.

Gia:

Do you use a customer advisory board to put those through too, or do you roll that...? How do you roll that out?

Hiten:

We like feature flagging. Yeah, go ahead. What were you going to say, Claire?

Claire:

Oh no, I was just going to chime in, that was my exact question too, is what is bringing in the customer actually look like.

Hiten:

Awesome.

Claire:

Jump in.

Hiten:

Yeah. Yeah, it totally depends on the feature. I think I consider user testing bringing it to customers too. We might user test something that's live, or we might use test something that's prototyped if we're not confident in the step one. Because of step ones though, we've actually reduced our reliance on user testing because the chunk is so small, whether it's a week or it's just something small that you could just almost feel really good about, because it's literally not word for word what the customer said because you don't do that, but it's word for word aligned with the solution based on what the customer said.

Hiten:

Anyway, so the way we roll it out is, we feature flag things. We will first let ourselves use it, so there's an internal release. Then there's a early access release, which is feature flag. Then there's the sort of in the wild so to speak, and those three are gated and they have some milestones that we pick. Internal release should happen very fast and iteratively before the thing needs to be... before the end of the week, let's say. Let's say you start on Monday, weekends on Friday, Wednesday, Thursday, maybe Friday morning we're looking at it internally. Usually because it's step one and it's really scoped and our engineering, which I can talk about, is very plantful. A word for our engineering is plantful. We end up basically doing the internal release, QAing it if you want to call it that, I don't even know what QAing is anymore, but totally other topic.

Hiten:

Then we ship it to customers if it's good and if not, there's a bunch of cycles of iteration. But, I can't stress this enough because it's such a small chunk, there's really not as much back and forth the second it hits the internal release before it can be feature flag for customers. We have a channel right now called Onboarding in Slack and every time we release the new features for teams, oh not release, every time we want someone to have it, we don't even have an admin or anything we literally ping in that channel, "Hey, we'd like this domain to have access to the team features," and some engineer goes and just takes care of it.

Hiten:

Usually our CTO because he's the one with the most time, supposedly, when he's not recruiting or whatever he's doing, sleeping, I don't know. He goes and feature flags it for them and the feature flag is just an internal database flag, not anything fancy. We plan on doing that with everything we release. The same feature flag exists for a component... a different feature flag exists for a component of the team's feature that not every company should have, et cetera.

Gia:

When I hear, Hiten, you describing things this way, I'm then left like, I guess it's because the team is small enough still that you can keep very close to all these things that happen. But I can imagine that this type of process, add 10 more people, 20 more people, 30 more people, you could get unruly quite quickly if there isn't a very clear, I'll say guidelines, even though I know that's too loose, but a vision for each of these things. Then you mentioned a Slack channel dedicated to onboarding, so there is an understanding by everybody that's in that Slack channel of what an onboarding is, what it should look like, who that customer is, what the needs are. There's the... it's the confines of that.

Gia:

I was actually wondering, operationalizing not only the customer research, but then what comes out of it, which is I believe what you're describing. I hear Slack channel. I hear Airtable. I hear Slack channel. I hear process around a very, very simple step one. I'm just wondering, does that... you've kept very small, which I think, by the way, super, super commendable and I'm all on this stay as small as possible for as long as you can bandwagon. But, as you begin to add people, do those guidelines or that vision, does that live in your head right now, you and Marie's head or do you have a process or is that documented? What does that part look like? Zooming out of it, I guess.

Hiten:

Yeah. I mean, we're a fully remote team. I've said before, many times that I think you need double the process and documentation for half the size or whatever way you want to look at it. If you're 10 people, you need the process and documentation of like 20. We're probably doing things as if we're like 30 people-ish and maybe 50 knowing us, and so lots of stuff is documented. I think even, the beauty of something like Airtable, it's very clear when you look at it of what's going on in it. I don't know why Google Sheets and those other products are not as clear. I'm not usually a fan person of anything, but I do like Airtable.

Hiten:

I feel very confident that someone can come in as we scale, look at it and understand it, based on the different views we've created and we would create a process document when the time was right. We have done these before and they've become obsolete really fast because we iterate the process more than most people. Even the step one concept, we tried other things, we had a... we called them the feature discussion document that didn't work. That was a dumb name. It didn't really align with what we needed to do, and that was the asset to talk to engineering for the first time about something. Now it's a step one. Everyone understands that terminology.

Hiten:

It's like, some people call it internal marketing, but really the words and what you call things matter. Even now we just... I just came up with, "Oh, this call is a step one. Great. Okay." But my point is the iteration happens so fast sometimes or so like at a cadence that we would do just-in-time process for some of that stuff. Some of those problems we get solved with certain types of onboarding things, which even FYI is overtime going to be designed to help us with, and help our customers with as well. For us, I think the way we treat this is, one, we're waiting for FYI to have a few features, because we think that'll make our lives easier, but if we were to do it some other way, we would create a document and the document would have a bunch of links.

Hiten:

Then obviously, they would go stale and all that kind of crap, but that's a whole different story. Just in time documenting a [inaudible 00:50:32] processes as we scale this side of the company would probably happen, but when you say 10 and we're, let's say three right now because the designer doesn't really count in the research, we're not getting to 10 any anytime soon. All we're hiring is engineers. Part of it is like Marie and I will do all the marketing, all the product, all the sales, whatever needs to happen for growth with very little assistance outside of the people, the one or two people on the team.

Claire:

I honestly, I do want to use this as a jumping off point for a potential part two, because there's so much-

Hiten:

Cool.

Claire:

... so much we could go into here. But I feel like if I start to go down the rabbit holes, it'll be another 30 to 45 minutes worth of conversation.

Hiten:

Yeah. I'm more than open to that. I would love to do it. Like I said, this was very delightful, you two know what the fuck you're talking about, most people don't.

Claire:

Thank you.

Hiten:

I really appreciate, I appreciate that. Otherwise, it's not as interesting and the depth isn't there. I think people need depth on this stuff. It's like, so when you dig in and you ask me how we're doing this stuff, look, honestly, I have no idea if what we're doing is going to work. All I know is it's working right now and it will change in the future, but I'm pretty sure that some of these things have been iterated enough that they're going to keep working for us.

Claire:

Right. Well, it's such a... it's so interesting to really talk about the nitty gritty of what this looks like for you and the team on a day to day basis, or like you said, at a feature by feature basis. Thank you for being so willing to really dive into that, super interesting. I had wanted to ask this question, for people who want to implement something we've talked about, what action would you recommend they take, but that feels almost silly because we've covered so many different areas, whether it's prototyping a feature or consolidating and centralizing research, or staffing your... or planning for your team growth. I don't even really know how to go about shaping that question. You're welcome to dive in if you've got [crosstalk 00:52:41].

Hiten:

I'll drop one nugget that might be useful. The number one thing that I think anyone can do that they're not doing today is go out there on the web and start doing competitive research to see what customers think about alternatives to your product or your business. I don't care if you're a coffee shop. I don't care if you're building a little niche SaaS tool. There are products out there that are reviewed by your potential customers or your type of customer or the type of person you're going after that you should be looking at. Like I said, don't care if you're a coffee shop, don't care if you're a software product, this is the number one thing that anyone can do.

Hiten:

You don't have to talk to anyone, you just need to sit on the internet for a little bit, which all of us do anyway, and just start organizing that information. The amount of insights you can get just doing that, as long as you have the idea of, it's not about my competitors, it's about my potential customers or my current customers, that's all the lens you need. Because then you're listening to what they have to say about these alternatives to what you're doing in your business. That's the tip I got. That one anyone can do now.

Claire:

That qualifier you threw in there, I think was very important, that research is not about like, "Oh, what are the features that this direct competitor has?" It's about, what is the market that you're trying to build for, what are they saying and what are they thinking and what are they feeling and what are the pain points that exist there? I'm really glad to-

Gia:

Yeah.

Hiten:

I need to do that or people will get me wrong and so it's more about the case studies, not the features page, for example. Listen to all the case studies, in fact, I'd tear the case studies down if I had a direct competitor and literally figure out why the heck people love the product. Because obviously they're biased, that being said, there are case studies from companies saying, we like this thing.

Claire:

Right.

Hiten:

That's huge. Sometimes if you're really listening, you'll figure out why they don't like it.

Claire:

Right. If you can master that skill of learning to, not make up your own answer but read between the lines a little bit.

Hiten:

Exactly. That's right.

Gia:

Review mining too.

Hiten:

Oh, yeah.

Gia:

I mean, not as in depth but you can do so much review mining and there's so many available now, just like a silver platter of information and market research and voice of customer, there's just so much there. I mean, it's an unpopular opinion. Do competitive intel? Nobody wants to do competitive intel and how many founders are like, "No, it doesn't matter, purposeful blinders." But yeah, that is everything.

Hiten:

Yeah.

Claire:

All right. Again, I want to thank you so much for a really fascinating discussion.

Hiten:

Likewise.

Claire:

Have a great rest of your day-

Hiten:

Thank you.

Claire:

... and talk soon.

‍