Jake stops at his favorite Starbucks off the Temple Place Tube station to pick up a latte, no milk, on his way to office. He works at the corporate headquarters of a large global financial institution in the city of London. Today is a big day for him because they are finally rolling out a private home loan product that has been 18 months in the making.
Jake is the business analyst, which means he was responsible for gathering the business and user requirements for the product. He spent three months creating the business requirement document (BRD), a hefty, 60-page document that detailed the specifics of the product.1 Later he supported the program manager in overseeing development of the product features. The product was created in Bangalore, India where the bank’s engineering uses an agile delivery approach. Initially Jake submitted the BRD for approval and later throughout the project he communicated the requirements to a London-based business analyst from the engineering side, who in turn communicated with the system engineer in New Delhi, India who was managing the engineering team in Bangalore.
When Jake entered the marble floored lobby, he saw Sarah, the program manager, and Janice, the VP of product; they looked distraught. He approached and could hear that they were speaking with a branch manager of the bank at a branch that opened early on Mondays. The new product, deployed with much fanfare, was a total blowout.
Similar feedback was received throughout the first week: the product was failing, users couldn’t navigate the menus, and required functionality was either missing or broken. The bank’s executives were upset, to say the least; they invested in agile project management in order to prevent these mistakes. What happened?
What I Read
You have to start with the customer experience and work backwards to the technology.
—Steve Jobs, co-founder of Apple Inc.2
What Happened When I Tried Implementing in Big Corporations
Bigger organizations find it difficult to focus on the consumer.
First and foremost, they’ve been in business for years, they make money, and they are comfortable within the confines of the organization; they don’t feel the need to interact with a consumer. Going outside of the office and actually asking a customer what they want is something they just don’t do. The concept of gemba is foreign to them.3 Most of them are convinced that they are not allowed to do it, that it’s the job of others to interact with consumers. The same is true for developing solutions for internal consumers; the prevailing mindset is “it’s not our job to ask questions.”
Inside-out thinking is a recurring challenge for enterprises. For example, traditional insurance companies focus on making it hard for the consumer to receive their money when submitting a claim. This isn’t a specific hurdle but rather a mindset of the insurance company around which many of the internal processes are built. They make it hard to issue a claim, they make it difficult to get support on the status of the claim, they instill an internal mindset in which the consumer is dishonest, they follow through with slow response to consumer requests, they require paper and fax be used rather than email (blaming regulation); the list goes on and on.
Implementing outside-in thinking in these organizations is more than a well-designed exercise in creating a persona. Rather, it is an ongoing battle to break free from the prevailing mindset of “the consumer is our enemy” and “there’s a zero sum game between us and the consumer” to embracing collaboration with the consumer. The only way to truly embrace “start with the customer in mind” is through the construction of a concrete persona. Having executives participate in sessions with real people as part of structuring the persona has a tremendous impact and leads to true empathy; the outside-in thinking usually follows.
Anti-Pattern
In many cases, there is an assumption that people who create software know what their customers actually need. There are two problems with that: the first is assuming that there is a single homogenous customer type. There never is. There are multiple customers with conflicting demands and preferences, so it is important to identify their types and make decisions about who your customers actually are. Second, you can’t know what the customers need until you talk to them and ideally give them a prototype to try out and provide feedback on. Fall in love with the problem, not a solution. It is only through empathy and trial and failure that you can get practical feedback from your customer, not by imposing the proposed solutions and hoping that they will resonate with the customers.
They’ve been operating for years with the same approach, and most likely this is an inside-out view of the market, which is contrary to embracing a consumer-centric point of view.
They merely develop products for external consumers. Other people gather requirements for these products, so when they get it wrong, it’s their fault!
They develop products for internal users that are less “fancy” and don’t require all the “fluff” of customer focus.
They are not a startup.
They are not Apple.
It is true that bigger global organizations find it more challenging to embrace this concept of focusing on the customer since they have existing frameworks in place as well as regulations and stipulations that stand in the way of delivering what customers need; and it is true that they are not startups and that not all organizations can be Apple. BUT, in today’s competitive environment, they have no alternative; they must align to the customer or perish.
Think John Deere
When I hear big corporates tell us that they can’t focus on the customer in the true sense, I am reminded of a conversation with a German petrochemical engineering and manufacturing conglomerate in Manheim. I received a call from a senior manager in product development; it was the same company that I delivered lean workshops to years before. He asked for help with a lean transformation and implementing a consumer engagement model, since the company was struggling with both. I asked, “You’re a company with 150 years of corporate baggage, why do you want to undergo this transformation?” He replied, “We don’t. We really and truly don’t, but we have no choice because John Deere is kicking us to the curb.”
John Deere as a lean transformation role model might surprise you because as it is a corporation headquartered in Blackrock, Illinois, not a fancy Silicon Valley technological giant. John Deere embraced lean agile thinking in development. In an interview, the John Deere Scaled Agile transformation leader shared that there is never a good time for significant change, and sometimes it seems easier to continue to do what you have always been doing. But the world is changing rapidly, and the customers and market demands that the company change too.
What I Learned as I Adapted the Concept in a Corporation
Remember the example of the bank?
When I analyzed the failure of the product with Jake, Sarah, Janice and the executive leadership, I sensed their aversion to startup terminology, so we had to dress the concept of starting with the customer in mind in a way that was less threatening and more in line with their thinking.
We discussed the business requirement journey: the number of handoffs that a requirement makes between the customer and the engineering team. Actually, while a requirement was referred to as a “requirement” on the business side, it was termed “user story” by the agile development team. By the time the team was working on the user story, it had been handed off four times, translated from English to dev-speak and some Hindi, so it lost most of the context.
The development team in Bangalore, true to agile practices, participated in backlog grooming4 with the System Analyst in New Delhi and occasionally with the Business Analyst from the IT side in London; however, they were twice removed from the internal customer of the system, the user at the bank. At no time during the 18-month project did the development team get a chance to receive feedback from the user; it was always through proxies.
No wonder the product failed.
What I Implemented
We were constrained by the distributed team, the language barriers, and practices that the bank had in place that made it difficult to focus on the customer.
How do we minimize the mileage of the requirement journey?
What is the minimal team interaction that is required to gain a better understanding of the requirement?
Who should be a part of the team?
What format should we use to communicate our requirement discussions?
What are the agreed definitions for requirements, user stories, capabilities, features, epics, etc.?
Focus on the most impactful horizontal interaction between the people who develop the product and those who will be using it, and enable communications on a weekly basis.
Create, refine, and relate to a persona.
The first was based on observations we had concerning collaboration with users and customers at big organizations. Collaboration often occurs at the initiation and completion of a big project, involves a large group of people, and doesn’t allow time for emphasizing with the user or customer. The Bangalore team might have interacted with users once at the beginning of the project, but this interaction was limited in scope, controlled top down by the business analyst, and wasn’t a two-way conversation.
Instead we suggeted that the team engage in discussions as the product was being built between users, marketing, sales, engineers, operations, and others based on the need. The meetings were framed as a discovery process; the team was encouraged to be curious about the users’ experiences and environment.
The second adaptation was using a lightweight persona as a method to develop understanding. Persona development is an increasingly popular and effective tool in designing web interfaces and is espoused by design thinking and more recently Lean UX. Personas are constructs produced by analyzing and aggregating the characteristics of users and building them into profiles of typical users. The traditional versions take a lot of research and time to put together and analyze in a scientific and meaningful context. More often than not the tool tends to be limited to user experience experts and product managers.
The team adapted the practice to include a wider audience both in discussing and structuring the persona, and later on referring to the persona when making important decisions concerning the functionality of the product.
The team created a persona they called Tim the banker . Notice that by merely identifying gender and name they limited the problem and solution options. Actually, by giving a persona a name the team uncovered many assumptions about the behavior, experience, and aptitude of the user.5 The persona in itself provides opportunities for assumption validation, which I discuss later in the book.
Among other benefits in using a persona rather than quoting demographics is the increased level of intimacy the team develops with the user. The team brainstormed various aspects of Tim’s work and social experiences. They focused on his day at the bank, what is he trying to achieve, what is challenging him, and what tasks he needs to get done.
When Jake, Sarah, and Janice prepared for the next project, they had a framework to start with the customer in mind and they kept the persona center stage while the agile development team created the product.
Key Learning: Starting with the customer in mind is crucial in aligning what we develop to what people need and removing feature waste. While straightforward in smaller organizations, it can be adapted to corporations by tweaking it in such a way that the team has direct contact with their customers throughout envisioning, development, and further product enhancements.
Tip
When creating personas to represent customer types, there are several non-negotiables the teams need to keep in mind:
1. Personas need to be well described. In the bank example below, creating a “customer” persona would not be helpful. It is important to collect as many details about Tim as possible: how tech savvy Tim is, what drives his behavior, what computer system he uses, if he prefers a mobile phone to a laptop. What are his drivers: Ease of use? Reliability? Time? Is he a decision-maker in major areas? If not, who is? Then I would create a manager persona, an auditor, and so forth.
2. Personas need to be very specific. There is no generic customer. There is Max the Millennial who invested in several successful startups. Max has his platinum account with the bank. Max uses mobile devices and keeps all his data in the cloud. Max does not care about graphics as long as he can access data easily and quickly. He also wants the app to be modern and sleek and provide maximum functionality for using digital payment media. There is also Ted, a retired accountant who accesses the application from a desktop in his apartment. His vision is not as good anymore so he is looking for accessibility features. He hates new graphics because it disrupts his user experience and does not like when new features are introduced because it requires adjustment. Max and Ted require different user experiences and some of their expectations are contradictory, so it is important to identify the actual customer.
3. Go out of the building and research who the customer actually is and whether they have the need you are trying to address. In many cases, we assume personas and their needs without actually talking to them. As an example, a test prep company saw students as their primary customers. They went out of their way to tailor their product to the needs of multiple user types: a fresh high school graduate, someone with a work experience, a graduate student, a law student, a medical student, etc. When they went out of the building and started asking how the decisions were made, they found out that for several of these categories, it was not the students who were decision makers, it was parents. So, while both categories cared about proven results, students cared about sophisticated interface and well-designed test practice, and the parents cared about functionality that would allow them to view the progress of their kids and how much time they spent using the software. And in case of high school students, there are parents who make purchasing decisions related to their kids’ test prep course. The only way to find this out is to go out and actually speak with both groups.
In essence, whether you are starting a new project or are attempting to enhance an existing one, start by identifying the right customers and developing customer personas. And once you do, refine the personas continuously as you learn more and more about your customers. Place persona pictures and descriptions of their “journeys” as “information radiators” around your office and on your intranet and let your employees empathize with them and their stories. This will take your product to the next level and increase employee motivation at the same time. Note that persona descriptions are specific to the needs of your business.
Besides being a useful product-building exercise, persona creation is a way to align the organization with who the stakeholders see as the primary users and what the interests of this person are. I recommend a two-step exercise, which can be done at executive level as well as within the delivery organization. Step one is to identify your personas and create “persona cards” and then share and align on a single vision as a team or the company. Step two is to go out of the building to validate your assumptions about these personas based on your analytics and call center experience; reach out to these users, individual customers, and institutions, and reconcile your assumptions with reality. The results are frequently eye opening.
Tip
Review the description of Max the Millennial depicted in the section below. All persona descriptions are business-specific. What business do you think the company is in that created this persona?
Sample Persona: Max the Millennial
Max the Millennial
Max the Millennial is tech savvy and socially aware. He cares about doing the right things for society while being thoughtful in his investments. He performs basic banking functions through digital channels. He needs up-to-date information and does not care much about personable customer service because he is doing all transactions via his Mac or his iPhone app. He cares about application performance and sleek app design as well as all modern payment media.
In his 20s. Max uses mobile devices and keeps all his data in the cloud. Max does not care about website graphics as long as he can access data easily and quickly. He also wants the app to be modern and sleek and provide maximum functionality for using digital payment media of all sorts. In the last two years, he never visited a bank in person–no need, since he values his time and the convenience of digital transactions.
Max lives in a rural area in close proximity to a large city so he is in the market for a new car (he prefers leasing one). He does not take risks but is open to experiments in his investments and spending. His loyalty is to people, not institutions, so if another bank offers better services, charity contribution opportunities, or has a reputation of being socially responsible, he will gladly switch, as long as the process does not require a time investment on his part.
Three words to describe Max: financially solid, tech-savvy, traveler.
Name: Max
Age: 27
Lives: NJ
Education: M.S.
Occupation: Programmer
Anti-Pattern
In many organizations, personas are treated as a sign of being “modern:” pictures are laminated on the wall and persona stories are included in employee booklets. Personas are as living and breathing as the people who they represent. Avoid creating static types of your users and customers; think of them as continuously evolving as the customer persona evolves along with a company’s understanding of the target audience and their needs.