New book: Donna Lichaw’s The User’s Journey

It’s book launch day here at Rosenfeld Media HQ! And somehow, we’ve reached the quarter-century mark: The User’s Journey: Storymapping Products That People Love is our 25th title.

Other fields, like filmmaking, have long understood the importance of narrative structure. In The User’s Journey, Donna Lichaw brings that same line of thinking to UX, and demonstrates how storymapping really can help us design and test just about anything—from landing pages to product strategies.

This last point is no exaggeration. For example, we were carefully following Donna’s advice when we developed last year’s Enterprise UX conference program. Thinking about story arc helped us make sure attendees had energy left over for the conference’s reception after an intense day of presentations.

So, while I’m biased, I really do think you’ll benefit from reading The User’s Journey, regardless of what you’re designing. And, at 160 pages, the book is short and sweet.

Enjoy!

Get your boss on board and come to Enterprise UX 2016

Hoping to attend Enterprise UX 2016? Need a little help convincing the powers that be? Here’s our contribution to the growing genre of “convince your boss” lit. But if you have additional questions or need more help, just let us know.

Reason #1: You’ll get better at designing and researching in and for large organizations

• Enterprise UX 2016 is built around four curated themes that magnify the conversation we’ve all been having in dribs and drabs: how to create better, more humane enterprise experiences
• Our main conference program mixes a wide array of session types—two keynotes, twelve presentations, five workshops, four challenge sprints, and eight raucous short-storytelling sessions
• Our advanced workshops are taught by acclaimed experts, and range far beyond design and research basics
• Our speakers are amazing, ranging from design leaders at Honeywell, GE, Salesforce, IBM, and Intuit—to authors of the field’s most influential books, likeRise of the DEO, Service Design, and The Connected Company
• We’re driving our speakers crazy by making them work—together—on their presentations months in advance

Reason #2: You’ll be learning from true innovators

• Our speakers are amazing, ranging from design leaders at Honeywell, GE, Salesforce, IBM, and Intuit—to authors of the field’s most influential books, like Rise of the DEO, Service Design, and The Connected Company
• We’re driving our speakers crazy by making them work—together—on their presentations months in advance

Reason #3: You’ll make important connections

• A healthy mix of industries send their people; in 2015, large groups from Apple, Capital Group, Dell, Frost Bank, Google, Intuit, Qualcomm, Rackspace, and Salesforce attended
• A healthy mix of industries send their people; in 2015, large groups from Apple, Capital Group, Dell, Frost Bank, Google, Intuit, Qualcomm, Rackspace, and Salesforce attended
• About 60% of attendees hold mid- and senior-level positions—a uniquely high proportion for a UX conference
• There will be no shortage of opportunities to mingle at the conference and reception

…and Reason #4: 15% off with this code!

Register with code 4REASONS by June 1 and you’ll get 15% off your pass. If you do, here’s an estimate of what the Enterprise UX 2016 will cost in US Dollars:

• $1,186 ($1,356 after March 14): Two-day main program at 15% off (June 8-9)
• $506 ($591 after March 14): Optional one-day workshop at 15% off (June 10)
• $697: Three nights at Westin Riverwalk (at $199 for a city view + 16.75% tax);reserve by May 17 for discounted rate)
• $100: Estimated meals and incidentals (we’re providing most meals)
• $400: Estimated RT airfare from San Francisco or New York
• $50: Estimated taxi to and from airport (we’re providing shuttles between the Westin and the conference center)
• $2,939 ($3,194 after March 14): Estimated total for attending Enterprise UX 2016, including one workshop
• The first Enterprise UX conference was a fantastic success—and we’re looking to top it in 2016. We hope you’ll be a part of it!

Want to share this with your boss in print? Here’s a PDF.

If you or your boss never needed these reasons, why not register now?

Whose Job is User Research? An Interview with Steve Portigal

