10x Your Chances of Finding Product-Market Fit with Vibe Coding — with Ali Hafizji

Most founders know their job is to build fast. But after the MVP, things change a little bit because now certainty matters more than speed. Shipping more features won't get you to the product-market fit. If you're building them blindly. So the argument is, if you don't change how you work post-NVP, you'll waste time, or actually you'll waste the little runway you have. So it's very likely going to run out of money before you find product-market fit and be another failed startup. Our guest today helps founders escape that trap. Couple of takeaways you can expect: why velocity is no pro— why velocity is not progress and how to measure learning instead, how 3-people AI-native pods can run 10 times more validation per sprint, why polishing MVPs is a bad idea, and how instead to build prototypes that test real behavior, and what tools to use to do exactly that. Hey, what's going on everyone? I'm Mike Sirius and this is Mastering Tech Growth. Every week we chat with industry leaders to bring you No fluff tips on how to grow. If you enjoyed the show, if you find value in the show, please do me a favor, leave us a review and drop us your biggest growth questions in the comments or DM me or go to masteringtechgrowth.com. I'm joined today by Ali Hafizjee, a CEO of Wednesday Solutions and creator of the WIP Sprints method. Ali built and sold multiple companies, wrote couple of books, worked on high-scale products handling over a billion requests per hour. But what we're concentrating today is his Wipesprint system, which helps founders to go from maybe this will work to this is what's working fast. Welcome, Ali.

Thanks, Mike. It was a very nice introduction, made me feel larger than life, but I'm happy to be here and, you know, talk to you and through you, your audience.

Excellent. I actually saw a couple of posts of VibeSprints on different social medias. So I did a little bit of digging because that's new to me. Like, I didn't know you created that, right? So it's very interesting to see new methods and new systems appearing which are effectively powered by AI. So we'll go into that. But before we go into, you know, the system, we love asking every guest When I say mastering tech growth, what comes to mind?

I think for me, mastering tech growth is about sort of learning to build scalable systems and teams, and also changing yourself at the same pace without breaking anything. So I think it's a combination of your systems, your team changing, and you changing all at the same pace. That's when I feel like if you've figured that out, then you will grow.

Okay, so let me rephrase this. From all the things which influence growth, and we're talking about marketing, sales, teams as well, you know, good hires, bad hires, leadership, there's many things, right? So we actually in the show, we actually have what we call the primary effect growth influencers, like, you know, marketing and sales, and secondary, which is like talent and leadership and other things. So if you would choose one from all the different factors which can influence a tech venture growth, what would be the number one for you?

I think all are equally important. So it's like the 3 Ps, right? You have people, process, and performance. All right. And in a nutshell, that's what I've discussed. But if I had to choose, I would choose people. Okay.

I love that. There's so many guests which goes with people, like the lowest denominator of any business is basically people. And if you have successful people, it's very likely your business will be successful. I love that.

Yeah.

All right, so let's get into it. You have this, and when I say you, it's, I picked this up either from your LinkedIn or maybe your newsletters somewhere, but you stated that speed Without direction is effectively a mistake. It's a trap. And we see that happening all the time. And I'm going to tell you, I would be that founder and I've been that founder which goes to the team and goes like, hey guys, we're going to build this because, you know, I'm a founder. Like, I know, I know what to build. So I'm telling you, we're going to build this. Yeah, go do it fast. Right. So you're basically saying like, like this is a mistake because Maybe I think I know the market, but what if I'm wrong, right? So we basically saying going fast to the wrong direction is actually a terrible idea, right? So the question is how, like, if it's not speed, if it's not velocity, like, how does our sprinting look like? Like, how is our day-to-day look like then?

Yeah, so I think I think founders, especially, or even founding team members, they use the word velocity a little too much. But one needs to realize that velocity has two parts to it. It's a vector. So one part of it is direction, the other part is speed. In my mind, I feel like what you need to focus on as a founder is just that direction. And directions are primarily based on your ability to identify insights. So, for example, as the founder, if you're spending all your time on the speed aspect of things, which is primarily just, let's just get this thing done. And you're too involved, and you're micromanaging, you're sort of deleg— you're just involved in defining the task, getting it done, etc. Then you will lose out on the opportunity of identifying the direction. And to do that, you need to zoom out from the chessboard and look at how you're strategically placed to be able to make the move. And that's what we say. So for example, if you look at Wednesday Services, which is the agency I run, our services primarily are meant for founders once they have achieved MVP. So we think that any founder, he has the courage to start something because he has some insight. He's primarily identified a gap, probably through his own experience. He's working somewhere, he met someone, he feels like there's a gap, I can build something. And he gets a few paying customers, usually through his own network, because, you know, that's how he identified the, the gap. That's how these things usually come up. And today, with AI tools, you can build that out yourself. You don't need help. But once you've, once you've built out that MVP and let's say raised a seed round, your role as a founder needs to change. You need to fundamentally do different things in your day-to-day. You need to stop building and you need to focus on 4 things. You need to focus on marketing, sales, fundraising, and actually observing and talking to your users. And if you do these 4 things, right, and work with an AI-powered team or hire someone and do whatever you want, if you can figure that piece out, you will be moving in the right direction, and that team should be taking care of the speed. And I can guarantee you that you will— I mean, if you're hard— I've never met a person who's sort of hardworking and not, you know, made it. But you need to change, you know, that's where founders usually struggle. Most founders, especially in the tech space, they come from a tech background. They just want to like perfect tech. They just want to work on that all the time. But their role needs to change. You need to do very different things to sort of go from MVP to finding product-market fit.

This is excellent. I love how you put that. Very well explained, Ali.

Is this—

so the opposite basically is that you're building something wrong. Or you're building something potentially people will not need. So you're going fast to the wrong direction. And that, you know, that mistake, are we saying that mistake is at the top for the tech founders? Or do you see that mistake actually happening irrespective of you having like a tech background? Like who actually goes and builds stuff without validating?

