Design Thinking for Agile Product Teams

Laura Klein is the author of “Build Better Products” and “UX for Lean Startups.” Laura has more than 20 years of tech experience and vast expertise in Product Management, User Experience Design. In this podcast she talked about the vital role UX design plays in modern Product Management.

“What inspired you to write Build Better Products?”

I’ve been in tech for 8,000 years and I started out sort of doing very, very early research,  and then pivoted to becoming a front-end engineer, and have since worked in UX design and product. And so I have kind of done all the things.  My friend, Dan, calls me a triple threat. I think that’s just because he finds me a little threatening, but I kind of bounced back and forth between UX and product a lot. I very much enjoy talking about product management to UX designers and about UX design to product managers, because I feel like we could all work better together.

I would love to see more designers turn into PMs. Especially the designers who have that sort of holistic user-centered thinking. I think that it helps in very specific types of products. The funny thing is, I started back in the nineties and all the product managers came out of either engineering or marketing back then, depending on the kind of product management. And I think that the reason that was true was because it sort of evolved from there, right? A lot of the products were extremely technical and extremely difficult to understand and you had to have a product manager who understood all of the technology. So engineers were a great source of that. I do that some of my favorite project managers have been ex-engineers.

“So what would you say are the main highlights of your book for people who haven’t read it yet?”

Well it’s delightful. It’s quite fun. It’s 400 pages long, so it’s a good value.  It came out of a lot of workshops and activities that I did with teams and clients that happened because I had written the first book. So what happened was I wrote UX for Lean Startups back in 2013. After that I spent several years going around and doing coaching and training and working directly with teams and doing actual hands-on work. I found that I was leading a bunch of workshops and helping folks. And I found that I was drawing a lot of the same pictures on the whiteboard. I found that I was doing a lot of the same activities over and over because a lot of people had really similar challenges that they were facing.

And so Build Better Products came from working with those teams to try to get more specific and teach teams how to use some of the concepts in, in UX, brilliant startups. So it’s very much a workbook, which is not typical.There are lots of activities in it that you’re supposed to use and adapt and change. And hopefully tell me about when you change, I love it when people do that. They’ll be like, oh yeah, we use this activity, but you know, we change these three things. I’m like, that’s fantastic. That’s exactly how you’re supposed to use it.

So it is very much a hands on, oh, you want to do this thing. You want to learn more about what metrics you should pay attention to, or you want to validate an idea or invalidate an idea, or you want to get better at making product decisions or whatever. Here’s an activity that you can try as a team to do this.

So what is the role that UX or design teams should play in? I would call like modern product manager, because back in the day, one of the things that I saw is that design used to come at the end, like a business people saying what’s going to happen. And then poor engineers and designers, like trying to make it happen. Right. But it’s almost like they received instructions, like what what’s going on now.

“What is the role that UX or design teams should play in modern product management? Because back in the day, design used to come in at the end.”

Yeah. That was supposed to be the way it worked. I 100% agree with you that that is the way that people did it. I would quibble with the description of it working that way. Cause I don’t think it worked particularly well even back then. So it also depends on whether you consider user research to be part of user experience design. I do. I think that there are specific skills and talents and roles, but I very much think that UX includes understanding your user… research and synthesis and ideation and all of that stuff.  So I am very much of the feeling that we should all be involved in making the decisions about what our team is working on together. Now that doesn’t mean absolutely everybody together doing absolutely everything all the time.

You don’t have to have a team of 15 going out to do all of your user research together. We’re not joined at the hip. But it does mean that everybody needs to be involved in the user research. You might have a specialist who is facilitating that, but everybody needs to be involved with deciding which features meet our business goals and our user’s goals the best.

You might have a designer who is facilitating that session. A lot of times designers also get into the details and the weeds of like, this is how it’s actually going to work. And this is how it’s actually going to look and this is the experience that the user is going to have. And I think that’s fantastic. I think that we should do that. I just don’t think that that’s at the end.

