Speaker Spotlight: Convincing Your Boss to Solve the Right Problems
Written by Jennifer Maerz, contributing editor of Lean Startup Co.
Product guru Laura Klein has the recipe for building things customers want. Her secret sauce is a combination of solving for specific problems, validating assumptions correctly and regularly, and building cohesive teams. The author of UX for Lean Startups and the recently released Build Better Products is an excellent resource for upping your product/market fit game.
Laura is hosting a hands-on 90-minute masterclass during Lean Startup Week focused on a Build Better Products exercise. She’ll lead a deep-dive through 14 key questions in five areas that are important to know about your user to avoid making faulty (and often costly) assumptions.
As a teaser for Laura’s masterclass, we’re offering an edited excerpt from a great webcast we did with her recently, where she connected building great products with the bigger picture of removing blame from failures, building metrics around user behaviors, and how the best teams work like heist films.
Solve for specific problems and remove blame from post-mortems
“We’ve all thought something was going to be great and had it not be great. Remember that you just need to learn the next thing. You don’t want to say, ‘I want to build a thing that does X.’ What you have to say is, ‘I want to solve a problem for a human.’ Once we’ve done that, then there’s no conflict. We keep iterating until we’re solving that problem for that human.
“When we do put something out there that we really thought would work [and it doesn’t], the most important thing is to do a post-mortem. It’s very hard afterwards to go back and say, ‘Well, why the hell did we build that? What were we thinking?’ because everybody will just be like, ‘Oh, that was Joe’s idea. Joe is terrible at this. Oh, Joe pushed for that,’ or, ‘Oh, the CEO wanted it.’
“It’s very easy to distance ourselves from our culpability at shipping terrible things. So write it down ahead of time. I have a thing in my book called the hypothesis tracker, where you have to say ahead of time, ‘This is what I believe. This is why I believe it. This is the date on which I’m going to check to see if I was right,’ and a bunch of other factors that actually talk about the metrics that we’re going to use to track it. And then when when everybody on the team has done that, you can go back and say, ‘Well, this is what we thought. Where did we go wrong? What research didn’t we do, what didn’t we know, and how could we have known that better?’
“I always think about the post-mortems as, ‘How could I have avoided this previously?’ and, ‘How does that translate into avoiding it in the future?’ I don’t necessarily want to avoid that exact same problem. I want to avoid that class of problems. I don’t just want to put out this fire, I want to prevent fires in the future. You can do a ‘5 Whys’ on this. You can say, ‘What organizational or personal thing that happens could have been prevented that caused this mistake?’”
Getting the decision makers to become more hypothesis-driven
“In influencing people who are making decisions that are not turning out well, you have to start tracking ahead of time. When they ask you to do something, you must start asking the question in a very nice, polite, non-threatening way — which, believe me, is the hardest thing I’ve ever had to learn — ’What do we expect that to accomplish? What business goal do we think that’s going to help? Is that the thing that we want to work on right now? Is that the most important thing?’
“Let me give you an example. Manager comes to me and says, ‘We’ve got to build this feature. We’ve got to throw ourselves on it.’ And as a project manager I can say, ‘Great. Let’s go do that,’ and figure out the best possible way to do that. I don’t think that’s smart. We need to ask, ‘Oh, what do you think that’ll accomplish? What user behavior are we trying to change, and what is that going to do for the company? Do we think that’s going to increase engagement? Do we think that’s going to increase revenue somehow? Do we think that’s going to convert more free trial users to paid users? Does it improve retention? I don’t know. Tell me.’
“You have to do that process of what are we trying to achieve here, and is this the right way to do it, and how will we know if we’re successful? And then you need to write it down. If they keep doing it to you in the future, sometimes you need to go to them and say, ‘Okay, well, this is what we thought before and we were wrong. So how do we fix that going forward because you’re doing the same thing?’
“You’re teaching them to be hypothesis-driven. You’re teaching them not to be feature and output-driven. You’re modeling good behavior. Figure out what’s important to them. As designers and product managers, we need to think about our users. Often, our users are the people who use our product, but sometimes, our users are the people who use our deliverables or the people who are our teammates.
“I make deliverables all the time that I share with my engineers. I write user stories and I make designs and I do all of these things. I make presentations to executives. Those are all also my users and my customers. Understanding what matters to them is so important because you’re not going to change their opinion just by saying, ‘Well, Eric Ries said.’ You need to understand what matters to them and what gets them promoted and what makes them look good and make them more of that.”
Model your team after a heist movie
“The last chapter of my book is all about building this heist team. Many companies are in silos where you’ve got all of your designers and all of your researchers, and they’re all separate. Some of them are in separate buildings. But you don’t want to rob a bank with 17 safe crackers and nobody to drive the getaway car. You’re going to be arrested. So what I think of is, what are the specialties, what are the roles that need to happen on this team? Who do I need to be an expert in something? And people can be experts in multiple things, or they can be an expert in something and kind of good at something else, but you have to think about that. It’s going to vary from team to team.
“Some companies are going to need industrial designers. Sometimes you are going to need a data scientist. Sometimes you might need a database person. Great, figure that out. And here’s the thing, don’t leave out the business stuff and the legal stuff and the finance stuff. Maybe you need somebody to help you figure out what the regulations are in India because that’s where your product’s going to be and you need somebody to help you navigate that. Make sure they’re part of the team early and that you don’t build something and then talk to somebody who knows a lot about India and have them go, ‘Well, that’s great except that it’s entirely illegal here.’
“Make sure you’re incorporating all the important roles early. Not all of them are going to be on the team 100% of the time. You don’t need to pay your lawyer to sit with you 40 hours a week. But you do need to make sure that everybody who is involved and everybody who is a stakeholder is constantly updated and involved and helping to make the critical decisions.
“You really want people working together, and you want it to be about what is the whole team goal. It’s not about one person coming in and being the hero. You build that trust over time by working with people on a day-to-day basis. That’s why I think these balanced teams are so important, as opposed to just, ‘Oh, we’re going to ship in a UX designer from somewhere else and they’re just going to sprinkle some UX on it.’ They won’t really understand what the goals are. They’re just taking what you’ve told them. They’re not contributing as much as they could.
“All of these people that we’re working with, when we ignore them or when we say, ‘Oh, their ideas aren’t important because they’re just an engineer,’ or, ‘They’re just a QA person,’ or, ‘Oh, we just need to work around legal,’ when we do that, we’re not taking advantage of how smart, and how wonderful, and how talented they all are.
Hear more from Laura and take masterclasses with other Lean Startup rock stars at Lean Startup Week Oct. 31-Nov. 6 in San Francisco.