Tricia Cervenan, Author at General Assembly Blog

How to Organize User Interviews to Inform Product Development


We all know the products that are successful; the ones that seemed to come out of nowhere and then change the way we go about our lives — like the smartphone, ridesharing, or turn-by-turn navigation. But there are a lot of products that didn’t make it. Though there are many reasons why products aren’t successful, one that often comes up is that people don’t see value in what it does. Or, they don’t see enough value in it to pay for it.

One way to avoid going down that path is by conducting user interviews. This is where product teams go out into the world and talk to people who fit their product or service’s personas, observe their behavior, and ask them questions. A persona is a representation of users who have the same problem or goal. Though personas are not real people, they are created based on real user data, often generated or validated by user interviews.

User interviews were introduced in 1990 when the authors of a report called Contextual Design: An Emergent View of System Design talked about “contextual inquiry” as part of the product development process. The goal of an interview is to discover what problems users have that product teams might be able to solve. This is done by visiting users in the environment in which they use the product or a competitor product, or where a problem is occurring; watching their behavior; asking them questions about their behavior; and then drawing conclusions from what they observed.

Anyone and everyone on a product development team — including product managers and user experience designers — is encouraged to take part in a user interview at some point. It’s very easy for teams to get caught up in their own assumptions around what products users want or need. By observing real people, in context, experiencing a problem, team members build empathy and have a strong desire to personally solve it. So the act of interviewing can result in not only more successful products, but also more inspired teams who find meaning in their work.

Oftentimes, user interviews are criticized as “asking users what they want.” That is a misnomer and not the true objective. As researchers, the goal is always to observe current behavior so that we can understand as much as we possibly can about the problems users experience, relative to the solution we’re able to provide. We try to prove that the problem is real, in what context it occurs, how a user currently solves the problem, the frequency with which it occurs, and how frustrated a user is when it’s occurring.

Critics will often add that they understand problems enough by looking at analytics, or quantitative data. Unfortunately, quantitative data can only tell you that there is a problem — it’s qualitative data that will tell you what that problem is and why it exists. The insights the team gets from truly understanding and empathizing with the problem allows them to think more broadly about their solutions and truly build the next set of innovative and successful products.

How to Find Users to Interview

A key step in planning user interviews is, of course, finding your users or potential users. Sometimes seeking out people who are willing to talk to you can be as simple as doing an intercept interview, where you approach people on the street, in a place of business, or digitally while they are using your product, and ask them if you can have a few moments of their time. It’s OK if they say no! Simply move on to the next person (who will most likely say yes).

You can also find people by asking your product or service’s current users via an email blast, or by reaching out to those who have submitted a support issue.

It’s common practice for researchers to compensate interviewees, though it’s encouraged to try to compensate as little as possible. That’s why you’ll often see companies recruit by saying something like, “Talk to us for 30 minutes and get entered to win a $25 gift card.” The idea is to provide just enough compensation to entice people to participate, but not too much to introduce additional bias into the data.

If you have a large budget and are looking to speak with very targeted users, you can also hire a company to recruit users for your test. This can be very expensive and can also inject a bit of bias because those users tend to be compensated at a greater rate than willing participants from other methods. But sometimes that route is the only efficient way to get access to a specific group of people.

Depending on where your users are located, you might conduct an interview in person, on the phone, or over video conference. It’s best to have two people from your team there to conduct the interview so that one person can ask the questions and have a conversation while the other takes notes. (It’s quite difficult to simultaneously take notes and practice active listening.) If you record the interview, make sure to tell the user beforehand.

How to Ensure a Successful User Interview

The goal of a user interview is to get at why users behave the way they do and how they feel about their experiences. Because of this, it’s important to ask open-ended questions that focus on the person’s past or current behavior. Interview prompts can even be phrased in a way that it isn’t a question, such as, “Tell me about a time that you [used a self-checkout/searched for clothes online/scheduled an appointment with a doctor],” or, “Tell me about the last time you…”

