 I'm excited to be here. I've been on several of these talks before. I'm really happy to be on this side and take the stage for once. Thanks to Product Tank and to Silvia for setting this up and getting us this great space. My name is Vile. I work for, I do product at Koda Payments, which is a FinTech startup here in Singapore. We are a payment gateway. We do alternative payment channels, helping online content providers, game developers, streaming services, whatever, monetize in Southeast Asia, particularly in the markets where traditional online payment methods aren't very widely used. I could talk a lot more about online payments and developing markets, but that's not for today. If that's your interest, catch me after this session and we can talk more and switch ideas. Today in this brief time slot, I wanted just to bring up one subject that's been coming to mind repeatedly in a bunch of different contexts of product projects. And it's a lot about how we talk about minimum viable products and the piece. That kind of term keeps coming up, particularly in a startup context. It feels like people have a bunch of different understandings of what it actually means and what they want to do with it. And I feel that that narrative often has almost a detrimental effect on some of the decisions we take when we, at the early stage, when we design and plan our products. So here's a popular definition of an MVP, a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. And that sounds lovely. Get it out there quickly, get some feedback, learn about your users, learn about your products, make it better. So kind of the pitfall or the problem that sometimes comes up more than I feel sometimes appears is that stakeholders might sometimes interpret it slightly differently, just from a slightly different angle. But it's more about minimizing time to market. Just build enough so that you can actually launch the product. We want to get it out there. We want to say we launched. It's going to have an impact on our financing. Time to market, time to market. Very important. We can always improve it later. And that's usually part of that narrative. Just get it out. You can always change and improve it later. And that's basically the idea of the MVP, right? You put it out there, you get learnings and you improve. So I wanted to approach this from kind of an anecdote from a product launch that I was PM for a couple of years ago. I had received a rather high level kind of requirement for a new product. And somewhere at the end of the email, et cetera, like we just put together a quick MVP and we can launch this in a couple of weeks. Should be fine, right? That's OK. So here's the actual picture of me after reading that email. Feeling the time constraints, the closing in. There's a small devil on your shoulder which keeps saying, time to market, time to market. Don't delay. You need to be quick. So time for some quick decisions, quick designs. Let's get this thing out there. So the requirement I got was actually to set up an e-commerce site. This was at Coda and it wasn't really our core business, which was payment processing. Just for context, Coda had set up a bunch of these payment channels, carrier billing, bank transfers that we were offering as a portfolio to online content providers. Well, we felt that there was also an opportunity for us to retail some game voucher codes. For example, it's topping up like a Steam wallet or buying a digital Google Play gift card. People in many of these markets had trouble doing that because of these big platforms. They hadn't really launched properly yet. They basically just accepted credit cards, which none of these young gamers had. So they might go to a convenience store, buy that physical code if it was available, or they might not just not be able to top up at all. So we figured we can harness all of those payment channels that we now have and we offer to our merchants for ourselves. We can set up this e-commerce site and we can help customers buy these codes. We can distribute them online and help these customers that have trouble topping up. Well, so you can see from the picture I'm actually super excited. This is my, like, yes, yes, post. This was an e-commerce site. I'd done these e-commerce. I worked for a couple of years actually here with Zalora. So I felt like, yes, we can do this. I can handle this. I, there's not going to be a problem. Setting up an e-commerce site. Piece of cake. So let me just tell you briefly about kind of how that played out. How we almost made a bunch of bad decisions and how we kind of lucked out and maybe did a slightly less bad decision. All in the middle of this squeeze, this, like, MVP rush to get something out there. So how do you create an e-commerce from scratch? What do you do? You have two weeks, you know, be quick. Let's do it. Let's do this. So there's a pretty established paradigm of what an e-commerce site looks like. You look at the big players. Everyone knows how you sell stuff online. You set up a product catalog. You have a product, like a cart that you put stuff in. It's like shopping in a supermarket. You take things off the shelf. You put them in your cart. You go to the checkout. You know, you pull out your loyalty card. You get some loyalty bonuses. Whether it's Amazon or Redmart or Zalora, there's quite a lot of parallels going on. So there's essentially this understanding of like a best practice or, you know, how do you do e-commerce. This was true for our competition as well for this new product. You went to the site, so you could almost envision it like being in a supermarket. There was voucher codes, like, presented as physical cards that you basically just took and you put in your cart. And you went to the checkout and you signed up. They asked you everything from your address to your shoe size. You did your payment and you get your code delivered. So clearly, there was a very clear blueprint of how to do this. If Amazon does it like this, it must be good. They know how it's done. We would be very stupid not to do the same. So here's me looking at that requirement. One hour later, I'm already kind of signing up for a trial account that's Shopify and we're looking at some of the similar services. It should be pretty quick. You just upload some product information. You configure some payment channels. And you're ready to go. Success, MVP launched in a matter of days. And there's always that we can always change it later. We get this out. We get some feedback. We see what happens. If we ended up doing that, I think it would have been much less successful than it ended up being. So this was kind of, I think, where there was a lucky break. So the founders of the company had actually played around with this idea before, like a year or two before. And part of that set of documents and ideas that I got, there was also a simple wireframe that someone had played around with sometime earlier. And it was very different. It was like, I was looking at that. It's like, where's the rest of it? How is this supposed to work? It was a one page affair. No account, no shopping cart. Like, god, there wasn't even a separate checkout page. It didn't look. It didn't feel like an e-commerce site the way I would have directly envisioned it. It was all just bundled into one. But this did when we looked at it and then it was like, hmm. Comparing these two almost e-commerce paradigms, like you have this should-are shop actually feel like being in a supermarket, checking out different products, comparing them, putting into your shopping cart. So after playing around and after a lot of discussion, we ended up kind of starting to design base on that simple mock-up that had initially been done. And instead of that supermarket, we ended up with a purchasing experience that does have a parallel in the real world as well, but it's definitely not a supermarket. It's a vending machine. You walk up to it, you punch in a number, you push a button, you put in a coin, and an order is processed. You get your thing. A completely different experience, both offline and kind of as an offline experience. So and that's actually what we went with, that design. And in that, we basically ignored all of the conventional knowledge, like the best practices of e-commerce. There was nothing there about multi-step checkouts or how to optimize shopping carts. So this was basically what you might have seen in the initial title that was on the meetup call. It was something about taking the wrong turn. And at the time, when we were working, it was like this kind of feels a bit wrong, because there's so much knowledge about how you're supposed to do this, how this is supposed to feel as a customer. Everyone's expecting these certain elements. And we don't have any of that. Like, is this going to work out? Are we completely wrong? It's not that the MVP that we ended up building and putting out didn't have issues, of course it did. But we did then learn based on that MVP. We learned specifically about how customers would interact with this kind of vending machine purchasing process, which was significantly different from interacting with a basic website. So the point I'm kind of trying to make is that those early product decisions, regarding like the design, the UX, it will put you down a certain path. If you put up a standard e-commerce site, you're going to get learnings that are very much related to that e-commerce site. Instead, if you put up something different, you're going to get learnings about specifically that UX and the way customers interact with that product. And even though, I mean, this mantras, you can always change it later. You can, but if all your learnings or your inputs, you're looking at this product that you've built, you're looking at the feedback you're collecting, it's all going to be tied to some of those decisions that you made early on. So there's that sliver of time when we make very long reaching decisions about our products early on. We might not always realize or give them due concern because of that MVP narrative, like, time to market, get it out there, do it quick, just learn. You can always change it later. When we say we always change it later, it's kind of like we're cheating ourselves a bit. We can change it, but will we really have the input and the learnings required that will actually push us to also try those other paths? The MVPs are supposed to be about learning, but if you don't have an abundance of resources, the time and the effort that you put in, the mindset that you build with those early decisions, they're going to be really hard to deviate from. You're going to need to get a really, really bad feedback or really bad experiences from customers trying out your product or even just trying out a prototype to make kind of a really drastic switch. It's much closer at hand to just do those kind of small improvements, try different things, you reorganize stuff. But for that main core like UX, you might be stuck, both mentally but also kind of resource-wise. If you have to go back up to a decision-maker and say, I mean, this is OK, but I think we should basically rebuild it. Can we do another project? Can I have another budget? And you're going to have to have a really strong argument if you want that to go through. So if that early small wireframe wouldn't have existed, we would probably be still on a path of building like a supermarket e-commerce for selling those codes. It likely would have performed OK, but we wouldn't have been much different from our competitors. We would have had kind of the same problems, the same customer frustrations for making essentially very simple purchases, but having to go through that whole heavy supermarket experience to do it. So just looking back, it feels like there was this important fork in the road, which we didn't realize at the time. It didn't really put enough attention or weight on those decisions that we were making early on. That said, I'm not saying you need to overthink early decisions either, but you need to make them consciously about the fact that they're going to have very long-reaching implications. It's much easier to take another day or two in that early phase to gather some more data, get some more input than to change your mindset even just a few months down the road. So try not lock yourself in too early just based on too hasty resources, just because someone is yelling MVP, MVP. Time to market, time to market. There's probably material for another three or four talks just in the frameworks and processes and stuff that you can use to improve those decision-making steps early on. Someone else is probably much better equipped to talking about that. But maybe, I don't know, do you agree? Do you have had similar experiences? Do you see when you're looking back, do you see these forks in the road where you might have been persuaded to go forward maybe a bit too quickly, maybe a bit convinced that it was just temporary, that it was just for the MVP, just to be quick, be first to market, and being able to change it later? We are at the fork in the road. So I think, like, this would be a work of code. Yeah, as of now, I think, what's our decision? I think we just decided, let's come down on our stuff to just make a work of code. Is that what you're saying? Yeah. We'll deal with the repercussions later. Yeah, so I mean, this comes from a very kind of start-up context, bigger companies, established companies are going to have more established processes and steps that happen. We are from a big company. Right, that happened at this point. But it feels like these experiences can come on any level. Anything from very even just small product updates, feature updates, to launching completely new products to maybe even on a bigger scale. Anyone else want to weigh in looking back where those forks, have you had any similar experiences? Or any general questions at all, as well? Yeah, I have a question. So this seems to have been kind of by circumstance. It wasn't necessarily a conscious decision to go and everything DMED. But what about, so let's assume we buy your pieces here and our manager is telling us to ship it to the MDP and you don't actually have any data to say, well, how are we going to argument why maybe we should try something radical? What do you think would be a good strategy to say? Because it's a matter of push back. Well, I mean, when you say you don't have any data to support that argument or that suggestion, that is a bit of a problem. You should, whether it's really hard data or whether it's observations that you can at least somehow validate, ask a couple of potential customers. There's a bunch of ways you can collect data on an idea just within hours or within days. You don't need to invest weeks at a time. So even that weak evidence I think is going to go a long way. Of course, the more data, the better. And I think just looking at the circumstances, for us, I mean, when we ended up, we evaluated both of those ideas, we had really good discussions about who are we actually serving, what type of customers are we looking at. When you go to a convenience store to buy one of these codes, what's the customer experience like? There's a rack of things. At the 7-Eleven, you go there and you pull a code and you queue up and you go to the counter. But there's also actually those vending machines where you can do the same. And given the choice, if you're a young guy who wants to top up his gaming account or any young person, you would do you want to go walk around in the store and touch the codes and compare two identical cards to each other. No, it doesn't help you at all. The simpler, the better. Instead of queuing up to the counter and interacting and payment and loyalty cards, whatever, if you can instead just punch in on the vending machine what you want, it feels like we thought that was a much more compelling experience to these impatient guys who are just going to buy one code. It's not like they're going to put a bunch of codes in the card. They know what they want. They get it. And the quicker, the better. Yeah, for your question, any data is better than no data. And Grants, you only had two weeks. We mentioned you had two weeks. Right. Well, that was the initial like, you should be able to do this in two weeks. I think we ended up doing it in like five weeks. And that was still considered a basic order, a best known practice that you were going to mimic up from Amazon the rest. So had you not had this potential MVP sitting in the bottom corner office drawer that you could pull out and work with, would you not have gone through micro-MVPs upon every design iteration? So you're pulling out multiple MVP's that at some point you have to validate which direction you yield some form of more positive direction. Right, positive direction. So you have micro-MVPs that you busy iterating upon each time. And the closest one to that goal or to a yieldable objective or to a generated objective should be close to the direction you should be choosing, right? Yeah, that's what the intuition says. Yeah. Kind of what I want. Given the time, or given that you had had a little bit of extra time to first of all try and prove something. Yeah. So what it feels like to me looking back and also from experience for some projects after that is once you've chosen, make some of those core decisions, it'll be even though you create multiple iterations or put in the time to try to make variations. It's a risk that your mindset is kind of stuck a bit on some of those decisions you made. It might be difficult to step back and say, OK, why don't we try something completely different? You might be looking at, OK, we'll still have the shopping cart here. And we'll just kind of move it around a bit where we make the catalog page different. But it feels like some of that. If you had the time, you would have probably denoted it differently in the hindsight of this exact science. So if you had the time, you may would have looked at a different path to explore different solutions for the customer at hand. I can only say I would hope I would have done it. I don't have the confidence that I would have had. The backside, you always look back and think, I should have looked at all of these different options. But I'm really worried that I wouldn't have. I'm kind of convinced that two years later, I would have still gone down that path and tried a bunch of different options and looked at different ways of doing it, but still had that kind of very underlying blueprint to work with. So do you have the follow result? It's pretty close to what's, well, I think one might actually be here. Yeah, these should be production stuff. So you're basically just on one page. I want a Google Play gift card. I want the Denom to be 20,000 rupiah, 200,000 rupiah. I select a payment channel. It's basically just a buy button at the end. Then depending on what you want to pay with, that's where the Kota Pay service comes in. Well, if you're paying with your mobile account, it will show a simple window where you input your phone number and authenticate. And then you come back to the shop and the code is right there. So it's rather close to that vending machine parallel. You punch. You select the product. You say here, well, you select the payment method. It's just cash. You have to actually make a choice. But it's still just one or two pushes off the button on the same, basically, page or machine, if you would. Great. I guess I'd say thank you at this point. If you want to talk about this further or talk about payments or whatever, just catch me after the other talk in the interactive part. Thank you.