Those of us who conduct user research as part of our jobs have made pretty big gains in recent years. I watched my first usability test in 1995 then spent a good portion of the 2000s trying to convince people that talking to users was an important part of designing and building great products. These days, when I talk to companies, the questions are less about why they should do user research and more about how they can do it better. Believe me, this feels like enormous progress.

Unfortunately, you still don’t see much agreement about who owns user research within companies. Whose job is it to make sure it happens? Who incorporates the findings into designs? Who makes sure that research isn’t just ignored? And what happens when you don’t have a qualified researcher available? These are tough questions, and many companies are still grappling with them.

So, I decided to talk to some people who have been dealing with these questions for a living. For this installment of the Whose Job is User Research blog series, I spoke with Steve Portigal, Principal at Portigal Consulting. He’s the author of Interviewing Users, which is a book you should read if you ever do any research on your own.

You still don’t see much agreement about who owns user research within companies.

Steve has spent many years working with clients at large and small companies to conduct user research of all types. He also spends a lot of his time helping product teams get better at conducting their own research. Because he’s a consultant, he sees how a large number of companies structure their research processes, so I asked him to give me some advice.

What Does It Mean to Own User Research?

“There are two aspects to ownership,” Steve says. “One is about owning the need. The other is about owning the actions where we build on what was learned in research. It doesn’t seem like there’s any perfect model for how research ownership works.”

As Steve points out, the concept of owning research is much more complicated than a single ownership model can describe. At a minimum, somebody needs to determine which business questions should be answered. Somebody needs to figure out how to get those questions answered. Somebody needs to figure out what to do with the results of the research. It’s not often the same somebody.

In fact, the different people involved in the research frequently are not even from the same department. Company org structures vary widely: researchers might be their own group or they might be part of marketing, product, or even engineering. The people requesting research and using the results might be product managers, ux designers, or marketers. That’s not even addressing the times when research is done by outside firms or by team members who aren’t trained in research.

There’s a reason this is so confusing. Despite the fact that various forms of user research have been used to develop products for decades, the widespread adoption of user research in the tech industry is still relatively new. Steve says, “People have more dogmatic theories about best practices, but I’m seeing so much variety and so much iteration as people try to figure it out.”

Hopefully with a few more iterations we’ll get a better idea of what works and what doesn’t. Although it’s likely there will never be one single answer. The best configuration may always depend on factors like company size, industry, and type of research that needs to be done.  

Who Should Do the Research?

Despite the fact that Steve is a highly experienced research expert who conducts research for clients, he’s very upfront about the fact that internal teams should be heavily involved with the research. Often they should be doing it themselves. This is one of the reasons he teaches people how to be better at research and why he wrote a book that explains how to interview users more effectively.

Not every research study requires an expert at the helm. Quite a few products would benefit from having somebody on the main product team who could quickly get feedback or answers to simple questions. “Even a newbie researcher should be able to answer some factual questions about what people are doing or might want to do. They also have the opportunity to reflect on what assumptions they were holding onto that were incorrect,” Steve explains. “You’ll always get more questions to go with your answers, but hoo boy–it’s better than never talking to users and acting with confident ignorance.”

There are some questions you’re better off bringing in an expert, though. “The more help you need in connecting the business problem with the research approach and connecting the observations to the business implications, the more expert help you need,” Steve explains.

We should all know by now that things like usability testing make our products simpler and more intuitive for our users. There’s also a huge amount of information to help you run a basic usability test. But when you’re getting into some of the trickier questions around generating or validating business ideas–or turning early customer research into innovative solutions to problems, an expert can help guide the research process and make these complicated research studies run more smoothly.

How Do We All Work Together?

Of course, none of this answers the question of how we all work together. Steve feels like there’s not a single answer to this question, but it’s very important to decide this ahead of time so that everybody knows what to expect.

For example, consider where researchers live in relation to the people who need insights to inform product design. When your company has expert researchers, they may be part of an in-house silo, embedded in the product team, an outside consultant, or some hybrid of any of the above. Wherever they come from, you should determine five things as part of your research planning process:

• What do we need to learn?
• Who are we going to study?
• What will we do with the outcomes?
• How are we going to work together?
• How will we define success?

A standard predictor of success is how much the client is able to join the fieldwork.

“Negotiating these elements is part of what a good research person should be doing,” Steve says. “The team structures, the availability of stakeholders – these are all inputs.” In other words, there’s no one-size-fits-all when it comes to determining how research projects should happen.

According to Steve there is one constant: “A standard predictor of success is how much the client is able to join the fieldwork.” And he’s right. The best type of research is the research that people use to make better decisions. The more involved your team is with conducting the research, the more likely they will understand and pay attention to the results.

Learn More

Want to know more about conducting research well? Check out Steve’s book Interviewing Users for practical, easy to use advice on getting more out of your research sessions. Or join us this October for a one-day remote conference User Research for Everyone–featuring 8 of the most respected experts in the field.

---

Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

Product Teams – Who Does What?

When we started talking about putting on the PM + UX Conference, the first thing we asked was, “What sorts of things should we talk about?” Since the folks at Rosenfeld Media are, not surprisingly, extremely user-centered, the obvious answer was, “We’re not sure. How about we do some research and find out what questions our attendees might have?” So we did.

The most interesting thing to me was that a lot of the questions people asked boiled down to “Who does what on a product team?” This was curious. I mean, we’re all working on product teams or we’ve worked on them in the past, right? Shouldn’t we know what our jobs are? Shouldn’t we know what everybody else is doing? Well, yes! We should! And yet… when I started to dig around and have conversations with people, I got very, very different answers about how things really worked.

That was odd. It turned out that, although we all have job titles like Product Manager or UX Designer, many of us have very different ideas about what it is that we’re supposed to actually do all day. Do designers talk to customers? What about PMs? Who decides what features go into a product? Who makes wireframes? Does anybody do usability testing? If not, could they please start?

Like any good team faced with more questions than they started with, we did some more research. Ok, first we had a couple of stiff drinks. Then we did some more research. I was volunteered to lead the way.

The Research Methodology

I wanted to make sure that we hadn’t gotten weird data or misinterpreted the questions being asked- after all, it was a survey – so I conducted several qualitative interviews with PMs and UX designers in various sized organizations. I asked about what PMs and UX designers did at their companies. Incidentally, I also got a lot of “but the way we SHOULD do it is…” answers, but I was focused on reality for the moment. And reality seemed just as confused as the survey results.

After talking to a dozen or so people, I decided I wanted to collect exactly what tasks were performed at different companies so that we could see how much overlap existed. To get as many data points as possible, I sent out a very simple survey asking people what their role was, which tasks they thought were performed by UX Designers and which tasks they thought were performed by PMs.

I got dozens of responses from people on different product teams–mostly UX, PM, and researchers–and even some engineers, marketers, founders and managers. Of these responses, I got hundreds of different things that are being done by product teams.I am not exaggerating. It seems that PMs and designers are performing a dizzying array of tasks from generative research to making roadmaps to managing stakeholders to visual design.

I got curious. Who on these teams are doing all of these things? Seriously, most product teams just aren’t that big, so how do they get hundreds of things done? Who’s got that kind of time?? I narrowed down all the responses by deduplicating things that were similar. I picked the things that were mentioned the most, narrowed it down to 73 discrete tasks or processes–which is still a LOT of things for a team to be doing.

Next, I did a card sort: I asked people to review each task and tell me whether it was mostly done by designers, mostly by PMs, done about equally, or generally done by nobody or somebody besides these. I also said you could make your own categories for things that didn’t fit.

I ran the card sort remotely using OptimalSort, which was handy, since that meant that I could gather a lot more input than if I’d had to travel around with a set of index cards and watch each person do the sort. It also made it a lot easier to categorize, and you’ll see in just one second why that was important.

The Research Results

82 of you weighed in with how things worked at your company. And, surprise surprise, there was virtually no agreement. I mean, there were a few similarities. Everybody agreed that visual design was done by someone in the design department (except for those of you who said it was done by outside people or people in marketing). And almost everybody agreed that roadmaps were made by PMs. Or by execs. Or by managers. Or by someone else.