I think it's just a human sort of trait, right? Like, your brain tends to do— like we always say in product engineering, like, we do a lot of strategy as well, that you want to design your product to have the least amount of friction, you know, because the brain, like any other muscle, likes to be in a state of rest. Now, what's the state of rest for you? It's primarily doing things that are not difficult. What's more difficult than, like, trying to identify insights on what to do and validating things? It's very difficult if you think about it. Let's say you're building an online business, offline online business, whatever, like to constantly go and ask for things, to identify whether what you're building is right or wrong. Many people will just say no to you. Fundraising is not easy. You know, 1 out of 200 people will probably respond to you. These are extremely difficult things that puts you in a state of unrest. So fundamentally, I think that the reason why— I don't think it's related to just tech founders. We just see it more because I think our services are more like, they're more tuned for those. We attract a lot those customers. But I think it's a universal problem. Um, you tend to focus on vanity metrics far more than you think.

Yeah. Is it bias? Like, is it— do we have something in the brain which makes us all susceptible to that situation? Because I see that as well, Ali. Like, I see that all the time with the founders, that for whatever reason, you know, bad choices are being made. It's like people tend to gravitate to what I would call a, a, a, a wrong progress where you basically, you know, you put it very rightly where you talked about polishing MVPs. So they build, you know, they build a product, they have a set of features, and instead of actually going finding a new feature to build or improve a feature based on some, you know, customer conversations, they will sit on that feature and they will start optimizing backend so it needs to take more load. But like, there's no reason. It's just like, I'm gonna build that because, you know, eventually we're gonna get you know, much higher scale or something like that. And they will go start building that, and it feels like progress, but it's like you're going to the wrong direction. Like, no one— like, you don't even have clients right now. Like, why would you chase scale, right? So, so that's, um— so let me ask about these polished MVPs. Like, when you say, uh, you know, polishing MVPs is a bad idea because potentially polishing something which no one needs, it's like, can you give us maybe like a story or a client story or something like that? It's like, what's the context behind that?

I can tell you one story that comes to my mind. So we, we didn't eventually, we didn't end up working with them, but we were introduced to a founder who built an app for managing contacts. So basically, it was a way to share your business card with somebody else and manage like a contact book. They spent about $250K on that product, um, and the only person using that product in the world was him.

That's actually a bit— so, so he spent, he spent quarter million and, and he was the only user? Like, well, okay, well, please continue, give me more, like how that happened.

I think it happens just the way that I'm talking about it, right? Like, you see, you have to understand that, like, the only thing that fuels the founder is hope. And hope is not a strategy.

Yeah.

It's needed. I mean, of course, it's a lot of positive energy. It keeps you going when things are difficult. But you have to go through that difficulty. If you're always on the path fueled by hope, you will end up in situations like this. So one of the tests that we have when we sort of work with founders, we do this litmus test where we'll sort of ask them a few questions and we'll see if, you know, because look, we are not, we cannot help a founder if you've not achieved MVP, and achieving MVP requires you to have a few users who are not you. You know, like, you need to have some validation. It's a viable product. So we always ask them questions around, like, you know, if you were to pick any one feature, and that's your bestseller that, like, customers just cannot live without, what would that be? And if you don't have, like, clear answers to this, right, which is backed by data, We also ask a lot of questions around, like, what are you celebrating about, you know, until now? We love to discuss, you know, project plans or roadmaps with founders. And when you start listening to language, which is around vanity metrics, let's say a founder is just constantly talking about, oh, I got so many number of downloads, or I got so much traffic on my website, or we raised X amount of money. That doesn't mean anything in, like, the business world. It doesn't mean that, let's say you have a million downloads, it doesn't mean that you have a million paying customers. It doesn't mean that you have a viable business. You know what I'm saying? So the problem isn't that you have a million downloads. This is great. Like, you've figured something out, which is definitely, like, a good thing. But if you start celebrating these things, then you're going down that path of doing a lot of vanity stuff without really identifying a business here. So we look at a lot of these tests, and many founders are made of that metal where they are able to sort of separate the wheat from the chaff and able to make decisions correctly. And we see these guys, this set of people really make it, and it's not so difficult. You know, you need to train yourself and create a framework of actually making decisions. And that framework It's actually very easy to understand. You need to look at things from an outcome perspective. If I do this action, what business metric does it change? Does it change acquisition? Does it change retention? Does it increase engagement? Does it increase referrals? Does it actually get me revenue? Does it— is it a conversion? If you don't have an answer to anything, don't do it. It's just as simple as that. It's such an easy framework to make a decision. And this is what we call the pirate metrics, right? So as a founder, the more grounded you are, and you have a decision-making framework to be able to decide what metric will change, you will make the right decisions, you will move in the right direction.

Okay, is the decision framework which you mentioned earlier, is that something, you know, which came from experience for yourself, and as well, you know, how you teach the clients? Or is it something, you know, There's a book, like, feels like there's something spoke about this before, but I know exactly what you mean. But now I'm trying to like think of like, is there any, you know, recommendation we can give to the listeners where they can learn more about why it's important to have decision frameworks?

I would definitely recommend reading a book called Crossing the Chasm.

Right. Okay.

I think it's, it's It's really helped me think through what to do at what stage of the business. I also would recommend reading books on product-led growth. There's a very, very— I mean, if you just— I don't know the name. I think it is called Product-Led Growth. I think it's a fantastic read. It talks a lot about the metrics that one needs to track. But overall, I think that, you know, Just really question if you're a founder and if you're listening to this, or it doesn't even matter if you're a founder, even if you're a product manager and you're in charge of actually building a new product, really question the actions that you're taking in terms of what is the outcome that is going to have, right? And one needs to understand that, you know, we are, we have these hands and legs, right? And if you look at our human body, these are made to actually do things. We are in a state of motion. It's very difficult to not do anything. So be okay to not do anything unless you have a reason to. So that's what I keep telling people. If you're a product manager, if you're a founder, if you don't know what to do, be okay with not doing anything. You don't have to do something all the time. But wait for that insight. If you have an ex— and the way you get your insight is marketing, sales, fundraising and talking to customers. If you have that insight, work with a team— and that's a very important aspect, don't do it yourself— after the MVP, work with a team that can convert that insight into a digital offering. But if you don't have that insight, you don't have to do something all the time.

I love, I love how you put that. I really don't do anything Like, it's, it's so hard. Like, when you were saying this, what came, what came to my mind, that, uh, it was actually— I mean, it's not related to, you know, to startups and founders, but for me it was from investment perspective. When I started investing, and, um, and when I say investing, I mean, you know, buying stocks, like investing in, in the tech market. The first and very hard realization was that you don't have to be trading all the time. Like, you don't, you don't have to move your investment if there's no reason, right? And for whatever reason, I felt like if I'm doing more, more moves, I'm actually gonna do better. And then after time, of course, losing money as well, and reading many, many books and learning from, you know, better people, in a couple of years I realized that there's no need to do any changes in your portfolio unless there's a reason. So when you were talking about this, that, that's what came to my mind. But you're absolutely right. Like, if I reflect on my work as well, You know, what you do, you tend to somehow think if you're not busy, that's bad.

