0:00It's been around forever.
0:01Yeah, honestly. Um, but I got into it just because I worked on a product a long, long time ago. The irony is, and most people don't realize this, it was an AI product.
0:11In 1980s, that's how old it was. So AI has been a thing for a long time. It just was never ready.
0:19It's only the last few years it's ready. It was just theoretical. Uh, and anyway, we did a product that was a I was the the lead engineer on it and it was a very impressive technology, but it was no market and I wanted to make sure that didn't happen again.
0:35And then you learned the hard way.
0:36I asked my manager to uh I said I want to learn this and he said he couldn't. He was an engineering leader but he introduced me to somebody who could.
0:45Nice. [music] [music] Welcome to rethinking people, conversations shaping companies in the age of AI. I'm your host today, Pedro Bobo, co's co-founder and CHRO. With me, I have Marty Kagan, product legend, founder of Silicon Valley Product Group, XVP of product for eBay and Netscape, and author of three books, Inspired,
1:12Empowered, and Transformed. Marty, thank you so much for being here. Really, really appreciate it. It's going to have an awesome conversation.
1:19Well, thanks for inviting me, Pedro.
1:21Appreciate the invitation.
1:22Yeah, it's going to be a super exciting chat. I'm super pumped. Uh I have been, like I said to you, I've been a big fan.
1:28Inspired was the first book I read uh early days and what got me into product management. I remember flying for the first time to Silicon Valley reading that book, prepping for a PM interview at Google. So classic case, I'm sure you had thousands and thousands of people in that scenario. And I guess to get started would love to maybe if you want to quickly introduce yourself maybe a couple sentences about your journey for maybe people that don't know you and then would love to talk to you specifically for the readers that
1:56haven't read your book when it comes to the product model that you talk if you had to simply put what's the difference between a company that works on a product model versus a project based model. So that would be the first opening for they would love to hear your thoughts on. Okay, sure. That's a lot to talk about in an opening. Let's see.
2:15Well, as far as me, uh, I have been working in exclusively technology powered companies for my whole career, right out of university. Uh, I worked as an engineer for the first 10 years of my career. And then I wanted to learn more about how you decide what products you should build. And so that pulled me into the product and design worlds. And I've been working uh initially on product teams and then product leadership and
2:43then uh and I I worked at some really uh great companies to learn about. Uh one of them was the original internet company Netscape. It was when uh a tremendous amount of change hit the industry and uh I was able to be right at the center of that and and see that change. uh and it also changed how we built our products then.
3:07So I I took what I learned and I wanted to write and I started writing some books and started investing and advising in startups um all kinds of companies and and just to be clear I uh my specialty is really product development.
3:23How do we create products? Uh pro normally products that we sell to our paying customers but one of the things I found is that many of the companies especially the large companies they don't just build they don't just use the skills to build products for their customers they use the skills to build product for their employees so they can build better products for their customers. So um that has pulled me into all parts of the company. I've obviously
3:51worked with a lot of HR groups in lots of companies including here in Brazil. I've worked with lots of finance groups, lots of marketing and sales organizations, uh lots of legal and compliance groups. All of these people have problems to solve with technology.
4:08So my I'm not an expert in AR HR rather, but I am um I have worked with a lot of companies building HR products. Nice. uh in in most of the major spaces, things like ATS systems and uh basically job marketplaces and employee engagement and onboarding programs and education, all of these kinds of uh products out there uh and many in many cases helped
4:36companies to build custom solutions for their users. And you also asked about the difference between the project model and the pro product model. That's a big topic. Um, and to be clear, it applies in both um, uh, building commercial products and building for internal users.
4:59Now, most of the time when you're building commercial products, you can't really afford to be wrong too much because you're spending your own money in the hopes that customers will pay you. When you build internal tools, they kind of have to use your product. it's not like they can go to a competitor. So, [snorts] in a lot of ways, that's much easier.
5:22But, uh, when you're building external products, it's hard. And there are, uh, lots of people that struggle with that all over the world. There are two main ways of coming up with those products.
5:35The most common way still is called the project model. It goes by lots of different names, feature teams and feature factories, but the idea is that somebody, it's usually uh an executive, it might be an HR leader says, "This is what we need in our new homegrown ATS system and they're coming from a good place.
5:59They've been living with these problems, but they see the pain, but it doesn't mean they know the solution that will actually work." And when we say work, it's not enough to work for your users. It has to work for your business. It has to be legal. It has to be compliant. Uh it has to be ethical. It has to respect privacy issues. There's a lot of issues around people related services and products that you have to be aware of to do a a solution that works for both the users
6:26and for the company. So um in the project model they just do their best to describe the the requirements and then they have developers to build them. The problem with that is that most of the time it doesn't actually solve the problem.
6:40Uh if you believe Harvard Business Review about 80% of the time it doesn't generate a return on investment.
6:48So that's uh pretty bad.
6:50And I think that's because of the model.
6:52That's really because of the model. On the other hand, um, for many years, the top product companies in the world have been working very differently than that. They're instead of building features and projects that are on some stakeholder-driven road map, they're given problems to solve. Now, they might get those problems to solve right from the same executive, which is normal, but now they're given a problem to solve, not features to build, not projects and
7:21features to build. So when they're given a problem to solve now they assign that problem to a crossf functional product team. That's what they do. And they have to be crossunctional. They really don't have to be crossunctional in a feature team. But they do in a product team because you need a range of skills in order to come up with a solution that works. And uh of course us coming up with a solution that works that's pretty hard. That's called product discovery.
7:49It's mainly a lot of prototyping and testing of those prototyping to come up with a solution that's that's got four risks addressed. The first is that it's got it's valuable. In other words, your users would choose to use it. If it's a commercial product, they would choose to buy it.
8:07Uh but even choose to use is hard unless they don't have any choice. If the user has no choice, then it's mandatory. Then it's easy.
8:16Of course, it doesn't mean they're happy. So it has to be valuable. It also has to be usable. If you need a training course just to help your poor users figure out how to onboard them, it's not very helpful. So uh it needs to be usable. It also has to be feasible. We have to be able to build it with the skills and the time and the money and the technology that we have. And finally, and often the hardest is it's got to be viable. That means that it's not enough that it well,
8:45let's say we're talking about uh applicant tracking systems. Well, there's a lot of regulations at least in the US about around the applicant tracking systems. Part of it is for legal requirements. Part of it is for managers to understand like what about their pipeline? How is that looking? So, it can be for lots of different reasons, but there's a lot of different needs.
9:06And the product manager has to make sure the solution is not just something that an applicant wants to use, but it's something that a hiring manager can use, a recruiter can use, uh the legal people say is okay, the compliance people say forth. That's right. So, it's it it means for solving for lots of different constraints. That's product discovery.
9:27And then we build and and deploy that solution. So that's a very yeah I know condensed version and then to unpack that and thanks for sharing that when we think about the productbased model you mentioned that you're essentially giving a problem to a cross functional team.
9:45Which has a multitude of skills.
9:47And then maybe could be a few people depending on the number of people might have more or less depending on the complexity and so forth. And then you're constantly iterating on that to build and evolve. But my question is in this day and age today I see a lot of people that don't have for example a lot of these skills that you talked about product discovery thinking cross functional alignment and so forth but they are building a lot of things they started a problem more than ever because the fre the effort to build went down yes but my intuition what I've seen is that
10:17they're not necessarily generating a lot of value they are creating a lot of things sometimes they do create value but some more often than not they don't and they would argue that they're like, hey, no, but I'm doing discovery. I'm doing these things, but I'm doing all of that myself.
10:30And then what is your intuition on this?
10:32So, is this happening because, okay, people can build, but they're still they're still following the projectbased model. They're just doing that a lot faster, or is it somewhere in between?
10:41It's exactly what's happening. And by the way, many many people have noticed this.
10:45It's even got a name today. Uh, the two biggest groups that have noticed this and measured this is McKenzie, the management consulting firm, and Atlassian. company that does tools. Both of them in the last few months published data showing this problem.
11:03It's called the AI productivity paradox.
11:06It means that the teams are absolutely moving faster.
11:10Just like you said, they are moving faster, but they're not actually getting better results.
11:17And that's exactly what you would expect in the project model.
11:21It's just faster. It's just makes it very clear that it's garbage in, garbage out. We The reason that's not a surprise is because even before AI, there were some teams at really good companies that moved incredibly quickly.
11:37And we saw them go through that same learning curve as well. Speed is still good, don't get me wrong. We want go faster. We want to go cheaper, but we only want it to go in the right direction. And what it does is it shines a light on the need for people to actually know the craft to actually figure out what is going to be a successful solution.
12:00But then would you say that let's say I'm I'm an HR head of HR and I want to build an amazing HR product for my employees.
12:06Yes. and I don't have necessarily a great product person and a great designer, a great engineer and all those things, but I still want to do my best effort to kind of build the best possible product. I can build my own team. So maybe I could maybe hire someone or build those skills, etc. Or maybe I just need to change my mental model and learn. So in a situation where I don't want to do the project based model, I actually want to do the product based model, but I maybe I don't have all the skills that ideally I would have
12:35in a super structured team. How would you go about that? Both is there some skills that you say these are absolutely required. So go hire someone that has that and these maybe you can develop or there are a simpler way to do the product based model where I don't need as many cross functional skills in a limited resource world more or less. That's the the framing here.
12:57Well, it's complicated. Um, and you'll see why. There's really only three skill crossunctional skills that are critical. Okay? There's three critical skills. So, it's not like you need 10 people. You generally need three.
13:10Uh, and not even for every product. Some products you can get away with two. if you're just building an infrastructure like a platform, which isn't really what most uh of the HR solutions are.
13:22Um, but if you were, then you can get away with just two, which is an engineer and a product manager. But for most, like we're doing a workflow of some sort. It might be for employee engagement. Who knows? We're doing a workflow. So, we usually need three. So, we would add a designer to that mix.
13:39And those are pretty important skills.
13:41It's not that if you don't have them, it only, you know, you can still put a prototype together and you can still test it, but number two things are going to happen. One is you've got to expect a lot of prototyping before you get something worth that will solve the problem.
14:00And uh second, and this is the harder one, is not everybody thinks that way.
14:08There's a famous quote which is uh in order to develop great software for something like sales, you need to understand sales. But just because you understand sales doesn't mean you can build great software for sales people. It's a different mindset.
14:26Uh and it's a training. It's it's something you can learn. But most uh stakeholders around a company not only in people ops or HR but finance they have they have very specialized skills but they're not these skills.
14:42They're not building product.
14:43That's right. It's a very different set of skills. So uh the other thing that can happen too is um and and this is also going on in our industry. If your approach is just to keep trying, you're eventually when we say we try, you're putting it in front of real employees or real managers, hiring managers, and say use this.
15:08They get really frustrated when you keep using them, we say, as guinea pigs. You're testing on them every day and you keep breaking it and you keep changing it and they're like, "Why don't you just come back when you know what you're doing?" Mhm.
15:23So they get very frustrated and that's employees. This also happens with our paying customers. The difference is we usually have many more paying customers so we can spread out that pain but for employees it's often a pain very frustrating.
15:36Yeah. And then so there's something you talk about that I took to life and it's been one of the best lessons I learned which is like you constant you should be always putting things in front of customers and iterating and there's that famous Reed Hoffman quote like if you launch an if you're not ashamed of your MVP you're launch too late right and I think that goes a long way in HR for people that are trying to go his quote is I would argue it's it's conf confused that's not what we're saying yeah well my point is you need to build
16:05with the customer and iterate from Correct.
16:08Or no, please push back.
16:09You what we are talking about is you need to test your ideas on customers. Uh a lot of people confused what an MVP was and that's what he is referring to.
16:20His point is that please what what people would do does and you know your audience may not know MVP stands for minimum viable product. It's um it's supposed to be the smallest prototype that we can test our risks on.
16:37But what so many people do is they don't want to spend six months to build a product. So they spend three months and they they have a very weak solution that nobody likes and nobody you don't learn from that. So there's a lot of confusion around that topic and your point would be you need to figure out what's the minimum you could do much better than what Reed is talking about.
17:01I see. So you're saying you don't need to get to the MVP to get the right signal. That's right. Perfect.
17:05And you don't have to wait months.
17:07Agree. Especially now, but even before.
17:10Yeah. I remember learning like just putting Figma things together in the day and put in front of people. So but but then when you think about these lessons in HR, there's this kind of sphere of mistakes. I think that a lot of HR people are scared of making mistakes.
17:26They're not risktaking. And a lot of it makes sense because you actually can make a lot of mistakes in a very regulated place. I can't actually make a mistake in a workflow that goes to payroll because I get sued. And when you think about building products in general in environments that are more regulated or strict, how do you go about balancing incremental launches and bothering people and and pushing and testing when mistakes are more rigid and any advice
17:54that you would have for people that are trying to build in those in that space?
17:58Yeah, and that's actually very much what I was alluding to when I said if you just are trying things on your users, they get very frustrated. And sometimes in some businesses like health care, you could get in trouble, big trouble. You can't, you know, you can't experiment with the health of your your patients, you know, your your users. You have to be uh responsible on that. So there are two um this is one of the most important
18:25concepts. We do experiments in the product model every single day. But those experiments are not build it and launch it to our customers.
18:37That would be first of all most of those experiments would be probably not even legal.
18:43Not even okay, not compliant, not ethical, not legal. So we are um uh there's a big difference between learning in discovery which is what I've been talking about and learning in delivery when you ship a product. One the for 30 years we have been create the the product industry has been collecting and creating new techniques for testing ideas safely on subsets of users where
19:12the where the users actually opt in where they often will sign a document saying let's say let's say it is for hiring.
19:20I've worked on many different job boards out there and you're and yes, you want to start with your own people, but you can quickly go to other companies and work with their hiring managers. Those hiring managers are signing a document that says, "I want to try using this experimental version and [snorts] I'm going to share the data I collect. I'm going to let those people understand how I'm using it in order to get this right." And they're doing this because they really need help.
19:47They really need help. And and to your point just to uh allude to it is effectively when you want to go and test and learn in this highly regulated you just find alternatives that are not necessarily launching and you want to avoid actually launching. you just want to do a lot of small snippets, maybe focus groups, maybe trials, maybe environments that are cons controlled.
20:06Let's call in fact one of there's a there's a fantastic technique, it's been around for years called the customer discovery program and the idea is very popular with internal tools like a lot of what we're talking about in the HR space. Let's say a company wants to do their own kind of employee their own approach to employee engagement pulse survey kind of thing and they don't really know what it is.
20:30They know it's an important but hard problem and they don't know what the right solution is. They can identify a set of employees and they might choose them intentionally by certain levels in the company or maybe you're trying to do something for the sales organization or doesn't matter whoever it is and you set get a set of those people. It's usually somewhere between six and 15 of these people and they volunteer or you ask
20:58them to volunteer to uh to be a member of this group where every day they are trying new versions and telling you uh what works and what doesn't work.
21:11I see. Nice. Yeah, because I there's this component that I see oftentimes which is um at least in my experience working with HR people that they are a little bit averse to that. They're averse to actually getting the potential customers on board and saying hey help me build this with join me do it. It's a little bit more like I need this precious thinking of this has to be great before I show to everyone because I don't want to be perceived as a little bit imposter syndrome that they say hey I don't want to show things are not
21:39great but your point here is okay just being intentional about getting a group of people that are going to opt in they're going to be okay if things are not working perfectly from day one and then you you learn from it but more from that more than that if they truly want it to be great they have no alternative but to do these experiments nice So that's what they need to understand. It is there's a great quote from Jeff Bezos. If you want to innovate, you absolutely must experiment.
22:07It's just unavoidable. So then the question becomes what's the safe way and the risk averse way to do experiments. We have a whole family of techniques for uh comp regulated companies uh kind of companies where somebody's uh life can be at risk um where you have to be careful but you also have to if you're going to improve their life you have to actually experiment and there's risk to it. There's always
22:37there's risk but you're controlling the risk. In fact the reason you're experimenting is to reduce the risk.
22:43Makes total sense. And then when you're experimenting, let's say, okay, a customer goes and I've seen this many times and I struggle to that dayto day, which is, hey, I actually think you should do this. That's a feedback from the customer. You know those crazy feature requests that you keep getting and pushes and so forth. And I know you say a lot like you need to build missionaries, not mercenaries, people that are in love with the problem, not the product, not the solution. But oftentimes the feedback that we get from customers are hey this button should be
23:12here or hey I need this feature or I need that. And a lot of people's reaction is hey let me just add that to my road map. Here's my backlog I added.
23:20And I would argue that many times that's actually whatever they're asking is not what you should do for many reasons. But I know you thought about it and sometimes I struggle to say okay I should listen to the customer here or I shouldn't or maybe I should always listen but understand their problem.
23:35like how do you distill that moment and that exercise for people that are trying to actually hear the customers but not be biased by them?
23:43Yes, this is this is super important.
23:46And in fact, it's the difference between the project model and the product model.
23:50In the project model, if it makes it to the top of the road map, you build it.
23:55And that's why the project model, it's called mercenaries, because then the product team is just there to build whatever somebody told you to build.
24:02So, they're going to pay for it and that's it.
24:03That's right. in the product model. Uh this is really important feedback. Somebody is saying I think you should do this and what we want to know is why.
24:15What is going on? Is there a different problem they need solved? Is it that our current solution does not address their problem? Is it they they found it not usable? Is it because they found it there was not the value they were looking for? What is going on?
24:30The why. [snorts] The why is super important. Now, we might choose to fix it exactly the way the person said because it's a great approach. Let's try it.
24:39And we might say, you know, that sounds logical, but here's why that's not a good solution. That would make it uh not compliant.
24:48That's why it's set up this way. But we have another way of solving that problem.
24:52And okay, I totally agree, but it's easier said than done, right? Like in the end of the day, you're an HR profession. The CEO calls and say, "I want it this way because I want it this way." This is the difference though between seeing a product company where ultimately you're you you either sell or you don't, right? You sell or you don't. It is very much outcome oriented.
25:13In an internal tool, there's some governance that goes there. It's more like I said, they're not buying it.
25:21So, you're going to have to pick your battles. Most of the time we're we're uh we we've got a lot more room there. uh we still don't want we don't want to create pain for our employees. We want to make their lives better. We want to help them do their job better. We want to help them take care of customers.
25:39So we don't it's just um you'll really see this clearly in a company that must come up with a winning solution in order to compete in the market.
25:51Nice. No, this is super helpful. Maybe shifting gears, Marty, to some more people topics specifically about roles, title, hiring, and all those things. Uh, one thing that I've been hearing a lot and seeing a lot is people saying that roles are changing. So, are we going to have engineers? Engineers don't write code or PM still a thing or they do different things or designers, you know, all those conversations that you see on X and all those places. And I I've heard two different school of thoughts high
26:19level. One is that the core roles are still going to be directionally the same. The skills that they have might be different. So an engineer goes from writing code to maybe directing agents to what to do. Others are saying that maybe you're going to have way less roles and roles are going to be totally different and you're not going to have some roles and some new are going to emerge. What what what what is your mental model for that? Especially because as an HR professional, I'm hiring people. I'm building my org chart
26:48and I need to think what is orc chart today and the orchart 3 and six years from now and I know no one really knows the perfect answer but how would you think and then more than your opinion what is a mental model that you use for coming up with those premises like how do you how do you encourage people to think about these very ambiguous problems because it's something I debate with all the time yeah and it relates to what you were asking about earlier when we talked about the AI productivity paradox
27:14so uh this is a very you know big topic because for AI has sort of been what it it's been major disruptive force for more than three years now and during those three years there have been all kinds of speculation of everything and in fairness it's very hard to extrapolate course very hard to know uh just last week I was with um a major conference in San Francisco and um
27:44and it had the product leaders from anthropic and open AI and they also don't really know where this is going. None of us really know where it's going to go. We don't really it's very hard to extrapolate from what you don't really deeply understand.
27:59We do know what it what we have today and there's things on the horizon that we can see but when and if we'll get you know truly fundamentally different and how that changes things is very different. So for the foreseeable future even at the or I should say even especially at the top frontier labs they are seeing three critical roles right and the irony is they're the same three
28:28critical roles we've had they're the same roles but the job you do the tools you use oh you are very different and the reason they're the same is be the same three roles I think is because they still we still have those three fundamental constraints we're trying to deal with. We're trying to deal with technology which is changing so fast.
28:51So that's why the engineer role is not going away. We are trying to if if you're developing something for humans to use then you are dealing with the usability issues. So we have the design constraints and then if you're dealing with something for a business right for your business you need the business viability constraints addressed. So, it's just become more clear how important those things are. Many teams
29:19thought they didn't need any of that and they could just have somebody vibe code a solution only to find like we said before it works. It doesn't work.
29:28Doesn't actually solve the problem. It doesn't generate the return. And and as much as people realize it's very cheap and fast, sorry, fast at least to uh cheap in terms of our time, but it's not cheap in terms of token cost. So there are still very significant expenses to building. The other thing I'd say is that we have a much more clarity today as an industry that there's that fundamentally a product team builds. That's what they
29:57do. They build. But they build two different ways for two different purposes. The product manager and the designer are really building to learn. They're building in order to figure us out a solution that's valuable, usable, feasible, viable. They have to solve the problem.
30:14The engineers are building to earn.
30:17They're building something that can make money.
30:20They're selling building something that your customers can run their business on or your own employees can run your business on. And that's a very different set of challenges around performance and scalability and runtime costs. Uh so very different, very hard. Both of them are hard.
30:39Uh what's one of the most significant sets of learnings over the last two years is each of those two communities starting to learn more about how the other one is hard.
30:50Nice. Yeah. Because now they're trying to do everything themselves. If you're like try to do it all yourself, you see the problems very quickly. And then the the takeaway here just to I'm trying to encapsulate your thoughts here, but the takeaway essentially is you have some skills that are hyper specific and needed today. AI hasn't solved for those and you need to make sure those exist and today almost no one really has all those skills. Maybe there's exceptions.
31:12So you really need to try to connect those three even where AI is at its frontier.
31:17That's right. And it is true and this has always been true. There's a few people that are good at more than one of those. An exception is always there.
31:25And I have not seen that actually change in any significant way because each of those three has become more difficult because as AI has raised the floor right from all kinds of stuff to it. I mean you can do something pretty decent pretty easily today but now everybody's at that floor. So the com the differentiator is above that. Nice.
31:49And that means design is more important, product management is more important, engineering is more important.
31:55Yeah. But then for example in those cases, let's think about hiring. Uh in the past I've done and even applied hiring interviews for engineers where there'll be a coding challenge and now engineers are not really writing code. You still argue that they need to understand and iterate and so forth, but the hiring process at least at comp we changed a little bit. It's no longer the same. No.
32:20And that's a frequent question that HR is being posed like, hey, how should hiring work? Because hiring is a process that HR is responsible for.
32:28That is one of the many process that I believe we'll be having to adjust and adapting to this coming age. How do you see for example hiring but maybe other processes how they're changing because the skills and the actual work is changing?
32:43There's a lot of change going on here.
32:45Um it's almost what do we want to pick to talk about? Certainly in the hiring in the interview process um most people know because this is the most the furthest developed of all those three areas is engineering. They know that the nature the handcoding interview is not so useful anymore. But you are orchestrating a set of agents. You are still what they're looking for now are is not just can you code but can you do
33:13you understand the architecture of a serious production system? Do you understand fault tolerance? Do you understand uh true site reliability engineering? Do you understand telemetry and monitoring? Do you understand these kinds of you know senior engineering level issues because that's what you need to be good at.
33:35Uh similarly with design um you're not just you know that's the models today can do basic design they can tie to your design system. So you're looking for designers that really understand service design holistic design interaction design and not just wireframes and comps and visual design. So uh and same is true with product. They're not the job is not like a backlog owner anymore or an agile scrum person. It is uh product
34:04judgment. It's how [snorts] well do you understand the different dimensions of the business? How well do you understand our customers? How well do you understand creating value and viability?
34:15That's the job. So what you're seeing is each of those jobs have improved their interviewing to test.
34:22So it's not unusual. I mean, obviously, it's not unusual for an engineer to see show that they can use these tools competently. That's been true for a while, but they're also they're also going uh in in a product manager interview, they're telling the product manager, "Here's a problem to solve.
34:39Here's an outcome to achieve. How would you do it?"
34:42How would you do it? They're expecting like, "Use whatever prototyping tool you want. Show me how you create a prototype. Show me how you're going to test that prototype. Show me what you're going to learn."
34:53And and so think of me, let's say I'm an HR professional and I need to figure out interviewing for all types of roles, engineering, design, product, but also marketing and sales and finance and HR and all those things. And as all these roles change so fast, maybe the what they're trying to do is the same, but the way I validate whether that person has the skills that I need is quickly changing. And I'm just one HR professional. I I can't know the latest and best of every single line. How
35:21should I think about that? How should I try to build a process or a tool, whatever is the solution I'm trying to come up with to actually optimize for so many different roles that I have in a company? And maybe I'm not the bright person to build like, but how should I think about it?
35:36Yeah, this is one of those this gets a little uh controversial topic in the people ops world, but I I think that is unfairly expecting the HR people to do things that they can't. I'm in fact just literally today I published a new article called experts lead experts and the idea is that in every good product company I know the managers are expert in what they're managing. So the point is if you're pick one I mean you mentioned let's say engineering
36:06an HR person they should not be doing that your top engineers your top engineering managers they should be constructing that interview they should be constructing the interview team they should be if you're going to have a practicum if you're going to have a project in there they should be doing that and one of the problems I think in too many companies around the is that the I'm I'm blaming here the engineering managers is there they're
36:35just going to HR and say oh you find the people and then they complain about the people it's like this is their job to make sure that is done well HR can help but you can't expect them to be an expert in everything agree even in really any of those areas it takes a lot of knowledge so yes and I couldn't agree more and the point is maybe you're helping them get there but you're not the decision maker on how an interview process should go.
37:00No, you're encouraging. And I think the bigger thing is um uh most companies today around the world need to do a major overhaul of their job descriptions. Nice.
37:15They just need to. They've been out of date for a long time actually in a lot of companies.
37:19Even before AI, they've been out before AI. But now it's just so obvious and um you know it's the systems out there make it very painful to do that. So I understand why HR is like oh no I don't want to do that. I don't want to like reclassify everybody and and also it's all on them which in reality they shouldn't be the ones deciding what is an engineer what isn't.
37:40They should work with the team to get it.
37:42That's right. But even you know even if the team says we have new curves, we have new job descriptions. Uh that's still a lot of work. nice on HR.
37:52One other process that I I've I've read about that you shared was about performance. Whereas today in sometimes performance more this like administrative way of saying who needs raise and not and that's not where development development coaching happens in 101 ones. I one thesis that we have at comp is that given now you have the ability to collect way more unstructured data and information on people performance could go to the next level where you can actually have a lot more
38:22inputs on people than the once a year review that I remember of what I was working with Marty because I don't actually have all the input if the data is all there and then you can actually have a more eloquent and or assertive view of people.
38:37How about more useful and more useful? Exactly. Definitely.
38:41Yeah. I mean, you're you know, the truth is the the conventional performance management system has never been about helping people get better at their job.
38:50Never been. At least in the US. It's true as well.
38:53In the US, it's there because if you want to fire someone, you have to go through you have to show that you did what's called due process, right? that you have said, okay, you sat down with a person and said, I'm sorry, you're not doing what you need to for this job. You need to understand that if it isn't corrected in the next three months, six months, whatever, then we will have no choice but to go our separate ways.
39:20I hate doing this, but as a manager, we all have to do this. And we have to show that we have gone through these steps.
39:26We have to document those steps. We have to get the person to sign that they have seen these you know that they understand and then we have to go through and say all right for the next three months you are on what's called a performance improvement program. Yeah. And this but this has never been about helping the person reach their potential.
39:48No nice that I agree. It's just I it's a very similar but but the point is we have always any good manager I have ever known never used that for helping they have to do that because it's a law they have to do those things but that is not what they do to help people get better at their job but now I'll give you a view of me as pedagon but one of the founders of like this 80 people company and I actually deeply care about knowing who's
40:18performing great and who's performing mediocre.
40:22But as the company grows and it's growing, it just gets harder and harder. When we were 10 people, so clear to me, I could say like that. If we're 800 people in the future or 8,000 people and go on, it's almost impossible for me to know in this day and age.
40:36But why why would you need to know first?
40:38I don't necessarily need to know. I just someone needs to know.
40:41Your manager needs to know.
40:42Exactly. And then someone needs to know about the manager and so forth. However, I would argue that a great performance cycle or it doesn't have to be once a year. It could be however you think about it would be able to tell and help you be more assertive about that whether someone is performing well or not and why. But I agree with you, it doesn't happen today. doesn't happen today in companies that make the mistake of just doing performance management systems
41:11because they they don't understand that they're not actually for this purpose.
41:16And what we're talking about here, helping every employee at comp or any company, every employee reach their potential.
41:24That is the highest order responsibility of every manager. Now, it used to be done, we're going to go back to what you observed where it used to be done by one-on- ones every week, and that still a lot of it uh happens a lot. But today, we have AI technology that lets that lets people get that kind of coaching they would get in a one-on-one every week, anytime they need it.
41:507 by 24. It's in your It's on your phone. It knows what you're working on. It knows your role. knows the the product strategy. It knows the team topology. It knows all of these things about what model you're using, product model, project model, and it is helping guide you. It is helping you get better at your job.
42:11That's our goal is to help people get better at their job.
42:14And this is uh this is not as simple. I don't know whether to throw this in or not. A lot of another common misconception is that they just want to evaluate a person.
42:27Not the work, not the it's the team. Uh that very same person can be awesome on one team and useless on another team. [laughter] And it might be the manager has now gone from a great manager to a terrible manager. It might be other co-workers.
42:45It might be the area. Could be so many things. So usefully evaluating people and helping them improve is never been a minor thing and is my favorite companies that's my single favorite HR application to work on is because you're helping people reach their potential.
43:06Nice. Maybe to go a little bit deeper on this because me and Chris is my co-founder. Our first thing that we never opened was comp wants to always make the best decision for its people and as a result it will work. It might not be individually it has to be globally and thinking about everyone but it has worked very well for us so far.
43:27So if I make what's best for people it's going to be what's best for com. So I do it out of selfishness that is out of the good of my heart and I do believe that HR should have a meaningful place in helping the company do its best work for its people. Sometimes it's helping working to build a better hiring plan in parallel with people. Sometimes it's doing that. And you mentioned something that I think is very interesting which is you have not only you have someone next to you, this agent that can help you do, you can al you also have a lot of data that you can use and build from
43:56it. And my my question to you and my my point is I often have this uh criticism of HR which is it looks in like silos.
44:05So you have someone doing performance but like you said it's way more than performance. You have to think about it holistically. The team which is about about workforce planning, it's about the task which is about the job description about and and I strongly believe and I would love to hear your point on that which is if you were to think of HR as a product and trying to build a solution which wants to do the best for its people capacitate them hire and all the things that it has to do. How would you try to construct it? Whether it would be in the same department that HR has today, you would think from foundation
44:35team and a and uh I know you talk about the platform team and the team that built the experiences just high level if you had to like think with me for five minutes on how would you go about building this like best-in-class HR function.
44:50You mean like portfolio of HR solutions?
44:53Exactly. Whether that's an ATS or I don't even talk about ATS. I talk about the journey ATS would be one of the things right there's many things you're including everything.
45:01Yeah. It's kind of like how would you construct the like how would you would you think about the employee life cycle or Yeah. Monumental model.
45:08I understand. So um this is like really any product even external product you could look at eBay or you look at Marcato Libre or whatever look at any it's it's a big thing that has many many pieces. The truth is there are lots of ways you could set up and and be awesome or lots of ways you could set up and be awful. So the silos that's because the there is if you have those silos you're describing that's because there is no
45:37single leader trying to make a holistic view.
45:41It doesn't really matter how you would set it up if that leader was there. uh very common problem and this is not specific to HR is not having that leader that believes it's their job to provide the holistic systems thinking overview of how these should all like how asking the questions like okay these are different systems and they make sense to be different systems but it's the same people going through that right so what's it how is
46:10it going to be experienced by the employee it's like on one day it's one whole different world. Another day it's a completely different world. So how can we how can we make that a a seamless experience? How c where should it be leveraged and where should it not be leveraged because it doesn't matter.
46:29These are the kinds of questions a leader asks and would you say that is similar to having a clear product vision? Yeah. So what is the difference is the vision for HR.
46:40So having an HR vision what is the vision?
46:41HR technology vision. Yes. This is interesting. And then I know we're running short on time. Uh there's just one more question that I would like to ask you on this on this topic when it comes to HR and then a few rapid rapid fire questions. But uh if you just to building a little bit more on this world where you are this leader trying to build this vision um when you think about advising people on product vision and building this product vision that is at least in my experience a hard exercise because there's so many things
47:11to think about and consider. Is my vision about the employee or the manager or the company or is it about all of them but in different what is the mental model that you advise people if they're trying to build a product vision it could be an HR vision it could be a external product whatever it is because at least for me I find that a very hard exercise to do that you have multiple ways to navigate it is it is and it's um one of the most important sort of principles in product
47:39thinking is you're making choices taking priorities. You and I are talking about the advantages of having a single holistic experience and maybe knock down the walls of those silos. Most people would agree that's a good thing.
47:56But let me just pose it this way. What if should let's say you are the head of HR.
48:02Is that is that the most important thing for you to do? Or maybe the most important contribution to your company is getting a good performance management system in place and just focus on that and just nail that which would have a bigger impact to your company because this is very much the kinds of choice product leaders face in every space. Uh, and you know that's a hard question
48:32because if you did a truly good performance management system that was able to raise the average performance, let's say 10 or 20% of every employee.
48:43Oh, that's like hiring, you know, that's the equivalent of another 10 or 20% of your staff for no same cost. Be amazing. Reduce retention of the top people. This would be huge. probably more than even the benefits we're talking about because really what we're talking about when we say knock down the silos, we're removing irritation and friction.
49:05We're not like changing the game, right?
49:09Yeah. Depends on if you unless your focus is to change the game. Yeah, of course.
49:12Yeah. But again, how is it really changing the game? And so to me there's very clear opportunities to have a single holistic view but it comes at the cost especially for an HR leader because you know even doing one of those spaces really well so hard that's hard and if you're a larger company and recruiting is a big part of it you know that the applicant tracking systems are not doing great jobs today they're all [clears throat] getting the
49:39same sort of AI input and so that might be a really critical area, you need to do a much better job at recruiting and onboarding your people. Maybe that's a bigger space. This is the kind of choice that leaders have to make.
49:54And your point just to make sure I understand is effectively try first figure out what's the business outcome I want to optimize for if that's holistic to everything HR that's focus. And then I build a vision for what I'm trying to solve and work backwards. just and the vision is a nice thing but the most important thing is to solve that well with the vision that's the most important with real outcome nice and then super quick quick last questions u more about you and who you
50:24are and and and quick things uh they would love to hear from you first is how did you end up getting into product like I know you mentioned you're an engineer and then you got to that but I don't even know if that time product management was a real term it was it's been around forever.
50:38Yeah, honestly. Um, but I got into it just because I worked on a product a long long time ago. The irony is, and most people don't realize this, it was an AI product.
50:49In 1980s, that's how old it was. So AI has been a thing for a long time. It just was never ready. It's only in the last few years it's ready. It was just theoretical. Uh and anyway, we did a product that was a I was the the lead engineer on it and it was a very impressive technology, but it was no market. Nice and I wanted to make sure that didn't happen again.
51:12And then you learn the hard way.
51:14I asked my manager to uh I said I want to learn this and he said he couldn't. He was an engineering leader but he introduced me to somebody who could.
51:22Nice. Interesting. No, that's amazing.
51:24And then about people uh specifically when you if you had just some advice for the audience few things one is about the best advice that you would give to people managers not necessarily HR on how can they make the most of their people that work with them and for them not just from the perspective of hey how do I extract as much value from you but how do I become the best people manager thinking about people in that lens.
51:52Okay, I have to make sure though I'm I'm not talking about if if you happen to be managing salespeople or you happen to be managing a different role. I don't know. But if you're managing engineers or designers or product managers, then I would argue the most important thing is that you have to realize when you're no longer an individual contributor, your product is your people.
52:15And your number one responsibility is to develop their skills.
52:19Your product is your people. your product is your people and furthermore you have no real chance of doing that if you're not an expert in what they do. We there I don't know if this is a common thing in Brazil but in Europe there is a real problem for the last several years and that is this idea of the people only manager this is not to be confused with a a people ops this is right this is a manager of engineers that doesn't know how to program
52:49I see just a great manager but doesn't well they may or may not be a great manager there doesn't make them a useful I see the point is you would never how can You literally lead engineers and help them get better in their job if you've never done it.
53:03It sounds so obvious. Yeah.
53:06But this is one of the fundamental leadership principles in every top company. At Apple, they call it experts lead experts.
53:14And so this is a way of saying if you're trying to if I'm trying to give advice to somebody who manages engineers, I'm like you better be a good engineer. If you're not, you need to get hands-on and get those skills.
53:28And then just the last because I I love that. But just to end on that last question, which is let's say I am a great engineer.
53:36Should I necessarily be the and my team is growing. Should I let's say I'm the best engineer at the company. Is that the right person to be the engineering manager or not necessarily?
53:46No, it depends. So this is why another common uh really best practice is called dual career ladder. You know, you must have a term for that. So that uh that engineer can continue as an engineer even getting very very high in the US paid as high as a vice president very high or uh become a manager. Uh might be a director of engineering, a VP of engineering, a chief technology officer at the top.
54:15Uh it depends on the person's interests.
54:18Usually if they want to develop others um they absolutely go into management. If they want to have more impact than what they can do themselves they go into it. Uh you don't want somebody to go into it for the wrong reason like because they think they have to to get more money or which happens all the time.
54:37It happens. Another thing that happens not not so much in the US but in other countries um cultural family reasons they they measure your success by how many people work for you.
54:50In Brazil that happens all the time. If you're director you're great. If you're not so and that's like why we don't care how many people work for you. We're like tell us your impact you know tell us like what are you doing? So it's not uh this is you know it's a cultural thing but that would not be a great reason just to get more people build an empire.
55:11Uh so we want it to be for the right reason but when those people do choose to become a manager I coach a lot of those people on that transition and the first and most important thing is for them to understand their people are now their product.
55:28Nice people. I would love to end. Let's end on that which is for people managers, people are their product and you need to hone their skills. That's a great takeaway to end. Marty, thank you so so so much for the time and conversation here. Super insightful for me and for everyone that's going to listen. So really really appreciate it.
55:46Thanks Pedro. I appreciate the invitation.