Oh, and nobody agreed about who was supposed to do user research, except that a lot of people made a category called something like “things we aren’t doing enough of” and stuck user research into it. So, that was fun.

Here are a few of the things people actually agreed on mostly.

What Are Designers Doing?

Interestingly, there was far more agreement about what designers do than about what product managers do across companies.

 

Visual Design

The most agreed upon tasks were things like visual design, design specs and style guides, image manipulation, illustration, and branding. Almost everybody agreed that these were mostly done by designers.

The unfortunate part about this particular agreement is that, while it’s true that these are more “design” tasks than they are “product management” tasks, it tends to confirm the idea that many organizations still see design as limited to visual design.

 

Interaction Design

It has “design” right there in the title, but 10% of the respondents said that interaction design is done equally by product managers and designers, and one sad person said that it’s not being done at all.

Other Mostly Design Tasks

Other tasks that were mostly done by designers were what you might expect:

• Mockups
• Wireframes
• Sketching
• Site Maps
• Information Architecture

Interactive prototypes were also very high on the list of tasks mostly done by designers, although at a few companies they’re still being made by engineers or developers. This may reflect the huge number of new prototyping tools available these days.

What Are PMs Doing?

There was a lot less agreement across  companies about what PMs were doing, frankly.

 

Roadmaps

The most agreed upon task for product managers was creating and maintaining feature roadmaps, with 63 people saying that this was almost always done by product managers. In twelve cases however, roadmaps were maintained equally by designers and PMs, and in six cases, they’re being made by someone else or not being made at all. Project and program managers are sometimes the keepers of the roadmap, but very infrequently.

 

Feature Definition, Business Strategy, and Scheduling

Many of the most common product management tasks, unsurprisingly, are things that involve defining and prioritizing features, creating revenue models, or project management and scheduling tasks like sprint planning.

But there were really only a few of these tasks where more than half of the respondents agreed that they were done mostly by product managers and there were no tasks where more than three quarters of the respondents agreed were all or mostly done by product managers.

Business strategy, for example, was reported to be done primarily by PMs in only 50 of the 83 cases. In five cases, it was done equally by PMs and Designers and the rest of the time was done by anybody from executives to finance to nobody at all. In one case, the entire team worked together on setting business strategy.

What are People Doing Together?

The most inspiring part of the study for me was how many tasks people are doing together – either as a whole, cross-functional team, or at least across the PM and Design roles.

In 13 cases, the entire team reported brainstorming new features together, and in 51 cases, brainstorming was done about equally by PMs and UX designers. Hopefully that means that more people are getting involved in figuring out which new features to build for users.

Perhaps the most evenly split task was customer discovery, which worked out like this:

• Mostly designers: 17
• Mostly product managers: 17
• Equally by PMs and designers: 20
• Not done: 15
• Other: 16

I don’t like to see customer discovery not getting done almost 20% of the time, but it’s good that when it’s happening it’s a shared task. Needs finding had a similar split, as did most forms of generative research. At least, when user research is getting done, it’s getting done by the whole team rather than being entirely run by one group.

Why Does this Matter?

Having a shared understanding of what we do and what we’re supposed to do is hugely important to creating a well-functioning team. Imagine trying to build a baseball team where nobody agreed on what shortstops were supposed to do or what made somebody a great pitcher. It would be chaos.

And yet, every day, we hire people, add them to our teams, and give them titles like product manager or UX designer or researcher, without realizing that the last company where they worked might have had an entirely different definition of the role. Then we’re shocked when somebody who was a fantastic PM at their last company isn’t succeeding. Or we can’t believe that the new designer can’t do what we consider to be a trivial task. Worse, sometimes we have no idea what our coworkers are doing or what they’re supposed to be doing, which is why important tasks can fall through the cracks.

Learn More