Yeah.

But what we're saying is it's not, right? Because that gives you time to get thinking and actually asking the right questions. So let's go into that. So what do I need to have to make a decision? And how does the Vibe Sprint actually help with gathering that information?

Okay, so let's zoom out a bit. I would also recommend another book that just came to my mind. It's called Mastering Mastery. I would highly recommend reading that book. And in that book, it actually talks about how one moves from different stages of being a novice to a master in a certain area of work. And it talks about the insight that you get as to what might or might not work always happens at the times at which you least expect it. So for example, the best inventions have not happened when people have actually thought about, you know, segregating time in their day saying, I'm going to spend 4 hours and invent something. It's never happened. It's always happened when they were doing other things. But there's something going on in their mind, right, that they're thinking about. And the mind is actively seeking answers while looking at things from the intersection of things. So, for example, if you're a product manager, and you're working at the intersection of design, marketing, distribution, fundraising, you will always get the best insights, the more you are working creatively across them and at the intersection of them. Now I'll come back to the WIP sprint question. See, the WIP sprint question— WIP sprints don't help you find insights. Wipe Sprint is a, is our twist to an Agile sprint. Agile is basically a method of building and delivering software incrementally. What that means is that the entire objective of running a sprint is that it's a short span of time, A team will work together for, let's say, 2 weeks with only one goal, which is, let's deliver something that we promise. The entire way that that sprint works is that you need to define what needs to be done. You need to break that down into small tasks, as they call it, user stories. You have to track when, as it gets done. The entire team functions from the perspective of let's get things done. Our take on this is that with AI, you no longer need to think of things as tasks. So let's say you're running a traditional agile sprint, and everything that you do in that agile sprint is taken over by AI. There is an agent that plans your sprint. There is an agent that is actually doing the daily standup. Just collecting updates from everyone asynchronously. There is an agent that also does the programming. There is an agent that does the testing. There is an agent that does the deployment. There is an agent that does— that manages communication. So what does the team do in that week, right? So the first step before we actually launch this sort of service— I mean, all our services are powered by Wipesprints— is that first, let's do this. Let's achieve, you know, designing, building, and managing software using AI. Once we did that, we realized that the team has a lot of time. So what if we change the objective of a sprint to be driven by a business metric? So let's say, you know, Mike, you're a customer, you're working with Wednesday, and you are currently, let's say, building a podcasting app. And because you found MVP, you're constantly talking to other podcasters, et cetera. And you find out saying, hey, look, I'm talking to these guys. I'm very confident. They have a lot of distribution. If we add this feature of having the ability to go live, right, I think we'll see some traction. So what you identified is an insight. Traditionally, this insight would be captured by some product manager. He would do some design. He would do some explorations. And then he you could get it implemented in a sprint-based fashion. So you're probably looking at probably like 2-3 months of work here. We're saying all that the founder needs to do is give us this insight, right? We will convert it because we have so much time, right? We will convert it. We will convert that insight because my entire team now has time to think product. We will convert it into a digital offering. So all my team members are only thinking about the business metric, which should be how can you validate— let's say in this case, in this example, it is how can we get these few people to use this live feature and give us early feedback. So we'll think of, let's say, an entire plan saying, okay, we need to A/B test this feature. You know, let's build some small POC out. What will this POC look like? And also build it out. So now, instead of interfacing with the team in terms of requirements, you're interfacing with the team in terms of insights. The founder only shares insights, and in return gets a digital product, right, or a roadmap or a plan. And we do this entirely in 2-week batches. And the reason why this is so attractive to, like, at least the founders that we've worked with, is for the first time, founders, number one, talk to their teams in terms of insights and everything else is taken care of. Number two, the— we're able to deliver the same outcome with a team that is far lesser in size. So, you know, whatever I'm talking about would be done probably by a team of 6, 7 people. We're able to do it in half that size because we use a lot of AI. And with lesser number of people, you have lesser delegation because everyone is typically very senior generalist. So there is less sort of loss in terms of communication. So it's a very different experience, a very different way of doing things. I feel like it's, if you ask me, because I've seen the whole waterfall, sprint, you know, agile movement, I feel like we're at a point where, you know, software development fundamentally change. And this, this just feels like the right move. It's a smaller team, it's more faster, it's, it's more— I would say it's, it's, it's working because I also many a times give insights to my team and they just like get back to me with like outcomes. It's a very different way of doing things. I think that it's primarily the future where a lot of the things is going to be done by AI, but what you're the teams that you're working with are— they just speak a very different language.

There's a lot to unpack here, Ali. Thanks for this very great context setting, and it explains the Vibe Sprint, you know, very well, and the philosophy or the context why and how it was born. There's a couple of things which you mentioned which I want to circle back. So if we just started at the beginning, of doing the Vibe Sprint. So we're basically saying like, look, you have an insight, you know, you being a founder or a, you know, head of product or anyone else, right? Like it doesn't matter where it comes from, but these are insights. So we sort of raise a hypothesis around that, that if you do this, the outcome will happen and the outcome is what we want. So you need to prove this before you actually do the code or go actually writing, you know, a code in the old-fashioned way. So how do you actually like measure that vibe, like, you know, like what's the metric of like, you know, doing that insight sort of validation until you go like, this is good or this is a bad insight, like there's no demand for it, like like, what are, you know, like non-vanity metrics around that, you know, Vibe Sprint?

Yeah, let's talk about this. So for example, any insight that a founder or a product manager gets, it's always— see, it's not really an insight unless you know what metric it is going to change.

Okay, so you're saying we have an insight. Okay, let's talk about like revenue as an example. Like, we'll come up with more examples. So everyone cares about revenue. It's It's always on the table. Everyone is looking at the numbers. So let's say I have an insight that if we're going to build this, that's going to bring more revenue because it has a direct impact on what sales team can sell or something like that. That's my insight. And the feature is, to your point you made before, we have a podcasting app, we can go live. Okay, so that's an insight, right? So now we go into sprint. So the team gets that, like, what's the next step?

