Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+
In Part 2 of our interview, Wizeline Director of Product Matt talks to former Facebook CTO Bret Taylor about the following:
  • Product design and making people understand a product in both a concrete and aspirational way
  • Quip’s Zoidberg function
  • Identifying costly features that need be cut
  • Marriage compatibility between product managers and tech leads
  • His favorite product that he's worked on

Missed Part 1? Watch it here

Watch Part 3

And don't forget to follow @thewizeline and @quip for more great tips on product management.

Create Your Free Wizeline Account


Bret Taylor: Wow, that's a good speed dating question. I'm not sure. I don't know if I've ever thought about ... aligned myself with a spreadsheet function so explicitly. I only use a few of them religiously, to be perfectly honest.

Matt Pasienski: What's the first one off the top of your head?

Bret Taylor: I actually have another answer to that question. My favorite function I could tell you-

Matt Pasienski: Okay, favorite function.

Bret Taylor: My favorite function if you use Quip Spreadsheets, which I'm sure you will after this interview ... if you type Zoidberg, the Zoidberg function ... I think you'll find that it's a really good function.

Matt Pasienski: I think that's pretty good marketing, everyone's going to go, Quip, Zoidberg function.

Bret Taylor: It's good. You have to see it to believe it.

Matt Pasienski: Yeah, survey says, pivot table is the-

Bret Taylor: Oh really?

Matt Pasienski: That is the best Excel function.

Bret Taylor: Yeah, no, I think that's true though I don't really understand pivot table, despite the fact that we built them, but I aspire to one day truly understand.

Matt Pasienski: 2015, pivot tables versus Zoidberg. [inaudible 02:51]

Bret Taylor: Every time I see a spreadsheet where people are using these extremely complex, compound functions, I think, why wasn't that a Python script, which is I think a very typical programmer way of viewing spreadsheets.

Matt Pasienski: That's the thing, once you've compounded six or seven different functions, it's like ... I really shouldn't be here. I think that's all banking, by the way.

Bret Taylor: Yes, it is. It is.

Matt Pasienski: You guys are adding, obviously, a lot of functionality very quickly, but you're attacking a enormous kind of  existing set of expectations around what productivity is ... how do you as a product team, decide we've built enough here that we can move on and attack something new?

Bret Taylor: I think there's sort of two decisions I think of when we launch new functionality, which is I think, actually, probably three outcomes ... one is that is was not successful, and you should cut it and move on ... one is that it was a good feature of your product, but something that you should sort of lead with, and you should probably stop working on it and just maintain it. I think there's a lot of functionality like that, even if you aspired for it to be greater prior. Then there's things that you feel like if you built it out it will actually gain you new customers, and will actually become the hallmark feature for a subset of customers ... I think I sort of group things in those categories, I think the mistake most product managers make is not identifying the features that should be cut, and it's really challenging to do it.

Matt Pasienski: If you had some advice, what would be the ... what's the tell-tale signal that this is time for this to end?

Bret Taylor: I think one of the things that distinguishes great product managers from good ones, is identifying things like technical risk and technical debt, and burn out on the engineering teams building them ... I think the most glaring features that should be cut are the ones that are very costly to maintain, cause a lot of headaches for your engineering team, every release they ... maybe you have the same pain or it compounds, and it's not that useful for any of your customers. Surprisingly, it's through no fault of any individual in an organization, there's this sort of sunk-cost mentality with features where, you already did it, so you sort of feel like you have to keep it, and I feel like the ones that are essentially are a burden on an ongoing question, so the ones that you should constantly question whether they can be done it a way that's not a burden, or they're in fact worth the burden.

Matt Pasienski: How do gauge engineer burn-out on a particular feature? It is, you're eating lunch and you hear it over and over, or it's just that bug that seems to never actually get fixed because people avoid it in their day to day?

Bret Taylor: I think the key is just having a really cross-functional team, and open communication. I think the best teams I've ever worked on have a pair of product manager and tech lead, that are essentially attached at the hip. When one of them goes on vacation, the other one can sub in almost seamlessly, and you need that deep trust and open channel of communication, even though their jobs are quite different in practice. With that you can have the trust of knowing that ... an unhealthy relationship between a tech lead and a product manager is where the tech lead is constantly hedging and sort of over-stating the difficulty of things, or constantly fighting against every new feature, and the product manager is constantly fighting for the moon, and you end up with sort of like a cap and trade mentality with product features. A healthy relationship is where two people are working together, understand the goals of the product, and are evaluating trade-offs in a really collaborative way, and I think you sort of know when you see it ... I've seen both black and white at various companies ...

I think that one of the things is like ... managers and product managers should do is be much more insightful about pairing personalities, and I think that the best tech lead-product manager relationship feels like, it's like a marriage. I think that there's a lot of compatibility and personality issues that people are completely insensitive to in placing teams that I think is one of the worst things that happens at larger companies.

Matt Pasienski: You think it should be that one-to-one, one product manager per one engineering manager, is that like the, maybe [sixth engineer 07:07], or something like that?

Bret Taylor: I think that's the idea. In general that works the best in my opinion, simply because it's collaborative, it's not like a sort of [inaudible 07:18] over the product, but at the same times, there's not ... you don't need a committee to decide things. I think two people is a really nice way of ... I think fundamentally engineering trade-offs and product trade-offs are a little different, and there's tension there that's healthy, and so I think it really helps to have both representatives in relatively equal ways ... I think the more people you get involved, the harder it is to make decisions, so I'd say two in my mind, is optimal.

Matt Pasienski: What was the first product you ever built?

Bret Taylor: The first product I worked on at Google was the search index, there was only three consumer product managers when I got there, so I was put on the crawl system, basically ... at the time Google had a billion pages in it's index, but we wanted to grow it to 10 billion, which was a pretty big undertaking. I was working with a bunch of ... a professor and a bunch of PHD students who knew a lot more than me, so I was sort of getting their coffee for a while, to be perfectly frank.

Matt Pasienski: What was your favorite product you've ever built?

Bret Taylor: Probably to date, Google Maps was probably my favorite product.

Matt Pasienski: How would you compare ... you have such a broad range, I want to make sure you include this here, you have the "like" button is attributed to your teams. What do you think ... what's it like to have that kind of impact in terms of knowing billions of people are using the things that started off as, what ... how does it go from zero to infinity like that?

Posted by on Wednesday, December 17, 2014.


Leave a Reply