THE STARTUP CHAT

[0:00:01]

Steli: Hey, this Steli.

[0:00:03]

Hiten: This is Hiten, and today on the startup chat, what are we gonna talk about today, Steli? This was your choice.

 

[0:00:08]

Steli: This was my choice, yes. (chuckles) We’re gonna talk about the most common product mistakes people make, startups make, and even some fucking mistakes that you made last year when it comes to building products, which you only did five of, right? So this is based on a talk that you and Marie gave at SaaSFest a few weeks ago, but also based on the I think most recent product habits e-mail. Again, quick shout-out for those that are listening to the podcast. Probably everybody has already subscribed, but for the new listeners, if you’re not on the e-mail list, make sure to go to producthabits.com and get on the e-mail list. Some of the most valuable stuff on the interwebs, and definitely one of my favorite e-mails I get from Heton. So the last e-mail two days was kind of an e-mail where you write in detail, in depth about the most common product mistakes you’ve observed other people make and other startups make. Those are some of those that you made, and I thought, “We should talk about this, because it’s gonna be super valuable to people,” so yeah, that’s what we’re talking about.

 

[0:01:18]

Hiten: Yeah, I’ll give the background. We know everyone builds products, you know? Even if you’re not on a product team, we just know that, like, whether it’s software, hardware, even if you’re a services business, we consider you someone who builds product, and we consider the service a product. So what Marie and did was we got really excited this year as the year started to actually ask people on our list what their biggest product mistake was. And so we asked that question last week on Monday, and then — was that last week? No, it was this week. Holy crap.

 

[0:01:56]

Steli: (laughs)

 

[0:01:56]

Hiten: So we asked that question this on Monday, and we got a whole bunch of responses. They came in super fast, and people were telling us their stories — very elaborate stories, some of them — about the mistakes that they made ’cause we asked them to. And we said we’d share them. We even said, you know, we might use your name, if you want us to or not, let us know. We ended up not using anyone’s name, not because they didn’t say we could, we just felt like, “Let’s just keep it anonymous and more make ours not anonymous.” And this actually came from what you were saying, Steli, is her and I gave a tandem talk, which I’ve never done before, and we talked at SaaSFest 2017 about our mistakes that we made. And we went really in depth, so I’m gonna go through a few of them, at least ours because I think they’re very indicative of mistakes other people could make, too.

 

[0:02:46]

Steli: Yeah.

 

[0:02:46]

Hiten: And then I’m sure we could have a discussion about product mistakes and probably how to avoid them, right?

 

[0:02:51]

Steli: (laughs) That’s a good angle, for sure.

 

[0:02:52]