There is actually one more bit of research that I’ve been doing in parallel for awhile now as I work on my new book, Build Better Products (Rosenfeld Media ‘16). I’ve been talking to teams in order to understand which ones are most effectively delivering value to users. There seems to be a very strong correlation between good outcomes and the teams that report doing certain of these tasks together. Teams that conduct research together are more likely to understand their users. Teams that use that research to ideate together are more likely to come up with feature ideas that users want. Teams that decide business strategy together are less likely to get into arguments about what should be prioritized.

If you want to learn more about how your team can work together more effectively, check out the upcoming one-day online conference devoted exclusively to Product Management + User Experience. I’ll be sharing activities you can run yourself to build team cohesion and get everybody working together. Your ticket gives you all-day access plus recordings to the full program. There are only a few spots left. Hope to see you there!

---

 

Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

Just in case you were wondering

…the answer is: no. We haven’t gone into the dietary supplements business.

A handful of you have reported receiving “Lean Fatburner” pills instead of Tomer Sharon’s new book, Validating Product Ideas Through Lean User Research. 

Although both products include the word lean in their names, they indeed are not the same product. We’ve explained this to our distribution company, and they appear to understand the difference now. If you do ever receive the wrong product from us, please let us know and we’ll slim the problem down.

This is ultmately something of a shaggy metadata story. I wrote a little more about it here.

We’ve signed two new books

It’s been a busy week. On top of launching Tomer Sharon’s new book Validating Product Ideas Through Lean User Research and reaching the verge of selling out our Product Management + User Experience Conference, we managed to sign two new books that should come out in early 2017.

Brett Harned, who helps organize the Digital PM Summit, is one of a new breed of project managers that focuses on the human element of getting projects done. In Project Management for Humans, he’ll explains why everyone should have at least some command of project management skills—and how the work itself is as much about understanding and working with people as it’s about managing schedules and scope creep.

Our other new signing—About (Design) Leadership—teams veteran UX managers Russ Unger, author of many popular UX books and now at 18F, and Chris Avore, who runs product design at Nasdaq. They’re chock full of practical advice (just check out the table of contents!) for UX people who are moving into management and leadership roles.

Looking forward to launching these two—and many more great new books—over the coming year.

Whose Job is User Research? An Interview with Tomer Sharon

This is part 2 in the series Whose Job is User Research.

As part of my ongoing series of posts where I try to get to the bottom of who owns user research, I reached out to Tomer Sharon, former Sr. User Experience Researcher for Google Search and now Head of UX at WeWork. He wrote a book called It’s Our Research which addresses this exact topic. His new book, Validating Product Ideas, is also now available. He’ll be speaking at the upcoming Product Management + User Experience hosted by Rosenfeld Media, designed to help teams work together to learn more about their users.

Tomer recently announced that UX at WeWork won’t have a research department and what drove that decision. I took this opportunity to ask Tomer a few questions, and to learn what suggestions he has for creating a team that conducts research well and uses it wisely.

Everybody Owns Research

Possibly the most important lesson you can learn from Tomer is this:  stop asking the question “who owns research?” “Everybody owns research,” he explains. “Research is a team sport. What research is needed is determined based on different sources–decisions the team is trying to make, known knowledge gaps, dilemmas and arguments among and between teams and more.”

Research is a team sport. The team needs to decide what it needs to know together. – Tweet This

He encourages people to use all of these sources to generate research questions. For example, if a team has trouble deciding on development or prioritization of new ideas, then a research question might be “What are the top needs or challenges our users have?”

“Research questions are questions the team needs answers to, not questions that you ask research participants during a study,” he says. That means that the team needs to decide what it needs to know together.

By making research a key part of everybody’s job, it gets rid of the problem many teams have of ignoring research reports. Instead, research becomes a tool everybody can use to answer important questions.

Use Researchers as Facilitators and Coaches

Of course, that all sounds delightful, but it does bring up three important questions:

• What if people just don’t do research?
• Should we really let people who don’t have any experience do research?
• And the most important question (to researchers, anyway) is does this mean we don’t need actual researchers any longer?

