S6E1: Nobody Said No with Richard Abi Chahla

[00:01] Karl Abbott: 

Welcome to Productly Speaking, the podcast with real stories from real product people about the messy, surprising, and occasionally brilliant work of building things. I'm your host, Karl Abbott. Here we have no perfect processes, no polished answers, just honest conversations and lessons learned the hard way. Let's give this a go. Today on Productly Speaking, we're talking about one of the messiest parts of product work: figuring out what's actually worth building before you sink weeks, months, or an uncomfortable amount of budget into something no one asked for. To help us navigate that very real terrain, I'm joined by Richard Abi Chahla, who has been helping subject matter experts and founders use AI not to build faster, but to learn faster. Richard, welcome to Productly Speaking. 

[00:51] Richard Abi Chahla: 

Hello. Thank you for having me. 

[00:53] Karl Abbott: 

Yeah, we're very pleased to have you on the show today. Could you tell me about a time when a team built something impressive on paper, only to discover that the problem it solved was imaginary? 

[01:08] Richard Abi Chahla: 

Yeah, actually, this happens a lot of times. And it happens usually whenever you have a CEO who's very convinced of one idea, and he is the one guiding the team and asking them to build something without doing any kind of research. And usually they try to override any advice that you give them because they think they are the subject experts. So, yeah, I've had that in healthcare. There was a person who had his family business in healthcare for a long time, and he wanted to build a platform that is like Function Health, but better. And whenever he started telling me the different features, I was like, that's not going to work. Because you have different journeys that are not leading to a better outcome, it's leading to a bad outcome. And he insisted on building that. And eventually, after I withdrew from the project, they had to stop it at a certain point because nobody was signing up. It was a really hard journey. It was more expensive, and it didn't work out. So, yeah, unfortunately, I highlighted that at the beginning. And what he was relying on was a quick ChatGPT querying that he'd done that was confirming to him that all his ideas were amazing. 

[02:41] Karl Abbott: 

So, confirmation bias from an AI on this one. I was kind of curious—what drives somebody to think they're so right? 

[02:49] Richard Abi Chahla: 

A lot of people think that they can not have a lawyer or not have a product person or not have an accountant or their tax person just because they're asking AI. They can get a rough idea from AI if they know how to ask it and how to give enough context to it. And in our work and our research, we are heavily using AI to be more efficient and to be quicker and to be covering more ground in a shorter amount of time. But unfortunately, not everyone knows exactly what context you need to give. And like our prompts are a couple of pages. The shortest prompt we use for a specific document, we query multiple models with a two, three-page prompt. And eventually, we check every link. We check every source. We consolidate. And we make sure it's not taking any assumptions. And we have configured our models as well to be critical, not to confirm blindly anything we said, criticize whatever we say. So, it's a different setup. If anyone does that, they might be getting some good results. But if someone goes to vanilla ChatGPT or Claude, or even Gemini—it's really bad these days—and tries to say, well, I have an idea for a clinic that does this and that. What do you think of it? This is the best idea I have ever heard. Go get it. 

[04:22] Karl Abbott: 

Yeah, they're very tuned to tell you that what you're saying is great. And I think you've said something very interesting here. And that's that if you give the AI the right context, if you've tuned the model basically by saying, don't just accept everything I've told you is the best thing ever, please push back, find the holes, etc. But how does somebody get that context right? 

[04:52] Richard Abi Chahla: 

It's very easy. They use AI to get the context for AI. It's as silly as that. So, let's say someone is using ChatGPT. They can go and open a new chat and say, I want to do this kind of role. This is my job. Those are my questions. Prepare for me a prompt for the instructions, the general instructions of ChatGPT or the project if they are creating a project. And I want you to be critical. I don't want you to accept anything I say. I want you to back anything I say with some validation or some sources. Don't take assumptions anytime you find you have missing information. Ask me about them. Or clarify every time you take an assumption. Clarify those assumptions at the end of the document or at the end of your answer. And ChatGPT or Claude or whatever will create you a very decent prompt to put it there. You might edit it a little bit. And you don't have to take it for granted because I keep telling them don't use em-dashes and somehow all AIs are really attached to the em-dashes. They keep putting them everywhere. So, this is love. 