So what's going to happen is there's going to be a small pod of 3, 4 people. They're going to take this data, which is going to be like, you know, hey, Mike has found this insight, which is saying that he did ABC and he was able to change XYZ metric, which is, let's say, revenue. And the way that you typically get an insight is by doing something. So let's say, for example, me, I, I, I am running a podcasting app. I found these influencers. I actually wrote to them and I said that, you know, hey, like what if XYZ happens, what would happen? So you sort of create like a manual process, for example, not a digital one.

Okay.

And you have some understanding saying that, you know, hey, like these things make the person buy, for example.

So it's a workflow effectively. I'm just like, yes, I'm just drawing a workflow on the paper or with the, you know, whatever app. So I have this workflow that that's how we're gonna go from A to Z. Okay, so we have that one.

Correct. At that point, the team is going to take over. And they're going to actually brainstorm with you. Sometimes, see, the workflows that we do as founders, they're not the most optimized. We do it a lot on a one-on-one basis. Many product managers also do it a lot on one-on-one basis. There are many ways to be able to scale something up and make it optimal, right? A lot of insights can come when a designer looks at it. A lot of insights can come when, let's say, a product manager looks at it because they bring their experience into that. They may be able to get a lot more, or maybe— so we define an experience as a set of steps that a user takes to be able to get the value that you promise. So for example, the value that this insight promises is revenue. So we're going to take that insight that you suggested and create that optimal flow, or maybe we may create two optimal flows. It depends. Right? So we're going to do that thinking and then convert that and deliver that into a digital offering. So the way that you communicate with the team is just saying, hey, I tried this, this happened, I think I would like to, you know, get this thing live. I'm confident enough because I am seeing some traction.

So when you say, uh, converted to— I mean, we started sort of with the metrics, so I imagine, um, you have that flow, right? So you want to validate the success of, of that flow. So would you create some success metrics, or, or is it more of— I mean, effectively, I'm trying to understand how do you measure the Vibe Sprints? Like, because Agile Sprints is quite simple, it's velocity, it's like how many story points you actually burned. Yeah, that's ultimate. Like, like, but for the Vibe Sprints, it's more about how much you learned. So how do you measure that?

We tie it to the metric, right? So for example, let's say revenue. So if we open up this particular feature to X number of users, how many convert into paying customers? Let's say it's based on engagement. If we open up this particular feature to a certain percentage of users, do they actually open the app or web app more? Okay. You can tie a metric to anything else. Let's say it's about acquisition, and you're trying a new acquisition channel, or partner, or influencer, and you want to A/B test different things. You can try that, and you might have a metric there. So you're looking at it from a 2-week perspective, saying, I now have this digital workflow or sort of steps, right? Ultimately, every digital product is a set of steps. And you're just measuring that versus did I get this story point done? You know, because that has no influence on business.

So it's either you have an existing metrics which you track and then you can, you know, your hypothesis or insight raises an insight that is going to go up and, you know, up if it's a good one or maybe down if it's a, you know, it's a bad one, or you create new metrics which will measure success of that. Okay, so you have this metric set, you go into sprints, so you get the workflow done, and then you need to somehow build a digital product, like you said, a digital offering without actually building too much, as in, you know, you don't go into full-on hands-on writing code, right? So how do you, like, what happens then? It's like, are we saying we're going to build a landing page which explains stuff and we're going to try to sell to the customers or show it or demo it before we actually go into actually building it? It's like, how do you cover that gap going from, I have this workflow to actually I have something clients can, you know, touch and play with?

I think that, see, it really depends on the type of business. You know, if you're building a business that's a B2B business or, you know, just an SDK or an API layer, or you may build a B2C business, it really depends what maturity means or at what stage is a feature viable, you know. But what we see happen is, what I can share with you is something that I'm seeing across the board, is that the product backlog is shrinking drastically. So for example, a product backlog for a B2C app that is probably releasing every day cannot be more than a month or a month and a half. But probably, for example, a product backlog which is for a B2B app, right, maybe longer. It really depends on the type of product that you're building. But that's what you're looking at. Like, there's no right answer over here because it really depends on the type of business.

Okay, so, okay, so trying to understand, Ali. So is the Vibe Sprints to answer the questions and validate the hypothesis, or is it actually to do this and plus actually build the product or whatever is the feature?

It is to— it is primarily to do this and build the product.

It is both, right? Okay, so it's not that it's, it's a separate, uh, 3-people pod to actually validate but it actually validates and builds at the same time.

Correct.

Right.

The same team can do both.

This— the same, because it's generalistic and they use a lot of AI tools. So effectively, yes, the notion is that they're just much, uh, faster because of the tooling, so they can, they can cover more, more ground on that one. So is that means that it's, it's about replacing of current agile practices, or, or does it mean it's about complementing current agile practices?

I think it will replace it. See, I don't know what's going to happen in the future. This is my prediction. I would love for, you know, myself, I would love for this to go my way. But the way I see it, I think it's already happening. So, for example, at least the people that I'm talking to, even what I'm reading on social media, I'm looking at, like, for example, the practice of product management itself changing, where people are saying that, you know, we don't need to write PRDs anymore. We'll just make a prototype using WIP coding and share it with my team. This is what we are referring to. You are changing the structure and way in which you work. Yeah, you know, we're just packaging it as a WIP sprint because we feel like a smaller, you know, more cohesive team can deliver far more now. But I'm already seeing it happen all around us. I'm seeing designers, you know, actually make changes to like code. I'm seeing product managers work cross-functionally to actually define how architecture should be. It's just like a lot of— there's a lot of change happening in just the way that things are going to happen. I think software development, especially the whole SDLC lifecycle, is fundamentally going to change. I don't know if you remember this, but probably about a decade ago, there was actually a role role that a person played, which was like a DBA. It was called a database administrator. This does not exist anymore.

