Why research is what lets you move faster
Yuriy: Hello, Laura. Thanks for joining us.
Laura: Oh, thanks so much for having me.
Yuriy: Your book is one of the first few books I read about design and product development, so I'm super excited to have you here. For people who don't know Laura, she did almost everything in product development, from engineering, design and management standpoints. And this is an awesome time to have you here, because we hear so many changes are coming to our industry, and I think we can compare our notes, because we are researching something about what's happening now in the market. And you have your own podcast about what's happening with hiring.
Laura: Yeah, although I'm not doing the podcast anymore. I turned it over to my co-host Amy since I took the job at Nielsen Norman Group, and I'm doing a lot of teaching these days. So that's plenty of getting out in front of the public for me.
Yuriy: I think it's even better for us, because you have connections with all the industry. You understand what struggles people have, and maybe you have some ideas about what people should do to stay relevant in the industry and to change themselves. And you are a great example, because you started with the lean approach — you should move as fast as possible — and now you moved to research and education, something that requires a lot of analysis before you move fast.
Laura: Yeah. Well, so the funny thing is that I actually started in research well before the lean stuff. I started in research back in the 80s, and then did engineering as you mentioned, and then design. And lean didn't happen until — I mean, I was at the original Lean Startup starting in, I think, 2007 or 2008. So that's when I kind of sped things up.
So I've gone back and forth, and I think it's still useful to go as fast as is safe, and I've always kind of felt that way. I've never been a huge fan of the move fast and break important things, you know. You can break a few things, but I've always felt like research was actually what let you go faster. I know everybody thinks research slows stuff down. I have never been on that train. I think research helps you get to the right stuff faster, which in the end is what we're all trying to do. We're not trying to run real fast in the wrong direction.
"Nobody knows what they want" is a thirty-year-old excuse
Yuriy: Yeah, but you know, I listened to some old man when he was asked how to build successful products. Now, we can have different opinions about whether you should trust him or not, but he said you move fast, because nobody knows what they want, what's possible. And in this type of innovation, when you have a technology push, you just experiment more. So this is the time for people who want to move faster again — because we had this kind of situation on the market when all the easy ideas were explored, in design, in products, and then you had to focus more on testing, improving a few percent. And now you should start moving faster again. What do you think about it?
Laura: You know, I've heard it a lot. I think it's fun how every new generation of entrepreneurs thinks that their situation is entirely unique, and nobody has ever run into it, and nobody understands what's going on, and nobody knows what they want. And I've been hearing that for 30 years, and it's never really been true.
People do know what they want. They may not know what technology exactly will help them solve their problems — that's a thing that we do have to figure out on our end. But listening to people and talking to people is still really helpful in understanding what we should be building. They're not going to say, "You need to go out and build X." Well, I mean, they will tell us, and we should take that with a grain of salt. We should just ask, why do you think that's the thing that you want, and build accordingly — because people really do understand their problems. They don't necessarily always understand, like I said, the technical solutions, if the technical solutions are brand new. But that's what makes our jobs interesting.
I think this whole "oh, we just have to experiment and throw things out there and try different things" — again, it's not new. That's not a new thing. People have been using that as an excuse not to talk to people for 30 years. Probably for longer than that, right? Thirty years ago, I was the one going, "Oh, this is all brand new." And it wasn't. I don't think people have changed a lot.
There is no such thing as an AI-native designer
Yuriy: But what about hiring and building management and product teams and design teams? Do you see that something changes already for what kind of people are in demand, and what should people look for? Because from our perspective, there are a lot of portfolios of designers who call themselves AI native, and whatever that means. Even if you look into existing products on the market, there is still just a little close to AI — there are just a few products that people use every day that have some AI in it. We had usability specialists, web designers. Eventually everybody became a product designer because of the marketing.
Laura: Everybody said they were product designers.
Yuriy: Yeah. And now we have a similar situation, like everybody tries to be the first AI-native strategist or designer.
Laura: They're AI native. Were they born two years ago? No. Then they're not AI native.
Look, there are people who are open to AI. There are people who are skeptical of AI. There are people who think it's absolutely terrible. And I can see all of those perspectives are useful and interesting, and I don't necessarily disagree entirely with all of them. I think there's a lot to all of that.
I think generally speaking, hiring people who are problem solvers, people who understand how to solve problems for other human beings, will always be the right answer. Sometimes that involves learning new tools, being open to new tools. Sometimes it involves trying out those new tools and saying, "This doesn't help me personally," ignoring them, or finding the parts of it that work and the parts of it that don't work.
Again, that's always been true, right? Did you have to learn Adobe Photoshop, to go way back, in order to be a great designer? No, you didn't. Although at one point there were lots of people who said if you don't know how to use Photoshop — and there were lots of places where they're like, we are only going to hire people who know Photoshop. And that was not necessary. At one point in the 90s — I'm dating myself — people said you have to know how to design for Flash. You have to know how to make Flash videos in order to be a designer. That's what being a designer is. And for a while, that was somewhat true in parts of the industry. And I think that maybe we have decided that that was also incorrect.
So I don't know. Maybe saying we all have to be all in on AI right now is about as correct as those things were. Or maybe it's totally different. Maybe it is going to wildly change the industry. I don't know. I'm not psychic. I just know what I've seen over and over and over, and this feels real similar.
How to interview for thinking, not taste
Yuriy: I totally agree that problem solver is the number one skill that's required for everything. And even this kind of product mindset, it's still about problem solving. But how do we find these people? Because I see that it's much easier to select people who can show proven designs, portfolios, what they did on successful products — that's super clear. But problem solving, only whiteboarding, I guess. Do you have any specific secret questions or approaches, or you just feel these people?
Laura: So, I don't like vibes-based hiring, because I think it's full of bias. But I will say there's one technique that I have found extremely useful, because I did a bunch of hiring when I was at the director level.
One of the things that I found was really reliable for me was — you know, everybody does the portfolio review, and that basically judges whether or not you can put together a slide deck and talk through something for a half an hour. And it's useful and it's helpful, because you can kind of see what their thinking is. I think personally, for me, a better approach even than the whiteboarding — because I think people are very bad at whiteboard tests, both on the hiring side and on the applicant side — I like to do deep dives into portfolio pieces.
So I will literally — this is a little secret, it's kind of fun — this is for designers specifically, not necessarily for researchers, although you can adjust it for researchers. Ask them to show you a portfolio piece, and then just start nerding out about it with them, in parallel with them. Just ask them, why did you make that particular choice? What was that for? Why this particular data and not this other data? How did this work? What problem were you solving? Who were your users? How did you learn that stuff?
But I'm less interested in their design process, more interested in their thinking process. So if you start asking them things like — not necessarily even why that color, although you can go into that, like if you care deeply about craft, why those visual design choices. If you care more about the sort of flow choices: well, what happens when you click this? How did you decide that? What were the other things that you considered?
Really deep dive into it, and make them explain their thinking on a fairly small thing for half an hour, 45 minutes. And you start to understand — when people really cared about their design decisions, they can explain why they did everything. And sometimes the answer is, well, I was negotiating with the product manager and I lost that fight. And that's a fine thing to know, and I don't actually hold that against the person, because I know that that happens in some organizations. I just want to know: why did you make this particular thing?
And if they can't answer those questions, then either they were just taking orders from somebody else — which happens a lot, and you get a lot of designers who make things that are fine but weren't part of their thinking decision, they were just implementing something for somebody else — or they just didn't think through all of the issues. They were just kind of going on like, "Well, because I thought it was pretty." And it's like, okay, well, great. Then that's maybe not the kind of designer I want, right?
Yuriy: My favorite answer is, "I checked how Apple does it and I did it the same way."
Laura: Yeah. Exactly. And if that's what you're looking for in a designer, now you know that's the right one for you. And if it's not what you're looking for in a designer, you've identified somebody who has, I would say, a better answer to that.
Yuriy: And what about product managers? Is it a bit different approach for their problem solving, or is it universal?
Laura: I think you can do a similar thing with product managers. Although often with product managers, I also like to get into — I would give them some data to actually analyze, maybe on their own, and have them come back with how they would analyze the specific data. Because that is such an important part of product management.
I think coming up with some good examples of that, some good sort of data questions, is very important when you're hiring good product managers. Because so many of them can talk a good game on, "Well, I'm data driven and I'm metrics driven," and then you actually get into it and it's like, oh, you don't understand the math here. You don't actually understand the why. You're looking at, well, this is an A/B test and this branch won. I'm looking for people who say, okay, well, why did this branch win? What was the thinking behind that? Did you actually go out and talk to users, or were you just kind of, again, throwing stuff at the wall and seeing what stuck?
Why taste is not what you should be hiring for
Yuriy: What do you think — do product managers need to have good taste? Because as a product manager you need to understand when the result of your team, of your product, is good or not. Because a designer can come — I see how junior designers solve the problem: they create five different versions and say, decide which you like more. And then product management has to decide from five options, or maybe return it back for another iteration. When you're senior you bring some data, some understanding why this option is better, but the easiest way is just to create five options and give somebody else the choice. So does it mean that a product manager should also be a person with good taste, to feel what will work?
Laura: Define taste. Is taste what will work? Because I don't think taste is what will work. I think taste is often aesthetic. And I don't care about aesthetics, generally speaking. I mean, I do to a certain extent — it should have the sort of effect on the users that we wanted. And I think aesthetics is often the least important part of design. I'm going to get into so much trouble for saying that. Again, visual design is important, but often what we have nowadays is we have design systems that constrain a lot of that.
So I don't care about somebody's taste. I don't care about somebody's gut feeling. I don't care about whether they think they have product sense or whatever. I care about whether they could look at it and say, "Well, this is the problem I'm trying to solve, and this is the thing that's going to solve the problem the best" — or, "I don't know what's going to solve the problem the best, let's figure out a way to figure that out."
I'm looking for somebody, again, who can solve problems. Not somebody who's like, "I think that's prettier." Because if one thing's slightly prettier than the other one, you're not shipping both of them, and it's probably not going to have that big of a difference on the actual metrics that you care about.
Again, when I did design, I tended to work on very complicated products. So whether something was two pixels or one pixel had much less of an impact on it than: is this the right data that we're showing to people, and are we doing progressive disclosure correctly, and are we personalizing the environment in the correct way to make this the fastest possible experience for the user, and all of these other kind of much harder questions.
You absolutely can stop development
Yuriy: So let me frame it this way, with AI. I already hear from some of our clients and projects that they have product managers who can, over the weekend, create five prototypes of the full application, or like 50% of the application. And they come to the team, to developers: okay, this is my idea. To designers — or designers can come up with a few more ideas. And then you need somehow to decide which option will work. You can't go with all five prototypes to users. Perhaps you can't stop development. You need to make a decision fast.
Laura: You absolutely can stop development. Sorry. No, I disagree. There is always tech debt to be solved. There are always bugs to be fixed.
I think this whole "we have to keep the engineers busy or they're going to, I don't know, go out on a vendor" — whatever. They're perfectly happy to take a little break and fix some of the stuff on the backlog that they haven't gotten to. Or if they're not perfectly happy to, they should be made to anyway, because tech debt will kill you in the end.
This whole idea that we have to get it out tomorrow for literally no good reason is so dumb. You can take the time to test it. You can do some usability testing. You can actually analyze it and figure out, like I said, which of these is more likely to work. And if you really can't figure out is this thing or this thing better — does it matter that much? Flip a goddamn coin. I mean, if they're not wildly different.
I think people get out there and they spend so much time thinking about these little tiny differences, or they spend so much time A/B testing the text or the button color. No. Spend your time on the stuff that matters. Figure out what the important stuff is, and figure out what the problems are, and solve the problems. Sometimes the problems aren't actually even that hard to solve. Sometimes it's go fix a bug.
Why prototyping with AI exposes what teams handwave away
Yuriy: So what's your take when everybody in the team starts prototyping product with AI? Product managers come with ideas like almost functional apps, the mobile team comes with web development prototypes, web developers prototype mobile apps, and you have over the week like 10 different prototypes of what has to be built.
Laura: I mean, I think that's probably a waste of everybody's time if everybody's doing exactly the same job. On the other hand, here's the deal. Again, since the 90s, I have been making functional prototypes for testing purposes. You can usability test and get better user research results from an actual functional prototype, or a real product if you can actually build it. You do get much, much, much better results than you do with some static Figma barely functional Figma prototype that has sort of like — you can click on things and that's it.
I'm very excited actually about more people actually prototyping out their ideas, mostly because when I've seen product managers actually try to make — and hell, some designers try to make — something that works as a whole feature or a whole product, they start running into the edge cases and corner cases that sometimes they conveniently handwave away when they're not trying to do that. They suddenly start to realize why the idea that they had that seemed so simple doesn't actually solve the problem that they're trying to solve.
So I think that's great. I think that there is nothing better for exposing the edge cases, the corner cases, the problems, the maybe misguided logic. I think there's nothing better for doing that than an actual functional prototype that you can click through and kind of go, "Okay, but what happens if the user does this?" And they say, "Oh, that won't work, will it?" No, it won't. Okay, great. Well, let's figure out together as a team what would work instead.
So again, I don't know that everybody should be going off on their own doing separate prototypes, but the idea that we can quickly make prototypes to test out and to play with and to get people using and to watch people use — I think that's great. Like I said, I used to do that, it just took a long time. If we can do it faster, that's better. Now, whether we can do it well is a question. It's very hard to do. It's very hard to make a functional prototype that actually does test out all the different edges and corners of a particular problem. That's a tough thing to do, and I can't wait for product managers to realize that.
Yuriy: But it also requires a new culture, that it's okay for everybody to bring ideas. Not everybody's comfortable that somebody else is doing designs. For example, for a design team, I've seen a lot of designers saying, "No, it's my job to do design. Do your backend logic." But from my own experience, I had on one team a backend developer who brought the brightest ideas to the project, even if he was a backend developer.
Laura: Me too. I mean, I've done all of those jobs, right? So this idea — asking me about whether it's okay for an engineer to bring good ideas to the front end of a product, that's basically what I did as a designer. I was an engineer. At one company I was literally all three: research, design and engineering.
So yeah, everybody can have ideas. Ideas are easy. What's hard is making those ideas work, and making sure that those ideas solve the problem that you think you're solving for the user and for the company. I think a lot of people have a lot of ideas that are just kind of fun or cool, or wouldn't it be neat if we did this. And when you actually dig into the "okay, but does it do the thing? Does it help people? Does it help the company? Is it going to make us money? Is it going to make our customers happy?" — those are much harder questions. And those are things that I think if we can figure those out faster, that's great. I'm excited about it and I want everybody doing it.
I don't necessarily want everybody doing it on their own. I think we do it better when we do it collaboratively and we all are kind of talking through these things and figuring out, you know, what is the point? What is the problem that we're trying to solve? What are we doing? And then folks kind of do the things they do best. They may also find out that they're not as good at it as they think they are. Or they may find out that they're better at it than they think they are. That's great.
I don't think designers have a lock on — they're not the only people who can come up with ideas. Now, if you're just talking about aesthetics, making something pretty or making something consistent or making something visually appealing, yeah, maybe if they're a visual designer they're probably better at it than other people. But again, if you make a prototype of it, you can see pretty quickly who's good at it and who's maybe not so good at it.
Backlogs, ice boxes, and designing around the edges
Yuriy: Yesterday I listened to a speech from somebody from Linear. And they said that even now they can already see that you can go to your backlog for something that was impossible, because usually the backlog is for something that you will never have time to fix.
Laura: I mean, it shouldn't go on your backlog. That's what the ice box is for.
Yuriy: Yeah. I remember from my history, when we put something from design to the backlog it meant maybe next year, and everybody agreed — they didn't say no. So I was not so angry as a designer, but it was there for maybe the next iteration.
Laura: That's an unhealthy product management environment, by the way. You should always be spending 10 to 20% of your time on those backlog things, and things shouldn't make it onto your backlog unless they actually are prioritized and important.
Yuriy: It depends on the complexity and value. There are always some things that shouldn't be fixed.
Laura: That's what the ice box is for.
Yuriy: They are nice to be fixed. And I know that you have strong opinions about edge cases, and also handling all the different stuff. When I was starting my career as a designer, one of the biggest usability issues in the product I found was bad error messaging — you couldn't understand what's happening, what should I do. So I came to the developers the next day with a long list and a plan for how we are going to solve every possible edge case, to help people recover from the errors. And they said that the development will take twice as much if you do it. We had developed this app for like a year, and if you want us to do all this kind of edge case handling it will take two more years. So, almost impossible. And yeah, that was my lesson. But I thought, if I could influence this somehow I would try to work on that, because this is the main problem of the product.
Laura: This is actually an interesting thing that I've run into at a couple of companies. Sometimes engineers say things like that just because they don't want to do it. Sometimes I have actually worked at companies where we have looked at what the biggest problems that our users faced were, and it was things like instability of the app — like it just crashes all the time, and it is driving people away, and it is getting in the way of our making money, and it is getting in the way of our customer happiness. And people were like, okay, but it would be really hard to fix that. And so we were told, no, you have to work on the other problems, the smaller problems.
But what I always called that is sort of designing around the edges of the actual problem. So we kept shipping things that were like, well, what about this feature? Would this feature be good enough for you to deal with the fact that the app is basically a buggy, crashy piece of crap? And the answer was no, unsurprisingly. People kept saying, just fix the problem.
And sometimes the problem is really hard to fix. And sometimes you just got to do it anyway, because you can design around the edges all you want and you're never going to get more than, you know, a one or two percent bump in your metrics, because you're just driving people away with the big problem.
And I get very tired of seeing these apps that get consistently patched, and it just becomes like this patchwork quilt of — this was obviously broken so we put in this little patch over here, or we released a bunch of new features but we didn't fix the old ones. Like, no. Come on. Just make a good thing that solves a problem, or does something that people really like, and fix the hard stuff. Sometimes that's the right answer. Now, sometimes it will kill your company if you have to completely rewrite it from scratch. But my argument would be, why did you let it get that bad in the first place?
Who you are designing for is a financial decision
Yuriy: Not far from edge cases are edge personas, or personalization of the software. This is a tricky part, because on the one point you don't want to over-complicate the software. It should be unified, simple, focused on major use cases, because if you try to build mega, it's really challenging.
Laura: Most people don't want that.
Yuriy: Yeah. Another thing they say is that in future, thanks to generative AI, we will be able to build features for every specific user type. Like you have five people with this specific need. Coding is not the limit anymore. You can build whatever you want, just let us know.
Laura: People say a lot of stupid things.
Yuriy: So what are your thoughts — how complex and personalized should the app be, especially if it's a B2B app or a B2C app? Do we need to focus on all possible personas that we have, or say, sorry, you are persona number three, use it this way, as our major dominant persona for whom we build this?
Laura: So it depends on how you're defining persona, right? Sometimes the personas are things like, well, you have the actual user, you have the admin — you have the actual sort of functional roles. And yeah, you actually have to design for all of those things, because if you don't have somebody who's an admin who can manage everything, especially in a B2B tool, then the actual customer experience is impossible. So you do have to design all those, but you can keep those separate, right? You don't have to show everything to everybody.
All I can say is you should know who the hell you're designing for, and you should know why you're designing for that person. If there really are three people out there who have this problem that you're trying to solve, and you're spending a lot of time designing for those three people — I don't know, they better be spending a lot of money with you. They better be billion-dollar accounts, because if they're three people who have $20 a month subscriptions, maybe that's not that important. But at that point it's a financial decision, and that's really where product management should be very clear that these are the people we're solving for, these are not the people that we're solving for.
With the exception, of course, of things like accessibility, where we just have to solve for that. Those are not a persona, those are a legally mandated thing that we need to actually design for and care about. So make sure that the product is accessible to anybody who wants to use it. But the types of people who are using it — if you've got one person out there who's like, "No, I want to use it to do this entirely different thing" — cool, but I'm not going to build it specifically for you. It's got to be actually a group of people who I can sell it to, and who are a large enough segment of the population to matter to me financially.
Finding adjacent markets
Yuriy: From what I see in real projects, usually it's: we have already people who are paying and they're paying well, but we want this larger market. So how do we build? We are not building a product only for these people who are already paying. Do you go to build another product for another market, or do we try to build on top of what you already have? And do you have a framework for decisions?
Laura: Yeah. I mean, you can either find adjacent markets. So people who have similar problems but are in a different area, right? Or people who have a similar issue but a slightly different take on it.
Let's say you're making a recruiting product — just because I know a lot about recruiting, because I've worked on a bunch of recruiting. So let's say you're working on recruiting and you're recruiting for engineers, and you say, okay, well, we've got this product that is fantastic for finding exactly the right kind of engineering. All right, well, we want to expand the market to people who are recruiting different kinds of people. Well, what are sort of similar types of problems? Are the people who are recruiting for servers in restaurants going to have similar problems to the people who are recruiting for engineering? Probably not, actually. Are the people who are recruiting for designers, technical designers, going to have similar problems to the people who are recruiting for engineers? Probably closer, right?
And maybe there's an even bigger market. Maybe there's people who are recruiting for — one of the things that I've seen a lot: oh, we're recruiting for things like nurses. Nurses have a lot of certifications, and you have to know about that sort of thing. You're asking for very specific education and certifications and those kinds of things. What's that similar to? Oh, that's similar to specific types of manufacturing. So you find these adjacent markets that work sort of similarly to the market that you are currently serving.
Now, at some point companies get so big that they are kind of like, we serve everybody. And that's where I think products tend to get a little over-complicated, and they tend to fall back on a lot of, well, you can configure it however you want. And I think a lot of that software sucks, quite frankly, but it makes a lot of money. Everybody ends up falling back on the "oh, it's totally configurable and you can set it up however you want" — and yeah, that's why a lot of the B2B stuff that you use in your company that you're forced to use is absolutely terrible.
Yuriy: And now you have messages on Twitter: I don't want to work with your crappy tool, or I will vibe code my tool myself. Nobody wants to serve me as a small business. Everybody wants to serve companies with at least hundreds of employees, and then you have all the CRMs focused on the larger corporations.
Laura: Yeah. And then somebody new comes along and they're like, no, we're perfect for this very small group. And that's great until they grow, and then they turn into the other ones.
Yuriy: And then the cycle begins anew.
Product management isn't a job
Yuriy: What about changes in product management? How would you see the future in the next few years? Do you see managers doing more research and ideation, or will backlog management still be the largest part of their work?
Laura: Here's the weird thing about product management. People always ask me about the job of product management, and having done it and worked with a bunch of them — I don't think there's a job. I'm going to say something that's going to piss a lot of people off. I don't think it's a job. I think it's a bunch of different jobs wildly dependent on where you are.
I think there will be companies where product managers just manage backlogs and are kind of just the scrum product owner type things. I think there will be companies, just like there are now, where they do a lot of their own research, or where they work closely with research teams and they really understand their users. And I think there will be places where the product management job is entirely — I have seen this — entirely selling ideas up the chain to the CEO, and it's all just CEO-based product management. Boy, that doesn't work well. Or it's just people getting features out that the investors demand. So I have seen product management be literally all of those jobs.
I have also seen the product manager who is more the sort of Steve Jobsian idea of it, where they know everything about the product and they control everything about the product and they're saying yes, no, this, that, not that, you can't ship that. And they're very micromanage-y, sometimes in a good way, sometimes in a bad way. Again, those are all product management jobs.
What's it going to be in the future? The same, right? In that it'll depend on where you are and what kind of product you're building and what the organization is like. I don't see humans changing that much. Will they use more AI to shortcut some of the stuff that they don't like doing, or to make themselves look better, or to do stuff faster? Yeah, absolutely. Will that be good for products? We'll see. Maybe in some cases. I think in some cases it will just make things faster, which I do not think has ever really made things better.
Yuriy: From all the stuff you mentioned, it looks like every organization needs somebody focused on this — managing stakeholders, clients, team, vision. And it's almost impossible to have it in one person, because as you mentioned, that's different jobs.
Laura: Yeah, well, it is. And there's even different skills depending on the size of the company and the type of the product, right? A product manager at a CPG, a consumer packaged goods company, does something entirely different than a product manager at a B2B startup, which does something completely different than a product manager at, I don't know, some place like Apple. And even within some place like Apple, a product manager on one team working on, I don't know, music or whatever, is going to do an entirely different job than a person working on all of the backend systems that they have, or platform stuff. They're just different jobs and they need different skills.
Strategy is not "more AI"
Yuriy: What about the ideal product team? From our experience, we have clients that say we need two designers, that's all, and we have clients that say we have 35 designers and we need much more. And the complexity of the projects is pretty similar — the number of screens, the number of features. In an ideal world, which I know doesn't exist, we hear that sometimes people always want to hire more and more people because of the quantity metrics. And sometimes it makes sense to have actually more researchers, more people running experiments. So is there any sweet spot — how to understand if you have too large a team and you should shrink it, or you need to grow?
Laura: I mean, I think that again it all comes down to what problem are you trying to solve, right? If you're trying to solve the problem of — which often happens — I have promoted a whole bunch of people to senior director level and they all have to build their own little empires. That's maybe not the best way to actually get things done, right? Like, one of the things that we see is companies grow until they're so big and they're so complex that they just can't get anything done. And that's obviously a problem.
So you need as many designers and as many researchers and as many whatevers as you need in order to solve the problems that you are trying to solve. And you maybe need to have fewer problems to solve. I mean, you shouldn't be trying to do a thousand different things at once all across the board. I hate to be all "it depends", but there's no — I can't say like five, or a two-pizza team. There's no kind of easy answer there.
I will say that when you get all of these different teams that are all interdependent on one another, you do need a lot more of those glue roles that make things stick together and that make sure that things are happening across the board. And it's going to slow things down. You're going to get slower. But you may get more done. So, just slower. You may be able to work on more projects at once, which may be good for your company or maybe bad for your company. I don't know. You have to understand what you're trying to do.
And I think so many companies are so bad at strategy. They're like, strategy is more AI, throw AI everything. And I'm like, okay, that's not strategy. That's desperation. That's buying the hype, right?
The strategy is: these are the kind of customers that we want to make happy, and that we want to make happy to pay us for the service or product. This is the thing we're trying to do for these people to solve their problems. That's a strategy. How do we do that? We do it by whatever the answer to that is. And for that, we need X number of people.
Are you going to be right all the time? No. You're going to be right some of the time. You'll be right more of the time than if you're just kind of like more AI, or more blockchain, or more whatever the hell it is that they're talking about. Quantum computing is next, by the way — I'm calling it.
Visionary leader versus empowered team is a false dichotomy
Yuriy: What are your thoughts on product leadership and design leadership? Here we also have two options. You need to delegate everything to the team, the smartest people, and say, brainstorm together ideas and build a successful product. And other people say it never worked for large successful companies — you usually have one designer or one CEO or product manager, somebody who has a nice vision and is translating this vision to everybody, aligning everybody on the solution, and that's how you have a great product. Because if you have design by committee, almost always you will have an average product that will try to satisfy 30 points of view, and usually it doesn't work very well.
Laura: So, okay, I think that's a false dichotomy. Hiring a bunch of smart people and having them do smart things does not necessarily end up with design by committee. Hiring a bunch of committee members and putting them together and saying figure out your own problems can end up that way. But I think that the job of the person at the top, or the people at the top, is making sure that that doesn't happen.
Now, does that mean that they have to make every single decision themselves? No, absolutely not. And I think that the places where they say that that does happen — I mean, even with Steve Jobs, Steve Jobs didn't make every single decision. He just killed a lot of products. I mean, he did a lot of other things. He was a kind of a special sort of case that doesn't always work, and didn't always work with him. That's the thing — we only hear about the successes in those.
So the job of that person at the top is figuring out, okay, how do I get everybody kind of pointed in the right direction and working on the right thing, so that it isn't design by committee? I don't need to make every single decision, but I do need to make sure that it's not turning into this kind of mid product that just is a big muddle.
So how do you do that? It's hard. It's hard, and it's harder on certain kinds of products than others. Especially, like I said, a lot of companies end up building a lot of different products and kind of mashing them together into one interface. And once you have that, it's almost impossible to design your way out of it anyway. So I mean, I think the answer is don't get yourself into that situation. Go back in time.
So here's what you need. You need a time machine, and you need to understand all the things that you're going to do to your product that's going to make it worse. And then you need to go back in time. You need to tell earlier you not to do those stupid things.
Yuriy: Sounds easy.
Laura: Yeah. See, it's trivial. I mean, come on, it's no harder than actually building a B2B product.
Hypothesis tracking: how to get better at anything
Yuriy: I've seen that over the last five years, especially before COVID, lots of designers and managers jumped into the industry. We have now a million more designers with just a few years of experience. We have lots of product managers, and I've heard statistics that on average they have around three years of experience in a product management position. So there are a lot of things to learn. What do you recommend to people who ask you about this kind of advice — what would make them great design managers, leaders, people who make an impact in the industry, and not just doing something that does not provide value and maybe can be replaced by technology?
Laura: So, wait — is the question how do these new folks become good design leaders and senior people?
Yuriy: Designers and leaders better than the previous generation of managers, leaders and designers. Because we had very fast industry growth, like 30% a year, and when you have this kind of fast growth lots of people are coming from boot camps or switching from different careers. From what I see in interviews, there are a lot of people who think they're already senior designers because they have five, six years of experience, and their previous company told them that they're senior, but they've actually read five books at max, might be one. They have just some practical experience, and that's good. And sometimes people with three years of experience can be stronger designers than people with like 10 years of experience.
Laura: It's not the years, it's the —
Yuriy: Yeah. Sometimes the more experience you have, the worse a designer or manager you are, because you just learned how to cut corners. But what's your advice for people who understand that they're still a bit — they feel imposter syndrome, and they understand that they jumped quickly to the project, they started doing something, but now it's time to become real creators?
Laura: I mean, everybody's a real creator. But I think that if you have imposter syndrome, that's actually probably a good sign. It's a good sign that you know that you still have more to learn. And we all have more to learn. I'm learning stuff now and getting better at certain things, and frankly getting worse at other things.
So here's — I'm going to give you kind of weird, unorthodox advice, and this is how to get better at anything. When you need to make a big decision about anything — about a design, about a feature, about what you're going to be doing, I don't know what you're going to eat for lunch, I don't care — whenever you need to make a big decision, write it down ahead of time. Say, this is the decision that I'm making. This is why I'm making it. Make it very intentionally. This is my expectation of what's going to happen, and this is how I'm going to test to see if that actually happened. And then go back when you're done, do a postmortem. Did what I expect to happen, happen?
I think so many people skip this step. I call it hypothesis tracking. You can call it whatever the hell you want, but it is: form a hypothesis, test it, see what worked.
And you know you're getting better when you are forming hypotheses, and the things that you are creating or designing or building — whether you're a product manager, or if you're an engineer, the things that you build — what did you expect to happen? Did you expect for that bug to be fixed? Did you expect for revenue to go up by X? Did you expect for users to be more engaged? What was the actual goal? So just by setting that goal for your project is going to make you better at the thing that you're doing anyway. And then going back and saying, was I right? Was I wrong?
If you were wrong, here's the deal: you have written down why you believed what you believed. Great. I was wrong. Don't trust that data source anymore, or figure out what was wrong with it. I believed this would happen because of my gut, or my product sense, or vibes or whatever. Oh, it didn't work out the way I expected. Cool. Maybe your gut or your product sense or your vibes are bad, or maybe they were bad in that case. What gave you that belief? Figure that out. Figure out why you were wrong and try not to be wrong in the same way the next time. You can be wrong in different ways. That's fine.
I just get tired of people who make the same decisions based on the same data over and over and over, and they're just wrong over and over and over. And I see this with product management constantly, where they're like, "No, no, this is the new thing. This is the feature that's going to save the company. This is the thing. It's going to increase usage by 100%" — every time. And they never do that self-reflection of, wait, last time? Huh. No. Wait, did it work two times ago? No, didn't work then. Make the decision differently next time. Come on, try something new. Maybe it works worse. Who knows? But it's probably not going to work better just doing the same thing over and over. Anyway, that's how you get better at stuff.
Yuriy: Or ask more people for advice.
Laura: Or ask different people for advice. If you're always getting advice from the same damn people and they're constantly wrong, I don't know. Maybe listen to someone else.
What Laura is teaching now
Yuriy: So after so many years of experience, Laura, how do you tell people what you do?
Laura: I try not to. At this point, I just say I'm in tech. I'm in tech, you know. And nowadays, actually, I do a very specific thing. I work at Nielsen Norman Group and I teach classes in how to do this stuff. And so I'm an instructor. I'm an instructor. I'm a writer. I help make new designers and researchers.
Yuriy: After returning to education, can we hope that you will write a new book?
Laura: Absolutely not. Under no circumstances will there be another book written — but thank you. There are two and they are fine. And I mean, they're a little out of date at this point, they've been around for a while. But I don't necessarily know that for me books are the right way to get that information out into the world anymore.
Yuriy: Okay, thank you. Maybe you have something to share with our audience. Maybe some advice, something to plug.
Laura: Yeah, I mean, keep an eye out. If you follow me on LinkedIn, I occasionally announce classes that I'm teaching. I'm currently teaching a class on using AI for research — how to do it, and more importantly, how not to do it, what works and what very much does not work. So it's a sort of a realistic class about how to use it right now. And I will also be teaching in the fall a class on making product and UX work better together.
About Laura Klein
Laura Klein is Principal Experience Specialist at Nielsen Norman Group, where she teaches classes on research and product work. She began in research in the 1980s, then worked in engineering, design and management, and was at the original Lean Startup in 2007 or 2008.
She is the author of two books for product managers, designers and entrepreneurs: UX for Lean Startups (O'Reilly Media, 2013) and Build Better Products (Rosenfeld Media, 2016). She previously co-hosted a podcast, which she handed over to her co-host Amy when she joined Nielsen Norman Group. She announces her classes on LinkedIn.