[06:05] Karl Abbott: 

Yeah, but what you just talked about is actually judging that output. So, like, you've now got the context. It's not enough just to accept it point blank. You as the person have to have enough expertise in the area you're asking it about to say this is good context to feed in, or, oh, wow, it went in a very wrong direction. 

[06:27] Richard Abi Chahla: 

Exactly. On top of this prompt that you put in the instructions, you go and get sample documents of anything you're trying to produce. Let's say it's a PRD or it's a proposal or it's anything that has previous templates that have been produced. So, you go and you get the best templates that you find suitable for your use case. You feed it there and you say use this as a reference. You also try to give it as much context around the use case or around the problem you're resolving or around the project you're working on. Even if you think something is for granted, for a person hearing it, it might not be something really easy for AI to assume. So, the more—and especially Claude, Claude likes really large contexts—so, the more you give it context, the better. And it prompts, like, this is Prompt Engineering 101. It prompts you to have five sections. First of all, from which persona the AI is answering you. Second, you just give it the general idea of the situation. Third, you tell it that this is what I want to achieve and this is why I want to achieve this. And then you give it do's and don'ts and you give it sample responses. If you give it those five sections and you have the original instructions to be critical of anything we give it, to ask follow-up questions, to not take assumptions, etc., you will start having very good outputs from AI. But this also depends on the model you are using. So, what we do generally, we query the same prompt with the same context to different models. Then we consolidate and we let a fourth model consolidate everything and judge the outputs of other models and check the links. And then we do the final check ourselves. This looks like a long process. But if you consider that whenever we wanted to do, for example, a market research before, it used to take three to four weeks. And we used to use the browser and do different Google searches and try to open all the links, read all the websites to see what's relevant, what's not. Now we do it in one or two days, full-time, let's say, 16 hours. We have a full market research, depending on the market size, of course. This is still very impressive. It went down from 15 to two working days. This is still very impressive. 

[09:14] Karl Abbott: 

Yeah, that's an incredible time savings, absolutely. And I've not built as detailed a prompt as you've talked about, but I do a lot of heavy prompting right up at the front. And then I do basically argue with the LLM for the next hour or two in conversational mode. And that's feeding in context as well. So, it may not look quite as structured as what you're doing. But at the end of the day, after a while of arguing with it, you can also start to get good output because it finally has what it needs. So, depending on your style, I've found both of those things to work. But it is interesting because now AI gives us this tool to really kind of help us navigate the space a little bit better. And kind of going back to this idea that sometimes we get on the wrong path and we're just incredibly confident that we're on the right path. When you think about products that flopped, what were some of the early warning signs that everyone conveniently ignored? 

[10:13] Richard Abi Chahla: 

A lesson that I learned really the hard way is that whenever you have a product you want to build, you need to go and do your list of risks and your list of assumptions. And you have to go and rank those assumptions. And you have to go and try to validate the riskiest assumption that you have. The issue that I've done early on and the wrong behavior that I've done early on was that I was trying to avoid the riskiest assumption. I was trying to postpone it because I want to hear the good things. I want to hear the thumbs up. And this happened in 2016. We were building a product that acted as an AI mapping agent inside events. So it would map out your journey inside large events by telling you these are the talks you should attend, these are the exhibitors you should visit that fit into the specific purpose you're trying to achieve from this event. And we knew that our profitable clients were large event organizers that do multiple events that have 10,000 attendees, 15,000 attendees. And we just visited one of those and we told them about the idea. And they said, great, this is a really good idea. We're having this problem. Whenever you build it, we will use it. We'll test it. And then we haven't spoke to these people for the next six to eight months when we're building. And whenever we were building something, we were validating them with small event organizers who were really easy to reach and really easy to talk to, but they were not our star clients. And whenever we built the whole event app with all the different features, we went to the large event organizers saying, that's the app we want to use. And they said, no, that's not what we want. We have the problem. We validated to you that this is a problem we're having, but that's not how we want to solve it. We already have our event apps. We're not going to let it go just to use yours because it has better networking and better mapping inside the event. So this was a huge waste of effort and time. And we tried to go back on track different times, but we did not manage to do that. And we ran out of money. 

