 Quite a few meetups in Asia, but not that we are understanding what we're going through basically, and you'll see what product they today does a lot of activity happening throughout the day. So we've got over 150,000 members of the community, and it's very much a community buying and for product managers. Again, the same spirit of how we started eight years ago, just buying for product people, creating a safe environment for product managers. That still helps through, even though we've always gotten a bit bigger and it's all a bit more global. But if you're getting a newsletter, that's something that we send out weekly. Again, that's got a really big audience because we share lessons learned, we share interesting articles about product management. And, similarly, we've got Slack channel, which has got over 50,000 people on it. But it's the easiest way, obviously, if you want to talk. So, yes. Yeah, I think Skype calls are never ideal for meetup situations. It's quite difficult. That being said, I think, Bill, are you ready? Yeah, I guess. There was something about the location post saying something, but I can start right away. Thank you. One sec. Fingers crossed. Great. Hello, everyone. Excited to be here. I've been on several of these talks before. I'm really happy to be on this side and check the stage for once. Thanks to Product Tank and the Sylvia for setting this up and getting us this great space. My name is Wille. 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. It's a lot about how we talk about minimum viable products and VPs. 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. I feel that that narrative often has almost a detrimental effect on some of the decisions we take at the early stage when we design and plan our products. 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. That sounds lovely. Get it out there quickly, get some feedback, learn about your users, learn about your products, make it better. The pitfall or the problem that sometimes comes up, or that 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. That's usually part of that narrative. Just get it out, you can always change and improve it later. That's basically the idea of the MVP. You put it out there, you get learnings and you improve. I wanted to approach this from an anecdote from a product launch that I was PM for a couple of years ago. I had received a rather high-level requirement for a new product and somewhere at the end of the email etc. We just put together a quick MVP and we can launch this in a couple of weeks. It should be fine, right? That's okay. So there's the actual picture of me after reading that email. Feeling the time constraints, 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. 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. 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. So you can see from the picture, I'm actually super excited. This is my yes, yes pose. This was an e-commerce site. I've 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. This is not going to be a problem. Setting up an e-commerce site. Piece of cake. So let me just tell you briefly about 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 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. Be quick. 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 or like a card 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 pull out your loyalty card. You get some loyalty bonuses. Whether it's Amazon or Red Mart or Zalora, there's quite a lot of parallels going on. So essentially this understanding of a best practice or 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. 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 the requirement. One hour later I'm already kind of signing up for a trial account that's Shopify or looking at some other 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. If 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. I was looking at that. Where's the rest of it? How is this supposed to work? It was a one page affair. No account, no shopping cart. 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. You know, comparing these two, I don't know, almost e-commerce paradigms. Like you have this, should our shop actually feel like being in a supermarket, being, you know, 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, you know, multi-step checkouts or, you know, how to optimize shopping carts. So, and 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 this, 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 this mantra is you can always change it later, you can, but if all your learnings are 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, like, 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't change it, but will we really have the input and the learnings required that we actually, 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 resource-wise. If you have to go back up to a decision-maker and say, I mean, this is okay, but I think we should basically rebuild it. Can we do another project and I have another budget? You're going to have to have a really strong argument if you want that to go through. 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 okay, 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. We 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 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? Have you 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? Yeah, as of now, I think, what's our decision? I think we just decided, let's come down on ourself to just make a quick decision. We'll deal with the repercussions later. Yeah, this comes from a very start-up context. Bigger companies, established companies are going to have more established processes and steps that happen at this point. But it feels like these experiences can come on any level. Anything from very even to small product updates, future 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? Yeah, I have one more question. So this seems to have been kind of by circumstance. It wasn't necessarily a conscious decision to go to kind of everything the MVP. But what about, so let's assume we buy your pieces here and our manager is telling us to ship it to an MVP and you don't actually have any data to say, well, I have a really compelling argument why maybe we should try something radical. What do you think would be a good strategy to say? 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. So 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. Is it like 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, any young person, 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 in 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. For your question, any data is better than no data. And Grant, you only had two weeks. You mentioned you had two weeks. 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. It was basically a best known practice that you were going to mimic from Amazon. So had you not had this potential MVP sitting in the bottom corner, an office draw that you could pull out and work with? Would you not have gone through micro-MVPs upon every design iteration? So you're putting out multiple MVP's that at some point you have to validate which direction yields some form of more positive direction. So you have micro-MVPs that you busy iterating upon each time. And the closest one to that goal or to a yielded 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. Right. Kind of what I... You would have 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 from 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, okay, why don't we try something completely different? You might be looking at, okay, we'll still have the shopping cart here and we'll just kind of move it around a bit or we switch the... We make the catalog page different. But it feels like some of... If you had the time, you would have probably noted it all differently in the hindsight of using text science. So if you had the time, you may be able to look to the different path to explore different solutions for the customer in hand. So let me say, I would hope I would have done it. Yeah, exactly. I don't have the confidence that I would have had. 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... It's pretty close to what's... Well, I think it 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 code of 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. Cool. No, it's probably... it's probably... yes, it's probably... Yeah. Yeah. It's funny. I mean, it's funny. Yeah. It's funny. My name is... I think that we're going to put it in two pages. The left is the screen, that's the... the screen is probably... Yeah. Okay. Yes. Hello. Ah, where am I? Ah, 18 pounds. You didn't see the cable so I'm going to go back and see. And... I don't know what we need to do. No, no, no, no. Alright. Hello. Sorry to interrupt your drinking. Ah, I feel important with the microphone. Okay. Sorry. So these are the slides that Mark was trying to share. I'll run through them quickly. You can see the animation. So yeah, today is... He's very excited about that. Today is World Product Day. So every product tank around the world, well, almost every product tank around the world, is trying to synchronize their events. So this is set up by Mind the Product, who are the parent organization of Product Tank. There's more information about them. So today there are meetups in 90 cities, 43 countries covering 20 hours. And I think that's why we've got the live stream going as well. So yeah, a bit of a history on Product Tank and Mind the Product. So it was started about eight years ago by Mark and a couple of his colleagues. Founders in London. It was set up by James. James and Martin. Yeah. I thought Mark as well. Okay. Sorry. So we don't really know the history. We're just minions. Inspiring talk kids. Thank you. We have Mark and Jenna and James. He had too much a girl for the regularity. Okay. So yeah, it started eight years ago in London because they felt that Product was a pretty lonely job. I think a few of them were working as kind of the sole product manager in the company and feeling like all the engineers were ganging up on them and they wanted some friends. So they all banded together and started a meetup. So yeah, they started Product Tank. I'm guessing from the laugh everybody gets that. And also Mind the Product, which is sort of the parent company of these meetups. And so eight years later, Product is a lot less lonely or maybe you just have more people to bitch to. So in total, all the Mind the Product meetups, they have over 150,000 members and 950 cities. You can see all of them on that URL there. Just out of curiosity, is anyone playing from a different city or everyone is based in Singapore? Because I've taken on a new role. If you are moving out of Singapore, but still within Asia Pacific, you can look for me. I need to look after you in this region. Yes. Yeah, she's the new APAC coordinator for Mind the Product. Yes, we have a newsletter as well. It goes out once a week. I would recommend it. There's actually quite a lot of interesting stuff on there. Yeah, I mean, there's a Slack group instance. I'm not sure what you call it. Where there's a bunch of different channels, like one for each meetup. There's conference announcements. There's general chat. There's sort of ask a question of another product manager. It's actually, it's pretty involved. So you can sign up by going to mindtheproduct.com slash Slack. There's conferences as well. I went to the London one a couple of years ago. It was really good. Never been to San Francisco, but I think that's bigger. So just a sharing for the conferences as well. We're trying to bring one here to Singapore for the Asian region. We don't know if it's going to happen. So I will work with the team back in London. Would you guys be interested in it? Yes. Oh, yes. Okay. So at least from this group of people, I guess. That's my survey. I'm very excited to take my time. Good to know, right? And there's a blog as well, which the newsletter summarizes. Yeah. So today's eighth anniversary of product tank. So it's celebration. They're trying to dedicate one day a year and get all the mingles across the world coordinated. So welcome to the Singapore one. A couple of hashtags if you want to have a look. Okay. So these are some of the ones we've got going on right now. So us, Hong Kong, which Mark was rushing off after his intro. Hanoi and Ho Chi Minh coming. And then Europe and then America and world domination. There's no animation. There is no animation on that. No. Sorry. Disappointment. But yes. Thank you for coming along tonight. We organized one of these. What we aim for about once every six weeks. So if you follow us on Meetup, that's where we always announce upcoming events. So yes. Thank you Villa. And now we've got Rizwan from Ninja Bam doing the second presentation. Grab another drink while we set up. Rizwan is setting up. Thank you all for attending us instead of the Google event. That's happening today now. Interestingly enough, we don't really have a recurring audience, which puzzles us quite a bit. So we take product tank as a product. We're quite curious as to why we have a floating demographic. We want to. But as you can see, this is kind of informal. And we just wanted to run it for the community. If you guys have anything that you want to speak to the community about, please let us know. We're always looking for speakers. If you don't want Zalora as a venue for these, let us know as well. We love the space. Thank you, Sylvia. But it's always cool to look at different venues. I think SPH is volunteering the space, but it's at the bottom. So I don't know if you guys want to trouble down. I know Red Butt is also very keen to volunteer their space, but it's all the way at your own port. Okay, so that's a no. Rizwan, you ready? Yeah, okay. And please, please, please take the stickers, guys. They're trying to get rid of it. We've been trying to get rid of it for a long time. They just arrived. That just arrived yesterday. This has been here a long time. One year. One year. One year. One year. One year. One year. One year. Okay. Okay. here. I will take the yellow. Call me. Okay. I don't know where it's from. Do you guys prefer me to use the mic or not use the bike? Hi guys, let me just check the time. This is going to be a little bit of a lengthy one. So first of all, I want to thank the product thank guys, each Sylvie, all the normal folks for inviting me today. I've always been on the other side. It's great to be on this side. I had a quick chat with Sylvie a long time ago and saying, maybe we could do something a little bit more technical. So thanks for having me here. No more fluff. So I'm talking about slaying the API bees and I've got a very sexy next slide here. They say don't judge a presentation by its cover, but in this case I encourage you to. Because this is probably going to be the most exciting slide that you'll see for the rest of the half an hour. I also want to wish all of you a happy World Product Day, if I'm saying it right. First time I'm celebrating it. It's the first time we celebrated, so it's my first time celebrating it. So happy product day to everyone here. So my name is Rizwan and I'm a product ninja. I've been a product guy for about 10 years now. I've been in different startups, primarily in fintech. So I've been hidden in the weeds for a while. I've moved into logistics even sexier. I'm known as Papa Rizwan, a product papa in Ninja Van. It just speaks to the youthfulness of the organization, not my age, although I'm married with kids. A little bit more about me. I started in 2007. I was a noob. I was trained technically in computer engineering, but very early on I realized something about myself. I wasn't a very good developer, not as good as some of my peers. And I took some time to reflect and I realized that I did have the gift for the gap. I could bullshit very well. So I decided to make product management my career. So it's 11 years later, incredible. I'm an experienced noob now. I am now a leader in BS. I basically lead a group of guys and I teach them the art of BS. I'm actually the product management director at Ninja. I've grown in many ways, including my waistline and my weight. It's not very apparent to the picture, is it? But it's true. There's this joke that's been flowing around in my office. We had a little session and we were all laughing about a product manager walks into a bar joke. This was another joke that we found. And we were laughing our heads off because we found it very funny. And then I went home. I reflected it in my shower and then I felt really sad because it's true. To a large extent it's true. Product managers are mostly entry-level programmers. This is the best we can do. Most of you would say yes. I work with a very young, the vicious, hungry group of product managers in NinjaVan. Always eager and hungry to learn new things. And the brand of product management that practice in NinjaVan is very technical. There was a small group of product managers with a very tight-bit group of engineers. We lean on them, we talk to them, we have stand-ups, we do the scrum, we do all that good stuff. We really depend on them to deliver our products for us. And as product managers who are not technical, you sometimes struggle. A young product manager came to me one day and said, Rizwan, I'm feeling a little bit difficult because I feel like I'm really going against the grain with some of these developers. He feels that he keeps saying, when can I have this? How difficult is it to be done? Why do you have to refactor it? Why can't you just add a button? How difficult can it be? And asking his questions over and over, he felt that his relationship with engineering was eroding. So he asked me, you know, what can I do to kind of improve this? He in fact told me that he felt like a pest, right? And he could only go to the corner and sink Crimea River. So what advice could I provide this little young Padawan, right? He wanted to know how he could work more closely and effectively with engineers and not always have his head bitten off. And I told him, look, all relationships are based on two things, trust and communication. So if you've got communication and you can speak technical communication, it's a huge bonus, especially if you have to work with engineers. I don't know how many of you have seen this infographic inside the mind of a product manager. I love it because I think it's extremely accurate, right? 40% of our brains or the product managers here, we should be very good in communication, at least 40% of our effort in communication, another 20% in engineering, 20% in design and 20% in business acumen. So if you've got the green bit covered, the communication, and you've got the orange bit covered engineering, you're already at 60%. You're 60% of the way. In high school, 60% was my go-to grade. So it's a good start, right? It's a good place to begin. There's this quote, and Martin will be very excited to see this. I'm quoting him, right? You know, being a product manager is all about stakeholder management. It's all about linking the various groups of people together. In order to do that, you've got to be able to speak to speak. You've got to be able to empathize. I was in a GA general assembly session last week called Inside the Minds of Brilliant Designers. My good friend over here, Norman Tay, was on the panel, and he covered tools for a CX individual, customer experience. And one of the things that he mentioned was a very important tool, was the ability to basically spend time with people you don't normally spend time with, right? Understand what's in their head, understand what's valuable to them, and that's essentially what this is about, and that's essentially what product management is all about. We have capabilities in design. We have capabilities and knowledge in technology and capabilities and knowledge in business. So today, this is my damn long introduction to my actual presentation, right? Today I'm going to talk about APIs. Why APIs? Because I feel in the line of work that we do, being able to speak API is almost being able to speak engineering. I'm going to try to cover some key things today. For those of you who have zero background into APIs at all, the five things that you've got to kind of understand about APIs is to be able to get there. My hope is that by the end of the day, you would have these fundamentals be able to go back, do some research and reading on your own, and you're on your way there, okay? I know the title of my presentation was Slaying the API Beasts, but for those of you who thought you were really going to come out of here and slaying the API Beasts, that was event bait or click bait for you, right? I'm going to be covering fundamentals. So quick question. How many of you know Karate Kid, the movie? Miyagi-san and Daniel LaRusso. The first one, the original one. Wax on, wax off. Who knows that? Oh, that's really sad, right? That's really sad. So I wanted to say today I'm going to teach you the wax on and wax off of APIs. And I realized that that should have been my presentation title. But now in retrospect, less than half the room knows about this, so it's quite concerning. So please go home and torrent it or something. Okay? So jumping into the meat of the presentation, watching my time, what is an API, formal definition, right? You can read it for yourselves. The layman way to define it is a stable contract for communications and computer services. Let me break this down for you. An API is basically a mechanism that allows computer services to speak to each other, okay? Servers, computers, web services to speak to each other. As human beings, I can talk to you and say pass me an apple or throw me an apple or throw me that red fruit on the on the planet or roll it to me and you still understand because you've got this thing, the internet and the world, the web, you've got to be more direct and specific. APIs are basically communication contracts. APIs are not languages, APIs are architectures for communication, okay? So every server has a different platform, every server uses a different language. We need to define it very specifically. A very common analogy used to define APIs is restaurants. I'm going to use the analogy right now. Very quickly, imagine that I'm a web service and the restaurant is a web service. I'm trying to get something. When you go to Google, you type it in a search, you're essentially going to Google and getting something back from Google, essentially, right? But those servers are talking to each other. When I go to the restaurant, what do I look for? I need to be able to order what I want to order, but I can only order what the restaurant serves, which is how kind of the web servers work, right? I go there and I look for what's called a menu. A menu essentially is an API document, right? A menu tells me what's available so I open it up and I go through it and I look at starters, mains, and I see burgers and I look, I see cheeseburger, great. So I'm going to call the waiter. In my example, the waiter is the API. The menu is the API document. Slightly different from this diagram, right? I speak to the waiter and say, get me a burger. The waiter says, yes, sir, goes over to the kitchen, passes the message to the kitchen and comes back to me and says, your burger is on the way, sir. And we've got a request response loop happening. That's a very good analogy of what an API is, simplified for everyone here. The problem though is that no two APIs are the same, right? So today, can I really give you a breakdown and you guys go home and pull out any API document and everything I've taught you applies? Unfortunately, the answer is no. But I can't give you some basic building blocks that allows to get you halfway there. There's five elements you should care about. This is the five I mentioned about. Request, response, data, auth, and hitters. Let's jump right in into request. So I mentioned this request response cycle. I'm going to speak in the world of the internet. APIs can be used in many different domains, many different areas, protocols. I'm going to use an HTTP protocol because most of us, I would imagine, are working with products that revolve around the internet. So let's keep it simple. So the basics are a client would send a request to the server and the server would return a response. Very simple, a concept introduced here, request and response and client and server. When you make a request to the server, what are you actually sending? You're sending a request block. And the request block has a very fixed structure. Remember I mentioned that APIs are contracts. They must have the required information and the formats that were defined by the API document. So there are four things in the request block. Remember, request and response, request is the first one. There are four items in the request block. I'm going to go through the first URL and method. What's a URL? A URL is me basically telling the waiter that I want a cheeseburger in this manner with a URL. So basically protocol is HTTP, which is the internet's protocol. The host is maybe the restaurant's name. The port is, I would explain the port, the resource path is where to find what I want, the resource that I want. If you go to Google Images and search for image, you're looking for images, the resource you want are images. But in my case, I'm looking for a cheeseburger. So when I open the menu, I'm looking at starters, mains, burgers, cheeseburgers. So likely my path would be mains, burgers, cheeseburgers. And what's my query? What's a query? A query is when maybe you've got many cheeseburgers, so you want to be very specific on which types of cheeseburgers you want. So I could put sauce equals mayo and bun equals sesame. So that allows me to tell the API exactly what I want. And this is the message that I need to be including in my little block when I pass this message to the waiter. The next thing I want to cover is the methods. So in an API, when you send an API, you've got to also inform the method that you're using. So there's many methods available, but the four most common ones, and I'm sure many of you have come across it, get, post, put, delete. Get basically is to get a response. Put is basically to create a resource. So you post to create a resource. Put is to amend or modify the resource. Delete is to basically remove or delete the resource. So imagine in that example I gave you in the menu, or sorry, it was at the restaurant. Don't bother to read all that. I'm going to explain it to you. I'm at the restaurant. I sit down. I look through the menu. I've decided what I want to order. I do a post to the waiter, starting with something abstract. I would like a cheeseburger, please. I'm asking for a cheeseburger. I'm going to make a cheeseburger for me. While the cheeseburgers are being made, I call the waiter because I have a change of mind, and I'm going to put a put request, put sesame seeds. So the waiter hears me and goes to the kitchen, hears my put request and comes back with a response, says, sir, we've added sesame seeds. So I'm waiting and I'm really hungry. I'm waiting for my dinner and I keep calling the waiter. Get my cheeseburger. Get my cheeseburger. Get my cheeseburger. The waiter keeps coming back and says, it's not ready. It's not ready. It's not ready. And I get really frustrated and I say, delete order. And I leave the restaurant. Those are the four methods which I just mentioned and how they would affect the resource based on the verb that was used. I also mentioned that the waiter kept coming back to me and giving me a response. The way the waiter gives me the response also has to be structured. Remember, we're in the internet world. Computers talk to each other. It has to be very structured. For a response, this is how the structure looks like. What I want you to focus on is the status code. How many of you have gone to the internet, looked for something and gotten a 404? I think that's the most common one. Everyone knows a 404. By the internet protocol, there are many, many HDTV status codes. This is a critical piece because what I told you early on is that we need to be able to bridge the gap between product managers and developers. Developers often say, Rizwan, we've hit a 400 or 503. Sounds like police codes, but they're actually HDTV codes. 503 is service unavailable. In the old days of Ninja Van and Zalora, Zalora would tell me, Rizwan, 503, we can't get our orders through. We need to be able to understand this on a very high level so that we can be effective while speaking to our developers. If our developers have to explain this to us, it makes it a little bit more difficult. I'm going to skip the next section now, which is the body, okay? Wow, you can't really see this, can you? It's very small. In my example I gave you, I went in the restaurant and I ordered one burger. What if I wanted to order a whole meal for my whole family? So two starters and five mains and three desserts and 10 drinks and extra fries and stuff like that. Does it mean I need to make 20, 30 different calls? The answer is no. The answer is you can actually put the information in the body of the API call, okay? So in this example, there are two types of languages which are commonly used with APIs and they are JSON and XML. I'm sure everyone's heard of them. JavaScript, object notation and extensible markup language. I'm going to introduce to you again some critical elements about JSON and XML. Okay, these are the languages commonly used or formats commonly used to define the body. Body is also known as payload. So when you developers say, can you check the payload, right? It means can you check the body of the response or the body of the request, okay? I'm going to show you this about JSON. JSONs, you can identify them basically by the curly brackets and what's called a key value pair. The other thing that really critical to know about is you can't really see this here, but it's a square bracket right in the middle. So there's an array. I hope you guys know what's an array, right? Key value pairs can be individual or can also have an array within them. This is an example of a very long JSON. The key value pairs have value strings and you can see this is an array within the key value. Each item is also called an object. XML on the other hand looks kind of like HTML. You've got opening nodes and closing nodes and you've got values in the middle and they use nesting to define arrays, okay? I'll show you why later on this is kind of important to know if this is something you're not familiar with. Next I'm going to cover headers, okay? We're almost at the end now. How do you know, you know, some restaurants allow you to just come in, place the order and kind of pay later? Some restaurants require you to put your credit card up front. They're not going to serve, they're not going to serve up your resource to you, right? So how do you know, how does a web service know that you're allowed to request for a resource from them? And this is where the concept of authentication comes in, okay? In that API, in that request and response I spoke about, there's also an element of a header and within the header you can put in a lot of different things which allows you to facilitate the communication between the two parties. Two examples are authentication and the next example is the language, right? There's many different types of authentication. I'm not going to dive into this today. It's a very deep and heavy topic, right? There's basic authentication, there's API key authentication, there's OAuth and they all do basically the same thing. It allows a requester to basically prove his existence to the, the client to prove his existence to the server so the server can willingly and clearly provide that response accordingly. Another example is the language. So if you've got machines on the internet that speak different languages, in this example, the client is only able to accept JSON. So you can include these headers in, sorry, these values in your headers, right? The client tells the server that I can only accept JSON as a language and the server will respond and in its header it will state that I've sent you a response, the body is in the format of JSON so that the requester knows how to kind of read that information, okay? So that's done. Five key elements introduced to you very quickly over 10 minutes I believe, right? So what's really next? What I encourage you all of you to do is to go home and try these things, right? Try to identify the authentication methods, grab an API document, try to identify the auth methods, review all the endpoints made available, examine the body of each endpoint and if there's a test API, try it out. Very quickly what I did last night, yes? Not yet, almost, yeah. Very quickly what I did last night is I pulled out the API document to point out some of these things for you, to kind of actualize and realize what we've just learned, right? So if you open Shopify and I encourage you to look at Shopify's API because it's one of the best written documents around. APIs are known to have really crappy documentation but Shopify has won the most amazing. They must have a product team just for the API documentation, right? When you open it up, the first thing you see is authentication, although you can't see anything here, right? I've extracted what it says here and now when you read this message, you kind of know what I'm talking about, right? It kind of means that you've got to provide an ex Shopify access token within the header when you make a request. How do you get that token in the first place? You've got to do this auth handshake and click there to find out how you get your auth handshake, right? Kind of makes a little bit more sense now. Zoom through the document, you go to the product page and you can't really see this but it says what you can do with product, right? Now you can see the first thing, get, that's your method and then you've got your URL which is your resource allocation, right? Or your resource identification. It says get admin products.json. What does that mean to all of you? Make a guess, get all the products in your store. In what format? Json format. Second one was get products count. Get all the product counts in your store. Suddenly you find when you look at documentation you kind of make sense. As a product manager, how do I use this information? I'll get to that in a moment. You can open up each of those calls and look at the content now. So when you look at a very good API documentation it has the methods which is also known as the endpoints and then it has sample responses, okay? So when you open it up, you have a sample response. This is for get all products. Suddenly you see it's in Json, curly brackets, square bracket. So if you read it downwards, this is a list of products. Array of products. A product has an ID object, a title object, a body HTML, a vendor, a product type. And then it's got nested array in it as well. It's got variances with a square bracket and further items as well. So suddenly scrolling through it doesn't seem as complicated anymore. One thing to take note though is for many API documentations, even though this is an array, they only show one instance. So it's not immediately obvious to you if you're not familiar with the usage of square brackets and curly brackets. That's an actual array, okay? The last thing you can do is one question someone would have is, okay, if API is a language that computers use to talk to each other, web services use to talk to each other, how am I as a product manager going to be testing APIs or trying it out? Your fourth step was encouraging me to go try it out. How do I try it out? Do I use terminal or command prompt? The answer is no. There are many other products out there that allows you to use third-party tools that allows you to play around with APIs in a visual format with a UI. The most popular one is Postman. And this happens to be a screenshot from, again, the Shopify website. Shopify even lists down how to use the API on Postman, which is freaking amazing. If you look at the interface of Postman, the common things appear again. The method, the URL, the body. I believe this is authentication, headers. It says here JSON, application JSON. And then you've got your body. All this doesn't become as scary anymore. Why is all this important to us as product managers? I mentioned the ultimate first and foremost. Our goal is to be able to speak the speak of developers. To be able to understand what they mean when they say, Rizwan, I think we need a new endpoint. It needs to be a get endpoint. It needs to point to a particular resource. It needs to return an array of items in its body. For you to be able to converse with your engineers, and that level will bring you that much closer to Nirvana. Secondly, APIs in themselves are products. So Shopify has a product manager who's in charge of the product. Ninjaven, unfortunately, we don't yet have a product manager who's in charge of our API. Our engineers take care of that. But in many cases, we've heard, for example, let me think of Trulio. Who's heard of Trulio? They have an API as a product. They have product managers who treat that API as a product in itself. So that product manager needs to know how to read, eat, breathe, and live API. How to write these documentations, how to understand them, how to communicate these documents to their users. That's the second reason why we also need to get familiar with APIs. Because APIs in themselves are products. Third reason, many of us work in organizations that deal with partnerships. Ninja partners with, you name it, Lazada, Zalora, Sephora, right? Yeah, Zalora. How do we integrate with them? APIs. I recently worked on integration with Line in Thailand. And literally the only documentation was given to me was an API Line documentation. They gave me a flow and they gave me a documentation and they said, let's integrate. So I had to spend a day looking through those, that documentation, understanding it, and then flying over to Bangkok, sitting with their engineers and product managers and speaking Klingon. Basically speaking API. We had to sit down and talk through APIs and understand them. Organizations like that also speak API even on the product manager level, even on the QA engineer level. So it's important for us to get there. What I've given to you hopefully today are the basic tools to get you started. There's so much more to APIs. That you can kind of begin to explore, right? I did mention that there's so many variants of APIs. They have so many formats. Every organization kind of implements it in their own different way, right? Some people use authentication in headers. Some people shove it in the body. Some people do it as a separate call, you know? Imagine the scenario, for example, where you're requesting for all the products in a Shopify page and you turn to 5,000 products. Are you going to consume all that? Authentication comes into play. Authentication comes into play. Companies put in call limits as well to ensure that you don't kill their servers. There's a concept called webhooks that's very closely tied to APIs as well. These are all further, a little bit more advanced concepts which I hope you take the time to kind of dive in and get to know. But basically my hope today is to have given you a little bit of that little baseline fundamental wax on, wax off of APIs, right? So thank you very much. Reach out to Rihya. Yeah, Rihya. Sorry, I'm not romantic, right? That's your legacy? You have any kind of an API? Yeah. So there's something called middleware, right? Yeah, so what he's asking basically is what if, for example, you've got system A and system B and system A and B use totally different variants of APIs or totally different languages. It might not even have an API, right? How do you integrate legacy systems to new systems? And the only answer I have for that is middleware. Basically, building another system in between that's able to talk to both sides and do the conversion, right? Yeah, it hurts. We do it in Ingeavan as well where we need to. But unless you can get out of that legacy systems there's no real elegant way out of it. Yeah. Any other questions? Yes, go ahead. Okay. Very interesting question. This is a struggle with, not even on the API level, but some of my product managers here. And there's a conversation that we constantly have. This is a struggle we have as agile practitioners, right? Agile doesn't encourage documentation. So even, yeah, is that wrong? That's what I've been taught in school, right? Agile doesn't encourage documentation. You do things quick, write high-level statements and go test and experiment. Similarly, and that basically transposes as a culture into how our devs do their work, right? I can tell you even within Ingeavan we've got varied practices around how well we document our APIs. We've got teams who are much more resolute that will build... I'm not sure what they're called, but there are libraries available out there that as you write your code and basically we're building off microservices, these libraries will listen for the new endpoints and document them as they go, right? So the hard work of doing all the typing out is actually taken over by libraries. It's all about finessing the document at the end of it. This is a great, I think it's a great idea because in a microservice environment, I'm sure most of us are working on microservices right now, this solves a huge problem. But that discipline to ensure that that library is set up properly and running and updating all this information is still required on the developer's side. So as a product guy coming into a new company and if I've been told, let's clean up documentation. The first thing I would do is to understand how bad the situation is, right? APIs have many versions or variants. So you have the legacy variant that each brought about. You've got the version 1, you've got the version 1.1, the version 1.1.1, right? And every time you have a new version of an API, you're going to push clients over or people who are integrated into one into two. But there will be laggards and there will be people who will be left behind. Unfortunately, just as we groom our product backlogs, we've got to be vicious about these things occasionally. So identify what is your company's goal or your company's roadmap for the next two years, for example, right? Is it to focus all our resources on a particular version of the API? As an example, if our focus is on version 4, then we've got to make a call on whether we need to call the users on version 1 and 2 because we cannot continue to manage an ever-expanding group of APIs. It's extremely difficult. Once you have that understanding of where your focus lies, for example, let's keep people on 3 for another 6 months and then push everyone over to 4, focus all your documentation both on the development level and on the product level on getting it right, at least to that degree. There are tools out there to help you these days. I don't know how many of you have heard of Apiary. There's also... Swagger. Swagger, that's right. That really makes it very easy for us to write documentation in a very structured, simple, organized way. No longer do we need to format confluence pages and stuff like that. It's really about filling up the blanks. Shopify is an anomaly, right? You can go out there and look at APIs or products that you use. Not many will reach that level of detail. It's a great example of what we all should be striving to be getting to in terms of API documentation. But we struggle because APIs, just like our products, are living organisms and they change all the time. And we build APIs in agile as well, which is anti-documentation, right? Next question? No more questions? Great. So, thank you for Rizwan and Bill, as well as Michael for helping us to record this. He's from energygears.sg, so if you're looking for the slides and the live stream, it's actually there. And thank you. I don't know why you guys are always new. Please come back again. We'll be here to clean up and please talk to us as speakers will be here. Thank you very much. Thank you.