After the user has described what happened, follow up with questions that get at why they behaved or reacted the way they did. Ask them questions about how they felt. Watch their body language as they answer those questions. Sometimes the most important information about how to proceed can come from what people don’t say.

Above all, do not ask users to predict what they will do in the future. If you find yourself asking questions like “Would you use this product?” or “Would you pay for this service?” or “What would you like to see in future updates?”, simply pause, and rephrase the question so that it asks about past behavior. “Why did you use this product or similar products?” “Have you ever paid for a service like this?” “Why have you stopped using this product or similar products?” By focusing on past behavior, teams will gather information about the problems users are facing so that they can use their collective wisdom and skills to come up with innovative solutions that succeed in market.

User Interviews at General Assembly

In General Assembly’s full-time User Experience Design Immersive (UXDI), part-time User Experience Design, and part-time Product Management courses, students get firsthand practice conducting interviews. We first discuss how to interview and learn best practices for being effective. Then we jump in and start interviewing. Students draft questions and an interview script, practice with one another, and get immediate feedback from their peers. Then they set out to find and talk to real users who have the problem they’re looking to solve. In UXDI, students work with real-world clients and conduct interviews with their current or potential users.

After their first interviews, students generally say that the experience of approaching and talking to strangers was a bit scary, but also that it gave them so much good information that they need to take their projects in a whole new direction. Essentially, they discovered that their assumptions were incorrect and they now understand what problems are worth putting more time and effort into exploring and solving.

Ask a Question About Our Design Programs

Meet Our Expert

Tricia Cervenan is an instructor for General Assembly’s part-time Product Management course in Seattle. She has been developing products for over eight years and currently helps clients solve software problems at the product agency L4 Digital. You can find Tricia on Twitter at @triciacervenan.

“Product managers are a stand-in for users, customers, stakeholders, and our development teams — depending on who we are talking to. We need to be able to share the feelings of any of those people throughout a project.”

– Tricia Cervenan, Product Management Instructor, General Assembly Seattle

How Lean Practices & Startup Methodologies Guide Product Management



Product development has had many methodologies over the years. We’ve seen waterfall, XP, Kanban, Scrum, “Scrum-but,” “Scrumfall,” and so on. Each one was created to compensate for a process that worked for some, but didn’t work for others. Since developing products can be costly, particularly if the wrong product is taken to market, teams have worked to mitigate that risk by iterating on how they get from idea to finished product. One such way is the concept of “lean.”

Lean was popularized by Toyota in the 1940s in an effort to increase the quality of its products for customers, while still maintaining the efficiency of the company’s assembly line. The idea was that as it continued to optimize the process for quality, anything that was unnecessary in the process would naturally be eliminated. So, when a team utilizes a lean methodology, it is working to achieve some value, with the least amount of waste.

The Lean Startup: Build-Measure-Learn

Lean became part of the software development lexicon thanks to entrepreneur Eric Ries, who in 2008 began teaching his own methodology to software startups. In 2011, he published the book The Lean Startup.

The Lean Startup was innovative and popular among startups because it came at a time when distributing software was no longer about spending two years developing something, packaging it in a box, and selling it on a shelf for the next four years. Since software is now easily deployed over the web, today’s teams can constantly push out new tests, ideas, and architectures that reach their entire user base in seconds.

The book’s main premise addressed this shift by introducing the “build-measure-learn” process to test a hypothesis. Essentially, you start with a problem that you think exists in the market (your hypothesis), build just enough of something for you to measure its success among customers, and use that learning to build something new, add on, or scale. Then repeat. Continue repeating this until the product has reached a steady state and proven that the product is valuable enough to users to have a team of people continue to develop it.

What’s great about the Lean Startup model is that you don’t worry about scale until scale matters. Why build for 100 million users when you haven’t even gotten one yet?