[12:36] Karl Abbott: 

This is your ta-da reveal moment. You're expecting everybody to go, this is great. Let us get our checkbooks out and start writing the money. And it falls very flat. What was the feeling in the room and how did everybody take that? 

[12:54] Richard Abi Chahla: 

It wasn't easy. It was really hard. And the thing is that you get the news when you are with the prospect client or with the investor, and then you have to go back and convey to your team. And you have to go and you have, because I was the founder and the product manager for the product. So I had to go and take full responsibility because they have done their jobs perfectly. They have built things up to the specs that I wanted it. They have built the features I asked for. And now I'm telling them, yeah, I was wrong. And it's not going to work out. And this is even harder for co-founders. It's not only hard for developers or the employees because they are getting their salaries. Of course, they are getting some vested shares in the startup. But the co-founders that were putting sweat equity because they believed in my idea and they believed in my assumptions. Now you have to tell them that the time you have put here is wasted. And this is really hard to say. But again, there's a saying that said, I am not smarter than you. I just tried more times than you've done. I just failed more times than you have tried. So yeah, failure is part of the process. The idea is that you just need to learn how to do the right experiment. So you fail less costly and you spend less time failing. That's the idea. So with all those lessons learned, I've been building startups since 2011. Now there's a clear process and there's a gut feeling that these are the boxes we need to check first. If we miss any box, we have to wait until we check this box or we have to change the plan. We have to make this box obsolete. Those are the assumptions. If one of those assumptions, we don't manage to do the right experiment to validate it or to rectify it, then we have to change the business. So this assumption is obsolete. We don't need it anymore. Otherwise, we don't move forward. And this is a very rigid process that I follow to avoid failing big and to avoid wasting a lot of time and money building the wrong thing for me and for clients as well. 

[15:19] Karl Abbott: 

Yeah. Yeah. That's a very important thing to get out of as fast as you can. Have you, in all of your career, ever found yourself in a moment where everybody's thinking, we know this is a bad idea, but we're still going to build this thing anyway? 

[15:37] Richard Abi Chahla: 

Yeah. Yeah. Actually, in 2024, we spent so much time and effort building MIA, which was supposed to be your personal relations manager. And MIA's inception was at the same time as the big AI inception, 2023, 2024. And at a certain time, we started seeing trends and features that MIA was doing that you could start doing now using a bundle of ChatGPT and some other software or GPT wrappers. And because we were really believing in this product, we've been working on it, we spent a lot of time and money building it. We just kept on building it for three more months than we were supposed to do. But then we had to really assess the situation saying that AI is not going to stop evolving. If now we see that some bundle of GPT wrapper can do part of the jobs, in six months, it will do everything better. So we either have to pivot into being an AI-first platform that is for a niche audience, or we have to stop building that. And eventually, we stopped building that because we couldn't control and we couldn't foresee exactly how AI would be evolving so we could jump on a trend that is still not there. We couldn't foresee the future. So we decided that it was very risky to keep on building this, and we stopped it. 

[17:18] Karl Abbott: 

Yeah, absolutely. And you've talked about now AI has gotten far enough ahead in its advancement that you're able to use it in that discovery phase to do some of the research and to understand, are the ideas that I have actually going to pass the muster of the market before I get them out there? Have you seen AI in that process speed teams towards the wrong thing? 

[17:46] Richard Abi Chahla: 

