A great product manager should be like Odo from Star Trek: they're able to change depending on what their surrounding team and market look like.

Are product managers obsolete? In some cases, maybe. The two discuss how really great engineers who are "smart creatives" are often able to deliver awesome products simply by focusing intently on customers and iterating.

Why Google and Facebook require that their product managers have a technical background (see Desai's expanded answer on Quora).

Matt Pasienski: Second question. If you had ... You know, you're familiar with the genetics industry, it's becoming a big investment. A lot of people are looking at genetic engineering. What animal would you splice with a human being to produce the best product manager?

Keval Desai: Oh wow. Good thing I'm not a physician or have anything to do with genetics.

Matt Pasienski: It's certainly not ethical, so you wouldn't be able to do this if you were a doctor.

Keval Desai: The one thing you won't let me look ... What animal? That's a good ... The way I would answer that question is you don't want to be a camel, you don't want to be a horse, or you don't want to be an elephant. In the sense that you want to pick best of breed and not try to do too many things with limited resources because then you end up with a camel, which is the best of no where. I think a great product manager in my mind is really, I don't know if you guys watch or fans of Startrek, the Startrek, The Next Generation, I think, there was this character called Odo, O-D-O, and he was a shape shifter. Yeah and he was a shape shifter. He would take a shape based on the need of the hour. I think a great product manager in some ways is like Odo.

The reason I say that, if you look at different companies, whether they're consumer, business facing companies, whether they're in commerce or cloud companies, the product manager's role changes based on the type of company you are at, the type of products you're developing and frankly how strong your engineering team is. I think one of the key ingredients to think about when structuring a product manager's role is the quality of the engineering team. If you have amazing entrepreneurial engineers who not only want to focus on technology and innovation, but also want to focus on customers and markets and want to go out there and interact with their users, you probably don't need a product manager.

I've actually done some experiments in my career where I've had teams that started within a combination of engineers and product managers and I eventually just let all the product managers go and see what happens. It turns out the engineers actually step up, they get excited about talking to the customers themselves. That feedback loop of the engineers developing the product, talking to the customer, actually helps the company accelerate their innovation in a market friendly manner, because you remove the layers of-

Matt Pasienski: Before I exit, that is by far the best answer I could have ever expected for what animal human hybrid. That was really, really impressive. We did not review this ahead of time.

Keval Desai: I just watch too much TV, that's what it says.

Matt Pasienski: That's incredible, but I want to follow up. One thing you said is engineers, if they are that smart creative type that Jonathan and Eric talk about in their new book.

Keval Desai: The Works.

Matt Pasienski: They don't need a product manager. What types of things did you see at Google where engineers went out and discovered from the customer. You have optimizing, doing AB testing, what are the things that engineers would do if they became product managers?

Keval Desai: AdWords is a good example as well, which is typically you think AbWords is a business facing product. You develop this product, you sell it to advertisers large and small, and you think typically in that kind of a scenario, you'd need a product team and a sales team, but if you look at how AbWords grew in the early days, and even today I think Google does this, where every engineer who gets hired into the organization, in the first 30-45 days, they have to go out and meet with at least 5 or 6 customers, advertisers. Meet meaning they could be on the phone, they could be listening into support calls, but that was part of the orientation program, where the engineers were expected to not only focus on technology and learn the product, but actually understand the use case and interact with the ultimate user of the product.

That was done not because the product team asked for it or because Eric or [inaudible 00:03:44] asked for it, it's because the engineers wanted to do it. They wanted to see, and I've seen this over and over again ... The really smart and ambitious engineers want to know how their effort is impacting the world. How is that line of code that they wrote creating a difference? I think the only way you find it out is by talking to the customers. I think that I've seen engineers, matter of fact, Jeff Huber, who was a head of the engineering team at Google AbWords and was a very strong proponent of spending some time on the road and getting in front of large agencies, and even some of the bigger advertisers and getting-

Matt Pasienski: Do you think that's one of the reasons that generally small companies can innovate more? Because their engineers are by default have to go out and talk?

Keval Desai: I think that's a great way of saying it. If you think about some of the biggest successful companies that we have come to know in [inaudible 00:04:31], maybe others, you look at companies like Microsoft, Apple, Intel, Google, Facebook, you can go on and on, Wizeline, Optimize, right? These companies, who are the founders? If you look at, I would say 9 out of 10 times, the founders are engineers. You say, well what happened on day one at this company? When the founders started the company, did they just focus on technology or did they also focus on customers and markets? Of course they focused on everything. They looked at the business realistically. These engineers, these founders, had no choice to go and think about customers and markets. I think if you grow a company, I think what happens typically when a company grows is that we add layers of people, because more resource is needed. With those layers of people comes management, quote end quote.

Matt Pasienski: Do you think a product manager or marketing team can actually become this layer of insulation between the team who's building and the people they're building for?

Keval Desai: I think there was a danger of that happening, because if the product manager proceeds their role to be just a communicator of fetching information back and forth, then I think there is a tendency for that person to become a layer. I think one of the things that Google wanted to do, I think we did that quite successfully, is that every product manager also had some technical background. If they had to make a case for their product for their team, they were actually required to do their own prototyping. Write a little bit of code, show a proof of concept and not just be a communicator or a PowerPoint jockey.

Matt Pasienski: That's interesting, because I also think of the product manager has to be like the ultimate communicator. They're talking about the future, they're talking about what's happening right now, but that technical background is actually a form of a language. It's a language that they speak, just as if you had a team in Russia, you should speak a little Russian. That's exactly what technical team, you need to speak their language.

Keval Desai: Yeah, that's exactly. There's actually a question on Corra that was asked, why does Google and Facebook require product manager's job as a computer assigns background. I answered that question and I didn't get to ... It's been one of the top answers there. You should look at it. I think it's exactly what you said. It's the ability to communicate with your audience. If your a product managers, your audience is your engineers, your customers, and sometimes the senior management in the company that is trying to allocate resources, valuable resources and you have to compete for those resources for your project versus others. I think being able to be multilingual, being able to speak code, being able to speak PowerPoint, and then being able to speak benefits, not features but benefits, which is what customers care about it. I think those are frankly the languages that a product manager needs to know.