Yeah, I do agree. It doesn't exist. And I do agree, Ali. I mean, I'm with you on the notion that things fundamentally are changing. The software development lifecycle, as we currently know, is going to get disrupted and is already being disrupted with the AI tooling to the point where it's just going to be something else. Like it's just not going to be like what we see right now. I mean, it will take time. And of course, you know, the early adopters is the smaller businesses or the smaller teams or the startups because they can, right? Because it's just a couple of teams. But if you take, you know, enterprises which have hundreds of developers and, you know, the current, you know, setups, a lot is, you know, Scrum, Agile type of teams and then sprints and things like that and team topologies. And then you have like the structure of a team being multidisciplined and frontend, there is backend, there is a technical architect and things like that. Like that to become like a WAI type of application building, it's hard to think, or at least for me it's hard to imagine at this point in time simply because of the importance of every single bit of code which goes into production, right? Like everyone needs to account for it. If you take regulated markets like healthcare, finance, you know, online gambling and things like that, like, uh, depending on AI is just seen as a huge risk because you don't know what they produce and you still need to validate. So it's about the fact that it's changing 100%. I think we're both on the same page. So we're basically saying that Vibesprint, uh, vibing or Vibesprints, as you put it packaged, uh, from, from your perspective, will replace the current agile Scrum type of setups, and you're already seeing that happening effectively with startups, right?

I'm seeing it happen with startups and larger companies.

How large?

And these larger— so for example, I feel like the insight that I'm sharing with you about product managers actually just sharing was actually done by the head of product at Google. Okay. Yeah. So he tweeted out saying that, like, there's no longer any point writing PRDs. From now on, all I'm going to do is just— and I believe that this is the same kind of philosophy that's going on in companies like HubSpot. So, in general, I think what you're saying is true, that the larger companies just have too many mouths to feed, and there'll probably be a lot of friction to change. But you cannot change something that is systemic. And I feel we're at that moment. See, large change happens only when you're at the precipice. When you're at the precipice where there's no option, either you change or you fall down, then change happens. I think we're very soon going to reach there. For example, let's say, you know, there's a large— I don't know— system. Let's say you're a large pharma company and you have a systems integration project, and there are two companies, one which is saying it's going to cost you $2 million, one which is saying it's going to cost you $200,000 but give you the assurance that you're clear compliance. Which will you choose?

Cheaper one.

Yeah, so you see, these things are happening. I mean, um, um, and, and, uh, when that decision is made, let's say it is made, right? Um, they're gonna question a lot about like, okay, these guys did it in 200K, why do we have a team of 1,000 people? What are they doing?

Yep.

Um, and all of these questions are not happening because they are doing something wrong. It's because we are at that precipice of change.

Yeah, I mean, enterprises are always the laggards when it comes to adopting innovation, right? Like, because as you put it, you know, many mouths to feed. They have systems which run the businesses in every layer of the businesses, and these systems, they need to be, you know, sort of changed or redone and replaced, and it's just not something they would just onboard unless it's a research and development type of team for a whole business based on a notion, right? Like they would want to see other businesses achieving success, you know, more books, more articles and stuff like that. And then someone else at the leadership level would come in with that notion and, you know, it will help to drive that change, right? Because any change as big as this would require change management. So it would always need to have a buy-in from the CXO or leadership. So So it will take time until that sort of trickles, but things are changing. Yeah, you're absolutely right on that one. Things are absolutely very much disrupted right now when it comes to software development. So let me ask this. So we said digital, so we went from workflow to digital, you know, product, right? And then there's a prototype, an actual product. And how would you define this then, like in the Vibe situation, like what we just put with the AI tools, can we say this is a, this is a, a, a production-ready build and, and we're just going to maintain it? Or are we saying that what we build with AI tools is a very fast prototyping? It's still a product which works, but we're using AI tools, we're putting this out, we're seeing it works, and now we're going to take it and rebuilding it into something which is more more, I don't know what's the word I'm looking for, something more like best practices engineering or something like that. Like, what's the, you know, like, is that getting merged now into the same thing? Or do we still have prototypes and production quality builds?

It's such a vanity metric, if you ask me. I'm not against doing, I'm not against saying that you don't need to use good programming practices. So I'm of the opposite opinion. I think that a lot of people are saying that, you know, you don't need experienced people because now you have AI tools and all of that. I think the opposite. I think you need more experienced people. They just need to be open-minded to use AI.

Okay, I get you.

So if let's say you have a person with 15 years of experience who's built production-ready applications but now is using AI.

Yeah.

You do have production-ready code because he's built so much and he's doing it faster. You don't need a prototype.

So we're saying basically clients, as long as they use the tool and it works, they're happy, they pay. And what's behind it? Is it AI? Is it handwritten? Is it this language, that language, this tech, that tech? Doesn't really matter at the end of the day, isn't it?

Doesn't matter. You, you of course want to— so see, what matters, why, why, why do people care about, like, technical architecture, etc. It's primarily because the cost to make a change to anything digital is very high. So let's say you make the wrong decisions, you choose the wrong language, it's very difficult to hire people for that. I don't know, you build things bad, so you have to refactor things again and again. Making change is very costly. Yep, in the digital world. I think that has gone down. Making changes is a lot more faster now. And number 2, um, I'm not saying that you need to do it with inexperienced people. You need to work with a super, super highly, like, experienced team or person or number of people, like, whoever you're able to hire. But they need to come with experience of having been there, done that. Right? So they need to have the white hair, but they need to be open-minded to actually use AI tools.

Okay.

And if you get that combination, it's pretty solid.

Did you meet any senior devs who are close-minded when it comes to AI and they go like, nah, this is bullshit?

Yeah, you meet a lot of people like that, right? So I think there's a lot of chatter happening on social media about, you know, engineers wanting to fuss, saying that Well, so there's, I mean, I would highly recommend like your readers to read this report that Google publishes. They run a research sort of, I don't know if it's a research, it's a foundation, God knows what it is. It's called DORA, D-O-R-A. So every year they publish a report, it's called DORA Metrics. And this year's report is extremely, extremely, extremely interesting. So they asked a bunch of people, so the amount of AI that people are using, especially experienced developers, is not that high. So they try to get deeper into that, saying that, okay, if people feel like, you know, the code that it's getting out is nice, then why aren't people using it? So it seems like what is happening with developers is that they get their work done faster, so the remaining time in their day is getting filled by things that they think is menial. So, for example, meetings, you know, all of these things that developers don't like. So it's creating this vacuum. So what is happening is that they actually think that we should not use AI. They don't want to do these things. And if you think about it, what we've done with Vibe Sprints is actually replace that. We are saying, in your spare time, think about outcomes and think about business metrics and think about all of this fun product stuff. And not do meetings. So in a way, if you want people to use AI, you also have to start thinking about how to incentivize how to use it, which is what that report does very, very well. So I feel like what many companies have gotten wrong is that they've created this manifesto saying that, you know, we want to use AI, here's the mandate to use AI, and all it includes are things that you can't do. Do. So for example, let's say you're a regulated entity, you can't do ABC, you can't share this data, you can't— but it doesn't talk about what you should do, you know. And I think this is something that they should talk about more. Use more AI and spend the rest of your time doing so many other things. This business needs help in so many places. These are such smart, experienced people, they can help you, you know. But they don't talk about that. They talk about things that you should not do. Which is sort of like disincentivizing people.

