We sat down for a Q&A on the art of product management with Hareesh Nagarajan, product manager at Google. Hareesh has made key contributions to multiple product lines at Google, which include AdWords, Google Fiber and most recently Mobile Search Ads.
We learnt from Hareesh about what PMs do, how they can be highly effective in their role and what he looks for in hiring PMs.
Watch the interview
Read the transcript of the interview
Transcript has been edited for clarity.
SUNIL KOWLGI: Hi everyone, I’m Sunil Kowlgi, CEO of Outklip. Today I’ll be speaking with Hareesh Nagarajan, Product Manager at Google. He’s been with Google for more than 10 years, and he’s been a product manager for the last 7. He’s worked on many product lines including Gmail, Google Fiber and most recently Mobile Search Ads. Hareesh, thank you for doing this interview.
HAREESH NAGARAJAN: Thanks, Sunil, it’s great to be here.
What do product managers do?
KOWLGI: I have a basic question to start off this interview. Product management is something we’re never taught about in school. You go to college and you’re taught software engineering and among other things you’ll have software project management, but not so much product management. However, it’s a very core role in tech companies and I think it was pioneered by bay area startups. Can you tell us, what does a product manager do?
What a product manager does is for any kind of mature product or a product that already exists, is really look at what the business goals are and then come up with product changes to achieve some of those business goals
NAGARAJAN: Yes I think historically when you think about this particular role, it’s been around for as long as a software has been built. I think the PM role has been around from the sixties. I think it got popular in the nineties. If you read Ben Horowitz’ essays on management. I think then product management was a bit different. You built software, you had a hypothesis, you tested it, you shipped it out, and then you send it out to your clients and customers. You got the feedback only maybe 6 months from now on how the product was being used. The big difference between product management then and now is we get feedback constantly. You have services which are running online, so you can look at the data, you can see what’s working what’s not working, immediately. So, in a nutshell what a product manager does is for any kind of mature product or a product that already exists, is really look at what the business goals are and then come up with product changes to achieve some of those business goals. Now of course this is not the general answer for every product management role. I think for smaller start ups, for smaller companies, sometimes the CEO or the founder is the product manager, because they have a greater understanding of where the product should go, who the product works for and who the users are. And then, they really are the nucleus, they understand what product management is really for that particular product. But over time when you have products that have been around for a while, that have gotten users then it’s a lot of Bob, hey what is this new feature that we can put out, what is this new business objective that we can achieve. At that point the more conventional PMs can come in and really take the product in the right direction. Because you have to constantly evolve and I think PMs are the one group of people within these organizations that help a product evolve.
Where do product ideas come from?
KOWLGI: You mentioned the PM’s job in some of the more established companies is coming up with new features and new products. I read a recent press release for one of the products that you shipped, which is for mobile search ads. So, can you tell us how you conceive new products and features as a PM. Where do those ideas come from?
It really comes down to your synthesis of the qualitative and quantitative aspects and then building a story, constructing a story, evangelizing that story with engineers and then get the ball rolling to actually build that
NAGARAJAN: On mobile search ads and on Google ads, there are such a phenomenal number of features, a phenomenal number of products. So, I worked on one small product within the whole Adwords product suite so I won’t specifically talk about that but I can talk about how ideas are conceived. Usually you know when we learn in software engineering school, at least the way I learnt it in the early 2000s, it was about gathering requirements. The thing is out in the field requirements aren’t just hanging out on the floor for you to walk and pick them up and you gather them. It’s not that easy. If only it were that easy. In many cases, even if you ask users what they want, they won’t be able to tell you what they actually want. So you need to synthesize what it is that is needed. It could be any particular metric that you’re optimizing for or you want to see improved. It could be, do you want to increase session time, do you want to get users to spend more time on the product, you can be working on a recommendation algorithm. Do you want people to actually spend less time, because you want them to finish whatever task they had planned and get on their way. If you are adding a product to an Amazon shopping cart you don’t want that to take forever. You want them to add it, check out and be done and you want to optimize for conversions. So I think it really depends on what particular feature, what the business goal is you want to achieve. In most cases you’re not starting from a blank slate, you’re starting from a slate that is already in progress, a product line that already exists, features that already exist, and you’re figuring out what is broken. And you have a few tools in your arsenal: you can either do quantitative analysis, you look at data and you see what is what is working or what’s not working. Or you can do something qualitative. You can get user research, you know ask some questions to users, you could put out surveys, you can physically go and talk to customers. So, I think you can do a blended approach of these things but nobody’s going to tell you what to build. I think that really comes down to your synthesis of the qualitative and quantitative aspects and then building a story, constructing a story, evangelizing that story with engineers and then get the ball rolling to actually build that, whatever that something is that you want to build. You get that out, you test that out and you repeat that process all over again. So, I think a lot of it is just continuous development, continuous iteration and having a tight feedback loop is super important in product management.
KOWLGI: Let’s say you’ve come up with the requirements for a new product and you put forward a proposal and it gets accepted by the team. What then are your next tasks, what do you create in order to enable engineers and other stakeholders to proceed with the development of the feature. What are your deliverables and that sort of thing?
NAGARAJAN: Yes, it starts with, once again, a goal. For example, I usually think of these things as two types of goals. One, the business has given you the goal, like hey PM, reduce the churn rate on a particular product. You could be a PM on Spotify and you could be responsible for making sure that people don’t churn as much. Churn would mean they’re canceling the subscription. So what are the levers that you have — you can change pricing, you can say I’ll give you the product free for the next 3 months. And then that might not fly with the revenue team. They might say, sorry you can’t use that lever. So then you could try and figure out other ways of potentially doing this. You could potentially have speed-bumps in place. You can tell this user that hey there are these other features you haven’t really used. Or you can tell them you’ve actually stored so much information here, maybe you don’t want to cancel. Maybe you forget that you’ve actually derived a lot of value from this. But of course if users still want to go ahead and cancel they will still cancel. Anyway, the point of it is if you have a business goal and that business goal is well established, then you can device any number of features for achieving that business goal. Then you would write down a spec, you would evangelize it with your immediate team, with your engineering team, you sort of communicate this to your leadership and tell them this is on. You communicate timelines, you will work with the UX team to build some kind of user flows and then you get cracking. You could you then estimate it closely with your engineering counterpart, this will take 6 months or this will take 2 months or whatever. Then you get this up and then you see. Did it actually change the metrics. You run some A/B experiments along the way and you’re like oh you know what I actually reduced cancellation rate in my cohort of users who saw a particular change by 5 percent. If 100 people were canceling on the control on your experiment and you only got 95 cancellations, so you did better. You can probably say that this is because of your change. Again that’s an A/B experiment and you wanna make sure that you constructed the experiment properly. So that’s one way: there’s a clear business goal, you achieved it and done. The other way is more bottom up. Nobody has told you that hey you need to make this change. You propose this thing organically. And then you start evangelizing the people and say you know what if you did this you could move this, the pain points today, people bounce out they don’t realize that they can actually do this thing but then if you add this particular feature, they will do this thing and doing this thing is good for the business, it’s good for the product and then you sort of bubble it up. So both are similar, I think in each of them it’s how do you go about selling the idea. In the first case it’s simple, the business has bought into it. In the second case, the business doesn’t even know there is a particular problem, you have estimated this to be a problem and so you have to do the job communicating, you have to do the job cheerleading, you have to do the job of shepherding. We often like to call this is how the sausage gets made and sometimes making the sausage is messy. I think building software is inherently messy but it starts from these things, either top down or bottom up.
KOWLGI: In the bottom up case how do you personally go about gathering requirements and data? Who do you speak with and and figure out new ideas for how to change the product?
As a PM, on most products, you have to be focused on engagement, whatever engagement means to you
NAGARAJAN: As a PM, on most products, you have to be focused on engagement, whatever engagement means to you. If you’re a PM on YouTube, a simple way of looking at engagement is are people spending more time on YouTube, as viewers. But if you’re the PM on the team that works towards artists, then engagement time could mean something totally different. You don’t care about engagement time as much but are they having a good experience, is their video showing up to enough number of users. So you need to see what metric matters to you and in many cases engagement because for products you have to engage with the product. You look at engagement you see that something is broken. In some cases hey you know what people are not seeing performance with this thing, people are not adopting this thing, people are trying this once but not trying it again, people are spending X amount with this thing but are not going beyond Y. I think back in the early days of Facebook they would say you need to get 10 friends on Facebook. If you get 10 friends on Facebook you’d be an engaged user. But if you were at 4 you would churn, if you were at 8 you would churn. So your goal was very clear. How do I get this user signing up to get 10 friends in there. So I think you would need to figure out what that north star is or what that metric is. And then relentlessly come up with some way of doing measurements to see if that metric that you’re working on has actually moved in the direction that you wanted to. So I think it’s a bit of about your own intuition, your own understanding, your own people, you need to talk to your customers. And then come up with the story, a narrative that if I did X and Y maybe you know Z will improve, and Z is what we ultimately want. And then do the same thing, talk upstream and then shepherd it toward launch. And then cheerlead it too. As PMs we sometimes forget that we are the cheerleaders for some things that we’re driving.
Gauging impact of product changes
KOWLGI: You mentioned running different kinds of experiments to validate your hypothesis. It’s an aspect of testing, you keep testing whether the feature you spec’d is actually moving the metrics in the right direction. Can you tell us about A/B experiments and any other kinds of experiments that you run?
NAGARAJAN: Yes an A/B experiment is a pretty simple concept to understand. Let’s say you have a form on a page for name, email and phone number. A possible experiment could be if we gave people 3 fields only 30% are filling out the forms. What if we did away with the phone number field, maybe we could bump up our conversion rate. An A/B experiment could be let’s send 50% of the users the name, email and phone number and the other 50% just the name and email. And then see what business objective we want to achieve. The goal is still the same, we want to seek conversions. We might then see that conversions didn’t change at all, in which case the experiment didn’t change anything. Or maybe the experiment bumped the conversion rate from an absolute 30 percent to 40 percent and it was statistically significant numbers. In many cases get a statistically significant numbers is very difficult because most of us don’t have the large scale of Google or Facebook, which can run experiments with millions and millions of users. But I think more or less we should have a sense of whether directionally the experiment make sense. So A/B experiments are maybe one way to do it. But the downside of the experiments is you can’t get a step change in improvement. It’s very difficult through an A/B experiment to get a 2x improvement. The key with A/B experiments is you don’t want to change too many things, you only want to change one thing. There are a lot of systems that let you do A/B experimentation, but I think you should really find one that you’re comfortable with that suits you. At Google there is very complex and sophisticated system that we use so we don’t often have to deal with the building such a framework. But, for people out there A/B experiments can come later. The big thing to focus on would be what does your intuition tell you, what does your data tell you and iterate on that. That’s a lot better than doing these A/B experiments, which help you at scale and they are what we often call low hanging fruit. Now in this particular experiment we saw more conversions, but are the leads the same quality? Did we lose quality along the way? So that’s when you start piecing the story. Yeah we got more leads but maybe when they didn’t give the phone number we saw more rubbish emails. It’s a tradeoff. That’s why you need to look at it end to end as a whole story. These quick wins come only when you grasp and understand the system.
How to price product
KOWLGI: Another aspect of a building new product and features is how to price it. So what are some of the important things to know about pricing products?
If I had to come up with the pricing by myself I would really look at the large body of SAAS software out there and then use them as an anchor towards pricing
NAGARAJAN: I think that’s a very good question. I think there’s definitely a behavioral aspect to this. I actually do not have that much experience in pricing. Internally on some products that really worked on. I’ve made use of pricing teams that have done some sophisticated pricing analysis. If I had to come up with the pricing by myself I would really look at the large body of SAAS software out there and then use them as an anchor towards pricing. It really depends on the market you’re in. SAAS software there’s a certain expectation that you price it a certain way. Enterprise software are priced totally differently. You could find an enterprise sales for a company, which is in the tens of thousands and hundreds of thousands of dollars. But if you are like a turnkey API company there is very clear pricing that you could end up doing. Let’s say you’re Sendgrid, you’re doing emails, or Twilio and you’re generating SMS numbers, I think in those that kind of pricing is very clear cut how it’s done. So you should step on the body of work of others in the community and what they’ve done. Pricing I don’t really have a good answer for you but I think it is a key aspect of how do you go about pricing software.
Product roadmap
KOWLGI: As a PM what’s your typical time horizon. Are you looking at projects 6 months out, 1 year out, etc. Product managers are in charge of the product road map. How far out do you actually see and plan ahead for?
Usually [product] strategy is I would say maybe 1 to 3 years out. It is constantly evolving but not frequently. Roadmap is more of a living doc that is constantly evolving but with the roadmap you’re looking usually a year out.
NAGARAJAN: Usually with any product you typically have a strategy document, where is this product headed. Either it could come from your leadership and you translate that into what it means to your particular team or some niche you’re working on. The strategy doesn’t change that often. I mean you might add a few things here and there but you don’t want to change it at all. It might be we need to grow revenue, we need to be in different markets we need to execute better in terms of US sales, we need to increase the revenue per user. You might have a broad set of strategies of what you want to do. The roadmap is really the tactics. The roadmap is this is how this dovetails with the strategy. Usually strategy is I would say maybe 1 to 3 years out. It is constantly evolving but not frequently. Roadmap is more of a living doc that is constantly evolving but with the roadmap you’re looking usually a year out. Again you have the greatest visibility into the quarter and the quarter after that. And then of course each of these items in your roadmap will eventually need PRDs (Product Requirements Document), UX reviews, engineering design reviews and all of that. Roadmap is usually about a year or 2 years long not more than that. Strategy is about 3 to 5 years and not more than that. Roadmap changes often strategy doesn’t change that often. Align a roadmap with the strategy doc usually.
Working well with engineering teams
KOWLGI: PMs usually typically work in cross functional teams with engineering. So you spec things out and engineering builds it. What are some of your tips for how to work well with that the engineering team?
I think that when there’s a little bit tension between engineering and PM teams, that is when I think the best product gets built
NAGARAJAN: I think that’s a that’s a great question. This is pretty much a general question that applies to any role. How do you gain the respect of your teammates. I think you will gain the respect by providing value and building trust and confidence. The build trust and confidence in you, you build trust and confidence in them. Sometimes what ends up happening on the product side is the engineering team looks at PM as adversities or vice versa. PMs look at engineers and only see people who build whatever you are telling them to. And that’s not a healthy relationship. I think mutual respect and you work in a collaborative way to add value. Software is not built in isolation. I think it takes many cooks sometimes, each one doing something very different to build software that is successful. I think it would also start with understanding what engineers have to go through. For example if somebody ends up saying hey you know what we need to redesign the system because it doesn’t work well for us and if you as a PM understand what that is and why that’s happening, you build a lot of credibility. If they were telling you that we need to run a map reduce, then you need to you need to quickly understand what that means. And you only do that so you understand what they’re going through. Again it’s about your empathizing with them. This can be used to bake into timelines and roadmaps, because you don’t want to project unrealistic timelines. You don’t want to say engineers can you get this done by next week or by end of day today. They’ll be like this is more complex than you’re giving credit for. So I think it’s about building respect, building trust, understanding the engineering system, understanding them, understanding where they coming from and being a healthy peer. Giving them a healthy balance and healthy tug of war between the two of you, I think that when there’s a little bit tension between engineering and PM teams that is when I think the best product gets built. I think engineers shouldn’t say whatever the PM gives me, I’m going to implement. And a PM shouldn’t be like whatever the engineer says I should just take. I think once you build up trust and understanding and I think if you can be a person that really understands where the other person is coming from and challenge them a bit and I think that is where PMs and engineers can work really well as one team.
KOWLGI: How do you measure the performance of a product manager? For engineering it can be measured in terms of whether the feature shipped on time and whether there are a few bugs in the product. What do you look for in a good product manager to decide if someone’s really good at their job or not?
NAGARAJAN: You just mentioned bugs, I think yeah the culture here in the valley and I’m sure elsewhere too has moved to blameless post-mortems. You don’t want to blame anyone for anything. We definitely have moved away from lines of code. I think it should really be focused on outputs rather than inputs, so it’s not like I spent 10 hours making this feature, nobody cares if you spent 10 hours. I think with time things have moved towards not just launches, so one yardstick is did this PM launch this thing. It’s not just launches, how is the landing. Imagine you launch a rocket and that rocket didn’t land where it was supposed to land. That’s not a success. Focus on landings not just launches. And also impact. If you end of doing something which did not impact anything, it’s not very useful. If you launched this thing and did not see any adoption, that’s not helpful. I think really focus on impact and relentlessly communicate that story, relentlessly iterate on what you’ve built. I think that’s one way of measuring a good PM. I think storytelling is another way of measuring a PM. Right but that doesn’t really tell you if this person executes well. So, internally we use yardsticks like how does a person communicate, how does the person provide product insight, how does the person execute and generate an impact. This applies to any job for that matter, but it’s more of a thing with product management because if you don’t launch, if you don’t deliver impact then it isn’t very good for the product.
How to evangelize product ideas in an organization
KOWLGI: What are some of your can a personal best practices for like evangelizing and selling ideas to stake holders and management? Because ultimately you’re trying to sell them on the direction to move in or work on a particular feature or product.
It usually starts with working very closely with engineers and building a story with them
NAGARAJAN: It really depends on the organization that you’re in, is it a big one, is it a small one. What is your sphere of influence. You need to read the organization. As a PM that is one of the first things that you really need to understand. Who are the decision makers, the key stakeholders and really work with them. I’m a very bottom up kind of a product manager, having been an engineer before as well. It usually starts with working very closely with engineers and building a story with them. Hey you know what maybe this is something that we could do or hey you know what I heard this from users or heard this from the sales teams and maybe this is a good thing for us to build and the data is telling me that too. It really comes down to talking to you engineers and building a story, with some data, with some intuition, with some anecdotes. And then refine that story. Once you refine the story and you kind of have agreement with your engineering team and then you start shipping it across teams. With your leadership, with other leadership that’s involved. It depends on the organization. If the organization has processes in place, start following those processes and move the idea forward and make it a reality. I think that’s an approach that I have often taken, which is a bottom up approach.
How to get customer input
KOWLGI: A lot of a PM’s job is of course also speaking the customers, being outward facing. In order to gather people’s perspectives and ideas for future product development. How do you talk to customers, what are some of the things you avoid and what are some of the things things they should do in order to gather good information?
With meeting customers one of the big advantages is really some sometimes they’ll have an interesting quote or something that really sticks with you. And that can help sharpen or build your narrative.
NAGARAJAN: Having a good feedback loop with your customers and users is super important. It varies from company to company. In a company like Google, Google Ads is very big, so we have multiple layers of getting such feedback. In a smaller team you’ll be more responsible for getting the feedback directly. Maybe of getting it from your support teams, maybe you’re getting it from your sales leadership. It really depends. On my end I think it’s super important to get feedback from customers. Why? Because you could be sitting in your ivory tower out here in Mountain View building something, but your users might be in India, your users might be in Argentina. So, you really need to get a sense for how is it working in all these different markets. What pains are they seeing, how are they using this particular product. So the way I’ve done it is you know over video conferencing. That can be extremely useful and keeping that channel open with them. Email is obviously another option. And also field trips, actually going out in person and talking to them in a very structured environment, you know something that’s organized by sales teams or support teams and getting feedback. I think a mix of all three and then be systematic about processing that feedback and referencing it wherever you want to. I think with meeting customers one of the big advantages is really some sometimes they’ll have an interesting quote or something that really sticks with you. And that can help sharpen or build your narrative. I think that to me is a super important aspect of actually talking to customers. They may tell you something that hey you know what that’s an amazing way of describing this thing and you can use that in your own storytelling going forward.
How to un-ship product
KOWLGI: Sometimes you even have to subtract from product like retire or deprecate old features. How do you communicate this to customers and what’s the best way to do it?
NAGARAJAN:Having been if software for about 10 years I’ve seen there’s 2 things that we probably do: we either ship things or we unship things. And both are super important. The same way you add code and then you have another set of people who 2 years later start deleting the code. It really comes to, PM is a lot about storytelling and about managing that story. And then of course everything follows with it. So if you’re setting a particular feature, a particular product or a particular workflow that the user had, it starts with giving them some kind of deadline that this thing is going away. And telling them that hey you know what we also have this replacement. And see maybe we’ve made a super easy for you, actually moved it from A, which is going away, to B, which is what we introduced. And all you have to do is tap this button and then say hey you know what I’m moving it all into B. If you don’t own within time B is gonna be the de facto source and A just goes away. So again it comes communication, it comes down to telling them there’s a viable alternative in place and sort of following up with that. I think it’s not a super important thing though, it really depends on the use case. In Outklip for example, there are features that you know you have seen adoption for and as well as all the features you want to retire. Sometimes you can also remove something and you know nobody might really notice that could either be a good thing a bad thing. Having some consideration for the user, hey they’ve used this thing and now you’ve taken away something that they’ve used, I think communicating up front is super important and that is just going to make them happy that you care about them.
Hiring PMs
KOWLGI: Next I want to tackle the topic of hiring product managers. So how do you go about interviewing? I’m should have done countless interviews for PMs. So how do you interview product managers? What do you look far?
We’re looking at quantitative skills, you’re looking at product insight you’re looking at if this person is able to communicate. We’re also trying to figure what product is this person going to manage
NAGARAJAN:Yeah, I think some of the things I’ve already covered today. Usually in the PM rubric at companies out here in the valley, we’re looking at analytical skills. Is this person analytically strong? Does this person bring product insight? Insight is something that is very difficult to measure. And in some cases maybe you don’t need the product insight. We’re looking at quantitative skills, you’re looking at product insight you’re looking at if this person is able to communicate. We’re also trying to figure what product is this person going to manage. I just said right many products are mature, they’ve been around for a while. It’s already captured some product-market fit, you’re not still searching for that product-market fit. And so in this case you’re looking at somebody who can execute, who can understand the existing road map, tied to the business goals that have already been established and really move that product forward. These are the sort of things we try to evaluate in the interview. I’m sure this is gonna be very different for if you’re a company of just 10 or 15 people and you’re hiring your first PM, the kind of questions you ask will be very different. You’re looking at intelligence, has this person built software and does this person understand what it takes to evolve the software. And of course as some people have said, they have to be PM junkies themselves. Are they trying out new products and have opinions? Can they talk about anything under the sun? Can they talk about what should Garmin do tomorrow.Can they talk about Dropbox even though they know nothing about Dropbox and its pricing? Are they following the field and do they have a sense for where the industry is headed and have opinions.
KOWLGI: A question about your personal background. You were a Senior Software Engineer at Google before you decided to make the switch to PM. How was your transition to PM and did your engineering background actually serve you well in easing into a PM role?
NAGARAJAN: I can maybe start with the second question. I think that the engineering background did help me because it gave me credibility with engineers. I think we should make it very clear you don’t need to have a technical background to be a good PM. In fact a lot of PMs I know here do not even have engineering backgrounds and they’re pretty phenomenal. It’s about adding value, it’s about really figuring out where this product should go. This is what really makes or breaks a great PM. In terms of why I switched over to product management from engineering and how that transition was, I just felt like I had done quite a bit about the how to build things, I had built distributed systems along the way. Then in the process I became very interested in what should we be building, really at the intersection of the business, really at the intersection of evolving an existing product or even conceiving a new product. I’ve done some of this as an engineer too on internal products and then I thought hey you know what as I’m approaching a new decade in my life, maybe it’s a good time to try product management because I’m a software and a product junkie, and you know been building software since my teenage years. It just felt like a good fit for me. I could talk technology, I knew what it took to build software and along the way I was also involved with conceiving features and software. So it seemed like it was a logical and a good transition for me. It’s not for everyone. I think you really need to see what your personality type is. Can you abstract yourself away from the actual act of building but still be close to the building.
KOWLGI: My last question for you. You mentioned about how when you’re hiring someone for a PM role, you’re looking for product junkies, somebody who’s able to talk about all kinds of products, and being able tothink deeply about and articulate what they see in other products. About your habits personally, what blogs, YouTube channels, Twitter, News feed do you follow to update yourself on product and be a better product manager. What are your sources of information?
NAGARAJAN: Yeah I think once again that’s a good question. Maybe sometimes it’s probably a good thing to not be looking at Twitter and other channels because I think as we all know that you might fall into a rabbit-hole and that’s not a very productive rabbit-hole to fall into. So, usually my sources are I would say TechMeme. Just to get a pulse well of what’s happening to the big companies out there. Then Hacker News is a key part of my reading. Also, Seeking Alpha is a very good data point for me. Especially new companies that have just IPO’d and seeing how they’re positioning their companies. These would be the names that you know people don’t often talk about, it could be Anaplan in San Francisco, it could be SendGrid that was recently purchased by Twilio, I think it is Denver or Boulder, I forget exactly. So again then you get a sense of how are these people actually positioning their products, how are they evolving their suite of products and it helps you shape and form your opinions. And of course there are the news sources, articles from friends and there’s an internal Google discussion forum that I’m a part of. But, I would say these are some three big pillars or sources of inputs for me.
KOWLGI: This concludes the interview. Thank you so much for sharing invaluable advice and perspective on product management. I learned so much from it, I mean you’ve put in so many years in product management and you’ve got so many awards and so on to go with it. Glad to have you do this interview. Thank you so much.
NAGARAJAN:Thanks, Sunil. I’m not sure about awards and I hope I didn’t ramble and bore your listeners, but you know I hope you see great success with Outklip. I’m user, I’m a fan.