There’s good news for researchers among us. We’re still needed, and we’re not just going to let completely untrained people take over our jobs! But instead of being a service organization, Tomer recommends that researchers become mentors, coaches, and facilitators of research. WeWork’s UX team will still have well trained research professionals. In fact, those are some of the first hires that Tomer wants to make. The difference is that they will be embedded with product teams and work with everybody to help make sure research is conducted well instead of working alone in their own silo.

Of course, there are a few types of studies that professionals should lead. “In 90% of the cases,” Tomer says, “I’d prefer a non-researcher doing research, supported by guidance and mentorship of a researcher. The remaining 10% are studies such as ethnography, surveys (yes, surveys), and highly complex quantitative studies, in which I’d prefer a researcher leads the project.”

Other times when you may need to bring in specialized researchers include cross-cultural studies:  where you learn about the behavior and needs of people in a culture very different than yours. If Tomer needs to learn about the needs of WeWork members in China or Indonesia, he partners with a local design research agency (not a market research agency!) to make sure the study runs smoothly and gets insightful results. But even then, all the team stakeholders must be directly involved with the research. Learning about your users isn’t something you should outsource.

Learning about your users isn’t something you should outsource. – Tweet This

Turn Research Directly into Design

Here’s some more good news for those of you who don’t enjoy writing twenty page research reports that are never read (or creating hundred slide Powerpoint decks that colleagues suffer through). Making research an integrated part of the design process gets rid of the deliverables step.

“Research must lead to design that then leads to more research,” Tomer explains. That’s why his favorite method of synthesis and communication is the design studio or design sprint. During a design sprint, the team comes up with a shared understanding of research outcomes and their design implications through sketching, critique, and quick research on team solutions. “The researcher or key decision maker in the team or company can facilitate a discussion in which the answers to the research questions are shared.”

Research must lead to design that then leads to more research. – Tweet This

In other words, get rid of the Powerpoint, and focus on rapid synthesis of research results. Immediately turn them into ideas and designs. This can save you weeks of report writing, and it also means that your team gets a clearer idea of the problems that you’re trying to solve.

Break Down Silos (even if it’s not your job)

Obviously this is all easy for Tomer to say. He gets to build the WeWork UX team from the ground up. But what about those of us who work in companies where research is off in its own silo? Do we have to wait until we’re in charge so that we can change the rules?

Tomer offers insight on this_having spent a lot of his career working at a very large company with a very large research group. “Talk!” he says, “Approach new hires and help them with something not related to research. Teach them how to find the best parking spot or how to change their profile picture on the intranet. The key here is trust and relationship building. From there, mountains can be moved and silos can be brought down.”

Even if we’re put in silos by management, all of us, whether we’re researchers, designers, product managers, or anything else, can reach out to our coworkers and build teams that transcend silos. It’s not easy, but the results are worth it, since we end up with better team communication and products that solve a need for our users.

Learn More

Check out Tomer’s book Validating Product Ideas: Through Lean Research. Or join us on October 11 for our one-day remote conference User Research for Everyone, featuring 8 of the most respected experts in the field.

---

Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

New book: Tomer Sharon’s Validating Product Ideas

One thing that you’ll immediately notice about our newest book—Tomer Sharon’s Validating Product Ideas Through Lean User Research—is that it’s so danged practical. To create the book, Tomer used a radically simple (and practical) recipe:

1. Interview hundreds of startup founders and project managers about the questions that keep them up at night
2. Group them into nine critical questions (e.g., “Do people want the product?” and “Which design generates better results?”)
3. Guide readers through a few quick and inexpensive user research methods that actually answer each of those critical questions

The results are fantastically useful for anyone who is struggling to reduce risk and increase product success.

In other words, lean user research meets product management.

BOOM!