Having [design] at the end is very much a, here, we made a thing, go make it pretty sprinkle some UX on it as we like to say. A lot of times it’s just kind of like, well, you have designed something that does not meet a user need, and also is completely unusable even for the thing that you want people to do, which they don’t want to do. So it is too late for me as a user experience designer. You are past help. And had you brought me on when you were saying, oh, this is a metric that we need to move within the company. And these are some of the user problems that we think exist, then I can help you craft an idea. I can help you craft a solution for the problem. I can help you figure out what user behaviors you want to encourage and discourage. I can help you think about things holistically, and then I could help you figure out the details of the design and exactly how it’s going to work.

And you know, that all of that stuff, that’s all designed, it’s all also product management. It’s just that the work is too much for one person. So I often feel like really good teams kind of split up all the things that need to be done based on who’s good at what. I don’t care that much about job titles. I’m not gonna say, oh, you’re an engineer. So you’re not allowed to do research. Well, that’s nonsense if you’re great at it and you really want to do it and yes, you should absolutely be involved.

“How would you recommend smaller teams, who can’t afford to hire an official UX researcher, could start conducting UX research?”

Get good at understanding things from users. I very much like working with external researchers when you can get them. I don’t like the idea of hiring somebody to learn all about my product and then letting them go away, that is not appropriate. So if you bring in an external user researcher, which I think can be extremely useful because they have a lot of specialized knowledge about how to get the questions answered, that you want to get answered. Have them guide the research, have them facilitate the research, but make sure that you are involved every step of the way, and that you are understanding all of the things that they are hearing. This is not a thing that you can pay somebody to go do for you per se.

I mean, you can, you absolutely can. There are people who charge you a lot of money to do that. And if that’s the best you got, that’s the best you got. But I think most user researchers that I know would much rather you be involved personally,  and the whole team is involved personally in the whole process. So that it’s basically like having somebody on your team. I also very much liked the idea of continuous discovery, which is the thing that Teresa Torres teaches a lot about, which is baking into your daily or weekly process, some interaction with users. Make sure you’re talking to users, make sure that you’re listening to different users. Make sure that that is just an automated part of your process, where this is just a weekly thing where you’re getting some feedback. Doing that, I don’t think gets rid of the need to occasionally run bigger, more targeted research to do something very specific, to do some ethnography, to really deeply understand your users, or even to do some very specific usability testing or experimentation. There are all kinds of research that needs to get done.

If you can’t bring somebody on, who’s a specialist full time, you can hire a coach, you can hire a trainer, you can get real good at it yourself, but don’t pretend like you can get away with not doing it and still build something good. Cause I think that is the default for people they say, oh, we’re going too fast. We don’t have time for research. Well, I hope you have time to change everything later when you realize how much you got wrong.

“What would you say to full-time PMs who want to learn more about design? Just to have a better eye for design and to better empathize with members on the design team.”

So I always like to say, you should think about designers and the concept of design the way that you think about doctors in some cases.

So stick with me on this, this possibly a tortured metaphor.

If you go to a doctor, you can go to a GP and they kind of help you with your general health. But there are a lot of specialists in medicine, right?  There are very few people who are experts in cardiology and also, I don’t know, feet. And if you have a problem with your heart, you probably don’t want to go to a podiatrist. Right. And vice versa. Like they’re not really interchangeable.  

You can get really, really good at understanding, the thing that you have that you want help with. If you have flat feet, you might know way more about how to fix flat feet than anybody but a specialist in podiatry.

So I don’t think that like product managers should think about, I want to learn design. Design is not a thing. There are no bonus points to learning design. Do you want to learn visual design? And if so, why? Do you want to learn more about user research and how to understand your users better? (Which I highly recommend, you know, learn more about that kind of stuff.) If you want to learn more about user flows and interaction design, learn more about that. If you want to get specific about things like, oh, I’m designing a new search system and I have to learn all about the different types of search and the different types of textonomies for catalogs and faceted search versus filtering versus tagging versus canonical categorization…but learn that if you’re working in machine learning, God help you, but learn more about designing explicitly for that.