I think the change will not come from businesses, Ali. I think it's going to come from people. I think it's going to come from people using the tools, just like you and me. I'm sure you use it daily. I use that daily as well for various activities, including, you know, doing some product and coding. So we use these tools and we know them well and we will become good at it. We will share our experiences online in social media. We will meet other people and that skill will spread. And then once we go to work for other businesses or create our own businesses, right, we will, because we will have that understanding of the value and where to apply it, we will effectively distribute that knowledge. We will go to business. Let's say you're getting hired. You have that notion, you know how to use these tools. You come in, the work and you go like, I want to use these tools because this is how I work right now. And they go like, no, no, no, you can't because we not AI-enabled company or something like that. You're going to find another company, you know, which will be either open to it or they will have more people like you. So you will build teams like that. So I think that will slowly will be phased into businesses, but by actual employees rather than business going like, hey, here's a 'Innovation.' So we all, you know, as a business, we now want you all to learn AI because there's efficiency and effectiveness. And then people go like, 'Well, what if I don't want to learn it?' Right? And it sort of becomes like a top-down versus bottom-up situation. But my belief is that it's going to be instilled into businesses by people rather than businesses instilling into people.

Yeah, I think the best change that I've seen was when COVID happened, right? And I think it's just like AI is just like a virus, right? It's just spreading everywhere. And sooner or later it's just going to happen. I mean, it's going to affect everything that we do.

Yeah, I'm seeing this. I mean, social media works very well. Algorithms works very well. Everything you engage with, you're going to see in your feeds. Like the next minute, right? So because I engage with that content, I see that all the time. But I'm seeing people, you know, young individuals, you know, who sort of go into technology from very, very young age. And because they're young, they have time and things like that. They can play with stuff and they end up playing with stuff which has the biggest return of investment. It's just how, you know, innovation and how people work. Like you would not be using AI if it doesn't help you to get to go somewhere or release something or get something done, you know, whatever is your goals, you would just not use it. That's it. Like you would find a better way. But there's many, many young people launching startups and products and it works, right? So it's just, it's just a matter of time. I do agree with that. So let's talk about these tools, right? So you guys do a lot of AI, you know, you have live sprints and then that's how you cater the market and your clients, right? So what is tools which is at the top of the list of what you guys use and why?

We're using a lot of, on the programming side, we're using a lot of Replit and Cursor. I think these tools have, I mean, for us, they're just—

Cursor is IDE, right? It's a development environment for UT code with AI. And what was the other one?

Replit.

What do they do?

They're also a programming agent. They're a sort of AI programming agent. They're fairly— they've got some meteoric growth right now. But they're extremely good with just understanding prompts. So they're in fact able to even work with non-tech people like a product manager who is able to sort of just talk to it in plain English and be able to do a lot of things. We've been enjoying working with these two. Okay. We're also doing a lot of things on the testing side of things where we work with— there is a tool called Caploi that we use a lot, which automates all of the test creation for any product that we're building. We're also using a lot of tools from AWS and GitHub for Deployments. Code reviews.

Code reviews, okay.

And deployments.

Yep.

And we are also using a bunch of Slack agents. So I forget the name, but I think there is an agent that we have that actually does like a standup as well. So what it does is it'll go and check the status on Jira and then it will actually do a status update, which is typically what you do in a standup. And that's also something that we use a lot. We've also started to use a lot of tools for documentation. So we use a tool called PRDKit, which is really, really good to create PRDs. You can just chat with it in normal English language and it creates these beautiful PRDs for you with wireframes and all kinds of things that you want.

Nice.

And it's a very, very effective way for us to communicate with our clients in terms of, you know, What are we thinking in terms of workflows as they share information and insights with us? That's something we use. We also love a lot of like automations because many a times when we're working on insights, we may need to build something out. Let's say it's a, I don't know, customer acquisition channel that we're trying, let's say adding influencers. It may not always be part of the core product. It may just be like a workflow that we build outside. So things like that, it's just like a marketing automation. We're using a lot tools like Make and n8n, um, uh, where we sort of build out the entire workflow, probably add like an LLM as a node. Um, and these things are done extremely far, like in a matter of days. Um, and we're able to just get it out and validate. Um, I think that's pretty much it. Um, on the design side, we're still quite creative, so we rely on Figma. Um, not a lot of like AI stuff happening there. But I think that's just how design should be.

I've seen a couple of tools coming out, not challenging Figma, but it's more like static page builders, you know, like landing pages and things like that where you just, again, you just put in prompt and you go like, you know, I'm selling this and that, or this is my service, you know, this is people I want to attract, you know, and just gives you the whole copyright and the whole page with the designs and then in images and stuff. But when it comes to UI interfaces, UXs, of course, we're probably young in that space, but it's not difficult to imagine Figma adding some copilot type of AI agents to help you with stuff. They're probably working on it. I mean, I'm sure they're working on it. Can I ask about the Slack, Ali? So is that because your clients are using Slack and you want to communicate this? Is that like, did you have any connections with something like Microsoft Teams or like, you know, like other communication sort of integrations? Or is it just literally because Slack is very easy to do that?

I mean, we can connect to anything we want. That's not a problem. But I mean, I've found majority of people use Slack, so that's just what we use. But you can connect with anything. It's just an API. Yeah.