In some respects, this book—our 24th!—is a return to our practical, “here’s how you do it” roots. In another sense, it wasn’t written for UX people at all. Tomer, like so many of us, wants to democratize what many UX people already know. So if you’re a product manager or developer, this book is most definitely for you. But if you’re steeped in user research methods, you’ll still appreciate Tomer’s help in doing what you’ve already been doing: sharing the UX good news with the people you work with.

Like every Rosenfeld Media book, Validating Product Ideas comes in four-color paperback and four DRM-free ebook formats (ePUB, MOBI, PDF, and DAISY). Enjoy!

Whose Job is User Research? An Interview with Jeff Gothelf

While doing research for the upcoming PM+UX Conference, several respondents requested guidance around how user research should managed. In fact, it was the most common write-in answer on our survey, and a question that comes up repeatedly whenever I give talks. Apparently, there seems to be very little consensus about who on a product team should own research. This makes it a lot harder to get user insights and make good product decisions.  

In a way, this is good news. Five or ten years ago, there would have been more questions like, “How do I get my boss to consider doing user research?” and “What is user research good for?” Those still come up, but far more frequently, I’m hearing things like, “How do we make sure that everybody on the team understands the research?” and “Who is in charge of making sure research happens and deciding what to do about it?” Research, these days, is assumed. It’s just not very well managed.

To answer these questions, I interviewed several very smart people who know a thing or two about research and building products. I’ll share some of their suggestions in a series of blog posts.

First, I spoke with Jeff Gothelf, the author of Lean UX (O’Reilly, 2013) and Sense and Respond (Harvard, 2016).

Jeff spends most of his time training companies around the world on how to build usable products using Lean user experience design techniques. He’s seen his share of different organizations, and has an excellent sense of which ones are building the right things. So I asked him to help me figure out the best way to incorporate user research into the development process.

User Research is Owned by the Team

Companies that are functioning well and building great products are doing user research. And they’re doing it together. “Research is owned by the team,” Jeff says. “It is as important as design or writing code. That said, in most organizations, it’s the UX person who typically drives the research or, in their absence, the PM. It’s not necessarily the best approach, but it’s what I see most often.”

In this model, the person responsible for making sure that the research happens doesn’t own performing or communicating the research. What this means is that the product manager or UX designer will request that some specific research will be done.

Unfortunately, this often translates into the PM asking for research and a researcher who is completely unaffiliated with the team or even hired from outside going off and interviewing users and then coming back six weeks later with a report, by which time the team has almost certainly moved on. This generally means that the results of the study will never be used by the team, since the results will be out of date and irrelevant.

Create a Better Scenario

Rather than seeing research as something that is simply requested by someone on the team and then delivered, Jeff suggests a more collaborative approach. The best case involves the PM or UX designer sharing a specific business or user need that requires some research, and then having that turn into a shared activity where members of the team are involved in performing the research. “I’ve found it rare that a team can’t execute their own research,” Jeff says.

“I’ve found it rare that a team can’t execute their own research.” – Jeff Gothelf – Tweet This

There’s still a place for experts in Jeff’s model too. “There may be some situations where getting to the participants or communicating with them may prove challenging (language barriers, cultural differences, etc.) in which case an expert can help,” Jeff explains. “Also, if nobody on the team has research experience, bringing in an expert to train the team is helpful. If you already have some researchers in the company, they can train and deputize others to start collecting user insights.”

Never Outsource Research

Jeff is also not a fan of having outside researchers conduct studies, since it takes time and can lead to a one and done mentality. “I advise teams to never outsource their research. Letting someone else do your research means waiting for them to do it, synthesize it and write it up. Also, outsourcing the research typically means it’s a singular or at least a finite event. I believe research should be continuous.”

When teams bring outside people in to conduct studies and simply hand off results, they’re missing out on a huge opportunity to build skills within the team. Outsourced studies, even relatively simple ones, can cost thousands of dollars. If you’re making that budget decision every time you want to learn something, it’s going to keep you from doing all the research you should be doing. On the other hand, if members of your team can find ways to learn constantly from users, that price comes down considerably, as does the time it takes to run a study.