Yes, it is doing that because building is cheaper and faster now. Everyone thinks that they can get a $20 subscription in Claude Code or in Lovable or Replit and build the next unicorn. So you see a lot of people wasting weeks and a lot of tokens trying to build something that eventually nobody asked for. I keep trying to warn people about that. I have on my website a free 40-minute consulting and people book that telling me their next unicorn idea. And I just ask them some simple questions and it is clear to me that this is not something that's going to work. It might be the right problem, but probably not the right solution for that problem. And those people, I'm surprised that they jump really fast into building, but they can use similar or even the same tools to do a market research as well. Or to prepare some questionnaires and talk to people and then use that to analyze the questionnaires, but they don't do that. Because they think, what do I have to waste? $20 a month and three months of work? But this is still a big loss, three months of work if you're building the wrong thing. So I'm seeing that on a daily basis. 

[19:09] Karl Abbott: 

So what do you think that says about the role of human judgment in all of this? 

[19:15] Richard Abi Chahla: 

The thing is that those people are either engineers and they see things from their own lens or they have a specific set of skills that makes them a great founder for such an idea. But they are missing the product mindset. They are missing the lean methodology mindset. So they do not do enough experimentation. It's not about human nature as much as it is about understanding what kind of skills you need to build a product and what defines a successful product. There's a lot of people that think because something is feasible and because on paper they think that if they sell it for $20 or $30 a month, it's going to make them a lot of money. Then this is worth building. They keep missing the problem part if this something is desirable. So people need to check three main pillars for any startup, which is desirability, feasibility, and viability. If they don't have those three, they do not have a product. 

[20:21] Karl Abbott: 

Yeah, and at $20 to $30 a month, you really have to have a lot of customers to make that pay off. 

[20:27] Richard Abi Chahla: 

A lot of customers is different than before. Before, if you're building a SaaS solution, you needed just to build it and to have all the features and to have the infrastructure and the support. You needed a team of five to eight people maybe with their salaries, with the location, with the hosting, and multiple months to build that. So you couldn't build any SaaS solution below $200,000, let's say, on average. So in order to recoup the $200,000 and to recoup the operational costs to keep things working fine, you needed at least 50,000 users or 25,000 users paying $30. And if you have a free tier, that means you should have 250,000 users, 10% of them converted to paid plans in order to have a successful product. Now, because building and maintaining is cheaper, if you are building the right thing, and if you have a certain niche audience that will use your product, let's say 5,000 people or 10,000 people using your product and 10% of them convert, this is 1,000 customers. This is still a very good market because you're making $30,000 a month. And you're spending probably $7,000, $8,000 on a team of two or three and a small infrastructure to keep things going as well. So the economics have changed, but they don't mean anything if you're building the wrong product. You're still not going to get the 1,000 paid clients if you're building the wrong product. 

[22:15] Karl Abbott: 

Yeah, exactly. This is where the wrappers, the products that are GPT or model wrappers, they kind of act as the middle ground between a person who's not a matter expert in a certain topic using vanilla AI tool and an expert in his field using an AI tool. So the wrappers are the middle ground of that. They still don't give as good an answer as an expert doing that, like an expert lawyer using AI. But I guess because the wrappers, they are programmed in a way that they ask for the context that they need, they have the right prompt and the right frameworks to follow. They can give you a better answer than what you would have prompted if you are not an expert. Let me give you an example of a small micro-SaaS solution that I'm building. And it's an AI mechanic for non-technical people. If a mechanic is using AI, they can get amazing outputs and they can diagnose very accurate problems in your car. But if a normal person is using that and they don't really know how to prompt, they will not be able to get a good output. We have built a GPT wrapper, practically, or a model wrapper that asks for the context that they need. And you log all your car maintenance or all your vehicle maintenance in it, preventive and reactive maintenance. And anytime that you have an issue on the road, you just describe the issue and the AI model or the AI agent asks you follow-up questions to get all the context of the problem that you are facing with your car. And then gives you assumptions. It's not trying to be your mechanic. It's just trying to tell you that this might be a risky thing. You cannot keep driving your car. Or there is a quick DIY thing that you can do just to get home or to get to your destination, but you need to get checked by the mechanic. And this is still in the middle ground of you randomly opening a chat in ChatGPT or Gemini and telling it, I have my check engine lights on. What should I do? And it tells you, probably it's nothing. Keep on driving the car. Well, that is the common knowledge, right? 