It's, it's, I mean, they have a great setup. I love it. I work with Teams because, uh, well, that's why I work. I miss Slack because of the easiest of, of just using APIs and, and getting automation and getting communication. Teams is just terrible, man. It's just terrible. Um, um, so can I ask about automation? So I find that I'm actually much faster doing Python automation than using, uh, Maker, and I can never pronounce them, N8N. So setting up these workflows, I mean, they have, of course, a place because if you want to do that at scale, you probably will want to do that. But what I found out, and I'll give you a simple workflow which we have with the podcast, which is, you know, once we get— once our editors do the shorts, you know, they just basically upload in the folder and automation kicks off, which takes the shorts, you know, transcribes it, builds the posts, you know, tags and stuff like that, and pushes to YouTube. I was trying to build that simple workflow with, uh, with N8N. It took me days, and I was like, I, I, I can't just be bothered because it was struggling to upload the, the video asset, right? Because YouTube's API is very sensitive. Something is off, doesn't give you an error, just says it's, it's not going. And then I went, you know, to, to the cursor. Uh, I use something else that than the Cursor, but it's the same IDE, you know, AI-driven sort of IDE. And I just want like, give me a Python script, you know, that's what I need to do. Gave me a code, boom, works. Literally instant, right? And I was like, I think I'm onto something. And I started doing this, you know, Python automation and it's just so much faster and easier. Do you have any opinion on that?

I think, you know, you should do what works for you. I do have a sense that many a times, you know, just doing something in Python is, far more easier, especially when you're doing something like what you mentioned, which is just tagging and uploading, which is fine. But I think that Nation— I think it's pronounced Nation. I know it's weird, but that's what they call it. But I think Nation has its advantages. So especially when you're trying to do something a little more complicated, which might be like a little something like upwards of a 5-step process. And let's say now you want to add a little bit of intelligence, which is, you know, let's say I want to look at I can't really think of something right now, but let's say I want to look at all of the tweets from like the top 5 influencers in the, I don't know, financial space who are probably giving tips on how they trade and then sort of bifurcate that into their tweets that have had the highest amount of engagement and then also further look at the type of media types that they have. This is a fairly complicated process.

Yeah.

And it might need a bunch of steps. Now you can still write a Python script for this. There's nothing wrong with it. But the difference here is that because everything in Nation is a block, if you want to make a change to, let's say, oh, I just want to change this part in step 3 to now do this as well, you can just sort of replace that block. So incremental changes is faster. And it can also be done by a non-tech person because a lot of things are taken care of for you. You can deploy it, you can change it, you version it, you can do all of those things. So we found it to be extremely effective in a non-tech— if the owner of that workflow is non-tech, which may be, let's say, a marketing person or a founder or something like that.

Okay, I love that. You can't give out Python scripts to anyone else and go, yeah, just run it, right? Yeah, exactly that. You do want to see that. And as well, Well, if you have AI agents in the workflow and you will need to have a conversation with it, as in, you know, your workflow will run and at some point it pushes everything to an AI agent node and maybe that's an input for ChatGPT and the output is not something you like. So you want to do a little bit of conversation, you know, trim it down or improve it somehow and then continue with the automation. You know, then Python doesn't work at all for that because you're not going to have that ping pong situation that freely. And then I'm seeing a lot of workflows as well getting converted to SaaS platforms, you know, like, here's a very common workflow, so let's just get it into SaaS and then let's sell it. Like, that's almost like gave another breath to SaaS market. Like, I feel like that's what's happening right now in SaaS a lot. And there's, of course, there's arguments of, you know, SaaS being limiting because again, you cannot affect the prompts because it's getting baked in the system. So, so it's sort of cons and pros, but a lot of that is taking place as well. So thanks for sharing the tools, Ali. So can we do a quick rapid question round if you don't mind? It's like 30, 60 seconds for each question, just, just to pick your brains a little bit. Yep. So how should you collect feedback and track results efficiently from early users? In the Wipe Sprint, let's say?

If you're a founder, I would suggest that, you know, spend a lot of time observing what your user does in the day when they're not using your product. So you need to know everything about your user, like what do they do when they wake up in the day, what do they do when they go to work, like what apps do they use, what other apps are installed on their phone, like how— what browser do they use. You need to literally know answers to all of these questions, and that comes through observation. You're not really looking for answers, um, on insights. You're looking to just know them as a person.

Um, how would you know that, Ali? How, how, like, where would you get that info from?

You just need to talk to them.

Okay.

Which is the toughest part, which is the toughest part of being a founder, right? You need to be able to to sort of get in a room with the found— like with your target audience, or find a marketable way for them to start talking to you, or share information. Like, I doubt that you'll get this information on GPT or any other market research report, but you just— you're either that person yourself or you know that persona.

Okay.

So I would suggest start by knowing everything apart from what you want to know. Um, and then leave the rest to just observation on analytics because you know this person so well, you will be able to read between the lines. Okay.

So you get some static data, quantitative data based on your system integrations and whatever you're tracking, Google Analytics events, whatnot. You're having conversations and you're taking those two connecting together. And hopefully you're getting some insights from that, I would imagine.

Okay, exactly.

How many users should you test, uh, your prototype to get realistic feedback versus noise? Like, what's the minimum you want to, you know, push your, uh, uh, I'll say prototype, but we talked about that being a digital product. But let's say we got an insight, we AI-powered a prototype, we pushed it out, like, what is the, you know, what is the feedback we should be aiming for before we go like, that works, that doesn't work?

So what we do is, and this may be different for different people, we don't really look at vanity metrics. We don't look at, look at like how many people should be using it, etc. What we do is we track, um, sort of your retention rate. So there are 3 metrics that you need to look at: day 1, day 7, and day 30 after every release.

Day 1, day 7, why day 1, why day 7, why day 30?

Because day 1 is your launch, right? Like you've planned for it.

Yep.

Uh, 7 days is enough time for a person to have witnessed it and see, you know, whether there's a recall value. 30 days gives you return, a good measure of understanding what's the return on this investment. Anything beyond that is, I think, just too much time. If you're a B2C app or a product, you want 50%, you know, day 1 retention, like 50% of your people need to open the app and like start playing with it. This should sort of move down to 25% by day 7, and then that 15, like 10 to 15%, day 30 range, right? So if like 15% of people are still coming back, you're probably doing something right.

So half B2B.

Yeah, if you're a B2B product, you want to look at a flat, you know, 20 to 30% retention every day for 30 days.

Hmm, okay, I love that. Um, how can solo or non-technical founder prove traction before hiring developers or hiring, uh, you know, um, outsourced companies?

I would suggest that, so do your MVP yourself. Like, see, traction itself is a vanity metric, right? I mean, you're just showing a few people use your app. It doesn't mean anything. You can, you should build it out yourself. There is enough available online on YouTube, on like social media. Just start searching live coding. There are enough tools available. Many of these available, available for free. You can actually get a lot built yourself just through like natural language in English. Build it out yourself, you know, get a few people to use it and you have traction. That's the answer to get traction. The next question is, is it a business?

