Prioritizing User Research

User research in API product development

Earlier, we learned how to identify the target audience and how to segment our target market. Once we’ve chosen a market based on a high-level strategy, the next step is to dig deeper into that market and start doing user research to learn more about all the user personas in that market.

User research is a close partner team for all Product Managers (PMs). When building API products, we start by first learning who our customers are. We can do this by establishing customer personas and mapping the customer journey for each of these personas. A developer’s journey is a map of sequential steps across all our documentation, tools, and marketing channels, such as blogs, videos, and others, that our customers use to learn about our product offering, assess whether it is a good fit for them, develop and integrate with our APIs, and use the product actively.

The primary users of the APIs we build are going to be developers. However, developers may not always be the only users. There are several other team members who are not developers but who are also part of the decision-making when it comes to choosing a set of APIs for the purpose of their project. This could include the product manager, security professional, software architect, and so on. In a B2B setting, different stakeholders make decisions, and each one needs a different set of information to evaluate our API offering. In the same way that there are several teams and team members involved in the development of APIs, our customers also have a number of team members who collaborate in the process of discovering, evaluating, integrating, deploying, and monitoring their integration using the APIs we produce.

It is the responsibility of UX researchers to generate trustworthy insights that can serve to direct the decisions made by product teams. Good intuition is an asset in the process of developing user-friendly and impactful products. The product development process is heavily reliant on UX research insights, and poor UX research insights can lead to poor product decisions based on facts and/or conclusions that are inadequate, inconsistent, or erroneous. On the other hand, it’s up to PMs to correctly evaluate these insights and use them to put a strategy into action.

Prioritizing the research process starts with asking questions that user research efforts can help research and shed light on. We might have a long list of research ideas across various aspects of the product experience, such as:

• What are the various customer personas who use our product?

• How do users discover or become aware of our API offerings?

• How do users compare our APIs to competing API offerings on the market?

• Is our pricing model working for our customers?

• How can we drive upgrades and increase retention?

• What developer tools do our customers most commonly use?

• What do our customers’ tech stacks look like?

All of these are important questions to answer in order to understand the customers and opportunities for our product offering. If we ask our users clear, simple questions, our research will be more useful and effective. User research should be a continuous part of our product development process, and this means that not only should we have user research that is in progress that is going to fuel the next iterations of our product, but also user research that validates our current understanding of the user base so that we are aware of the changing marketing dynamics and user sentiment.

Big roadmap items can sometimes overwhelm our research strategy, but if we spend too much time on long-term projects, we might miss out on ways to help our customers more immediately. On the other hand, if we work on a lot of small goals and changes, the User Experience (UX) could become too busy.

To balance our user research efforts against short-term and long-term goals, we should fill our schedule with mostly short-term goals that meet both the company’s current strategy and the needs of users right now, with long-term research needs spread across longer periods of time. If we’re still not sure which project needs our attention, we can run a cost-of-delay analysis, which looks at how much potential revenue we’ll lose by waiting. This comparison of timelines and effects can help us figure out which projects could pay off the most.

Our user research strategy should enable us to go broad and understand things such as the size of the business, geography, industry, and so on, that our customers belong to. Once the broader segments have been identified, we can go deeper into each segment to understand trends such as the size of the team, skills on the team, and the tech stack being used by our customers.

When creating a user research strategy, it is important that we look at a wide range of customer segments so that we can not only identify the ideal customers for us at the moment but are also able to create a prioritized set of user personas that we might want to target in the future. In the following section, we'll learn more about creating user personas that can be shared within a team to build a shared understanding of customers.

Establishing user personas

When building consumer products in a B2C environment, we can segment our audience in a handful of ways, such as by demographics, age groups, location, income buckets, and so on. This lets us figure out which groups of people like or dislike our product. Similarly, in B2B and B2B2C environments, we can segment our audience into these categories:

• Individual developers: In a many cases, our customers might be a small team of a handful of people, or even a single person, who are building applications using our APIs. A common scenario is where there is a single developer in a university or a nonprofit organization. These developers make all the decisions regarding the evaluation and usage of our APIs in their organization.

• Small-to-medium businesses: Start-ups and small businesses sometimes have a small team of developers who start out by using our APIs. These teams might have a small number of people who are involved in the decision-making and development process. Small-to-medium businesses usually have a business owner who is focused on the business aspect and hires a team of developers, either in-house or externally, to do the development. These developers will only be focused on the technical evaluation of the solution.

• Enterprise: As we look at enterprise customers, the number of decision-makers grows significantly. The evaluation decisions that are often made by a single person in a start-up are made by a number of teams in an enterprise setting. The scale of usage is also significantly larger and we will partner with sales and account management teams to connect with this type of customer.

Any development team could have one or more developers with different levels of experience and areas of expertise. Depending on the skills available on the team, they will look at solutions and tooling options. For example, if a customer is an individual business owner, they might prefer no-code or low-code solutions because they are easier to maintain. But if the customer is an enterprise user with a number of senior developers on their team, they might have questions about scaling and security that other customers may not have.

We can also segment our audience based on industries such as finance, healthcare, and so on. Once we establish the segmentation of our customers, we must create a user research strategy in a way that allows us to speak to a variety of those segments. When we work on an existing product, we can run online surveys to allow users to give feedback on our product and also input that allows us to segment our audience. Existing users are a great way to get insights into customers who are already successful in using our product.

Customer interviews are a great way to get deeper insights into our customer base. We can reach out to existing customers and incentivize them to meet with us for a 45–60 minute conversation, or we can use user research teams to help recruit potential customers. We can also work with a user research team to create a user interview questionnaire. This will generate a list of questions we can ask customers that are organized and in the right order. This will let us create a dataset that can be mined with answers from our users about the different things we ask them about.

Diary studies are a great technique to get insights into the actual integration process that our customers go through in the process of integrating with our APIs. With this technique, we recruit developers and share a specific set of instructions with them. Developers will keep a diary where they take notes as they follow the set of instructions, and at the end of the exercise, they share their notes with us. This is usually done over a few days to give developers time to work independently, and we conduct interviews at the beginning and end of the process.

As we talk to customers through various channels, we can create a methodology to log and track all the learning in such a way that we can compare and contrast the responses from various customers and use this information to identify patterns. This clustering of information will help us develop archetypes of users that are called “user personas” since they represent the demands of a wider segment of the population. One- or two-page documents are usually all that is needed to convey a persona (like the ones we see in the following example). Examples of one- to two-page summaries include a person’s behavior patterns and goals, as well as their abilities, attitudes, and background information. When creating user persona templates, designers often incorporate some fictional personal details (for instance, quotes from real users) as well as context-specific details.

A set of well-researched personas helps make them more relatable and enables our team to collaborate and ideate together. The following illustration shows what a common user persona template looks like for four customer personas.