[34:51] Karl Abbott: 

I mean, like if your check engine light comes on and the car keeps driving, well, there's a lot of things. 

[34:57] Richard Abi Chahla: 

There's no weird sounds. The car keeps driving. Go ahead. 

[35:02] Karl Abbott: 

So in all of your work with AI and using AI to do this research to inform product discovery and product building, has there ever been a time when the AI surfaced something uncomfortable or inconvenient for your team? 

[35:20] Richard Abi Chahla: 

The most common thing that surfaces with AI is during the market and the competitive research. And sometimes, even if you Googled the different keywords that you think are going to show your competitors, and even if you did a quick prompting about what kind of solutions is there for this kind of problem, you might not get all the answers. And it depends on the model you're using. And there's a lot of people, surprisingly, that have no idea about deep research in the different models. But I had a couple of situations where I get to a client that have done months of research by Googling and by prompting, and they tell me these are the solutions that compete with me and I think I can do a better job. And then just the market research and the competitive landscape reveal some conversations on some social media where people have solved this DIY somehow. Or some competitors that emerge from our research and they have no idea they existed and they are solving the problem way better than they are even considering to solve it themselves. And the reasons are different. They might be querying the wrong keywords. Those competitors might be ranking on different keywords. They might be in other markets than his market or her market. Or they might be new startups that have emerged from an accelerator six months ago or one year ago and they still did not get the popularity needed to appear on the search engine rankings. But AI is helping us dig through that now. And whenever you really do thorough research and the empathy phase is really detailed and thorough, you would have saved yourself a lot of heartaches in the future. Because right at the beginning, if you see that there are two, three startups that are solving things much better than you would have solved the problem. They have the investment. They have the right teams. They have plans to expand to your target audience. Then it's a bet that you would like to take. Do I want to continue doing that? Did I get ideas from them so I changed the path of my startup by changing how I'm solving the problem based on how they are doing it? Do you want to be a me-too product for something that's already existing and that have the funds to come to your market later on? Now they are making a more informed decision. I'm not saying that whenever you find competitors, you stop. Competitors validate that there's a market for something. But if you don't have an edge on those competitors, you don't have an advantage over them, then this is a more informed decision. Probably you would say, I wouldn't spend that much because now my money is at risk more than it was before when I thought there is no one competing with me. 

[38:34] Karl Abbott: 

Yeah, that is an interesting point. So in your own work, what's a decision that you've had to make that's kept you up at night? 

[38:47] Richard Abi Chahla: 

There's a lot of decisions that keep me up at night. But when you are in a situation where the customer is not really close to the users they want to sell to, and you're doing your research, and you have to derive—you don't have direct contact with the actual users who will use the platform, and you have to derive from different conversations what are the features and how the features should look like. And you have to use your previous experience, your gut feeling, your analysis of the stories and the events they are describing to make decisions what to build and what not to build and how to build. There's a lot of product managers that prefer not to take decisions based on this vague set of information because they cannot validate it. But as a product manager, this means that you have to make the decision if we build it or not, and you have to make the decision and advise the client, if they really want to move this forward, what they should build. So those kind of decisions, they are a risk on you as a product manager because you are the one to blame later on. And this is part of the job. You need to have the courage to take some decisions on, because you cannot pause development, you're already in it, you're already moving forward with the product, if it's for an NGO or if it's for an organization or an SME. And you need to make a decision here because the team needs to continue building to get this product where it should get. But whenever you make the decision, you need to keep observing. You don't make the decision and then move to the next thing. You make the decision and you put some KPIs and you put some indicators to keep on monitoring to make sure that the decision you've made is a safe one. And you make sure that anything you build based on assumptions is very short and is very limited. So you can take it and go try to test it there and get some kind of validation if you persevere or if you stop. So I'm the kind of product manager that takes those decisions and I don't push the brakes whenever things get really hard to decide on or whenever the information gets vague somehow. But they keep me up at night because this is a budget from the client that he's spending on a feature that I'm not 100% sure that it's going to work out. And I keep monitoring the indicators so I can come back to them saying, look, I was wrong. I read the situation wrong. Now let's pivot and let's make use of the work done in that way so we can not throw it in the garbage. 

