 It's always an interesting session to take right after lunch, to sit and take both. Indian food doesn't help either. So I'll try not to bore you too much. We'll see how it goes. So one of the things Narish talked to me about was to really bring out how we are leveraging lean product development. So we thought, OK, we'll put together a few things and share our experience as to what's happening in our world. Maybe it's of use to some people here. Maybe you guys are already doing it. So that's basically the session more about talking about how we are leveraging lean product development. And we are a bootstrapped company. So talk a little bit more details about that further down. So customer discovery or product discovery? Is this really a question? I don't think so. Anybody who's worked in a large corporation or startup always knows that working towards what customer wants is the prime focus. You want to build something what customer wants. At the same time, you want to see how or what they want. So you do a lot of tests for that. In my previous organization, we used to do a lot of AB tests, MVD tests, usability tests, customer feedback survey, everything. So why did we actually do it? You guys know why we do these kind of tests? Feedback mostly. It's feedback. But at the same time, there is a contrary to this. Henry Ford once said that if he always listened to customers, then he would actually find a faster horse instead of building a car. So it depends on how you look at the world here. We believe in data, and we like to see what they want, and then go based on that. So customer discovery is something that you always have to do to understand what customer wants. And then you follow up with your product discovery. So it's a feedback cycle. So in our organization, what currently I work intent-wise, basically we spent almost a year doing customer discovery actually. So what we really did at this point was we knew a lot of problems that we were trying to solve. So we went to fear for customers, rather people we knew who would work in different companies, and we worked with them. And we tried to solve those problems through both our knowledge of the business and also using some of the technology. So it's a constant feedback between your customers, your business, your development team. So that's basically the theme of this. Customer discovery, you do first. You go do your product discovery, start building your development, and continuous feedback cycle after that. So what's our story? So me and my co-founder, we have more than 15 years of experience, worked in large corporations. So we have lived and breathed the problems while we were working at that company. So what we decided was let's go find a solution to this problem. Everybody faces this problem. And I'll tell you what the problem is in the next few slides. So we said, OK, let's go figure out what the problem is, how we are going to do it. And then in the process, we said that, OK, before we do this, let's try to put some ground rules. What's our core belief? What do we want to build our company on? And myself, I have actually been working on the agile since 2006. I've been an agile coach, been helping our organization to actually grow into agile in the large company. So I've been doing this for a long time, and I know that it works. So that is something we leverage both from process perspective and also from a development perspective. Business hypothesis. This is exactly where the question comes in. As to what do you want to build? How do you want to build? What is this address? I mean, building something for the sake of building will never help. So this is where our hypothesis comes into picture. So I'm going to talk about a few hypotheses as to how we went about this, how we chose what we did, and where do we see ourselves going. And so that's basically our story in terms of where we started off. So like I said, I worked in a company called Orbitz Worldwide prior to this. I used to head there India Center here. Right now, I am the co-founder and CTO of Intent Voice. So that's the company where we help our customers with marketing strategy, analytics, and optimization. And basically, I am an engineer. So I've been coding for a long time. So I've helped people in terms of architecting big data systems in terms of how you manage your pedabytes of data, especially at Orbitz we did this. We started in 2009 using Hadoop infrastructure. I think two years back is when we actually moved a lot of those to cloud infrastructure. But the point here is that I've spent a lot of time in data and my co-founder has spent a lot of time with marketing. So that's kind of where we came together to really try to solve a problem. And like I said, agile is not new to me. So when we actually came together two years ago, one of the things we started reviewing is, should we go after B2B or should we go after B2C? The challenge with B2B is it's a little bit slow in terms of how you build your organization. B2C is interesting, but it has its own caveats to that. So what we decided was based on our skills and our experience, B2B makes more sense for us because one, we knew the system in the digital marketing space. Two, we worked on these problems before. And three, we know that there are not good solutions out there to really address these problems. So we decided, okay, we're gonna do B2B. Then came the tech piece to this. Once we did a couple rather, I would probably say nine to 10 months of work, then we figured out, okay, how do we really address the automation part of it? How should our platform be like? What do we need to leverage? So me being a tech person, I realized very early in my career that technology is an enabler to a business solution or a business problem. You shouldn't go build a business based on technology. Right? There are a lot of cool stuff happening in the tech world right now. And everybody wants to work on cool stuff. It's good you can work on it, but what we really need to understand is that, is there a business problem that we are trying to solve? And what technology really makes sense to use for that business problem? So that's kind of the approach we took in terms of tech. I'll talk a little bit in further slide on what kind of things we do in a tech scenario. And finally, the other question we had was, have you guys read this book called Blue Ocean Strategy? Anyone? Okay, cool. So that's basically what the blue and red is here. So it's a blue ocean and a red ocean. Red ocean is basically where you have way too many players in a particular area. And the blue ocean is where you find an opportunity to really innovate and come out with some kind of good business model there. So we try to figure out what is our blue ocean, right? If you look at digital marketing space, there are, I don't know, maybe hundreds and thousands of companies out there trying to solve problems for marketing world. They use data, they use what not. So what we really identified was over the last, I would probably say five, six years, we worked very closely with marketing team at Orbitz and I was working at Orbitz and we actually identify the core problems which nobody is trying to solve at this point or maybe they're trying to solve in a different way, which is not mainstream right now. So what we really went after is something called customer intent, right? In the marketing world when you show ads to people, they base the ads on certain things, right? What computer are you using? What browser are you using? What geography are you coming from? A bunch of different parameters. But when you go to the search world and display ads world, there are a lot more involved in terms of how you can target the ads. And for us, understanding the customer intent and targeting based on that was very niche. And hence our company name is called Intentwise. So basically we said, okay, this is the area we're gonna go after and that's where we did the customer discovery for a long time while trying to build our platform and automation along with that. And finally data, right? I mean data, obviously for us, data is the foundation on how we build and do things. But in general, considering data is very important when you actually look at the startup ecosystem, what you wanna do, how you wanna do. You look at any startup pitch, you will see, okay, who are my competitors and what's the market? What's the target revenue, blah, blah, blah, right? And understanding that data before doing something is very important. Okay, so what's our core belief as founders? So my co-founder is in Chicago. He used to work at Orbitz with me. So one of the things we believe is that you cannot do customer discovery in isolation to product discovery or vice versa. And you will hear me say this over and over again in multiple slides. So that's what one thing we really believe in and we actually went through this process of a year of customer discovery to really figure out, okay, are we in the right track? Are we doing the right things? Are we building the right things for them? That's one of them. Search and discovery at every step. Some organizations call it as test and target, whatnot. So basically every single thing that you do or build, you wanna test it out, okay? A minimum viable product or A-B test, A-B test. What may be it, whatever format, you have to test it. So we truly believe in that. And the last one, again, coming from a technologist, this may sound odd, but this is very important. It enables the business. That's basically what we believe in. It doesn't mean that we don't use cool technologies. We definitely do use cool technologies, but we do know where the fine line is between running a business versus building something in a technology and figuring out a business for that. So that's kind of what our core beliefs are. So lean product development. I think this is interesting. So I wanna quote Eric Rice here. So startup success can be engineered by following the process, which means that it can be learned, which means that it can be thought, right? So a lot of you have been exposed to Agile, Scrum, Kanban, whatnot. There are way too many processes out there. You can basically figure out what works for you, right? For us, what really worked is lean product development, right? So one thing what you guys need to understand or which we did understand very early is lean is not something which means that you don't spend money on. Basically, lean is a process that you need to understand for your product development. That's basically what lean product development is. And again, the slides basically talk about more about how we iterate in iterations. So by the way, we use one week iterations. I've done three weeks. I've done two weeks, especially with startup. Things change a lot very frequently. And we wanna make sure that it's small enough cycle that we can address it. But at the same time, the process is ingrained within our developers and the business teams together. So this is the one slide that I thought, okay, I will put for tech, since me being a technologist. CI and CD are the core of your culture, right? And we've done CI and CD at Orbitz for many number of years. Many companies claim they do CD, right? But in reality, what you need to understand is there is a continuous deployment and there is a continuous delivery. In a world where you are focused on customer, you need to focus on continuous delivery. What continuous delivery tells you is basically, I wanna give an incremental value to a customer every time I deliver something. Whether it may be a new feature, whether you are fixing something for them or whatever it is, you can have hundreds of continuous deployments in a day with zero value to customers. That's still okay, because from a deployment standpoint of you, that's there. But what we are focused is more on continuous delivery, which means that every time we deliver something to production, it has to be of value to the customer, right? And again, I cannot stress more on the data stuff. So when I was leading the data analytics team, the constant complaint we heard was, we haven't instrumented the data. We are going live tomorrow. We don't have any metrics to measure. We are going completely blind. So how do you address this problem? Even last year when I spoke at Agile India, I was talking more on the data front of it. And there were so many people who basically said, hey, these are exactly the problems that we go through. And this is not new, right? So when you guys are developing something or focusing on building something, right from day one, think through data, because data is what will really tell you whether you're successful or not, right? And this is one of my favorite. Do not fall in love with your code. Do you guys know why? Anyone? Exactly, right? The moment you like your code, you will not take it away. You think that's the best code that ever could be written and you will not touch it. And the problem with this, so two weeks back we were at a panel, Nareesh was also there and is a big organization. We are talking about this whole thing. And one of the things they said was, hey, we built a POC, proof of concept. And even before we realized there were many customers using it and we didn't know how to stop it. And they realized they had some issues with the tech that they chose. Now it became very difficult for them to change, right? That's one aspect of it. The other aspect of it is things change a lot. You have to adopt, right? Large organizations have data centers and basically some of them have data centers throughout the world. But when you talk about cloud, then there are huge issues in terms of how they move from their data centers to cloud, right? What works in your data center might not work in cloud because there is something called resiliency, right? You will have to take all those aspects of it when you build your code. So don't just fall in love with your code. Yes, you can, but make sure that when there is a need for change, you can adopt to that. So that's one of the principles that we really follow. So to give you an example, initially when we built some of our batch processing of data through the APIs, whatever we need, we built it on Amazon EC2, right? How often do you run these batch processes? Maybe once or twice a day, right? When you run once or twice a day of batch processors, why would you need a whole instance for the entire day and pay for it, right? So immediately we realize that, oh, okay, there's something wrong in here. How can we make this better and cut down cost, right? So we started using AWS Lambda, which is a serverless architecture, right? Where it spawns off its own instance based on your needs. So that's kind of how you have to adapt and change based on your needs. And that's the reason why we keep stressing within our organization and whoever I talk to saying, don't fall in love with your code. The last one. Has anybody here been in any discussion about build versus buy? Build versus buy, I see one hand here. Okay, many hands, good. Build versus buy is the most complicated battle you will ever fight in an organization, right? You have a group of people who say, I can build the coolest product that you need within our organization, I don't want you to go buy. Then comes your business team, marketing team and all the leadership team and say, hey, you know what? You will take six months to do this. Guess what, I'll pay money and go buy it right now. And this is very common in a lot of organizations. So what I've seen, I've been through a lot of these battles personally and what I recommend people is that, hey, you wanna build something? Just answer this one simple question. Is this code to your business? Okay, I'll give you an example. We were an online travel agency in my previous company, Our Bits, right? We tried to build a log processing system. You know what log processing systems are? Like, so you have server logs, there is a problem, developers has to look at it. So we built a UI, we built a log processing, use Apache flow, we use Hadoop, blah, blah, blah, everything. Guess what? One year or maximum two years down the line, it became stale, splunk, killed it, literally killed it, right? And these are the things you need to really realize, the building aspect of it, answer simple question. Is this code to my business? If not, there are way too many people in the industry who will innovate much faster than you. Do not build. And that if you understand, the battle is won here. And say it's not an easy battle because there are way too many stakeholders involved, way too many egos, whatnot. So that's something that we focus on in terms of our tech. If it is not code to our business, we try to go in the market and see, hey, is there a solution for what I'm looking for? Guess what? I'm gonna go buy it. A simple example is we needed to do a lot of integration between multiple systems. I could easily write a Python script to do this actually. But guess what? It's not my core. We went and started using Zapier. If you heard Zapier, it's actually a fantastic tool. It connects like almost 50 plus products and integrates with each other. You can do a lot of things out there. So that's kind of what you need to really realize when you were building something. Okay, so this is where our journey started two years ago. Basically hypothesis current gap, right? What we started looking at is when we are working in the marketing industry, we said, what are the current problems in paid search marketing? What are the current problems in display ad marketing? What is it that keeps a CMO awake through the night? These are some of the questions we started looking at. And what we really realized was we went through multiple vendors to try to solve these problems and none of them had solved these problems. And even if they had solved, there's like a fraction of the things that were solved out there. So we started reviewing the landscape and figuring out, okay, hey, are there people out there who have solved this problem? If so, then it's a moot point for us. We look at something else. But in reality, the way people were solving this problem was really putting people to it rather than solving it through technology or solving it through automation or solving it through different means, right? So we figured, okay, this is a great opportunity for us. And let's figure out how we can actually solve this problem. And that's kind of how we ended up with few beta customers in terms of doing our customer discovery and trying to build the product out there for them. And at this point, if you really look at our system or platform, we are probably, I would say, 40% automated. That's it. But it's okay. We are still doing well. We are a profitable company. We are not burning somebody else's money. We are building something which customers actually want and are using. And that's kind of how we actually see this, okay? So 40% is still a long way for us to go. And you need to understand bootstrapping and B2B is really challenging. Patience is really needed in terms of building a solid, scalable company out there. Are we doing it right? So intent, right? So this is kind of where we actually started doing the niche area of our innovation on how we do it. So like I said, we saw problems in search marketing. We saw problems in display. We saw problems in Amazon ads. What we really did was basically, okay? How do we solve this problem through technology, right? So what we really realized is the focus should have been around customer rather than anything. And that's where we went after. So we said, okay, let's figure out what is the customer intent. Is there an easy way to figure this out? If not, how do we figure it out? What other data points we want? So we started building data corpus for this. And data corpus is nothing but a data set basically for different things. We have multiple data corpuses based on businesses, based on geography, box core, lot of things. And we actually use our core IP, which is our ML algorithms, to derive customer intents in multiple different ways, which is leveraged within our platform. So let me give you an example. The first example is actually from a travel company. So if you look at this, a user is searching for Chicago hotels, all right? When an analyst in a marketing team looks at this, he can't derive anything. He just thinks that somebody is looking for cheap hotels or Chicago hotels. And Chicago is a huge city. You probably have thousands of hotels around the Chicago neighborhood. So what we really started looking at was, we look at start looking at the customer searches, right? When you look at, oh, by the way, the top one is the keyword for paid and the bottom one is the customer search. So when you start looking at the customer search, you can actually derive some intent out of it. So if you look at customer hotels near Navy Pier, Navy Pier is a big attraction place in Chicago. And maybe this person is, he wants to stay near Navy Pier because he has kids, he wants to take them, what not? You can derive some intent out of it. It might not be perfect. Models are never perfect, right? Some are useful, but never perfect. So if you look at the second example, hotels under 100. Okay, this person doesn't care where in Chicago, but all he cares about is his price point. He wants it under $100. And the third person, if you look, it's a Wrigley Field. It's a Cub Stadium or a baseball stadium. And the point is, we are trying to derive intent out of it. Sometimes it's easy to derive through the searches, but a lot of times it's not. And that's the reason why we built out a set of data corpuses in terms of leveraging that within our algorithm to build the intent. Similarly, we have another customer which talks about tutoring, right? Somebody's looking for organic chemistry. Somebody's looking for inorganic chemistry, completely different, right? If you just bid for chemistry tutors, then instead of showing 50 tutors, you might show 100 tutors for them, who tutors both organic and inorgan. Chances are they might teach both, but the point is the intent is missed out here. This is the best we have. We use this example everywhere. So one of the pass distributor has something called Jackson Control. So when you go to Google and search for Jackson Control, actually it would show Janet Jackson Control music album. Why is that? Because there is a match between Jackson Control of what they're expecting versus what customer is searching. Completely irrelevant. No connection here, right? And these are the things, there are millions of search queries for each customer. How do you scale? Like one customer, yes, fine, but we have many customers and how do you scale this for so many customers? How do you derive intent for so many customers? I think that's kind of what our really the core work began in terms of building our platform. So I said we do strategy, analytics and optimization. All these things that I'm talking about comes in the analytics part of it. Optimization is where we help people do the ad testing and landing page testing. So that's what our platform does and strategy is mostly targeted in terms of CMO discussion, in terms of we do build out graph DBs called intent maps, which helps basically derive strategies in terms of a long term vision for a CMO aspect of it. So that's kind of what our second one was. Any questions so far? Yes and no. The reason why we believe that way is because, see think about this, you gave an example of VPCM over. These are just people and roles out there. Eliminate all these guys. When you really talk about customers, in a B2C world, customers are basically all of us, right? That is very simple straightforward. In a B2B world, there are way too many stakeholders, way too many customers. But in the end, if you really look at this industry, what it boils down to is, it boils down to the people who are on the ground level actually doing this in and out. So even if we talk to CMO level, it boils down to the analyst level who do it in and out every day. So when we say customers for us, right? We are talking about the ecosystem of people, not just one or two people out there. And you take this same set of ecosystem and go to any company. It's the same story for us. They all give us the same story. Say, hey, I can't do this matching easily. How can I make it better? And I can't do this manually. How can I automate it? So those are the feedback that you actually get. Obviously you don't take all the feedback because you have limited resources, limited money. And by the way, we are, our company is two years old. We have eight people. We have in Bangalore, Hyderabad, Chicago and Russia. So the point is with a small set of group of people, you can't do everything. That's where the decision-making has to come. What do you wanna do that makes impact to the customer? So that's where we really review from an impact perspective, what is the ROI for each of these, right? So when I say customer, it's the ecosystem of people within an organization, not just one particular. Yes, sure. Good question actually. See, in our, more than our mind, based on our experience, what we went through, simple example I'll give you. We wanted to build something called customer intent model, where it will really say in the previous slide I was talking about this, right? So where I can really derive a customer intent for what they're really looking for, okay? So when we say customer discovery in our mind, we talk about this ecosystem of people on how they operate and run this business, okay? And when you talk to them, they basically say, hey, here are my big problems. Here are my problems. Here are the problems I can live with. So you need to figure out, based on all the people that you talk to, okay? Is there a common theme across all the customers here? And based on what we've done in SEM world, we've worked for six years in SEM world too, and we know that, hey, this is a problem or this is not a problem. So when you take all these things, talking to people, you understand, okay, does this really make sense to build something on your platform or not? So that's basically our customer discovery aspect of it. When you're building a product, right? Usually product development happens in many different ways. Typically you basically write, product people gives you stories or whatever it is, and you build basically. But who decides what story to build? It's the product people, correct? But how do product people decide what to build through customer discovery? So the point here is at some level, whatever that level may be in a startup or in a large corporation, people are doing customer discovery, and that is fed back to your product discovery. Now you build something, and this has happened many times for us also. We go try to build something and say, hey, you know what? This doesn't make sense. I'm trying to build this. Let's go back to the customer and ask, do they really need this or is it something else that we figured out based on the product? That's your feedback cycle out there. Hopefully I answered your question. If not, we can always cover that. All right, how am I doing on time? Complexities, a lot of complexities, whether like any organization or for us, what we deal with size and scale of data, like each of our customers are small customers where we see a couple gigabytes of data on a daily basis. But when we combine all our customers that runs into terabyte for us, so for us the problem is still complexity of the data itself. Thankfully, this is not something that is new to us. We built systems both on our cloud, private clouds, public cloud, whole data systems on handling this. So that was not our problem. Text analytics basically is very complex. So if you have ever worked on NLP, you realize that there is no one silver bullet that will solve your problem. So far from what I have seen, they say 60% is what you can reach with your accuracy of this. So that is our biggest problem, or rather was our biggest problem. Or how do we define or design our model to really solve the problem that we had after? Which is the customer intent and the customer map and all those different pieces of it. And like I said, while doing this, while building models, we came across a lot of data sets which we call data corpus, which we built into our platform, which could be leveraged to actually improve our algorithm in terms of how we define or derive these customer intent. So question for you guys, anybody here follow GTD? I'll tell you what GTD is if you don't know. Okay, one person. So GTD is a concept called getting things done. Very, very popular. You can go search on Google, you'll find everything about it. Okay, I personally have been following it for a long time and I believe that it brings rigor, it brings a set of commitment in terms of how you actually do things. More importantly, it will help you organize, re-prioritize and execute, okay? You can figure out whatever works for you, but the concept remains the same, getting things done, how do you do it? So I have a Trello board basically. I have to do column in progress column and done column. It's as simple as that, right? I have three things for a day, three things for a week, three things for a month, right? Every day morning I come in, I wanna see what are the three things I wanna get done today? It can be the tiniest thing or the most complex thing. Doesn't matter. I wanna get these three things done. I do the same thing every week on a Monday saying, what are the three things I wanna get done this week? So the daily accumulates to weekly, all right? Do the exact same thing for monthly. At the beginning of the month, what are the three things I wanna achieve this month? Trust me, it will help you really prioritize and organize your tasks. It's very, very difficult to get all the three done, but over time you will get a sense that it's not about completing those things, it's more about organizing and prioritizing that comes along with that, that really helps you guys. And this has been used by some of our team members internally and actually it's working so far good for them, but thought of sharing this just a personal philosophy in terms of how to getting things done. Goals and roadmap, again, I won't touch too much on this. The reason I put out there is that with the startup world, things are so quick that whatever you plan for one year makes no sense after two months and it's happened for us in the last six months. So you have to be agile in terms of figuring out what your roadmap and goals are and adapt accordingly. And you must have heard a lot of companies talking about pivoting different times, multiple times, not to take away credit from people, but pivoting really means that the first one didn't work, I'm going to the second one. And the goals and roadmaps really help people in terms of organizing what it does. But for us, mostly our core pivot is fixed from the last two years what we've been up to on our platform is working fine and some of these processes and lean product development kind of all helped us really well. And it really helps. My co-founder is actually a business guy, but he knows enough tech to be dangerous. So I have to keep him away most of the times to not make any tech decisions. But the point here is that collaboration in terms of how you plan and execute things is very important. So the number one might not be true for everybody. That's what we are doing, especially because, one, we don't like to burn somebody else's money. Two, it really puts you in a place where there is no easy way out. You have to make it succeed basically. You can think about plan A, you can think about plan B. I can think of plan B, we can say that, hey, startup doesn't work, I'm gonna go to a corporate job and get done with it. But the point here is that when you're really committed into it, you will make it work. And especially when you're bootstrapping, you will feel that pain because, yeah, anyway, you will feel that pain. Absolutely, absolutely, no undermining that. But the plus point to that is that I am running my own roadmap. I'm not running a VC's roadmap. I went into this business because, or rather startup because that's my passion. I wanna do something there. I wanna innovate, right? It's the same thing for my co-founder too, right? That's exactly what it is. The point is the moment somebody else comes in, now you have somebody else to answer to, right? See, there is no running away from taking external money, whether it's VC or angel funding, whatever it is. When you're ready to scale, and when you're at a point where you really think you can't scale without external money, even there you have multiple options. You can take loan, you can take line of credit. There are a lot of options. VC's and angel funding is not the only option. But again, it might not work for everybody. There are enough companies in India who are bootstrapped. So how you guys know? They're bootstrapped, right? They're like really good, doing really good. There are many companies like that who are bootstrapped and done well. But it's not everybody's cup of tea. So you have, and in this journey, you're on your own, right? No friends, no family. What you go through is just what you go through. People can sympathize with you, but they can't feel for you. That's basically what, we're sticking to that. We'll see how that goes. So far we are good, we are profitable. The moment we wanna scale, then we'll think through the rest of the options. Focus on customers, I don't want to reiterate this. Oh, thank you. So focus on customers, again, I've spoken enough of this. You guys know Amazon, built a multi-billion dollar company just by focusing on customers. And nobody can beat their customer service today. It's, they're doing really well out there. And it's important for every company, whether you're a startup or a corporate, for your customer is internal, external. Make sure you focus on them. And the last one is listen, learn, and test. Feedback cycle is very important, okay? Without this feedback cycle, it becomes hard to really measure and say, hey, is this working, not working? What am I doing wrong? What am I doing right? So that's very important. Again, if you guys haven't read this book, please go read this. Your whole perspective of startup and entrepreneurship changes. Pretty much these guys preach everything that I spoke about. Anyway, so I just thought I'll put it out there. And that's it, that's basically our story. Again, we are not there completely. But it's the journey that we've been through. I'll be here if you guys have any further questions. If not, thank you so much. I know it's harder after lunch, but thanks again.