The purpose of a product or service is to act as a vehicle to deliver value to your customers and make their lives easier and/or better in some way. As covered in the vision blog post, The starting point of any product or service should be the gaps in society and the pain points that potential customers feel. In addition to subsequently defining the mission and understanding the market, it’s critical to truly understand who your customers are, empathize with them, and understand what challenges they have that they may or may not be aware of. But how can you do that?
There is no better way of learning more about (potential) customers than by conducting user research. The most successful product organizations have a wide range of user research methods to conduct and pick from according to a specific aspect of the customer that they’re trying to learn about – such as their attitude, behaviors, and feelings. In the previous blog post, we talked about using the market adoption curve to learn about the competitors, customers, and your product portfolio’s maturity.
Knowing where in the market adoption curve your product currently is can help you better understand who the target audience for your product could be, and what they value and are looking for in your product. If the leaders of a product are unsure which area of the curve the product lies in, support them in validating their assumptions with customers and target groups. For example, an Agile Coach can pair up with a UX Designer to host a session where the product leaders list down their assumptions for different personas in the target audience. As a next step, the UX Designer can set up a user research method, such as a diary study or user interview where they validate or invalidate the assumptions about each persona.
Exposure hours is another user research method that was pioneered by Jared Spool. According to the concept, each individual in any organization should expose themselves to a regular and direct touchpoint with a customer. For example, if you are working in an organization that creates an app for food delivery, each member of the organization, including the CEO, should spend a few minutes periodically acting as a courier to deliver food from a vendor to a customer. Alternatively, in another organization, its employees should spend at least 60 minutes every month acting as customer support in order to directly hear the customer’s pain points, rather than working from an ivory tower without getting feedback from the customers. Jared argues that having frequent and direct customer touchpoints results in the organization being better connected to reality and formulating opportunities and solutions based on the actual needs of the customer. According to Jared, the “magic number” for exposure hours is 2 hours per team member every 6 weeks.
Conducting a workshop around the creation of personas can be powerful when combined with exposure hours to learn more about the actual customers and validate or invalidate some assumptions that exist when creating personas. A persona is a fictional character that represents non-fictional user types. In reality, these user types may or may not be the actual users of your product or service. Using the creation of personas as a starting exercise helps validate or invalidate who your actual users are. When creating personas, think about the target audience of the product or service that is being built. Who are the individuals that it is catering to?
Follow the four-step process below to identify and validate personas that you can learn more about when conducting different user research methods such as exposure hours.
- Pick a user segment – User segments can be thought of as groups or categories of personas. Typically, they represent job titles, industries, or departments in organizations. For example, if you are working on a education technology (EdTech) startup, your user segments could be the principal, teacher, and student. Within the user segment of teacher, you may have personas such as experienced teacher, new teacher, substitute teacher, etc. Keep in mind that these user segments can be both internal and external to your organization – think about both options.
- Identify personas – Pick a segment and think about which personas exist within that segment. Think about especially the individuals inside and outside your organization who frequently use your product.
- Identify attributes for the picked personas. List down the traits that allow each persona in a given segment to be different from the others. Identifying attributes that can be scored on a scale, such as experience, risk tolerance, fun personality, and creativity, allow you to assess them on those attributes during the user research method of your choice. It’s best to avoid binary attributes that are either completely true or false. Pick the 3-5 most important attributes per persona.
- Identify the user research method that you would like to use to validate the persona that you’ve created. During this user research method, think about how you would know whether the attributes you’ve ideated are reflected in the actual user or not. Jot down your learnings from the research session in the template below and use it to update the persona definition.
Coming up with personas can be helpful but it’s key to look beyond demographic information, and into whether individuals that represent those personas could actually benefit from your product/service. This is why identifying attributes that can be validated is key to truly understanding who your (potential) customers are and could be.
Refer to the following template for creating personas and learning more about the actual users behind those personas.
For a lot of teams in organizations, user research may seem like something very new to them because they work in silos where the role of the design team is to design, the role of the development team is to develop features, the role of sales is to close deals, and the role of customer support is to understand more about the user problems. However, this siloed way of working often results in handovers of information between teams and departments in a Chinese-whispers-like approach, where information is lost and miscommunicated. Such a setup also tends to encourage an ivory tower approach of building a product or service with only one team having a direct touchpoint with the customers. Wouldn’t it be helpful for the development team to observe or interact with customers first-hand so that they could get more context about what the customers appreciate about the product and what they are struggling with? Wouldn’t it be easier for customer support to have a product and tech role to work with to validate customer queries for your product rather than creating a ticket or issue in Jira or a similar task-management tool, and then “tossing it over the fence” to another team to deal with it?
Working in a collaborative way tends to reduce time-to-market (TTM), boost the working environment internally within an organization, and lead to more satisfied customers. If the team that you’re supporting has no direct access to their customers, encourage them to reach out to a team that does, such as customer service, and see whether they would be open to having the team’s members sit in and silently observe. As time goes on, they can have a more active role, if needed, and support the customer service team member in filtering requests that are valid and ones that aren’t. Once the team has developed the skills and experience to interact with customers directly, they can take the next step in conducting different user research methods independently.
Adopt a continuous discovery approach, where the aim is to constantly get small amounts of direct feedback from customers which should be infused into the day-to-day decisions and work for the team. Pairing up with a UX or Product Designer can be beneficial for teams who don’t have a lot of experience with introducing user research methods. One simple way to support teams to get into the habit of continuous discovery is by automating user research sessions with the help of tools like Calendly. The team can set up a timeslot every week or two weeks where different customers who you would like to target can set up different forms of user research – whether it’s interviews, usability study, or live split tests (also called A/B tests). This way, the team spends minimal energy trying to get customers to sign up and more time preparing for the interaction, digesting feedback from the previous session, and infusing the generated insights into the product. Rather than running a large survey at the end of the year across hundreds of clients, it’s easier to have a weekly or bi-weekly session with one or a few customers focused on a small scope the team is working on at that time. This allows the team to immediately use direct customer feedback and incorporate it into the piece of the product or service that they are working on at that specific time.
For example, suppose the research and development (R&D) team in a natural wines startup is looking for feedback about a specific ingredient – honey, in this case, in one of the unreleased wines. They can use one of the automated user research slots to do a split test between wines that contain honey and wines that don’t. This single-blind study could reveal preferences for the target audience, which can help the R&D team decide whether they should proceed with the development of the wine with honey or not. A single-blind study is a method in which only the researcher doing the study knows which participant is receiving the wine with honey until the trial is over. A single-blind study reduces the likelihood of participant bias.
The What-Why framework for user research, developed by the Nielsen Norman Group, helps teams pick a user research method based on the types of insights they are trying to generate, as represented by the ends of the axes: behavioral, attitudinal, qualitative, or quantitative. Spotify popularized the practice of simultaneously picking one user research method per quadrant of the What-Why framework across two or more quadrants in order to yield comprehensive insights. They call this method Simultaneous Triangulation. By using just one method at a time, Spotify’s design team argues that you are setting yourself up for blindspots and contradicting results from different methods if they are employed sequentially. By running two or more methods in parallel with the same group of users, you have more of a 360-degree view of the needs of the target group as a result of probing into at least two of the four elements (qualitative, quantitative, behavioral, and attitudinal) at a time.
Lastly, it’s a good idea to include generative and evaluative methods to give the product further insights. Generative methods promote a divergent thought process and help define the problem by being open to the different opportunities that may exist. Evaluative methods are typically used in the solution space to assess certain solutions for the problem that you’re trying to solve. Such methods help you converge into possible solutions. Pairing the two methods is at the heart of design thinking.
Depending on the results of the user research and what they indicate about where in the market adoption curve the product could be, the focus areas and approaches for the product would differ. On the left side of the market adoption curve, the product should focus on innovating and testing different low-fidelity business models, whereas on the right side, the product would focus on building the existing offerings to a higher degree of fidelity. Based on that context, support the organization and its teams in the sense-making, discovery, and delivery phases. In order to do so effectively, it can often help to pair up with a product leader in the organization to have such conversations about the market adoption curve as a starting point for learning more about the product and its users.
Understanding the market and your customers, and having a business strategy and business model de-risk your organization. Building products in this manner can systemize their success. In the next post, we will look at what business strategy and business models are.
Rahul Bhattacharya 
2 thoughts on “The customers”