[41:54] Karl Abbott: 

Yeah. Yeah, that's definitely in the territory of what keeps a lot of us up at night. I see you relating to it. Yes, yes. Been there. And yeah, it's so funny. You say that there's a lot of product managers out there who want all this data that they can validate and it's like half the time the data is just not there. You have to go by gut instinct and like you said, just keep monitoring to make sure that what you did was right. And that's a challenge. It definitely gets the brain going. 

[42:29] Richard Abi Chahla: 

You have three kinds of product managers. You have the ones that do take the decision and monitor it. You have the ones that take the decision but they are overconfident and they do not say I was wrong later on because of some ego. So they go even deeper in the problem. And there are the product managers who just hit pause and they say, I cannot decide here. I don't have enough data to decide. And they ask the founder or the CEO or the director to take the decision on their behalf, which is completely wrong because they do not have the skill set to make this decision. And they do not know how to monitor their decision later on. So it's as if you're telling the client, consider you don't have a product manager and you take the decisions. I will just execute whatever you said, which is not really a product manager profile. 

[43:20] Karl Abbott: 

Yeah. Yeah. So what's one lesson that you learned the hard way that changed how you think about deciding what to build? 

[43:30] Richard Abi Chahla: 

Going back to 2016 to Monica, validate your risk-based assumption. This is like the most important thing. Make sure that you have the three pillars of the startup. It's desirable, it is viable, and it is feasible with the skill set you have and your team and the technology. And make sure that the riskiest part of this is validated first. And don't try to make yourself comfortable because you don't want this to fail. If it's going to fail, let it fail in the research phase or let it fail in the validation phase. It's better than it failing whenever you have poured a lot of development money on it. And then you have launched it and you did marketing around it and then it fails. So this is the biggest lesson I have learned from 2016. And since then, like in the first couple of weeks, I highlight my risk-based assumptions and I have them in front of me all the time to see how we can experiment into validating them. 

[44:32] Karl Abbott: 

Yeah, thank you for that, Richard. That's an excellent answer. So one final question, just to have our audience get to know you a little bit better. If you had to give a TED Talk tomorrow on something totally non-work related, what would it be? 

[44:48] Richard Abi Chahla: 

Well, up until now, the most challenging thing I have ever had to do is to raise my daughter. And I'm trying to use some product mindset into doing that because there's no manual to kids. There's no manual on how to raise them and how to make sure that they have the right mindset, they have the right ethics. You give them enough room to experiment, but keep protecting them. And after all, it's much more valuable than a product. It's a human being. It's your human being. So yeah, probably this thing takes a lot of my thinking. And probably if I wanted to give a TED Talk, it would be some of the lessons learned from raising a kid and how my critical thinking or product mindset or experimentation process helped me in this. And how it is always helping me because she's still four years old. There's still a lot of experimentation to do. 

[46:01] Karl Abbott: 

So how much has, if you don't mind, how much has your parenting experience of now four years influenced what you do in product? 

[46:11] Richard Abi Chahla: 

Actually, I get to experiment being on the other end of the interview, the five whys, if you know the five whys. And it's never five. It's like a thousand whys. It's an unending stream of questions.