Keeping Pace with Business Innovation by Oracle Dir of Product

I am Suresh Krishna Madhusu. I'm from Oracle, and a sort of vast experience that I come from, which is really like I started like most people like as an engineer. I worked with Bosch, another startup, and then when I came into U.S., I started working for a startup and then got acquired. Within 1.5 years, that was a happy ending. After that, I went to Oracle. I spent about 3.5 years again as an official product manager role and really taking care of utilities business unit expansion, the collaboration, and their software development toolkits and whatnot. And later on, I went to a startup. Within again 1.5 years, Funny enough, got acquired by Oracle, and then I came back to Oracle, and then it's been about past 6 years I've been with Oracle. And I've been building products on multiple verticals. That is really what I love about my role and job, where I get to see the problems of retail industry, construction industry, oil and gas, and the utilities and whatnot. and yet apply these, the so-called horizontal technologies like the Internet of Things, blockchain, or chatbots, what we call it as, right? And that's really where I've been spending the last 3 years tremendously looking at the drones technology, the Internet of Things, the blockchain, and chatbots. That's where I work. And then briefly, I've also been with a couple of companies as a product advisor for them. These are all the startups that are primarily into the education startup or the venture funding, and then the third one is really on the Salesforce automation side of it. And I've been a mentor for Product School for about 2 years. I have taught classes San Francisco as well as in Santa Clara out here, and there is also an organization called The Product Mentor that is based out of the East Coast, and I did teach over there as well, right? Yes. So with that as a context setting, the innovation— everybody has a definition of their own innovation, right? I mean, probably what an organization calls an innovation versus what a vice president calls innovation, what you and me call as innovation— everybody has their own sort of definitions. It might all end up in something new, something creative, but everybody has a different way. And the way we organize today is probably very briefly, I'm going to provide a little bit of business context on what happened exactly after my acquisition, and then we'll briefly go into the struggle that we had in really the changing business dynamics. And then how that evolved into the product strategy, and then how I executed, and then finally there are a lot of learnings that I want to share at the end of it. Right, so here is where it is. The startup that I used to work is called Skyer, and that actually got acquired by Oracle in 2012, around September timeframe. Right. And we were primarily into, uh, think really about— I'm sure you would have been using IT project management tools, right? You think about the Atlassian Jira or Basecamp and whatnot, but then you think about the multi-billion dollar construction projects or oil fields, refineries, mines where the cost of the project itself goes into $200 million now and anywhere up to $1 billion. So the whole idea is how do we really provide this project management software so that they can complete the projects within resources, within cost, within the budgetary constraints and whatnot. So that's really the market and the space that we were in. Clearly, like any other acquisition, we were really— we had as Thayer, these blue parts are the ones where we were really strong at, and then Oracle was really strong at the red parts. So the idea was once because of the acquisition, we were going to make it full solution-oriented approach, and then we have all the capabilities together. Like any other acquisition, acquisition. But then the funny part was you acquired, which is fine, but at the end of it you also need to think about what are the business drivers. You acquired something, so I'm sure probably if you have gone through the acquisition process, it's always like there is a due diligence that happens before the acquisition on what your products are, who are your customers, what are they talking about, how long is the revenue cycle, how is the sales cycle, and there are a bunch of things that happen. But then nobody can actually look at the complete source code that you have, right? And it's very difficult for companies in those initial days to formulate a strategy to say, okay, because of this product and the solution that we have, Should we integrate them? Should we sort of just use the IP and make as a whole solution? Those are some of the questions that we keep asking soon after the acquisition. Within 6 months of our acquisition, we realized, hey, you know what, there are a bunch of business drivers that we were really trying to answer, namely it's all about— I'm talking about 2012, right? How do we really transform the on-premise software onto the cloud SaaS business model, right? And the question is, it's not about so much of technology per se, but are our customers ready to accept the SaaS solutions? Because we don't want to be too early in the market where customers are like, oh, you know what, we like your solution, but we are not still there. versus is it the right time, right? And then clearly there is a lot of pressure on the companies to increase the margins, especially because when we talk about the cloud transformation, you have to invest in the cloud, but at the same time you can't lose track of the revenue, right? And similarly, we had the product issues where we have these multiple technologies and multiple products. So at the end of it, do we want to really maintain these older technologies and then increase the cost, or do we want to bring everything together as one single platform and one single solution, right? And so these were the some of the drivers that everybody from the executive's point of view, we were thinking and making sure that how does the business strategy drive the product strategy, and then how does the product strategy drive the product as such, right? Because the one thing to be clear is on the product strategy side, we are not really talking about which product it is, what kind of technology should we use? There is nothing like that. We are simply talking about what does it really mean to us executing the next 3-4 years and what is that product strategy problems and the solution statement look like. So one of the very important questions that we all had to answer was we have all these products within the business unit that we got acquired into, So should we build simple integrations across all these products, which seems to be the easy enough solution, right? But then the question would be, sure, we can build the simple integrations, but then from the customer point of view, if I am using all these different products, then one product has a different UI, another product has a different UI. And then your integration sometimes have to be done with the consulting folks. So that means your actual cost of implementation is going to increase. So there are multiple problems with the integrations, and the only way that you can scale up for the next 10 years, and what we very frequently call as the future-proof is building the complete technology and products all by yourself, right? And then for us, from the product point of view, the drivers really were we want to make sure that it is cloud native, especially because the enterprise customers— we serve range of customers from the utilities, retail, banking, mortgage services, and across the world. Our products go to 120 different countries at any point of time. So for us, it's really like, how do we really scale the whole cloud aspect of it? And then making sure that, especially when we talk about the enterprise solutions, it's very important to understand there is analytics that is behind it. There are group of users that are on various levels, and for the executives, it is very important to understand the business sense in much more analytics and the business sense, right? And for that, we don't want the users to again go for a different analytics solution and then integrate the analytics solution into our product So the whole idea was how do we really bring in that innovation and then say you don't have to buy any different analytics solution, but analytics is completely baked in, right? And then the social aspect is very, very important because in the crudest form somebody could say that, hey, I'm sending you an email and that is a collaboration. You can send me back an email, that is still a collaboration. But then think about the Slacks that we use probably, right? Many people are very well versed with what happens on Slack or maybe Facebook Messenger. So that is what the modern experience of social collaboration really looks like. But the problem is we understand what happens on the social side, but how do you bring it onto the context of the enterprise? Products to the extent that they are not overpowering the functionality in a way that users say, hey, you know what, you know, this is not really for me, it really looks like another Slack that is coming out there, right? And then the last and very important aspect was the mobile apps that we have. So I'm sure you would understand if you've built your technology stack probably 15-20 years ago, you would have based your technology stack on SOAP services or maybe at the best Java services. But then the same service levels are not really useful for you when you want to build your mobile apps. At the very least, you want to have the secure RESTful services at this point of time and our traditional products didn't support that model. So, and then there is a lot of push from the sales and pull from the customers where everybody's asking for, I absolutely need to have the mobile solutions, otherwise it's not going to work for me, right? But of course, it's very easy for the customers to say I want mobile solutions, but then when we ask them, okay, can you please tell us what are the use cases? That is when customers go back, yeah, yeah, the use case, they will tell something very abstract which you can't really translate that as a feature. Makes sense, right? So once we looked at all these business drivers, in a way we basically said it makes sense to build a completely new cloud-based platform, and that is what we basically called as project success platform. So it took about almost 1.5 years for us to integrate, analyze, and then come back, go back to the management saying that, okay, this is what we want to do, which is to build a completely new platform. As you can see, it has probably about 11 different modules on the top of the platform. So think of the platform as the cloud infrastructure, the social infrastructure that you have. It's all about the administrations, it's all about the analytics that are baked in, the mobile access points that are there, and these modules would simply sit on the top of this platform. So at that point of time, You simply have the services and the UI, the business logic and everything. Right. So as we did that, some of the questions that we had to critically think was, when you build a platform as big as what we built, the question always becomes, Do you want to first take one module and then go in depth in building out the complete feature set, or do you want to build multiple features on a shallow level? Because that really defines who your users are and then how they are going to use it, right? If you are especially very new to the market, going on the broader level and then shallow features makes sense. But unfortunately for us, there was too much of competition, and even worse, we had a successful product that's already there in our business unit. So the moment you release anything with a shallow depth of functionality, users used to come back very quickly and say, hey, you know what, Your other product had much more depth, why can't you make it the same way? We figured out very early in the cycle where this is the kind of comparison that they have for the right reasons. So what we really focused was building in-depth of the functionality and making sure that that functionality solves a particular problem for the user before we go on and add multiple feature sets. And it could be in the terminology, but then the moment it becomes very legal-ish, the moment you say it is MVP versus POC— a proof of concept is something that you can say that, oh, you know what, I'm just doing a proof of concept, and then people are okay for you to do it undercover. The moment you say I'm doing an MVP, then everybody is like, okay, fine, what does it mean? How can sales use it? How can marketing make sure to bring in the awareness? And then the documentation is there to write about the feature set. So it really depends on— even though you might be doing the POCs, sometimes you want to dub it as MVP. But then you need to really understand what you are doing, right? If there is a particular feature that you want to just show to your customers, that is it the right feature that you are looking at, and then that really has no revenue potential at that point of time, you might as well better be called as a POC rather than MVP, even though MVP sounds cool, but the downstream effects of calling something as MVP is too big for you to consider. The exclusive communication and exclusive buy-in are one of the very important aspects for us that I personally learned where For them, it is all about how can I increase my sales. That is the very important aspect of it. Even though they want to understand at the product level, but their day-to-day job is how can I increase sales, right? You think about your general manager, you think about your VP sales, your VP marketing, whoever they are. For them, it is all about how can I increase my reach? How can I increase my revenue potential? So for them, it is very important for you to make sure the expectations are set right from the beginning, which is, I am building this product, but this product is not going to come out in the market for the next 1.5 years. However, every 3 months we can have checkpoints. You can review what's happening in the product. you can give the feedback, but the only way we are trying to bring it to a GA level is whatever timeline that you think is the right thing. So the reason why it is important to communicate that to your executive management is they are the ones who is funding your project. The moment there is a slight rundown on the revenue potential for them in one of the quarter, the easiest cut that they can make is your project or the product that you are trying to build. Right. So, and especially because in a startup scenario it is clearly different, right? Because you have only one product that you are building. Either you source the revenue to the product or not. There is no real question over there. But then in an enterprise mid-level segment companies where there are multiple products that you need to source your revenue or the cost, that is when the prioritization comes, and that is exactly the reason why you have been upfront with the management on what those expectations are, when you will bring out the products, and what is the timeline. This one for us, just as to the scale, each one of these bubbles, there are multiple smaller companies in the market, right? So when you think about this cost management or contract management, there are a bunch of cloud companies, startups, medium and multi-billion dollar companies, right? Just on the contract management. So the whole idea for us was, of course, we're not going to displace them, we're not going to sort of kick them out of the market, but by building each one of them, you see what is the net revenue that you could gain, right? And then at that point of time, there was no single product in the market that was integrated enough to bring in all these capabilities. Every company provided, for example, there was a company or multiple companies that provided budgeting and forecasting solution. There were other companies that provided the contract management solutions, but for us, the winning strategy was the whole platform as one single solution. So that they don't have to go out and then try for integration. They don't have to learn how to integrate one product to another product, right? Everything in one. So for us, that was the trigger point to say each and every module has a certain potential of the revenue. And then when you combine at the end of the development on what you could get, so that is when you project some revenues as a percentage of each module, and then that becomes your forecasting for the products. And of course, that's in a way bottom-up, right? You are adding up all these smaller segments and then saying that, oh, you know what, at the end of 3 years, maybe it could lead to $10 million revenue to start with. But at the same time, sales will also have their own projections as to say, okay, you know what, I see there is a huge potential in Africa because especially in Africa there is a huge infrastructure building, buildings that are happening. The government is spending a lot of money on the highway infrastructure. So that would actually give me about $300 million potential per year. So even if you take about 10% of that overall revenue There is some value to it, right? So there is no absolute value that you can put on these forecasting, but it's really about what do you think from the product perspective, and then what does the sales think about the product perspective from their sales perspective, and then you somewhere meet in between and then say that is really the revenue potential that you have. And that revenue potential is by the module or by the overall product? product line? By the overall product line. Because I'll talk more on the bundling strategy, right, when you think about it. Because for us, if you keep thinking about individual module, then you have to price what the other competitors are pricing. And then for that, it might be like $10,000 per user per month. Which you don't want to go there, right? So it's all about bundling, it's all about— because now that you are one single platform, you gain the scale, right? For a typical customer, for a typical competitor, for somebody to build budgeting and forecasting solution, they have to have their platform to be built from scratch. But for us, once you build this platform, The rest of the modules can just take the advantage of this platform, and then you can cut that overall development cost almost by 40-50%. So that's really the channel that we went through. Basically modular solution and product depth which you can leverage across the board. Correct. And this is a funny thing to say we all provide products. There are so many products that we sell, but at the end of it, it's very difficult to answer the question of, is the customer really buying your product or a solution, right? Because your customer is trying to solve a problem for himself. He is trying to improve his project management efficiency because today there is a lot of manual work. He is looking for some automation solutions, right? So for that, they are buying your product. So the question really becomes, when you say we are building products, just giving a product is fine, but then did you look into the overall ecosystem on what they are trying to do exactly? A simple example would be we give the project management solutions or the products for our customers. They would take them and then think about the drones are very famous these days, the last 4 or 5 years, and when they do the aerial surveys of the construction sites, that video imagery, everything comes into your project management solution. Right, the product. So the question really became, okay, if there are more and more customers who are really trying to integrate the drone imagery into the platform, the product, then why don't we actually provide the integrated solution to them so that they don't have to integrate, build the APIs again, bring in a consulting firm to do these integrations. So that was really the idea to say providing product is fine, but if there is a bigger need, you can also provide solutions on the top of it, right? So that's really where we moved from the product category to solution category at the end of 4 years, of course. I mean, the day one we were still products. But at the end of the mature level of the multiple product releases, we went from the product to solution level. The innovation is a very important aspect that we have to keep thinking about because the moment you say, okay, I am going to innovate, to your point, is it going to be incremental? Incremental innovation is fine, but incremental innovation may not always bring you the extra revenue that you're looking for, right? So in that sense, you want something fundamentally different, fundamentally new, which provides you value. And now think about it as, what about machine learning that you can provide into your project management solution so that once a project is done, typically the project is closed and then It's put in the back shelf, right? But then if you can apply your AI techniques and then if you can cluster these projects that are already done by saying, hey, you know what, there are these set of projects that you have done as a contractor, and the moment you see these 2 subcontractors, the projects always got delayed. Right, or in this particular region of US, the projects always went over budget, right? So those are the some of the things that never happened before, but now you are really looking at, okay, with the help of the ML techniques, how do I really bring in those value to the customer, right? So that's really where One is, okay, we have this nice idea, but then do we want to build ourselves? Do we want to buy? That is one aspect. And then can we really commercialize the innovation? And that's another big challenge that we had to solve. But anyway, end of 2015 is when we released the Oracle Primavera Cloud. It is completely our solution, cloud-based, mobile-centric, social-centric, and this has been in the market for almost 3 years for now, and we have hundreds of customers working on this platform, right? Very quickly, I will go through our mobile journey so that you have an idea on what it really means by the whole journey as such. When we initially started the mobile apps, in a way, everybody said, you know what, mobile apps are very important for us, but we are not going to pay for it. We expect that to be part of your product, right? In a so-called as, yeah, it's nice to have in your contracts, you always— there is a checkbox, you have to say that, yeah, we support the mobile apps, but then over a period of 3 years, we moved that from the nice-to-have to must-have. What this really means is, one, customers now look at the value of having the mobile apps, right? A simple example could be, I actually went to a customer in San Francisco, just walked around with them from morning to evening. So these are the people like the general contractors. With the hard hats, they are the superintendents. Every day morning they would take a big iPad, right, or even worse, in some places they would take a camera and then there is a notes. They would go around from morning to evening the whole of the site, construction site. They would take pictures, they would write notes, and then at the end of it, you might have observed the trailers that are sitting in front of the construction sites. Those are the places where the computers are there, that is the technology space for them. So they would go into the trailers, they would enter the notes into some project management solution, and then they would upload all these pictures that they have taken into the, again, the management solution. The question really became, when we came back, I went with my team, we came back, We said, okay, what does it really mean, right? They're having this problem that they're going everywhere, they're collecting these pictures, but they don't know exactly where they collected, which notes belongs to which picture, right? Because there is no correlation between the notes that you have and the pictures that you took. So the first step that we took was a mobile app that basically where you can take a picture, you can mark it up, and then you can put in the notes, or you can talk, and then that is saved as an audio file, right? As simple as it looks, as easy as it looks, for that particular industry, for that particular user, that's a 10x improvement in the productivity because now you are not spending the half an hour time in the trailer really looking for the pictures and writing the notes, but it's really all about, okay, how do we improve their productivity? So those are some of the things that we looked at. And just for you to look at, we started with very simple HTML, very rudimentary, and then we said, you know what, why don't we really apply some stylesheets? But this didn't really cut the quality for the customers. And then we said, yeah, sure, let's do the native apps. And native apps were highly used, but still you could really see some of the design really looked like a web application design, right? Because you think about it, for the whole organization to really move from whatever traditional application to the mobile application design and thinking, it took almost 3 years for us to completely move the organization, right? So it is about the designers, it is about the engineers, it is about the engineering managers, it is about the documentation folks, it is about the salespeople, because the innovation in the apps comes only when everybody is working towards one goal that, oh, you know what, we want to build the best mobile apps. Then this is a very close representation of what we have today where you can really see it is purpose-built. There is an area for each and everything that you can do. You can look at the tasks, you can create issues on the site, and then we use the complete notification mechanism on the iPhones. and make sure that the iPad Pros and everything is supported. So that's really where our journey went from static HTML mobile app to all the way where you have finished purpose-built mobile apps that are used by hundreds and thousands of users. Right. So with that journey, here is where very quickly I will cover what we went through and what I learned as a process of 5 years in a way. Do you have like a framework to uncover the pain point for the customer, like a set of questions, or how did you find, like, when— I mean, I really like the idea. Yeah, you can take a picture and record and everything. Yeah, so I mean, there are multiple things, right? I mean, there is this design thinking methodology in a way, and then there is also an argument as to say don't look for the great ideas but look for the problems. Because when you look for the great ideas, you are so obsessed with the optimization of the idea that you actually forget what the real problem is. So that's really where I think what industry keeps talking about, that user empathy. That's really where I see if somebody can develop that user empathy as to say, I'm seeing users behave in a certain way, but how can I really help them improve their daily tasks, daily efficiencies, right? And then sometimes those simple tweaks that you do probably gives them a 10x increase in efficiency. So Especially when we started the whole journey, it was very easy for us to look at one small module, one small feature set, and then say, oh, you know what, this is what I want to do. But then what we really have to look at is define a vision for where you want to go, even if the product or the feature or the module becomes a failure. But make sure you have a vision of where this product should land in the next 1 year, 2 years of time, right? And once you have the vision, that is when you formulate your strategy as to say, okay, what does it really mean? What is the roadmap for us? What kind of technologies and what kind of product problems that we are trying to solve? And then go through that whole exercise of— the road mapping and then formulating the product strategy. And a very important aspect is focus on the customer, innovate, and make sure that you wait for the results, right? Because it's very easy to think about what is the ROI for this particular feature set. Sometimes that ROI doesn't come in 3 months, 6 months, but it's really the question of how do you educate your industry, how do you educate your customers. Sometimes you could be too early in the lifecycle, which is okay, you have the first mover advantage, but make sure that you educate your customers on what the technology is, how to use it, so that at some point of time what they call as the snowball effect— one customer takes it, 2 customers takes it, And then the more and more you evangelize and then make sure that you are referencing the customers, and then that particular feature set or that particular product just gets more and more revenues. Very important aspect to say, again going back to our original innovation theme, you can work in one product, you can improve small features again and again, and then we can still think that, oh, you know what, great, I'm innovating, so nice, I'm releasing the product year after the year, month after the month, so I'm great, I'm innovating. Versus, yeah, sure, maybe you are innovating in that product line, but then there is also an aspect of, okay, can't we build new products adjacent to my own product, right? You think about the whole aspect of Windows PowerPoint. You have the Word. Initially it was only the PowerPoint, and then Word came in, right? That is where you are really looking at adjacent innovation, where in a collaboration space you were trying to provide as many tools as possible. And now you think about disruptive transformation innovation where Cortana, for example, in the recent Microsoft Innovate conference, they did a great demo of— we're all sitting in the nice conference room, there is Cortana that is there, and then we all finish our talk, whatever we have to talk for the next half an hour. Cortana basically records everything that we talk. It makes meeting minutes, it creates the action items, and then sends it to the right people. Right, so now you think about, okay, yeah, sure, I mean, I have the same Word, I have the same PowerPoint presentation, but then on the top of it you increase a— you put in the technology like the AI Cortana. And then that gives you a totally different experience on what these two can give on their own. Very famously called as the hype cycle, right? What we often forget is we have these Internet of Things, the whole aspect of the blockchain, for example. It's very easy to— of course, when you are here, it is very difficult to see whether it is going up or it is going down. All these hype cycles are very easy to look from the backward perspective, but the idea that we are talking about is it doesn't really matter if you are here or here, as long as you are learning from those hype cycles, those technologies, and trying to solve the user's problems. you're always in a good shape, right? So for us, blockchain was at some point of time was the biggest thing that everybody was talking about, especially the Ethereum cycle. Another question is, okay, should I invest in prototyping something on Ethereum and make sure that blockchain as a technology is used in our solutions, or do you wait for somebody else to do it? By the time that somebody else got their feet wet, they got their experience, what if this technology really takes off? Then you are basically left behind, right? So that is really where, especially this cycle is what they call as the hype cycle, and this is the reality, but it's very difficult for anybody to really look at when they are executing whether you are on the hype cycle or the reality, right? But as long as you are learning from your experiences, it doesn't really matter what the hype cycle is. The reason why this is important for me was each and every conference that you would go to, people will say, oh, you know what, blockchain is the completely new thing. I mean, you should really have it. And then the question really becomes, okay, Blockchain is the new thing, we should integrate into the products. What does the investment look like, right? And what does the messaging look like? So it's not just about using a particular technology, but then especially for the products, you have to really look at what do outside people talk about it, what do customers think about it, is there real value for the customer at the end of the day? This is my most favorite part of the innovation, and especially the gluten-free toilet paper and the remote control, right? That is the reality that happens in organizations where, you know what, why don't we really add in more features? More features, few more, and then at the end of it, it just becomes so bulky that either you can't explain to the customer what feature sets you have, or it becomes too dense that the user is not just able to comprehend what buttons, what menus, where they have to complete their business process and whatnot, right? And it's really like Maslow hierarchy, and I really love this particular hierarchy because based on where and how you look at the products, it's very easy to say, oh, you know what, if you have the great sexy user experience, your product will sell. But the question that we need to really ask is, who are we selling? What is the user's problem, and does our product solve that problem in the most efficient way? Right, so that's really where we need to look at the functional features first. Are we trying to solve their problem or not? Right, it doesn't really matter how many emotional features that you put in without these functional features. A nice example is I'm sure you would have heard about the gamification concept, right? It's really about, let's say you are a great colleague who answered 10 different questions by your other colleagues, and now you will get these coins, gold coins, and then you will be on the leaderboard, and then everybody recognizes you. Oh, you know what, Suresh is a leader in answering the other question. So the whole idea of the gamification is how do we really bring in these gamification concepts into the enterprise applications, right? And there were many products, many solutions where without really looking at, yeah, functional, that is fine, but, you know, I want to put in that gamification feature so that they can come in again and again. But the problem is users come to your product again and again only if they have a particular business need, they won't come to your product just because you have gamification aspect of it. And the last one is, of course, a great example is when we think about Facebook, when they initially launched, it is plain website, you go register, you do whatever you have to do, connect with the people, chat and whatnot. And then now look at after 15 years of life cycle, there is such a huge ecosystem of ads, the content developers, and then the sellers, the buyers, everyone. And now they have moved from all the stages, and then right now they are in a big ecosystem where they are literally helping multiple vendors buy and sell, exchange information, and exchange communication on their platform, right? And clearly they never tried to build this ecosystem right that they want, right? So it's very important for us to understand when we're building the products, make sure that it is functionally solid and it solves a particular problem. And there is this concept of— how many probably of you heard about the Betamax? No? So Betamax was supposed to be the stronger of video technologies before, and VHS was the one who won the market. Cool. Probably if you don't remember, it's fine, but VHS and Betamax were the 2 prominent video technologies that were there. And arguably, by technologies, Betamax has the superior technology, but VHS won the market. There is a lot of sales push, there is a lot of marketing push behind it, and then they just made it easy for the vendors and the ecosystem providers to adopt the technology. Right, and how many of you use Zoom? Wonderful. So you can really think about— it's not— Zoom is not the first one to be there on the video conferencing system, but why aren't people using the Google Hangouts even though it is free, right? You can think about why is Skype not being used as much as Zoom. So the reasons come out arguably saying that even if you have slightly better product with better experience, based on where you start and how you project your product, some products win the market. So there is this very hard argument amongst the product community that the best products always win, but that's not true. There is something called as the stack fallacy, and that is actually— the name itself is actually brought in by one of the Salesforce vice presidents, and that basically talks about it's very easy to think that, okay, once I have the infrastructure layer, once I have the PaaS layer, platform as a service, it is very easy to build build the SaaS layer, which is your applications. But the idea is just because somebody knows infrastructure well, for example, the likes of, to some part, the VMwares or whatnot, they are very strong in the infrastructure, but it's not very easy for them to make the business applications like the ERP software, CRM software, or CX software. Right. So the way this concept is useful is just because I'm really good at making application software doesn't necessarily mean that I will be able to make platform, like IoT platform, like your blockchain platform. And the same thing is true, which is I may be really good at making the IoT platform, for example, the Intels of the world, they really have a lot of IoT platform per se, but it's very difficult for them to make the application software because application software is full of business rules. You need to have a different mindset to really write the application software versus the PaaS layer. Very useful when you're really thinking about prototyping a concept. Prototyping a particular completely new feature. All that they talk about is the day one, you bring in, you define the problem, you define the users, you really think about the market space, user space, and the problem space. And then the second day, you come back and then you talk about multiple solutions to solve this problem. And then on the 3rd day, you decide which one is the best solution amongst those multiple things that we talked about. And then day 4 is when you prototype. It could be paper-based or very simple JavaScript-based prototype, whatever it is. And then day 5 is when you actually present it to your management and customer. As much drastic as it sounds, of course, I mean, honestly, I haven't— we haven't really done this way of rapid prototyping in 5 days, but it's very interesting to understand the 5 stages where you are really looking at in a shorter period of time, you're really coming back, defining the market problem to all the way going to the customer and then giving them a presentation, that really changes your whole idea of, oh, you know what, I need 3 months of time with 10 people. Maybe you don't. You probably need just 1 engineer and then 1 business guy and then 1 product manager, and then you can probably in a couple of weeks of time, you can really see if a particular idea is worth examining or not. And then especially when we're building new products, one thing I absolutely realized is it's very difficult to bring everybody on the same boat, right? Think about engineering team has their own way of thought process, their own way of thinking. And then marketing has their own way of saying what is the best for the market. And then salespeople are absolutely in the field, they are looking at the customer in a different way. And now when we are bringing all these and then saying, hey, you know what, I am going to do something really cool with the IoT, why should they believe you? So instead of saying that, oh, you should believe me because I am a product manager, No, nobody's going to believe you. But the idea is, how do you go talk to your engineering team, convince them that, hey, you know what, there are multiple IoT products that are out there, there are startups that are doing a bunch of innovation, why don't we sort of look at it? And then you go to marketing people, you talk about the benefits of such a technology to the end users. How you can really amplify that with the marketing. And then you go to the sales, you talk to them, you sit with them, maybe you go with the sales for a couple of customer flights and then see what customers are really getting into. And then as a matter of what we call as the water cooler conversations, you try to influence them in a way that they may not be totally board with you. It's not needed that they are completely on board with you, but at least they understand that, oh, you know what, this product manager has a great idea, let's give a chance and see what happens. That is the trust we need to build with the rest of the organization. I know, really talking about Of course, you don't want your projects to be killed early on, so there are some criteria that you need to keep in mind as to say, okay, what does it really mean by keeping lights on? That's really what it is, right? So make sure that there is evidence for you from your customers, from the market, And then many people talk about the data-based product management, but at the same time, don't get carried away that it's not necessarily quantitative data that people are talking about, but it is also qualitative data. As long as you are able to mix and match the qualitative and quantitative data to your management and the customers, you should be okay there. The third one is a very, very important aspect, especially what I realized is when you are building products, it is very important to say, I want to build this product, I want to give to the customer, customer starts using it, and then that's really when I start realizing the revenues. And then one product leads to another, and then there is a future value that I see from this product versus sometimes we see that the current state of the product is as though unless I have services or consulting on the top of the product that I have, it provides no value. Even if it has services, maybe in the next couple of years we are going to completely revamp our product. So in that case, we are giving a bad message to the market. So that is when you need to really think about whatever product that I'm building, does it work in the long run? Can customers adopt it without any problems? Can sales sell it without any problems? Can— is it serviceable, right? If you really make a hot hodgepodge solution because you just want to release it very quickly to the market, then you can release it to the market, but then when customers come back with issues and problems, maybe instead of getting all these things fixed in 1 week, we might take 1 month because the backend or the backend processes are not that strong. So this is a funny story that I realized a few years back. So the PowerPoint that we know as of today is not really Microsoft, but it is from a company called, uh, For Thought, and it was actually very famous with the Mac users, not the Windows users, as you would expect. But of all the story, the very interesting one was one of the reasons many people claim the success of the PowerPoint was really about when Microsoft started really bundling the whole Microsoft Office suite. Yeah. Had they kept the PowerPoint to be an independent product, then of course it would have been a different story altogether, right? So the idea that we're talking about is, to your question on whether should we price individual modules separately or should you take it as one complete platform, that's really where the bundling strategy really helps you to increase that optionality. The same thing can be argued with the Internet Explorer. If they had not bundled the Internet Explorer with the operating system, then you always have a choice. Instead of Internet Explorer, you would have downloaded something else. Just because IE is there, there is a natural tendency for the people to say, oh yeah, okay, I have a browser, why not just use it? And then the last ones are to really about— there is a lot of credit that I want to give to these Amazon press releases. What they typically say and do is make sure that before even you start a product, they want to make sure that there is a product release that they write about that product, and that is vetted by the CEO and the VP of the product, whoever that is, to make sure that that is the expected outcome in the market. For example, the best thing is working backwards is something that we need to think about. Okay, if I'm building this product, what does it really mean for my market, and how does that the first release looked like. And as you can really see, as per Andy Jassy, he says he went through 31 iterations of the press release before he showed it to the CEO. So that's really where the— one of the important points that I realized is it's not easy to actually work backwards and then write a press release before before you actually develop a product because now you are really thinking about who are those users exactly, what are the problems that I'm trying to solve, and what is the expected outcome. For you to really think it almost 1 year ahead is a big deal. But I mean, there is a lot of success that you can probably associate to Amazon's products just based on those working backwards Actually, I just have to say that it is a must for every product manager to write the press release for every product. That is what at least I think the literature says for the Amazon products, because it really forces you to think about how do you want to project your product to the press. Right, and indirectly you are really answering the questions of what is your market, who are your users, what are your outcomes, and then what do you feel proud of your product. So this press release is in the anticipation of product launch, right? Correct, yes. So this one is actually a real product launch press release that Andy Jassy did for the AWS. So, yeah, so that's really what I had for today.