It’s not about achieving Agile for Agile’s sake. It’s about delivering customer value and achieving better business outcomes.
—Mario Moreira
The most important ingredient in understanding customer value is precious customer feedback. A customer-value-driven (CVD) enterprise is a company that optimizes for what the customer finds as valuable and adapts until this outcome is met. As you look to build a CVD engine within your enterprise, the customers and, specifically, their feedback are the “driver” that steers the engine of customer value.
Gaining customer feedback along the delivery axis is crucial, from the Record stage to the Reveal stage to the Refine stage to the Realize stage to the Release stage and, finally, to the Reflect stage. Feedback should be collected more than once, and it should always be incorporated. It must be collected, considered, sorted, merged, and applied toward customer value on a continuous basis.
As a reminder, who is a customer? A customer is someone who has a choice of what to buy and a choice of where to buy it. A customer is someone external to the company and pays money to help you stay in business by purchasing your product. Consequently, engaging the customer is of utmost importance. When talking about customer feedback in this chapter, we are referring to people who are outside of the company who have the choice of buying your product and, hence, providing revenue to the company.
Throughout this chapter, I will discuss incorporating feedback loops along your delivery axis, constructing personas, embedding personas, and creating a customer feedback vision. By doing these things, you can more systematically understand your customers and engage them during many meaningful moments to receive their precious feedback.
Customer Feedback Loops
Feedback loops are specific points along the idea pipeline where the output received from one activity is used as input in the next activity. In the case of building an idea, feedback from a customer who has attended a demo is used as input in the next planning session to adapt the direction for the product or idea.
Agile Pit Stop
There are two types of feedback loops. Verification ensures you are building the product right, and validation ensures you are building the right product.
Feedback is the result of an activity and can be termed as testing an idea. There are two primary types of testing: verification and validation. Verification testing provides you feedback to help determine whether you are building the product right and that it works as designed. If the button is supposed to take you to a new location, verification testing will check it and provide feedback on whether it does or not. The testers in most verification testing are employees internal to the company.
Validation testing provides you feedback to determine if you are building the right product and are satisfying the needs of customer. If the user story says to build a button, then validation testing would ask the customers if they are satisfied with the button, providing the enterprise with customer feedback to understand if the product is adequate or if a change is needed. In this case, the testers in validation testing are meant to be customers who are external to the company. Customer feedback loops are, therefore, a type of validation test to ensure you are meeting the needs of customers.
Customers delight in seeing working product in action and the inspect-and-adapt approach allows customers to consider and adjust their needs until they are transformed into a valuable working product. Feedback loops should be considered all along the delivery axis of the idea pipeline, as illustrated in Figure 14-1. The outcome of each customer feedback loop informs future decisions and product direction. As a note of caution, a non-disclosure agreement (NDA) may be needed with external customers prior to sharing ideas as part of any feedback loop.
Figure 14-1. Feedback along the delivery axis
Mindset behind Customer Feedback Loops
The concept of learning what the customer considers valuable is an important mindset in the journey to customer value. This learning allows you to shed the dangerous attitude of pretend or arrogant certainty and allows you to explore what the customer needs. The best approach is to incorporate the concept of learning through feedback to identify what is customer value. This is a discovery method of gaining incremental information through customer feedback loops and taking what you learn to continuously adapt toward customer value.
The goal is to have as many customer feedback loops as feasible. This can be challenging and, in some Agile efforts, the result is few if any customer feedback loops. Customer feedback can be an uncomfortable endeavor in that it can frustrate those who’ve invested time into a building a product. It requires a mature and willing mindset to collect, consider, sort, merge, and apply the feedback to get closer to customer value.
Agile Pit Stop
Establishing customer feedback loops consists of part mindset and part practice. You need to believe in the importance of customer feedback to achieve customer value.
To prevent frustration and pride of ownership when a lot of time has been invested in working on a product, apply short iterations or periodic timeframes where demonstrations occur more regularly. This limits the investment of time before it gets reviewed and ensures you don’t move too far in the wrong direction before customer feedback is gained.
As simple as it sounds, embrace the fact that customer feedback is a very positive outcome, ensuring the betterment of the product and company success. If you are used to a process where you sub-optimize for following a plan over responding to customer change, then responding to change by accepting customer feedback can be a tough mental shift. The answer is to develop a discovery mindset that is always willing to collect customer feedback.
Also, spend time identifying the best feedback loops for the effort and construct a sound vision for customer feedback. As you consider the best customer feedback loops for your effort, look for places along the delivery axis where getting feedback is of high importance and low effort. A good example is the Web-based sprint review or demo. Customers can observe the demo in a low-effort manner from the privacy of their office or home.
Types of Customer Feedback Loops
There are many types of customer feedback loops that can be applied as the idea travels through the enterprise idea pipeline. The most common customer feedback loop is the sprint review or demo where customers view the working product developed to date. As illustrated in Figure 14-2, there is a list of customer feedback loops with details that you should consider applying to build a stronger path toward customer value.
Figure 14-2. Various customer feedback loops through the delivery axis
During the Reveal stage, share the idea on a Lean Canvas or Customer Value Canvas with customers. Then walk through the idea with customers to see if the idea’s manifestation is what they had in mind or if it is something that they would find valuable. The goal is to understand if you are moving in the direction of customer value.
During the Refine stage, play the “Buy a Feature” game referenced in Chapter 12 to help POs choose the features to include in an upcoming release that would be most valuable. In this game, the players (customers) use play money to buy and negotiate for features they find most valuable. The goal is to understand what customer value looks like to customers.
During the Refine stage, bring in customers to review the user story map prior to cutting an increment. Highlight the backbone and process in order to validate the customers’ experience path. Then walk through the options to gauge their level of interest and to see if some options are more compelling than others. The goal is to move in the direction of customer value.
Agile Pit Stop
Customer feedback loops can be applied along the delivery axis from five stages: Reveal to Refine to Realize to Release and, finally, to Reflect to help you move toward customer value.
During the Realize stage, invite customers to the sprint review or demo. This is a type of feedback where the team or PO demonstrates the working product completed during the sprint to customers in order to highlight progress and gain the all-important customer feedback. The goal is to have demos periodically so adaptions to customer value can occur regularly. The goal is to move in the direction of customer value.
During the Realize stage, invite customers to participate in a hands-on customer-experience activity. This is a type of activity where customers experiment with the product in a hands-on manner in a simulation or pilot environment. Such activities may be a form of a customer or user experience exercise and may be known as alpha or beta. The goal is to gain usability and satisfaction feedback.
During the Release stage, for those on-premise products that require installation, ask customers for product-installation feedback. This is a type of validation where customers physically install the working software into their environment. This can apply to customers installing a product onto servers or mobile customers downloading an app. In both cases, receiving technical and satisfaction feedback is beneficial.
During the Reflect stage, the idea has made its way to the public. This is a time to collect an array of feedback: how well it is doing in the market, how many customers have paid for the product, if the deliverable is satisfactory to customers, if the product is being used as advertised, and more. Primarily, the goal is to capture revenue data, market share data, and customer satisfaction data to ascertain if it is perceived as valuable to customers.
As you look at possible feedback loops, the question is not about having a lot. The question is about having feedback loops at points where they can help you understand customer value. Some feedback loops may return less feedback value than the effort it takes to establish them. Look for the “high feedback value, low effort to establish” feedback loops first.
Building Customer Personas
When you are building a product, how well do you know your customers? Can you visualize who they are? Do you understand their motivations? Do you have user stories for all of the customer types that may use your product? By knowing who your personas are for the product that represents your idea, you can answer yes to these questions.
Personas represent specific users for your product or service and act as examples for the types of users who would interact with it. Most products have several personas that use the product in different ways. Examples of three personas for a banking product are Erin the Senior Citizen, Sunny the Gen X-er, and David the Gen Y-er.
Erin the Senior Citizen represents customers who use very basic user interface functionality to conduct straightforward tasks. They primarily use a computer or work with tellers to conduct their business. They are primarily motivated to check balances and extend their investments.
Sunny the Gen X-er represents customers who need more complex interface functionality to handle sophisticated tasks. They are technically savvy on the computer and less so on the mobile phone. They are primarily motivated to do more banking on the phone to take advantages of opportunities.
David the Gen Y-er represents customers who can work on both simple and complex interface functionality. They are technically savvy on the mobile phone. They are relatively new to investment and are motivated to understand investment practices and for ways to invest their money.
All three customer personas use the product differently, and diverse features are designed for their respective needs. Personas are a powerful way to guide your decisions about functionality and ensure that you are, in fact, building functionality to help each persona. Personas are a key ingredient in the way user stories can be presented. Including the persona in a user story description provides you the point of view (POV) and defines who the user story is for. Typical information in a persona includes the following:
Fictional name with function
Demographics: age, gender, education, and family status
Background, responsibilities, and experience in story form
Motivations that drive their ideas and behavior
Pain points that show the areas of frustrations that impact them
The goals or job to be done
A quote that sums up what matters most to the persona
Casual picture representing that user group
I recommend that you establish a persona for each persona type. This description typically portrays a fictitious person who represents a real role. Writing a persona as a fictitious person with a name makes the persona easier to imagine and relate to as illustrated in Figure 14-3.
Figure 14-3. Example of a persona
Typically, the product owner constructs a persona. Personas should be initially considered as early as the Record stage, should be drafted in the Refine stage, and should be shared with the team so team members better understand whom they are building the idea for. Afterward, the personas should be posted in the Agile team or work room where refining, grooming, planning, and other Agile team events occur. They should also be shared with those stakeholders involved with prioritizing the work in the Reveal stage.
Agile Pit Stop
Jobs to be done shift your focus from the product and to the job that product can do for the customer. It isn't a calendar. Its job is to remind you of appointments.
Consider establishing personas for your products so that you can understand the customer point of view when evolving the idea from the Reveal stage to the Reflect stage and build a product that better aligns with customer needs.
Personas of Today and Tomorrow
Customer value comes in two parts. The first is understanding the customer of today via personas. This is having the pulse of the customer and the marketplace as you continually receive and adapt to customer feedback. It takes a creative, yet disciplined, focus on what you think the customer needs and where you think the customer marketplace is going.
The second is understanding the customer of tomorrow. This can be crafted in the persona called Customer 2.0, which is the customer of tomorrow, and looks to find out what you think they want and what they don’t yet know they want (unknown unknown) to help with future product direction.
Agile Pit Stop
Customer 2.0 is the customer of tomorrow that you are aiming for.
An example of an unknown unknown is the large smartphone. Who would have guessed that, as the market was moving to smaller and smaller flip phones, customers would move to larger phones? An example of a known is customers wanting their apps better integrated. During the Refine stage, you may establish a part of your idea or backlog of work to integration work. Customer 2.0 can be aligned with the future perspective of a product vision and help you adapt personnel and tools toward that vision.
Customer 2.0 is a unique type of persona known as the “future customer.” While it may be hard to identify people that fit into this persona, you can look for people who are trendsetters searching for the cutting-edge technology or products. While Customer 2.0 is focused on the future, your primary focus should be on the needs of the customer of today with a secondary focus on the needs of the customer of tomorrow. Immediate customer feedback should drive a majority of your decisions.
Using Personas from Record to Reflect
Personas can have a significant benefit along the delivery axis to ensure what is being delivered is of value to the customer. The main benefit is that anyone associated with the idea will better understand the customers and users, which helps guide better decisions about the functionality. In order to effectively apply the intent of the persona, you must embed the concept of personas all along your delivery axis, as illustrated in Figure 14-4.
Figure 14-4. Using personas along the delivery axis
As early as the Record stage, personas should be considered to gain an understanding of whom the idea is meant for. If you use any of the canvases discussed in Chapter 13, there is a specific block for personas (that is, customer segment).
In the Reveal stage, personas could be used to help drive prioritization decisions. Particularly for existing products, there may be a specific persona that needs significant attention, which helps drive prioritization. For example, if the mobile interface is currently complex and geared to David the Gen Y-er (as early adopter) but you need to adapt it to Sunny the Gen X-er, knowing the Gen X-er persona can help with Sunny’s experience.
In the Refine stage, a specific persona may be used as the reason to cut a first increment of the idea. When you consider the user or customer experience, is there a specific persona that you are targeting? For example, David the Gen Y-er may have a different customer experience or pathway through the mobile interface than Sunny the Gen X-er.
In the Realize stage, personas should be part of the user story construct. This ensures that a persona is written into the user story. It also helps teams understand who the requirement is being written for. For example, Erin the Senior Citizen may require a simpler mobile interface than Sunny the Gen X-er.
In the Realize stage, testers can create acceptance tests and test cases that support the way specific personas might use the product. For example, the test case of how David the Gen Y-er may might use the mobile interface is different from the test case of how Sunny the Gen X-er might use the interface.
Agile Pit Stop
Ensure you gain feedback from the right persona because feedback from the wrong persona can lead you down the wrong path.
In the Realize stage, based on personas, the product owner knows whom to invite to the reviews or demos to gain the best feedback. This is particularly important as the feedback from one persona can give you bad feedback if the feature is meant for another persona. For example, feedback from David the Gen Y-er will give very negative feedback about functionality meant for Erin the Senior Citizen. In fact, for every feedback loop of any kind, you need to consider the right persona group(s) to invite.
In the Reflect stage, when you collect revenue data, market share data, and customer satisfaction data, it can be beneficial to attempt to understand what personas the data are coming from. If, for example, you learn that 90% of your revenue is coming from Sunny the Gen X-er, then during future prioritization decisions in the Reveal stage, this information can be factored into what gets built.
Customer Feedback Vision
The composite of thinking through and establishing a serious feedback approach for ideas, along with feedback loops and personas, is something I term as the Customer Feedback Vision. Unfortunately, serious thinking and applying feedback loops are missing from many product teams professing to be Agile. Most customer feedback in Agile is limited to the demo and often customers are not in attendance. Customer feedback is the guide for customer value and should be taken far more seriously.
The goal of the vision is having a place to capture the thinking behind applying customer feedback. This simple vision includes building personas, establishing feedback sessions, identifying the companies, and finding ways to motivate the customers to attend the feedback sessions, as illustrated in Figure 14-5.
Figure 14-5. Example of a Customer Feedback Vision
This vision should be owned by the Product Owner and live with the product. Once established, the vision should be shared with the team so that everyone is aware of the vision and the importance of the validation activities. The Customer Value Canvas can be used as a starter home since feedback loops and persona blocks are included. If you currently don’t have a place for formulating and establishing a feedback vision, then the Customer Feedback Vision should be used.
Are Feedback Loops Leading to Customer Value?
As you look to build a customer-value-driven (CVD) engine within your enterprise, the customer or, more specifically, customer feedback, is the “driver” that steers the engine of customer value. A CVD enterprise optimizes for what the customer finds as valuable and adapts until it meets this outcome. This means gaining customer feedback all along the delivery axis is crucial. Feedback must be collected, considered, sorted, merged, and applied to guide you to what the customer finds as value.
In pursuit of customer value, implementing effective feedback loops form the backbone for a CVD engine. Establishing personas help you and all those involved to gain a strong understanding of whom you are building for. Embedding personas along the delivery axis ensures that the right customer(s) is being focused on. Remember, you can get feedback from the wrong persona, which can lead you away from customer value. Knowing what persona(s) you are focused on will provide a stronger focus toward delivering customer value. Packaging your feedback approach into a Customer Feedback Vision can help you consider feedback elements leading to more meaningful customer feedback.
For additional material, I suggest the following:
VFQ Feedback by Emergn Limited, Emergn Limited Publishing, 2014
Buyer Personas: How to Gain Insight into your Customers Expectations, Align your Marketing Strategies, and Win More Business by Adele Revella, Wiley, 2015