Agile Project Management: Know Your Customers

"Who is my customer?" is a fundamental question everyone must ask as they begin product development. Product development teams explore this question frequently, using product and customer usage data to see trends and watch industries and markets closely. Not clearly understanding who your customer is makes product development difficult and rudderless.

Customers range from external paying customers to internal users. Sometimes the customer is even several layers away, spanning wholesalers, distributors, and retailers. Product landscapes also change dramatically and are uncertain. Each new generation of users, from baby boomers to millennials, brings a new set of needs or considerations. Add to that cultures, races, and ethnicities; new or changing technologies or inventions; new laws or regulations; and even results from competitive benchmarking.

Customers continually demand faster, better, and cheaper. From cars that receive operating system updates every week to wearables to home automation, customers expect more—and more often. Product providers who can meet these demands remain relevant.

Knowing who your customer is will put your product development effort on the right path. But how can you know if you’re on the right path? This uncertainty can be unnerving.

Getting comfortable with uncertainty

Modern product development is fraught with uncertainty. In fact, it’s the one aspect of product development that’s certain. Rarely can we develop the same solution for our customer’s ever-changing problems. Product providers continually question, “Have we accurately identified our customer and are we addressing the right problem?” Product development teams need to be comfortable with uncertainty.

The certainty end of the spectrum is predictable, safe, secure, and settled—aspects you would expect of a low-risk investment. The uncertainty end is fraught with anxiety, worry, doubt, and danger. Product development teams continually strive to address the highest risk and highest value for their customers. They learn and grow, and gain experience and opportunity throughout their product development journey.

With iterative product development, the team can present at every sprint a fully-functioning, working product increment—not a half-baked increment—and get feedback. At each sprint, the team aligns the product closer and closer to what the customer needs through a tight, consistent feedback loop. The team becomes more and more certain that what they’re creating is what the customer wants. The team validates assumptions along the way, thus reducing uncertainty.

Being comfortable with uncertainty is important because it changes the team’s perspective. It enhances the team’s curiosity rather than giving them a false sense of assurance. Innovation and better ideas result from a curious team, an attribute shared by all famous inventors.

Uncertainty enables a team to channel its worry, doubt, and risk into a fruitful learning experience with growth and opportunity. Uncertainty motivates the team, which aligns with Agile principle number 5, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Product development is risky business, in a good way.

Common methods for identifying your customer

Although you can identify customers and their needs in many ways, we discuss several popular methods used by product development teams. In the context of agile development we refer to customers as the end users and clients as the people paying for the product or service.

Product owners and developers who are experts in techniques for better understanding their customer are valuable to their organizations and teams. Scrum masters who can facilitate using these techniques are likewise valuable. Each technique puts the team on the path towards certainty.

Product canvas

In Inspired: How to Create Tech Products Customers Love (Audible Studios), Marty Cagan wrote, “discover a product that is valuable, usable and feasible.” What he meant by this, as shown in the figure below, is that successful product development hits the sweet spot at the cross-section of:

• Valuable: Will customers buy it?
• Usable: Do customers need it?
• Feasible: Can we do it?

Many teams use a visualization technique, such as a product canvas, to start to explore and understand the key factors, partners, unique value proposition, problems, and potential solutions that may contribute to finding the sweet spot, where value, usability, and feasibility meet.

The product canvas is a collaborative tool that enables teams, in a brief amount of time, to accomplish two tasks: One, start identifying desired goals or product outcomes. Two, validate assumptions about the problem to solve for the customer and ready the team for development. Product canvas exercises can inspire a clear product vision.

Teams use the product canvas as a visualization activity to create a shared understanding of the customer and his or her needs. The tool serves as a starting point for the team's assumptions and enables them to dive deep in gathering new product insights.

Product development teams create a shared understanding through visualization. The most effective communication medium for them is face-to-face with a whiteboard, flipchart, or other holistic surface. Why? Whiteboards allow people to not only explain but also draw what they mean. Peter Lencioni, author of “The Five Dysfunctions of a Team” said, “If you could get all the people in an organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time.” A shared understanding helps teams row in the same direction.

Many variations of canvases are available, such as a lean canvas or a business opportunity canvas. They all serve a similar purpose of organizing ideas, challenging assumptions, and collaborating to find a strategic direction. The following figure demonstrates the product canvas we often use with agile product teams. The left half addresses market and customer issues, while the right half addresses product and business issues. The left half defines the customer segment, customer problems with alternatives, the value proposition, channels, and revenue projections. The right half defines the solution, key stakeholders, success factors, resources, partners, and costs. Both halves enable a team to do a more detailed evaluation of their product.

Following, are some categories a team might use in building its product canvas:

• Customer segment: Describe the target customer segment that needs the problem solved. For whom is the value being created?
• Early adopter: Describe the initial target customer. Remember, your product can’t be everything to everybody—at least not at first. What market segments are opportunities for testing your product idea first?
• Problem: Describe the primary problem experienced by the target customer segment.
• Existing alternatives: Describe available alternatives to your product.
• Unique value proposition: Describe a single, clear, and compelling message that states why or how your product is different and worth buying.
• Channels: Describe the channels for acquiring, retaining, and increasing customers. List ideas for creating awareness, interest, activation, and usage. Describe what will entire customers to return and encourage referrals. List upselling opportunities.
• Solution: Describe the ways the target customer segment’s problems will be solved.
• Key stakeholders: List the people who are most important to your product. This list may include people whose buy-in and support you need, executives, and influencers. Who are the people you can trust to criticize your product and tell you the truth?
• Key success factors: Describe how success will be measured—measure outcomes not outputs. Are there key metrics you can use to test your hypotheses?