Finding ways to learn constantly from users brings the price of research down considerably. – Tweet This

There are a lot of options for getting your team up to speed: outside experts can come in and facilitate training sessions or work with the team to do the research rather than perform everything for them. Jeff also recommends Steve Portigal’s book, Interviewing Users, Giff Constable’s Book, Talking to Humans, and my own book (Thanks, Jeff!), UX for Lean Startups.

Get Out of Silos

Cross functional teams make many Lean UX practices possible. It’s easier to have “the team” be responsible for customer discovery if the team exists as a persistent entity throughout the life of the product. But the reality is that many companies still don’t work that way. Research, product, design, and engineering are often in their own silos, communicating only through deliverables, if at all.

The best approach is to get rid of silos entirely, but very few of us have the option to restructure how our companies work in order to make research more effective. If you’re in an organization where research has its own silo, Jeff has several suggestions for making those silos less restrictive.

“Brown bags, demos, ride-alongs, workshops – these are all good tools to show how to do research and what to make of your findings,” he explains. “At the same time, the PM/UX folks should seek this out from their researcher colleagues if it’s not offered up.” Even when your company is divided up by practice instead of by product team, there’s no reason why you can’t reach out to other people working on similar things and build bridges between the silos.

Learning what other people do and how to do it and teaching them what you do and how you do it can be a wonderful way of creating respect and unity within the team. It has the added bonus of making the product better because everybody ends up working together rather than stepping all over each other and ignoring real customer needs.

Learn More

Interested in helping your teams collaborate to create better research outcomes? Check out Jeff’s book Lean UX (O’Reily, 2013) or join us this October for a one-day remote conference User Research for Everyone, featuring 8 of the most respected experts in the field.

---

Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

Announcing the Program for Product Management + UX Conference

The Product Management + User Experience virtual conference program is live! Thanks to the 150+ people who sent in feedback to help inform the final program content. Our six speakers will tackle your most top of mind questions. Register yourself or your whole team so you can better tap product management to design successful products.

The Program Lineup

Good to Great

The market competition is fierce these days. Users can choose from thousands of apps and products. So what questions do you need to ask to make well-designed products that are widely adopted in the world? Marty Cagan will share insights on how to smartly use design and product management to make and launch successful products.

Balancing Continuous Discovery and Delivery

Many product design teams struggle to balance research and discovery with production. How do you cross this imaginary line? Jeff Patton will help you identify a clear set of measures to improve this balance. By incorporating discovery in ways that are lean and meaningful, you can take advantage of missed opportunities and improve product performance.

Whose Job Is It?

When designers and managers are too constrained by title, talented people get underutilized. And in turn, the product suffers. Laura Klein knows a better way. By organizing work around people’s strengths, everybody can deliver value to the customer. Laura shares this exciting line of thinking that you can use to transform your own team’s work.

There is No Such Thing As UX Strategy. There is Only Product Strategy.

Most companies have yet to realize that UX strategy and product strategy are the same thing. By focusing too much on differences, you create silos and impede collaboration. And ultimately, miss important opportunities in the market. Jeff Gothelf will share new ways designers and product managers can rethink this relationship. And tap the best thinking from each approach.

UX <3 PM: 6 Ways To Learn Better Together

Designers and managers can work at cross-purposes because each can so easily lose sight of the other’s unique value. Tomer Sharon will elaborate on how to tap the rare gifts designers and product managers offer each other. And how to articulate an agenda that brings them together after all.

Get to Radical Focus with OKRs

Few things rally an organization to life like a monumental goal. But it has to be well considered and clearly delineated. Christina Wodtke will share the advantages of using objectives and key results (OKRs) to create a high level of zeal and discipline for your entire organization.

Taking the Next Step

If you’re ready to improve collaboration between your designers and product managers, join us on February 3! Hear from these six thought leaders from anywhere in the world. You can use this day as an opportunity for your teams to break silos and learn together. Both individual and meeting rooms ticket give you access to unlimited replays and surprise perks. Register now.