Or if you’re doing voice user interfaces, that’s going to be wild! I remember I did a project a million years ago. I did several projects in voice user interface. And let me tell you something, typography is not a part of that. There was no use for any knowledge about typography. When you’re doing voice interfaces, you’re doing a multimodal thing that also has a voice interface.

But anyway, figure out what you’re trying to do and get better at the thing you’re trying to do. Figure out what your problem is and how to solve it. Don’t worry too much about like, oh, I want to be a designer. It’s kind of like saying I want to learn more about engineering. Well, I mean…it’s gonna depend a lot on what the stack is that you’re working on and what the product is that you’re working on and what your engineers are like. There’s no single thing to learn.

“What are some practical things that a non-technical PM could apply to break down barriers and be able to have a conversation with engineers?”

That’s a great question. It’s tricky because I am probably the wrong person to answer that question, I will be perfectly honest, because coming from a somewhat technical background…I was never a great engineer. I was never a super hardcore backend engineer. I was a front-end engineer. But it was also back in like the late nineties, early two thousands. So I kinda had to be a bit of a generalist in a lot of areas. I touched a lot of things, but again, a lot of my data’s kind of out of date. So just being open and talking to people and understanding what they’re talking about. And then when you don’t understand something saying, Hey, do you mind explaining that to me?

Make friends with the engineers, have them help you. A lot of them are perfectly happy to explain things (not all of them, figure out which ones are). Find the friendly ones who don’t bite and offer them some snacks or whatever. And just have the conversation and have them explain things they love in my experience. Many of them love drawing things on the whiteboard that explains the full product architecture. And if you don’t understand that, just keep asking questions and you will eventually understand it.

And you can also take notes about things like, oh, they mentioned X, I should go learn more about X, and try to get sort of an overview of that. One of the great things that exist now that just did not exist in the nineties when I was learning to program, there’s just so much free information out there. All you really need is some pointers to like, oh, it’s this technology. 

“How can you involve an entire agile team into a design thinking process so they can all be part of the problem and the solution?”

It very much depends on what your definition of agile is. If your definition of agile is like mine, a cross-functional collaborative semi-autonomous team that is judged based on outcomes rather than outputs, then it’s really easy. Like it just happens.

The trick is that you need to have specific goals and metrics that you are given as a team, and that you have to have some flexibility among the team to do things like experiment and find the best way forward to do the thing that you want to do. You need to actually incorporate good user understanding and user research techniques. You also need to be able to work at multiple levels. This is a really hard thing for a lot of designers and PMs.

I have found you need to be able to sort of say, okay, well, this is the vision. This is the overall thing. Like we’ve validated that this is a thing that we really need, we need to build this feature.  We think based on our understanding that it’s gonna move the needle in this particular direction,  it’s going to be good for users because of this. We understand this, we know this because of the research that we did or whatever. Now we need to move forward and actually do it. And there’s a lot of details and things that need to happen. And you need to be able to slice that up into pieces where you can be continuously delivering value to the user, getting feedback, iterating, figuring out what the smallest possible thing that you can build is, and constantly just improving that. I did a bunch of research on designing for agile teams very recently, and one of the things that made me just absolutely wildly angry was so many people said that they hated designing on agile teams because they never iterated.

That’s kinda the whole thing. Iterating is like 80% of agile. I mean, that’s probably not fair, but it’s one of the core tenets, that you’ve got to get customer feedback and you have to iterate. And that’s the whole point, that you’re getting things in front of customers. You’re getting feedback, you’re coming up with new ideas. You’re seeing what you’re right or wrong about. And so you have to build that into the whole process. None of that is easy. I’m saying it like, oh yeah, you just do all of these things. Each of which is incredibly difficult and possibly doesn’t work at your organization and may require a tremendous amount of effort and learning on your part. That said, if you can do it, it’s a great way to build products.

We’ll be back again next week with even more of the latest insights from the Product Management world. Stay tuned for more!