Hiten: That’s probably a good idea. So what we did is one mistake we made was we built shiny objects, and it was one specific shiny object. But we built it because we were really excited about it, but we actually didn’t dig in enough into the market and the opportunity and realize that we were gonna have a retention problem. And that means that we wasted a few months, in that case, of building the product, and honestly, it works. People love it, but they only use it once a year or twice a year. And these days, unless you have some other model like a services business or something that’s not software, it’s actually very difficult to create a product that people only use once or twice a year, and that’s what we built. I’m sure we could’ve kept iterating and figure it out, how to make it work. It was just one where we also weren’t as excited about the market after we dug into it after building the product. We feel like we could’ve went in to prevent that mistake and dug much deeper into the retention of the product and how often people would use it instead of just getting excited about the category. We were really excited about the category. Another mistake — I’ve got four of them here — but another mistake, so this is number two, so we took the code from one product, and my bright idea was to copy and paste it, which is a non-technical technical term that everyone understands, I’m sure. And our engineer said, “It’s cool. We can do it.” So it wasn’t my fault fully, and we decided to copy and paste it. And what we didn’t realize, especially with the things we wanted to add to it, is that it was gonna take longer than we thought, and it wasn’t as simple as copying and pasting, you know, in a Word document or a Google doc a paragraph and moving it around. Code is not that simple, is the learning there. And so we done more technical research, which means digging in to what it would take to copy and paste it, we would not have done it. That product probably wouldn’t even exist today. So, you know, another learning, another harsh one. Took a lot of time. Number three was we forgot to research our competitors. This one was good, though, because even though we forgot to research our competitors, we actually remembered early, partly because we made bigger mistakes before in that year and realized that we better catch them early, so we’ve been having more discussions about, “Are we doing the right thing? Are we focused on the right problem to solve right now? Do we have enough thorough research?” So what we realized is that we didn’t, and so we were creating a product in the document space. And so we decided to research and do competitor analysis on a bunch of the products in the space, whether it’s Google docs or Quip or Box, and those aren’t fully competitive products to us. But they are products in our space that we hypothetically could’ve been competing with, although we’re not going to. We found another opportunity, so we researched those after we realized that we almost didn’t. And that gave us such a unique perspective on the market that we were then able to share with the audience, ’cause all this stuff we’ve been sharing as we’ve been going, too. We haven’t been sharing it as mistakes. We’ve been more sharing it as we do stuff and we learn, so it was really nice to close off the year and share it like this and then start off this year and get everyone else’s stories. This has been really a fun year so far on that list and with that audience, and it’s just gonna get better. Another thing is we were actually afraid to run user tests, because we thought people were — you needed expertise, and I’ve been that with my companies for years, “I” meaning “our teams.” And always, it was a designer or a user researcher or a product person who had a design background and was very familiar with the tools of the process or a firm that we would hire to do it, and so we missed out on months, probably a whole year of learning, because we weren’t doing it. And now we have multiple user tests running all the time after we got over that hump and realized we don’t need expertise. Just figure it out. And I think, you know, the way I would say it is that, like, everything can be figured out. You just need to know that it can be figured out and get over your issues of expertise and experts needing to do things in most cases. Not all cases. And so those are the four kind of mistakes, and I think they’re very common in a lot of ways. And ours were very specific to our problems and the stories, but at the end of the day, the most common theme, even from the research that we did by asking people for their mistakes, is that people are basically really have a lack of focus and don’t know how to get focused, is probably the high-level mistake I see most people making based on their responses to kind of our question about this. So, you know, I would challenge you on this, Steli. What mistakes have you made on product in the last year?

 

[0:07:42]

Steli: Huh.

 

[0:07:42]

Hiten: ‘Cause I didn’t hear from you, bro!

 

[0:07:44]

Steli: Yeah.

 

[0:07:44]

Hiten: I didn’t hear from you.

 

[0:07:46]

