How to Deal with User Interviews

•

Product teams need to keep in touch with customers on a regular basis — it’s simple. However, the world works differently. Despite the fact that the product community as a whole supports the development of products under the guidance of the customer, it is still difficult for most companies to implement this operating model when flexible teams independently make decisions about what to create next based on research and insights. We want to tell you how a B2B product has implemented a modern technology called Continuous Discovery.

Problem

Wasting time

We are faced with the fact that conducting interviews with our users has become very labor-intensive. We need to notify our users about the problem we want to discuss, write to everyone, and arrange a meeting, among other things. It is not profitable for us to pay for companies that help in hiring respondents or use other resources.

Saving Time and Resources

Reference to Theresa Torres’ book “Continuous Discovery Habits”

The product manager of our team advised the design team to read “Continuous Discovery Habits” by Teresa Torres and consider whether we can use continuous research in our process. This approach is convenient because, once we have made an effort to create an environment for constantly hiring our users for interviews, the team no longer needs to spend resources on finding respondents and sending invitations. This becomes an automated process.

Collaborative Efforts

Upgrading workflow

We started our work on the implementation of this research by discussing with analysts, developers, product managers, and designers whether this process is suitable for us at all and whether it is worth investing effort in it. For the research, Teresa suggests creating a trio from the product team members — 1 PM, 1 designer, 1 developer. In our case, we wanted to include an analyst in this process. However, the planning of the research part has been postponed until we figure out how it will work.

Recruiting users for research

We organized a meeting with the development team, demonstrated our idea, and asked them to consider how we could implement a separate pool of users into our database, add and remove users from there, and send them invitations every 30 days. Those who have already been contacted should be marked in the database to avoid spamming them with an invitation to an interview for the next 30 days. While the developers were thinking about the database architecture, the designers were creating a user flow to cover all the corner cases. By the next iteration, the analyst had applied the user flow, the tester had applied the requirements, and the designer already had layouts in which the user could independently include themselves in the pool of loyal users who would help to develop our product. The last stage was verifying the invitations, which we decided to send directly to the application for better conversion with the marketing department.

Database Development and Adaptability for Panel Users

Reducing the scope of tasks

The difficulties during the implementation stage were mostly related to the development and adaptability of our database for panel users. For all the features we were unsure about, we decided to try with an MVP and added an additional column to the database, along with an “if-else” condition when sending invitations from our admin panel.

Results

Improving the result

During the week, over 30 respondents responded and almost all of them were hired. The collection of contacts for the product manager took only 15 minutes… whereas before the changes it would have taken several days of focus.

Our future plan is to add additional columns to display the context for determining the target audience for any specific research.