Product Agility

Why Early Testing Beats Fancy Metrics Every Time, a CTO’s Guide to Building Products People Love (with Tamas Kokeny)

• Ben Maynard & Tamas Kokeny • Season 2 • Episode 40

Share episode

Send us a text

In this episode of the Product Agility Podcast, Ben welcomes Tamas Kokeny, CTO of Bobcats Coding, to explore the often-overlooked yet critical intersection of technology and product agility. Tamas brings his extensive technical expertise to discuss how to prioritise early testing over relying solely on sophisticated metrics to create products that truly resonate with users.

If you've ever grappled with finding the balance between innovation and pragmatism in product development, this episode delivers insights and real-world advice to transform your approach.

Key Takeaways:

  • Early Testing Over Perfection: Why embracing failure and quick iterations often yields better results than long-term product visions.
  • From Vision to Validation: Practical tips on avoiding the trap of building for months only to find no market fit.
  • Building the Right Infrastructure: Insights into setting up systems for continuous experimentation and feature toggling.
  • Mindset Shift: Moving from "house-building" to "evolutionary" thinking in digital product development.

Practical Tools & Methods:

  • Concierge MVPs: How manual processes and simple tools like Google Sheets can validate ideas without heavy investment.
  • Feature Toggles: Streamline experimentation with small user cohorts before scaling features.
  • Case Study Insights: Stories of startups succeeding with minimal viable products and adaptive strategies.

Quotable Moments:

  • "Most product ideas are bad, and that's okay. The goal is to quickly figure out which ones aren't."
  • "The infrastructure for testing isn't optional—it's the lifeblood of lean product development."
  • "Digital products should evolve daily, not be treated like static house blueprints."

Links and Resources:

This candid and knowledge-packed conversation reveals how to innovate smarter, build products users love, and stay ahead in an ever-changing digital landscape.

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility


Listen & Share On Spotify & iTunes


Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Sorry for my French, but most product ideas are shit. Yeah, yeah. And and I think you're lucky if your value proposition works right away. And in many of the cases you have to figure out, even if your product idea is good and and the value proposition is good for some people, go to market strategy can vary a lot and you need to experiment a lot with different strategies there. So, so I think you, you really need to create an environment where it's totally fine to fill with ideas and also where where you don't spend time on ideas. Because what I see especially with when you are a product studio, people come with their ideas and right away they would like to see their product vision like low term product vision. So always we get the question like how much time does it take to build the whole thing? And if you if you focus on that, it's very likely that we build something that nobody cares and about and you have spent a good amount of money and a good amount of time like it. In many of the cases it's measurable in month. If it's measurable month and developers are working on it, then it's measurable in 10 thousands of EUR. Welcome to the Product Agility podcast, the missing link between Agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard, and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello. Welcome, everybody. This is the Product Agility Podcast. And today we're going to tell you how to make quick and easy money very quickly. Yeah, Exactly. Exactly that. Exactly that. We're not going to tell you how to make quick and easy money. However we are going to be exploring how we can test ideas quickly and really embrace principles of early stage lead product development because we are joined by Tamash Cocaine. I didn't say it quite right. No, no, that's good. No worries. Excellent. A gentleman who I spent actually quite a lot of time with in product, relatively speaking, compared to whoever people I spent time with, got a lot of house on fire. It's great to have him back on the podcast. He is CTO of Bobcats Coding and it is a delight to welcome you back to our audience. How are you today? Thank you. It's a good day. And and thank you for having me back. It's it's a nice opportunity. Ah, well, look, you're being all formal now. Like when I thought we had a great time chatting shit at Productize. And I've got high hopes for this episode because it's a really, really interesting product. Product, product. Is it a product? No, it's a really interesting conversation because when I said it, what is it you're really interested in at the moment? You said it's early stage lean product development, you know, from the tech point of view. And I think this is really an interesting point because it being a certified trading partner for Sensor and Respond Learning, which is Jeff got help from Josh Ryden's company. You know, I teach lean UX and which which is now called a lean product development, and it's a just a really fascinating, still fascinating topic because so many people don't really understand ways in which you can test ideas early. And from a tech perspective, I think it's easy for product people or product coaches to talk about this more serving them from the tech point of view. So to have Acto talking about it, it's going to be a really fascinating conversation for our audience that perhaps haven't heard your previous episode. Would you mind just giving them a little bit of an introduction into yourself? Yeah. So in the previous episode, we were talking about an experiment that we did with low coding and low coding tools. Yeah, that we recreated Twitter or X in three weeks. And not the whole thing, of course, and not the scalable one, but something that you are not that embarrassed to send to users and you can try something with it. So it's a similar topic that we are talking about now and I think quite a few changes were happening in the industry with no coding platforms, with AI tools and so on. So it got way easier but. It's still not easy, not just from the technical point of view and also from the product mindset point of view. So from your lived experience, yeah, your practical experience, when have you seen this idea of early stage lean product development really coming to life and working but having a big impact? I really like those stories that I experienced either with my start up 10 years ago or others people start up that I was working on as a contractor or or as an agency where we have built something in couple of weeks. And right away we were able to either validate the users or the user flow and so on or either really make money. And and I guess that's why you said that it's an easy way to make money. Yeah, it's not that's always the case that you right away make a good amount of money, but I think it's the best validation when you have something right away and and you can make people pay for it. But it's interesting. It was my friend, I think I was talking to my friend Mike Moran who's been on the podcast before, and maybe I spoke to Kim Farah about as well have a previous podcast guests. It said that when people are looking to make investment, actually the the IT seems to have been a shift away from fancy growth targets and loads of metrics which say this is that we think we're going to make money to actually people, we're able to rock up and say, no, actually how we are making money. It puts you in a much stronger position when you're going for investment if you can prove you are making money rather than you believe you are, but shouldn't in a much more stronger position. Yeah. And also I think it's way harder to create a product setup where you're able to experiment and you have enough user flow and use an interest about your product then then to be in that flow already and optimize it. So I think it's it's harder to get there than to do the optimization. And I think that's that's your first job to get to the stage where you're able to optimize, you're able to have different cohorts of users, test them with different ideas and so on. But until nobody cares about your product, it's a hard job. I suppose it's hard for different reasons and different contexts. Yeah, but broadly speaking, what have you found that makes it so hard to get that first thing into people's hands? Sorry for my French, but most product ideas are shit. Yeah, yeah. And, and I think you're lucky if your value proposition works right away. And in many of the cases you have to figure out, even if your product idea is good and and the value proposition is good for some people go to market strategy can vary a lot and you need to experiment a lot with different strategies there. So I think you really need to create an environment where it's totally fine to fill with ideas and also where you don't spend time on ideas. Because what I see, especially when you are on a product studio, people come with their ideas and right away they would like to see their product vision, like low term product vision. So always we get the question like how much time does it take to build the whole thing? And if you if you focus on that, it's very likely that we build something that nobody cares and about and you have spent a good amount of money and a good amount of time like it. In many of the cases it's measurable in month. If it's measurable months and developers are working on it, then it's measurable in 10 thousands of EUR and and and dollars. Do you find when people turn up with a a vision, they're able to easily articulate exactly then what needs to happen first, or how far? I think manifest, first of all, I think it's tricky because for some people it's easy because being there done that. So our dream people or people who have done some kind of a digital product before, because I think it varies a lot to build a pretty digital product or digital service compared to a non digital 1. So even if you are a Syrian entrepreneur, you have a different idea about how to build a product. If your product wasn't really a digital native thing and and you still have the mindset that, OK, I will put this amount of money in and I will get this amount of money out and I will be happy. But you should put in tenths of that amount of money or or 20th and, and just a couple of weeks and try if, if you even have a marketing channel where you're able to get users. So then when you're faced with these situations, you think about this early stage lean product development. How, how do you go about speaking to people to help them? Yeah, find their ideas or actually begin to bring it to life in some way? Because it's quite a big challenge. Yeah. I think in one hand, you have to have empathy because it's definitely, these people are really pumped up about their product ideas. You cannot just say it's not a good idea. We need to test it because they are really, really thinking that that's the best idea ever. And I do think that it could be a best idea. And, and I'm not saying that they are having bad ideas. I've just been there so many times that I thought it's a good idea or somebody else thought it's a good idea and spent a good amount of money and indeed it work. So I think it's really a mindset and, and mostly that helps us to communicate. This is with case studies and and telling stories about other people. Like one of the one of my favorite examples, it's a startup that I worked for actually bit more than 10 years ago and they have built a marketing automation platform. And the very, very first setup or very, very first MVP that they will rolled out was a easy front end, like a form where you were able to set up your campaign. And the back end was nothing else, just an integration with Trello that created a Trello card about the whole content that was on the front end. And everything else was done manually by people. And basically they they were able to charge money with the whole thing that they haven't even really had a back end. It reminds me because that was that was it. So there was a concierge MVP, I don't know which I think was in Lean Startup, I think it was mentioned, but it was similar to that situation you articulated. The British government did it with online tax returns where they had to. I'm not sure whether they did this on purpose or whether this was just the way they found it to meet their deadline. But they had an online form, and then people would print it off and still do it the same way it always had been done historically. But it was online. They were able to event, like, work, that format, that work. And now, you know, it's been going for many, many years. And I think it's good concierge MVP. But is that what Alberto Salvoyo calls the Mechanical Turk situation, where you've got some kind of front end? Yeah, yeah, yeah. And you know that people want to engage with it, and you can begin to test all out and see if you have something worthwhile in the back. It's just people still doing what they would have done anyway. And I think that's a very awesome way. But people, I suppose, then get uncomfortable, right. You said they want to get their vision there in front of them on day one when you're suggesting those kind of compromises. I guess that some people don't see it that way and can't give up on that vision. And usually if that's the case, we are not working because yeah, they. Then they really don't have the experience yet to build something like this. We don't want to be the experience where they fail 1st and and they attach that. Oh yeah, they did something for us and it didn't work. But no, it it was because of your mindset about it. And I think the only way for some people to change it to fail first with something. Yeah. But in many of the cases when you really compare the prices of the two approaches that that opens doors. Explain a little bit. So if you have even a really simple product like I don't know, a mobile app that has a couple of screens, a simple back end, maybe some kind of an EI integration, it can easily take like 3-4 months for 2-3 people. So that on the end gonna mean that you will spend a couple of €100,000 and and when you say OK, rather than that let's build something with an O coding tool and and spend 3 weeks on it with a single person that that's gonna be 20 times cheaper. And and to really pay for something that 25 cheaper and to try it, I think it's a no beer near for quite a few people. So when we kind of began this at this conversation and we spoke about early stages in product development, you said from the tech point of view. What was in your mind when you said from the tech point of view, because at the top I mentioned about product product coaches. Yeah. And then maybe this is a slightly different perspective. What is it that makes a tech point of view? I mean interesting or different? Like why did you bring it up? Because I think there is a big gap between you have built something with these low coding tools and you validated your idea and and you basically really figured out your value risk and between that stage that. You already have something working and you're able to tweak it and week by week you're able to create experiments on your new features and ideas and create AB testing and so on. Because just to have that infrastructure that you are able to measure stuff, you are able to do testing, you're able to do E testing and, and have a different experience with different cohorts and so on. To give you an example, many of the early stage products right away, if it's a consumer product, they, they would like to focus on retention and to measure retention and to figure out if a new feature really impacts retention. It's a, it's a hard task just to figure out what's your retention definition and then to figure out how you're going to measure it and what's the infrastructure that's able to do that. And also to have some kind of a feature flipping system that is able to switch between experiences and make sure that you are basically measuring the two different experiences and the retention on those and so on. It's a whole product itself. And, and to get there from, from the really success story that in, in three weeks you had something that you validated, you would like to have the same kind of speed. And, and unfortunately, these AI tools are helping with the very early stage that you build something right away. But with the second stage where you're basically just creating the infrastructure to run a start up that's still not solved by, by third party tools. You still need to pick a good amount of tools. You still need to create an entangled infrastructure between these. That's a big challenge for people. So that's why people come to companies like Bobcats or yeah, other organizations. It's because you've got that great idea. We are appreciative that we want to go and go and and test that idea. But at some point your lack of technical understanding is going to get in the way. Yeah, they can't launch a digital product. And maybe this is where it comes back down to what you were saying earlier that you may have kind of have some experience in getting a product to market. But if you've never launched a digital product and got that to market and you're not familiar with that, at some point your lack of technical understanding is going to get in the way of you being able to proceed. So it's either you you do your best to learn it or you find someone to help you with it, I suppose of the options. Yeah, yeah, yeah. And I think it's also the same. So I like that you mentioned this. Yeah, this difference because because there is the same problem of, of having an idea about lean product development during development. And I just the in the early stage where you build something and you validated your market, but rather continuously you are still treating any new feature as OK, It's an experiment. Is this something that's going to change on our KPIs or not? Can we measure it? Can you validate it? Can we turn it off right away if it doesn't work? Because it's a good amount of code and that that means that you need to maintain it and that means that it's a good amount of money and also a good amount of effort that you could put on something else and so on. So still, if you are really lean in the beginning, but you don't continue that continuously, you can, you can have a sense of success in the first three months, but you're not going to have a sense of success in the next year or something like that. If you still think that, OK, it's an important idea and we must build it because you are continuously still going to spend three months in a new feature that it's very likely nobody cares about. And and three months in a startups life, that's quarter or half of your runway. So it's a really, really precious resource. So when we were talking at the beginning about a quick and easy ways to make money and saying actually there are so many stories out there and contexts where being able to test your ideas early, yeah, and even make decisions about how you're going to attract user behaviour and which tool are you going to use. You know, they are hard decisions to make in some contexts. And I think it's easy to say, well, if we're a big organization or organization that's been around for a long time because of the history and because of the complexity we're bringing with us do it's really hard to make those decisions and to do something about it. But that doesn't mean that they're making those decisions is easier. If you're in a start up. It's just a different, it's a different kind of hard in your experience. Let's take the example of you getting a skeleton front end out and kind of getting some, making some money and then testing the idea and looking to grow it. Like what are like why it is what makes it easy? What helps smooth the path to success? Like what do we need to put in place? Unfortunately, I think a good amount of things or maybe not that. So if it's a bullet point list, it's not a good amount, but it's a good amount of effort. It's it's not easy for a startup and it's also not easy for a big company. And I think these kind of metrics that how much time it takes to release something like from I've, I've written some codes to it's production, it's in production. And also am I able to do experiments to, to be able to have cohorts inside the application also turn on and off features easily. I have the whole infrastructure on that and I just. Turn on and off globally, but for a certain type of user, for a certain cohort, for a certain percentage of the people and so on. If you don't have these infrastructure set up, I think you're still, you're basically light years behind organizations that are on the cutting edge. And, and I think to have this infrastructure, it's hard for a startup because they don't have a couple of months to just focus on this infrastructure. And it's really hard for a big company because if they don't have it, then it's hard to spend a couple of years to build that infrastructure into the existent infrastructure and re factor the whole thing. But I think that's the key infrastructure. If you don't have it, you're not going to be able to do continuous mint product development. And when we say the, the infrastructure like you described in, in some detail, but if you're going to put a, a label on that infrastructure, like what are we specifically talking about here? So I think it's product metrics in general. I, I've met really, really big products and big companies that had no idea about their usage data. So like really simple questions like how many people are using this feature and yeah, we, we are not measuring it. We have no idea there not even a Google Analytics or something like that plugged into the plugged into the product. And also regarding feature flipping, yeah, that's, that's kind of a kind of a new idea for for quite a few companies. Is it feature flipping like feature toggling or? Yeah, yeah, yeah. And the whole idea of that you can dark launch something that you can, you can build something, you can start to build something and right away you can release it to people and just a certain percent of the people or just to the stuff inside or something like that. And not like in a monthly release cadence, we put everything online and and that's it. And I think it's a critical infrastructure and it's not easy to build. I think there are quite a few tools that are helping you to build it and 3rd party libraries and so on. But it's not an still not an easy task. Like I'm just going to use bubble and right away it works. So if you were, I was going to say, if you're in a lift, if you're in an elevator and you have to pit the pitch, like why this is so critical? Like what would be your pitch? Because I know that that we people listen to this who are agreeing with you, but don't know how to influence people. I can think of people that you know, I engage with who would, you know, don't would say that they probably understand the criticality of this, but probably I would say don't really because it's not very high up on their list of things to consider. So how would you like pitch it? What would you elevate a pitch for the criticality of this infrastructure? It's a hard question. I think I would try to pitch it from the point of view of you can have the same kind of success. That's the usual success stories that somebody built something in a couple of weeks and right away it made money. But you can do that continuously. So to give you an example, one of the startups I I worked with, I had this idea that OK, the most important part is, is it's weekly detention. Because if we have a good weekly detention, then if we pour in a good amount of users, then they still going to be active and we will make a good amount of money. But what we figured that less than 1/3 of the feature ideas improved retention and and if you spend 3 months on a new feature or even just a month on a new feature because you have this idea that. We build it and then we ship it and that's it. And rather than that, let's just put out the button for a certain amount of users. And when people are clicking it, we just put up a model that, sorry, this feature is not yet ready, but we're going to measure if people are even clicking on it. Then you spend a week on it and one week and a couple of months versus of development time. It's a good, it's a big difference and a good amount of money, but you still have the same chances that at certain of the time it's going to improve retention. So, yeah, it really reminds me of the right hit by Alberto Salvoya. I'm not saying like we're borrowing from that, but yeah, it really reminds me of this was a great advice in that book, I think. Yeah, there's a big mindset shift to say to people, how about we just get a button up? Because As for some, they might think it looks unprofessional or unfinished or like it isn't in keeping with their vision for things. I mean, have you come across that before when people. Yeah, yeah, definitely. And I think that's that's why I I said it's just a certain percentage of users. So definitely, if you have this mindset that like I like to label this mindset as the mindset of building a house that you are only able to do it once and it's a long lasting thing. And, and from the long lasting thing, from the point of view of when you built it, you're not going to change it because that's how it looks now. You're not going to spend a good amount of money on on it again. And also from the point of view that it takes years. So if you have this mindset about building a product, then you are not having the right mindset about building a digital product because a digital product doesn't work that way. Your digital product should change every week, every day and and you have the power because the. I really like this quote from. I'm not, I don't know the exact word, but his idea from Uncle Bob that if we have this idea about the OR metaphor that we are building a house as to the software, the building part is way cheaper with software because the architecting part to the planning part, that's where we write the code. That's that's where we plan it. But to build it that just to have it, it's just a couple of minutes because there are quite a few automations. So if we would have that superpower with houses that from architecture plans, we have the house in, in 5 minutes or just even a day, you would have a totally different mindset about your house. You would think about the kitchen, like, oh, do I like the kitchen this way. It may be, it would be nicer if the fridge is there, if the room is narrower or wider or whatsoever, then you would change your house. You're just not have this mindset about it. That's really interesting. So it's the, yeah, this mindset that we've got that. I say some of it is because software engineering was kind of based on building houses or building buildings for a long time in so much that we thought we could design it all up front and then things would run on a project and it'd be done. Particularly when things were based on people's desktops. There was a whole heap of that has opportunity to make changes quickly or look at video games, old video games, you know, once you had that committed to a cartridge or ACD ROM or a DVD, Yeah, there wasn't there was a particular cartridges, there was no going back and changing anything you'd released which wasn't right. If it had a bug, it was there forever pretty much. You know, and you look at all the the code and stuff that knocks around in some old games. It's fascinating. Like Streets of Rage for the sake of Genesis or Mega drivers. It was here in Europe, you know, if you wiggle the cartridge in the right way, it will kind of read read the memory differently and you access you can access like different languages and it's just phenomenal stuff. And it's all there because they have no choice but to put it all there. I said when what you're saying is that if we. We've persisted that kind of cartridge based mentality that we have to design it, to build it, build it and it's done, it's not going to change. But if we then said actually whatever isn't the case anymore, digital products, you know, things should change very frequently. And if we then transferred that mindset to building a house and we could just easily go into a 3D kitchen planner, redesign it, click on a few buttons and within 1015 minutes we've got a new kitchen. Yeah, we've totally changed our approach. We'd be much lesser risk adverse when they can try on things because the cost of trying things is very low. Yeah. And I think people who haven't had the experience of you're able to change your product every week, you're able to create a meaningful driving difference on your KPI's. If you haven't had that feeling yet that you're able to change your kitchen, you're still going to have the idea about product development, that it's a, it's a physical product or it's a house. Yeah. But I suppose that there are some organisations, large organisations, a lot of them have been around for many, many years, decades even, who had created software with this house building mentality and now find ourselves in a situation where, yeah, it's such a herculean effort to get their software into the hands of the customers. Actually they can't change that mindset, mindset very quickly. Yeah. So I mean, a lot of these ideas are are fantastic, right? Let's just do something quick and dirty. Let's go out and test it. Let's focus on a certain percentage of views. Let's get some feedback. Let's figure out are people willing, are people willing to engage with it and they're engaging in this way or that way. It's all brilliant. But when it's taken six months to get something released and there's a never a shortage of stuff which people want to see in that release, that's really hard for people. And I says there will be some people feeling that this is just futile. And you mentioned it before when you're talking about small companies versus bigger companies, actually that for the big companies it can take many years to kind of put in place some of this infrastructure. What advice or? Things you could say to kind of help these people who are stuck in these positions. Yeah, I think it's it's basically it's an engineering question because if you have a big monolithic or it doesn't even have to be monolithic, but like a huge product and a huge code base, it's not realistic that you're going to change the whole thing. But I really like this idea from Ken Bag that he said it for, for testing, for unit testing actually, that if you're proud of your 100% coverage with unit tests is the same kind of idea that you're proud that you have read every article in the newspaper. And no, you should just read the important articles in the newspaper. And, and I think if you are a huge organization and you have a huge product, that means I'm pretty sure that 80% of your product shouldn't change because people are already loving it. That's, that's the very course that's, that make makes the money and so on. It's only the 20, but I think many of the cases is just 5% of the product where you need really need to experiment and to figure out to have how to have this infrastructure just for 5% of your product and, and how to have it for a certain aspect of your product or certain user base of your product and so on. It's a way easier task. And, and actually I've seen this live in a Hungarian bank. It's a new bank and I think all of the banks are having this pressure that Revolute and Vice and so on are here and they are having so cool features for the end users. So the end user's idea about the banking software is like, why isn't it that easy as Revolute or and so on. But if you're a huge bank. To change all your back end processes that are doing all the black magic around money, you're not going to be able to do that. But they just just have that upper layer where you have the user experience working differently and have their infrastructure where you're able to do experiments and and have a different feel. I think it's a way smaller task than to rewrite the whole thing and and get rid of the COBOL code base that you're still having. I was. I was talking to a client about COBOL, actually, a couple weeks ago. I learned COBOL at college. Nice. Yeah, we say nice. You can make a good amount of money with COBOL. Actually. Yeah, I did it. My lecturer at college said this to me. I didn't believe her. Elaine. I'm sorry. Elaine, if you listen to this, I apologize. You were right. COBOL was the career we should have gone for. Thank you for teaching us COBOL. I've still got a COBOL book somewhere, you know, fascinating language. But what we're saying here is you don't have to necessarily experiment with your COBOL code base, but you can do some experimentation on the front end. And what you were saying that 80% of the product is probably 5, maybe it's only 5%, requires experimentation to just find the way to experiment on that 5%. I think it's really, really useful advice. It's very similar to kind of refactoring, which is where you don't refactor everything, but if you're, if you're touching it frequently and it's painful, then you can refactor it and say then next time we touch it would be easier. But that's like nought .1% of the code base because the rest of it maybe it's fine. So it's a very pragmatic approach and I like that. Would you have any other advice for people? I think you kind of need to treat it as a feature, but it's not a feature that's user facing. It's a feature for the organization. Because also what I've seen with organizations that OK, then it's going to be done and it's out of the way. But unfortunately, even if you start your. Whole code base in a way that you have all these built in and so on a good amount of time still going to continuously go into, OK, how we going to build the reports on it, how we going to figure out this and this for that new feature and so on. So unfortunately it's a continuous effort and it's continuous down payment basically. But that's something that definitely worth it. So I've I've never I've never had that that we went totally lean and or went totally agile and and then it was a mistake. We should we should go back to have an ever changing model and so on. Yeah, I like that. So treat it as a feature. Yeah, more for the organization than for the end users. And because it's a feature, then it should go through the same rigor that you would probably be putting the rest of your features through exactly. And as a result, as investment for that needs to be done by a team. I mean, maybe before there was a big question I wanted to ask, but just before we move on to kind of do that big question, would you recommend that people do this work internally or they get a third party and to do this? I think it really depends. So I think it's a core feature. So because it's a core feature, you need it from the beginning, you need it on the end, you need it always. It's really dependent on your business model, on your users, on your product and so on. It's only outsourceable easily. And by outsourcing, I really mean not just another team or an agency or something like that, but rather buy it. So have a package product that does feature switching or something like that if your business model allows it, and to to be able to say if your business model allows it and so on. It's really case by case. It's not because that's really a core feature of your. It's really similar to that, that if you build a product and you are selling, I don't know, something on online, then the payment feature is something that's easy to outsource because OK, it's something that's easy. Everybody does that and so on. But the payment feature for revolutor wise, it's the core feature. Then I'm going to outsource a payment to Stripe or something like that because that's their core feature. And and I think it's really similar to that, that OK, what type of a product are you, are you building and how easy it is to build up this infrastructure? Do you have any recommendations or of tools or particular the third party libraries or stuff that you find were very useful for actually early stage metrics? I think the best ever tool is Google Sheets. It's so easy to set up your application in a way that everything saves to Google Sheets. Actually there is an easy hack with Google forms. If you create a Google form, you can inspect it on the front end with the dev tools and you can figure out all the entities, entity numbers for each of the fields and you can recreate the HTTP request. That's saving the answer to Google form and it's going to be 6 lines of code. If you Google this, you will find a Stack Overflow answer how to do that right away, and there's a couple of articles. And basically if you have a front end, you just put that code there and whatever was done on the front end, you can save it to Google Google Forms and Google Forms saves everything to Google Sheets. Nice. So basically in a day and less than a day, you can have a back end that everything is on Google Sheets right away and with Google Sheets you can do whatever. I think Excel is the most power to. If I would go to an island without anything, I would bring Excel. That's if I could have a single software that would be Excel definitely because you can do everything. So you can figure out all your product metrics, you can figure out all your automation you because with Google workspaces, you can have automations around it and so on. So basically you can have a full fetched back end with six lines of JavaScript on the front end. Well, maybe, maybe one day you can show me something. I'm intrigued by it, but we'll, we'll pin it there because we've time is really kind of moving on. So just came back to the, the setup we had for this conversation, which were early stage lean product development from the tech point of view. And I suppose and the connection for me really came together about 5 minutes ago. When they think of how work flows through and they think of teams getting together and saying, let's use a lean product canvas, which will say the lean UX canvas has now been rebranded. You know, when I'm teaching people how to use this and I'm facilitating people through how to use this, they come up with lots of really great ideas and that really, really helps them think through those ideas. But I think it normally gets to a point, especially in the larger kind of stereotyping here a little bit in the larger organisations where there is such a delay in getting something out and then no real feedback mechanism for once that thing is out that that makes it really hard to get the value from these canvases. I mean, sure, it's great, incredible of a shared understanding, but unless you're taking that tech point of view and this you're getting in place as you said that critical infrastructures if you are able to see OK, are your hypothesis paying out? Are you? Able to flip between features, are you able to kind of focus in the individual users or cohorts of users and really begin to test those ideas not just on paper or for interviews, but actually like on the front end? It's then and only then that you can really tune into the and reap the benefits, let's say of a lean product development. Is there is a fair summary, Thomas? Yeah, definitely. And while you were talking about it, I, I was started to think that I think what's really hard about this is if you have this infrastructure, if you have, have something like this, that's going to impact a lot on your on your company culture. And, and I think it's hard to change a big code base, but it's way harder to change company culture. And, and I think that's, that's a problem with, for example, the link canvas as well, that all these tools are basically are good for creating conversations that figure, having the critical conversations and the critical thinking about something. If you don't have an empowered organization where people are able to do decisions on their own and so on, you're not going to be able to use these tools because then huge hierarchy needs to have ideas about it, giving feedback and so on. And, and unfortunately, you need to have the same kind of structure for a good product. I just, I'm trying to think of like a metaphor for it. And I feel that exercise and it's reminds me of, you know, people who think they'll just go and drink those protein shakes and magically they'll get really fit and muscly. But if you're not putting the work in, if you have infrastructure to put the work in, you change your lifestyle. You don't, you don't start lifting weights or going for runs, sort of go going swimming, then you can drink all the protein you like and you can have all the calories. Like you're never going to change your physical appearance and the way that you think it's going to happen. That's why the lean product canvas is almost like a. Yeah, let's take the lean product canvas. Let's say it's like a protein shake for the Yeah, definitely. Exactly. If your organization is unable to do decisions, then you cannot put more decision drink Yeah into the stomach that then have more decision. Now, it's still gonna take a year. Yeah. Because it's it's politics and it's hard and so on. It is really hard. And I think I'm going to put this into ChatGPT later because then they get it to come up with a much more concise metaphor for me that I'll use. Yeah. Yeah. But guess what? My favorite way to use ChatGPT at the moment is like, I've had this idea that this is like this in this context. Couldn't you write me something to explain to other people by that could be like that? It's great. I'm not that creative. How much, you know, our time has come to an end. It's flown by. It's been so nice to have you back on the podcast. It's a pity we can't do it in person, but, you know, that's the way it is, right? Hopefully we'll get to see each other again at some point at a conference, because I know you off to a conference this week. Yeah. To Malaga, to Weiwei. Web. Nice. Lucky, lucky you. Yeah. For people listening, the time is now 1132 on Monday, the 25th of November in the United Kingdom. So it's different times in other countries. That's the time it is here. And we this episode will be released this Thursday. So you're listening to it a few, you know, pretty fresh. So when you're listening to this episode, Tamas will probably be a Malaga and I will be probably where I have now talking to somebody else. So if we thank you for sharing the the your thoughts, your ideas, There's some challenging stuff in there, some really practically useful stuff in there as well. If people were interested in learning more, asking you a question, maybe wanting to see what do we need to Google to get the stuff around Google Forms and Google Sheets. What's the best way for them to contact you? I think go to our website, bobcatscoding.com and you can find all of our contacts. And we are happy to help you with any technical challenge that you have. Lovely. Yeah. Do check out Bobcats, Cody. I mean, lovely branding. I like the branding. I like the colours. Also the people that work for Bobcats are all pretty awesome. Thank you had a really great time apart from you, they were all really good. Yeah, they are definitely they they they had a great time hanging out of your productized and I do yeah. Everyone check out Bobcats coding. If nothing else, they've got great branding and it's a it's a pleasure to look through some of your material for your website. And yeah, I wish you all the best of the future success for the company. I'm sure it's going to go from strength to strength at some point. I may pick your brains and ask for a bit of advice or at least bounce some ideas off you for a few things I've got knocking around my head. But that's a conversation for another day. If people wanted to connective you on LinkedIn, are you adverse to that? Yeah, no, no, it's totally fine. I'm. I'm happy to connect. Excellent. Well, Thomas, thank you so much for coming along. And everyone, thank you very much for listening. This has been yet another episode of the Productivity podcast. I think we're on like episode 200 and it's over 250 episodes now. It's crazy. How many more will we go for? That's listeners. That's for you to let me know. Let me know how many episodes you want. I'm setting, I'm setting an arbitrary target. But everyone, thank you very much for listening there. The fact that you give up your time to listen to us on your walk or exercising or just sat at home, it means the world to us. And if you've got any feedback for us, you want to ask me any questions. And please do get me on LinkedIn. I'm more than happy to to help guide you through whatever challenges or problems you may be encountering with your desires for product agility. And do check out Bobcats coding as well. So we'll draw some to a close. Everyone, thank you very much listening. Tom, thank you very much for coming on. This has been the Product Agility Podcast.

People on this episode

Head Shot

Ben Maynard

Host