Steli: (laughs) Well, you know, if I respond to this, I’m gonna be very prominently highlighted, so I’m just gonna chill and talk to Hiten about this about podcast. So that’s a good question, what mistakes we made. I think one thing that stands out to me is that funny enough, like, at the beginning of last year, we hired our first success team, right? We started building a success team, and we said, “All right, so the first time — ” We have a pretty amazing support team, but we said, you know, “For the first time, we’re gonna be practicing investing and reaching out to our customers to help them get more value out of our product.” We’re super excited about that, and we put together a really awesome team. These, you know, gals and girls, they did a great job in, like, reaching out to customers, caring about them, championing them, helping them, but one thing that happened kind of by default and not by design is that, you know, when they looked at all the customers we have, they had to prioritize somehow. And the simplest way to prioritize was to say, “Hey, let’s start with our biggest customers and learn how to help them and make sure that they get the most out of the solutions, as they’re paying us the most money, and then work our down to the smaller ones and figure out more scalable ways to help the smaller ones as much as we do the big ones.” Totally fine, totally logical rationale. The funny thing is that as we started more practically reaching out and talking even more to customers, we started talking to a specific stakeholder of — we have customers. There’s multiple users and stakeholders when you use a CRM, it is the end user, the sales rep, that’s using the tool eight, nine hours a day, but then there’s the sales manager, you know, that tries to, like, keep track of a small sales team. There’s the sales executive, maybe the VP of sales that just checks the tool out maybe once a week or once a month and puts together reports and that type of stuff, and then you might have a founder, a CEO, other executives that might want to take a look. You might have technical team that use the PI to integrate it with other things. There’s multiple people that use the product, right? And different kind of personas, and our most important persona has always been the end user, the sales person. We always wanted to build the best sales tool for salespeople. Not for managers, not for executives, not for anybody else, but our number-one priority was always the salesperson itself and their productivity. And because our success team started reaching out to our larger customers, they started talking to the managers and the admins and the higher level-ups. They started getting more and more feedback from these people, and they started conveying that feedback very vocally, as they were really strong champions, back to our team. And without even knowing, we started focusing more on the use cases and the things that are admin users wanted and a little it less on our end users, our salespeople that use the product eight hours a day, and, you know, I think that we kind of lost a little bit of touch with our core customer. We developed I think a bunch of stuff in the product that are features that long-term, I still think serve our customers well and are things that we would have wanted to do, but it was not a balanced field. We did too much for the admin and too little for the sales rep, and it took us, you know, it took us like eight months into the year until we realized that, until we even started having internal discussions that were differentiated of talking about different users personas. Before that, we always kind of intrinsically knew we want to build the best sales tool for salespeople, but as we started growing as a company, growing as a team, and as we started building to the — creating the success team, the success team started reaching out, we lost our sight of that. And we had to kind of find our way back and get back in touch with our most important stakeholder, which is the salesperson in terms of what kind of features, what kind of products and innovation we develop, so that was the biggest mistake, I think, that we made last year. It was a very admin-focused year from a product-development road map, and I don’t think that was by choice. That was by kind of mistake, kind of just happened organically without us strategically deciding we wanted to go that way.

 

[0:12:06]

Hiten: Interesting. Yeah, I think product is actually very challenging today, and I’m realizing that more and more as I build more products. And I’m also realizing that, you know, as they say in a lot of times, it has everything to do with team. So, you know, your perspective and kind of that mistake or that way to frame it, I think, is really valuable. For me, like, I feel like in product especially, like, if you want to talk specific to software because that’s what both of us do, for the most part — this is also a product, by the way, this podcast. And we always look for feedback, so if you have any, hit us up. We always tell you how to, so I won’t get into it right now. But the point I have is, like, I think setting up a team that wants to learn, setting up a team that keeps their eye on the right ball, those are the hard parts of products, and we’re just barely getting into a place where we can be very systematic about not making these mistakes. We can be systematic about learning how to do better all the time on product, so I guess my question for you, Steli, would be, like, are there things that you’re looking to change this year on product, on your team?

 

[0:13:27]