Using metrics allows product development teams to evaluate the success or failure of each product release. Metrics help them see if they truly understand and are solving their customers' problems. Product development teams don’t consider their work completely done until those objectives are met. The product canvas can help identify these business metrics early. Agile product development techniques increase the likelihood that bad or wrong ideas are quickly discarded.

• Key resources and partners: Describe the critical internal and external people, equipment, or resources needed to deliver the solution to the customer.
• Revenue/business value: Describe the business value of delivering the product, service, or capability. Consider what will drive revenue, save money, increase customer satisfaction, differentiate you from your competition, improve market positioning, and more.
• Cost structure: Describe the important costs inherent in the product model. Identify what will be most expensive, for example, resources, activities, development, marketing, or support.

Using the foundation of a product canvas not only helps the team to better understand the customer and desired outcomes but also enables the product owner to build a concise yet strategic product vision statement with a supporting product roadmap.

Customer map

Other customer-focused mapping tools can be powerful visualization activities for a team seeking to better understand its customers. We introduce two common customer mapping tools: a journey map and an empathy map.

A journey map helps the team visualize the day-to-day experience a customer goes through when accomplishing a goal or addressing a specific problem. Goals are followed by actions in a timeline format, by calling out the user’s emotions or thoughts. The journey map creates a narrative. The insights gained inform product designs. This figure outlines the flow of a journey map and the relationships between the customer's goals and his or her steps, insights, and emotions.

An empathy map helps the team think through the user’s emotions and senses. It explores what the customer sees, hears, thinks, feels, and does. It identifies pain the customer experiences and how the product can give the customer the gains he or she seeks.

Teams build customer maps together, learning and digging deeper into their customer’s needs, motivations, and challenges. They openly discuss their perceptions, observations, and insights to validate their understanding along the way.

Job-to-be-done lens

Jobs theory, developed by Clayton Christensen and the Harvard Business School in response to his overwhelmingly popular theory on disruptive innovation, refers to an approach used to discover functionally, socially, and emotionally why customers make the choices they do. According to the theory, products and services are hired to help the customer make progress. They call the customer’s progress the job-to-be-done, which when understood enables significant innovation. Beware that if a product can be hired, it can also be fired.

The jobs-to-be-done approach adheres to four principles:

• Job is shorthand for what an individual really seeks to accomplish in a given circumstance. Product development teams need to understand the experience the customer is trying to create, which is not a straightforward task.
• The circumstances are more important than customer characteristics, product attributes, new technologies, and trends. This principle speaks to seeing the innovation through the lens of the customer’s circumstances.
• Good innovations solve problems that formerly had only inadequate solutions—or no solution. If customers see only two options, a third option that addresses all the relevant criteria can help fickle observers become customers.
• Jobs are never simply about function—they have powerful social and emotional dimensions. Understanding the social and emotional dimensions of a customer’s choice makes all the difference in the customer's purchasing decisions.

Christensen shares how viewing products through the jobs-to-be-done lens significantly increased sales of his sample populations. Specific examples he cites include milk shakes, condominiums, and even Reese’s Peanut Butter Cups.

Product development teams use the job-to-be-done theory throughout their product development, particularly as they evaluate the timeline from when customers identify a need to their purchase. This figure shows an example job-to-be-done timeline. Close interactions with stakeholders and customers help validate their assumptions.

Product development teams can benefit by considering the job their product or service must fulfill for the customers. Better understanding the job-to-be-done requires customer interviews so you can truly understand their needs.

Customer interviews

What better way to understand a customer's needs than to talk to the customer? Teams interview customers because they value “customer collaboration over contract negotiation” and “individuals and interactions over processes and tools.” Customer interviews are critical for enabling progressive elaboration techniques such as decomposition and story mapping.

The key for performing a successful interview is to get customers to talk by allowing them to tell stories about their problems and imagine possible solutions. You escape from your perspective into the customer’s. Interviewees will discover things they didn’t know and interviewers will discover whether they're making wrong assumptions. Consider the interview as an opportunity to validate the team’s assumptions and to vet both good and bad ideas.

This table outlines the types of questions interviewers should and shouldn’t ask.

The types of question on the left invite storytelling. They encourage the customer to answer beyond any biases you may have. The examples on the right give significant constraints to customers on how they can answer the question, and don’t encourage much conversation or storytelling. Instead, get them talking.

Product discovery workshop

Product development teams use product discovery workshops to gather product ideas and insights from stakeholders and scrum team members. These workshops have many different formats and applications.

Workshops, if done correctly, allow creative juices to flow. What is key is creating a safe environment where ideas can be shared openly. Timeboxes (setting a time limit on the discussion) for topics are helpful, as well as plenty of Post-it Notes and markers, and the freedom to diverge, converge, explore, and discover.

Some people, especially introverts, find that receiving prepared agendas beforehand is helpful for getting their thoughts flowing. Agendas can also help everyone to arrive prepared and ensure that the workshop objectives are accomplished. Be careful to not use the agenda to provide excess structure, however. Lightweight structure, particularly with workshops, can help the discussion go where it needs to go.

The frequency and participants of the workshops depend on the team, the product, and the problem to solve.