In The Lean Startup, Ries talks about several startups that had success utilizing his methods. One of those companies, Food on the Table, tested out its ideas by providing concierge meal planning for users. Rather than building software first, the founders went to grocery stores, recruited a single user, and provided meal plans to that user for several weeks. The experience allowed them to quickly and easily make changes to their feature set because they simply changed paper forms and how they provided this concierge service. After testing their new plans with a few more users, they went on to build software to reach thousands more. In 2014, Scripps Networks Interactive went on to buy the product and eventually turn it into what is now

Skills for Lean Teams

Not all teams are able to function in a lean environment. Some companies have a lot of necessary risk they need to mitigate that generates a need for more process, documentation, and predictability. But for those who are able to cut out unnecessary process, there are a few skills that can be beneficial.

Be comfortable with change.

Since the idea of lean is to adjust based on learning, teams can only function leanly if they aren’t married to their ideas or dogmatic in their processes. This is why lean practitioners love simple tools like whiteboards and sticky notes — what they write or draw on them only takes a few moments to create, and that content is so easy to erase or throw away that it helps keep emotional distance from the idea. That way, they can determine honestly whether they’ve proven or disproved their hypothesis.

Google has popularized the concept of design sprints by utilizing some lean techniques. In a design sprint, participants use letter-sized paper to sketch out ideas and collaborate with one another with the goal of creating a simple paper prototype (though sometimes they use software) that they can then test with users by the end of the week. Teams using design sprints allow ideas to come from all over the organization and uncover answers about product direction. In the process, many ideas are discarded, and the user feedback drives the next sprint’s work.

Communicate well, and often.

Teams that cut out documentation and processes can only be effective if they fill the void by talking to one another, either virtually, in person, or both. It’s helpful to ensure everyone is using similar definitions for words, especially jargon or acronyms, to ensure that there’s a common understanding of how the team is using those words.

Collaborators also need to talk about the things that are and aren’t working for them. To mitigate waste in the work the team is doing, the processes used will constantly need to be evaluated. The most efficient way to do that (without adding more processes) is to do quick check-ins for understanding. This cultivates an environment where colleagues are comfortable speaking up when something isn’t working.

Talk to users.

The only way the build-measure-learn feedback loop works is to put something in front of users and talk to them about what’s working and what’s not. Some might say that quantitative data is sufficient in measuring success, but that view is quite short-sighted, especially when it comes to developing new products. Quantitative data tells you there is a problem, while qualitative data tells you what that problem is and why it exists. It’s only then that teams are able to know how they should iterate on their product.

Lean at General Assembly

As an instructor at General Assembly, I implement lean methodologies in my classroom with each lesson. At GA, we don’t create droning two-hour lectures and then send students on their way; rather, we share many short lectures followed by monitored activities, then check in with the class to ensure students are achieving each lesson’s learning objectives. This way, we can determine who isn’t catching on to what we’re teaching and what types of teaching methods are effective for this cohort of students, and then adjust the current lesson and future lessons accordingly.

We explicitly teach lean skills and concepts during the Lean Startup section of our part-time Product Management course, for which I’m an instructor at GA’s Seattle campus. Namely, we cover hypothesis development, minimum viable products (MVPs) and experiment testing, and the build-measure-learn cycle. And we implicitly practice lean concepts in the way we quickly move from idea to testing with users, to planning future iterations. In a 10-week course, there isn’t time to worry about scale, so students get the opportunity to practice lean skills, giving them the most amount of value from the course with the least amount of waste.

Ask a Question About Our Business Programs

Meet Our Expert

Tricia Cervenan is an instructor for General Assembly’s part-time Product Management course in Seattle. She has been developing products for over eight years and currently helps clients solve software problems at the product agency L4 Digital. You can find Tricia on Twitter at @triciacervenan.

“In teaching GA’s Product Management course, my goal is to jump start your understanding of product management, so you can be successful while you refine your skills on the job.”–– Tricia Cervenan, Product Management Instructor, General Assembly Seattle