A Product Market Fit Show | Startup Podcast for Founders
00:29:42 · Tushar Mishra
And then most importantly, there's not a lot of differentiation in what I can do in scheduling today. So I can do scheduling, I'll be another scheduling vendor and it'll just confuse my go to market. So we started ignoring some of those things. So as you start to do those iterations, being very clear about your hypothesis, the problem that you're solving, and your ICP becomes important because that's how you stay disciplined. So that was one thing that came out of these conversations. We would make those changes, the Figma prototype. And in the next demo that we'll have, we show the new one. And we'll reach back to the old one saying that, hey, okay, we added these things. Do you wanna look at a new demo? Sometimes they would say yes. And some of those conversations would actually turn out to be an actual customer.
00:30:27 · Pablo Srugo
[00:30:27] S1: Yeah. The the thing or the dive deep, you you touched on it a little bit was, first of all, you only take feedback from true ICP customers that are actually thinking about paying your product. I think this is something that, especially first time founders get wrong too often is they'll ask just about anyone and everyone, hey. What do you think of this product? Like, what do what do you think is missing? Right? People that are tangential, this and that. And asking is not a problem, but taking the stuff too seriously is a problem because then you end up adding a lot of things from people that have no no skin in the game. So they'll just say things just to kinda say things, and and there's no reason why their opinion, frankly, is relevant at all. So I think that's one piece. But the other piece, maybe a little more nuanced, you talked about scheduling. How do you tease apart customers, even legitimate customers, ICP customers, will very often... Especially if prompted. Right? So it depends maybe that... That's part of it. But, like, especially if prompted, they'll they'll give you advice. They'll give you opinions, feature requests, whatever. How do you tell which ones to build and which ones not to? Like, what's the framework for for teasing those two apart?
00:31:25 · Tushar Mishra
[00:31:25] S0: That's a great and a very nuanced question. Right? So the way I think about that is there are two things that you are trying to balance every day. And this is why when you talk about product management, a great product manager is not the one who is just making a list of all customer requests and building that in the product. A great PM is somebody who has a vision, who understands the problem really well and who has a vision for what the outcome of that problem would look like. And now you need customers' help in figuring out the nuances, right? Which is I, on my own, cannot make a decision of what the org structure, that setting should look like on the product without really understanding how these organizations are structured. So that's the approach that we took. So while we were having these conversations giving out demos, we had a perspective on the industry, the ICP and the problems that we were looking to solve. So we knew that our ICP was the franchisor, which is the brand. We understood very clearly what are the things that they care about, what are the things that they care about that they can also pay for that they have the budget for, And what are some of these problems that are common across most franchisors? So that's one sort of vector. The second vector is what does the competitive set look like? Like what's out there in the market? How does that work? What are people using those things for? Why do they buy those things? How much do they pay for it? And understanding that really well also becomes important. So because you have these two, now you have a perspective and a view on things that you want to do and things that you don't want to do. So you want to learn from customers on how they actually work, what their workflow is, and then make an assumption about the solution, build out a prototype of solution, and then see their reactions to the solution and then iterate on it rather than asking for problems and creating solutions to those problems. Especially on the feedback, I think I really like the point that you mentioned, which is, yeah, there are lot of people who would give you feedback, which is great.
00:33:30 · Tushar Mishra
But I've also seen there's usually a selection bias in getting feedback Because the kind of people who would typically respond to give you feedback are more on the early adopter side who anywhere on the frontier of like different things. They have seen a lot more. They love to give import feedback. They're more tech forward. And so building your worldview based on what you're learning from them can also be dangerous. And then in certain markets, can build a large business with early adopters and eventually scale. So understanding your market where, okay, early adopters, how much depth do you have in that market, and is what they're saying makes sense even if they're actually paying you money? Like, I
00:34:10 · Pablo Srugo
[00:34:10] S1: think we all understand that simplicity matters, but at the beginning, when you have effectively a blank canvas, it's easy to forget that. And I think even with AI now, if anything, this is more of a problem because a feature request only costs less than it ever did. So why not do it has a weaker response. But in the past, it's like, well, it's gonna take three days. It's not worth it. Now it's like, it's gonna three minutes. So why why are you fighting it? And what you might miss there, this ties into your early adopter point, is early adopter tech types, like, they understand technology in a way that, by definition, the later adopters don't. And so they're more willing to have a product with a lot of features, a lot of things, like, you know, kind of they can go and configure it the way that they want, and that's maybe fine for them. But the average people, the masses, if you will, like, they don't want all that stuff to be cumbersome. Simplicity... And I I would argue for most people, honestly, and for most products when you really boil it down, like, that's what's hard, is sometimes stripping it versus adding. So it's a risk that it's just kinda hard to see it upfront. You start saying yes to things, you start adding things. You're like, okay. Well, then if you have this view, then we should do that. And if you're this type of person, we do that and this. When they start competing, all of a sudden, you know, your product is just so cumbersome and so hard to understand when you see it for the first time as a new user, it's confusing. And so that's what I think you're you're also watching out for when you when you listen to feedback a little too much.
00:35:31 · Tushar Mishra
[00:35:31] S0: And I think one quick thing to add there is a great example is playing out for us in real time here. So if you look at like OpenClaw, when that first like it was all early adopters and everybody like it was complex. There were some agencies that were charging you to set up your OpenClaw and people don't do it and more complex workflows. And then you compare that with Mules now, which is how do you strip that down, make it super simple for somebody who can actually use it every day. That is extremely important because when we would go against the legacy provider in the market that we were trying to replace, they had a lot more features than we did. But people hated it. They hated it for the reason that it was complex. It was too cumbersome. The UX was a mess. Mobile app did not work. So we knew that if we do the same mistake, we can add the same features. Like, that's not the hard bit. But unless you think about the problem from first principles... And great example of that is the training example. If I want to build an LMS and build it feature by feature, I'll build the same version of an LMS, maybe slightly better UI. But if I think about the problem for first principle, which is I need to teach a 16 year old how to quickly start being productive in a pizza store, then I think about that separately. I know that that guy grew up with Google, so I need to have great AI sorts so they can get just in time answer. I am standing in front of a point of sale system, I need to be able to ask, hey, how to apply this coupon code and do it instead of me teaching that in a video or in a silly motion graphic sort of thing, which most LMSs were doing.