Exactly.

That's where you need help. To prove that it's a business, you need to stop building.

Yeah. And everything we talked about, basically, that's the post-MVP situation. Yeah. So traction itself, yeah, it depends how you define it. I love, I love how you put it, like, just build it, get a couple of people, there you go, here's your traction. It's, it's true, it's true, it's so easy to build now. Okay, uh, what's a realistic cadence? How many experiments per week or month can teams sustain?

Um, we see, we see a realistic timeline to be about 2 weeks. You can easily run about 2 experiments in 2 weeks.

2 experiments in 2 weeks. So it's basically, uh, What we know right now is a Scrum sprint, 2 weeks, is very often, uh, it's, it's probably the most popular, uh, sprint cadence, right? So, so we're saying in that 2 weeks you could, you could test 2 hypotheses, 2 insights.

Correct. And Scrum doesn't test an insight. That's the difference.

Yeah.

So you may be in the exact same place after a week also as a business.

Yeah. So with the why, we're not in the same place Well, actually, okay, so we, we, I'm not just thinking because it depends on the size a little bit, isn't it? It's like if, if the, if what we're testing is, is actually big, it's probably going to take us more time to, to test the insights and actually build something for it, right? Like that doesn't—

you need to break it down.

Yeah.

So you break it down and you deliver something small on that insight. See, everything doesn't need to be like changing the world. right? So, um, um, you can break down an insight to get, you know, some small metric to move, and that should be enough to plan further. Okay. But you still need to get an outcome.

Yeah. So it's a, it similar, not similar, the same iterative approach is just the mindset behind that. It's not an output. Exactly. It's an outcome.

And yes.

And then we're utilizing AI tools to actually do things faster, right? Okay.

Exactly.

Can you test willingness to pay without building anything? If so, how?

I've done it myself, um, with Wipesprints. Um, before, before we even told anyone or started practicing it, we went and sold it to people. Um, and the way that I tested that was, um, I basically just told people that, you know, just the way you have a subscription for a SaaS What if you had a subscription for your team? And instead of you telling them what to do, you just work with them on insights. And if they deliver a product, like deliver the outcome, you pay. If they take longer, you pay at that. That's on us, the skin in the game. So let's say if we promise that we are going to change this metric in a week, and if we don't deliver what we promise in, let's say, 2 weeks, it's on us. You still pay us the same. And suddenly, like, I started seeing traction. I saw people doing that. So I think the way that you sell it is you just, like, sort of define the value prop for people, right? And you're able to— I think a large part of the founder's role, or even a product manager's role, is to be able to communicate that effectively. If you're able to communicate that value to people, you will know what to do.

Yeah, 100%. Build a value prop, build a landing page, or maybe not, go in a conversation, try to sell it. Uh, if you can, great. There's definitely an interest, uh, and then you go ahead and build it, right? Or implement it. Uh, what trade-off— what trade-offs exist between a high-frequency validation and runway risk? So when I say high-frequency validation, I mean you gave 2 per sprint. Uh, you know, let's say we have, I don't know, 12 hypotheses and we need to validate them as soon as possible because we're not sure So if we just validating, you know, these assumptions, we actually not building anything, right? So the runway still is getting, you know, runway still is getting ticked. So like, is there any trade-off over here? It's like how many validate, how much you build is like, yeah, like what's your take on that?

I think prioritization remains to be an extremely tough problem for any team, whether you're a startup or whether you're an enterprise. Nothing can solve it. Only humans can solve it. I don't think AI has the context to be able to prioritize for you. But there's always a risk of running, of letting, of sort of finishing your runway. And all you can do is try to mitigate that risk. And the way you mitigate that risk is ask yourself questions around, you know, what metric does it change, which will affect your prioritization? And then you sort of focus on that, right? Because the runway being limited is a fact, no matter who you are, you don't have infinite sums of money or time. That fact is not going to change. What you do in that time is up to you. And you decide that looking at insights. And again, you can still be wrong, and it's okay, as long as— see, it's It's okay to run out of money because at the end of the day, you are running a startup and you are doing something risky. As long as you have the framework to decide, as long as you are able to justify why you did something.

I love that. I mean, it's ultimately starts, everything starts from the point of the fact that you don't look at vanity metrics, you look at business metrics. And then it just goes off, right? Like, like, like, that's the fundamental to everything. Like, you have to understand, uh, the metrics you have and which one you want to move up or down. And then from that, you have insights which will affect that. And then you go implement with the AI, effectively a prototype, or, or as we talked, potentially a production release. And then you look basically what happens with your metric, and then you just sort of rinse and repeat all the time. But it always tells starts with what metric you want to move up and down, right? Okay, I love that. Okay, cool. So we covered a lot today. Uh, just as a recap, we looked at why speed is actually a trap and why you should be concentrating on learnings and outcomes, how AI-native pods can run more experiments, and as a result, you know, uh, I want to say defend your runway, but it's actually not about defending runway, it's actually utilizing your runway post-NVP much, much more clever— cleverly, let's put like this, cleverly. I'm not even sure if that's the word. Why most MVPs fail and why polishing out them is not the best idea, and, and how to actually pick the right tools and what tools Benzna Solutions are actually using right now. And if people want to learn more about you, about what we just discussed today, how they get in touch with you, how they learn more about Wednesday Solutions?

Yeah, I mean, if you're interested in like exploring any one of our services or just want to have a chat about how you're doing things, you can find us at Wednesday.is. You can reach out to us through the Contact Us page. I'm also quite active on LinkedIn. You can just search for Ali Hafizji and connect with me. I'm happy to have a chat.

Excellent. We'll have the links in the show notes, of course. Why.is? I mean, When I saw your domain, yes. Yeah. Why, why not something like thisiswednesday.com? So like, why that?

Yeah. So it reads as a sentence, right? So if you look at any one of our URLs, yeah, it'll say Wednesday is blogging, Wednesday is writing, Wednesday is servicing. So it reads like a sentence.

That's cool. That's cool. Good approach to the branding. Good approach. Right. So to our listeners, if you find value in this episode, of course, click that subscribe button. We'd love to grow. And if you have founders in your network who are still sort of building blindly and hoping something will stick, share this with— share this episode with them. They need to hear there's a better way of doing this. And as always, guys, until the next time, stay safe. See you online.