Steli: Yeah. So there are a bunch of things. I think one thing was that we set a much better kind of year priority in terms of, like, some of the big innovation things that we’ve been wanting to do and haven’t prioritized enough yet, so that’s something that I’m excited about. But also, just, like, starting to track NPS scores based on different user personas and just doing a lot more research and being a lot more diligent in the way that we introduce things is, I think, the main goal here, and this is also what I wanted to say earlier. What I noticed — the four main kind of mistakes that you described last year making, funny enough, they’re all, like, research mistakes, right? The first one is, like, doing better and more product research. The second one is doing technical research, which is interesting. The third one is doing competitor research, and the fourth thing is doing user research, right? Usage research or whatever you want to — user testing, but it’s all just, like, research based on people using something and giving feedback. So it’s interesting as, like, those four levels of research, ’cause a lot of times, we say, “Oh, you know, before you launch a product, do research,” but what does that really mean? And I think we — people will mix some type of, like, looking at the market and maybe looking at a few users, but, like, thinking about it in very kind of categorized ways, especially the technical research is an interesting one that I think a lot people forget. And that can make a big difference in how the product then ends up or how late it ends up being developed or how unsatisfactory it is. All that is, like, just do your homework, and do it a lot more diligently than you think it’s needed. And for us, another thing that really was a big change that we do now, we see a massive difference in the quality of product we’re able to develop, is that, you know, we’re just — we used to develop features and new products and then literally test them as little as possible, you know, because we want to launch as fast as possible, and then just launch. Launch, see what happens, make a few improvements and adjustments, and then go on to the next thing, and now we’ve become much more diligent in, you know, A, testing internally really heavily, then releasing these new features in our company and having company-wide usage and testing, then selecting, you know, 25 to 30 customers we think are kind of diverse group but also the group that will benefit the most from that feature and onboarding them in a beta program and releasing the feature just to that group and doing research with them and checking in with them and getting feedback from them and building case studies. And then after we’ve done that, and usually that beta is that phase — like, the internal alpha phase is the one where you get a lot of easy bugs to figure out or easy problems to figure out. The beta one is the one that we really start developing the product and making it, like, really well-thought-out, really well-rounded, figuring out all the edge cases that are easy to overlook, and really, sometimes, you know, that beta phase might delay the release significantly. But it always makes a massive difference in how strong that new feature or product release is, how powerful, how thoughtful, so that’s something that we just started towards the end of last year, to just do that process very diligently. And that’s something that we’re committed to this year that is very different from how we used to build product and launch new features and things of that nature.

 

[0:17:14]

Hiten: Yeah. You know, it’s funny you mention the research side. I feel like it just didn’t matter back in the day to do as much as research or even do what I would call technical or any of this stuff because we weren’t in markets that were super commoditized, and this is why what you hear right now is a lot of folks are talking about brand again, especially in software and tech. And part of the reason is — and I say, “Again,” because brand is always important, but it’s become something that people are just speaking about a lot. It’s because I think they’re thinking that brand solves all problems or that by having a brand, you can have an equivalent product to other things out there and still make it work, which there’s some truth to that, but I think a mistake — I’m gonna see I think a lot of companies make this here — is overinvest in brand and either under invest in product or not invest enough in product. And for me, there is no product without research. I guess that’s, like, probably the biggest statement I can make and my biggest learning from last year There is no product without research. I don’t just mean user research, I don’t mean competitor research, I mean technical research. I mean these things that we don’t even know to research sometimes.

 

[0:18:32]

Steli: (laughs)

 

[0:18:33]

Hiten: Right? Like, there’s so many aspects of it, and I know, like, sometimes, I say, “Research,” and there’s people that have been, you know, have PhDs and been to school and done research, like real, hardcore research. And they’re like, “Research? That takes a long time.” I’m like, “No, no, no. I don’t mean that word ‘research.'”

 

[0:18:48]

Steli: (laughs)

 

[0:18:48]

Hiten: But I mean the other word “research,” which is, like, actually do your homework. Like, figure out, like what’s going on in your market, what’s going on with other products, what’s going on with other businesses, et cetera. So, you know, for me, the solution to most people’s problems is actually figure out what kind of research you’re not doing today. Figure out where you’re not digging in in product and go do it. That’s it. That’s what I learned last year, you know? And I have many different sizes of products and companies and customer bases right now, and I can tell you — and types of businesses — consulting, product-based, software, you know, consumer product goods. I’ve seen so many of these things over the years. That one thing is what solves the problem. There’s a lot of other things that are helpful, but if you do research and do it fast and do it diligently, you’re likely to have better outcomes than other people.

 

[0:19:50]

Steli: I love it. Amen. Amen, my brother! All right, we’re gonna wrap this episode up on that note. There’s nothing more to add to this. Make less product mistakes …

 

[0:20:02]

Hiten: Please.

 

[0:20:02]

Steli: … By doing more research, all right.

 

[0:20:05]

Hiten: Done.

 

[0:20:05]

Steli: Do your homework. That’s it from us, everybody.

 

[0:20:09]

Hiten: See you.

 

[0:20:09]

Steli: We’ll see you very soon. Bye-bye.

[0:20:10]