Empathy for the Customer

Introduction

A purposeful architect is searching for a diagramming software tool. She plans to use the tool to show customer stakeholders and developers what a proposed solution looks like. She wants to find the best tool, but has limited time to look through what’s available. She realizes a college classmate is a product manager at one of the software candidates. She contacts him and arranges a meeting to discuss how his company’s tool could meet her needs.

A Promising Meeting Takes an Unexpected Turn

At the meeting, the purposeful architect and product manager catch up on what’s happened since college. The product manager started in development, then took an opportunity to go into product management. He looks forward to controlling what goes into the product rather than building what he’s told. The purposeful architect wonders to herself if he really believes he will control the product. 

The product manager launches into a speech about what makes his diagramming tool so great with all its cool features. He proclaims the tool “has more features than Visio.” The purposeful architect listens in disbelief, as he hasn't asked a single question about her needs and continues his soliloquy of the tool’s features. She gives him a red flag in her mind.

When the product manager finally takes a breath, the purposeful architect asks him if he has any interest in what she needs from his company’s diagramming tool. He claims the tool will meet her needs with all its features, but takes some interest in what she has to say. The purposeful architect says she needs to diagram process flows and data relationships as easily as possible. She would use the tool occasionally and does not want to relearn it every time she uses it. The product manager frowns, admitting to feedback he has received from customers about how long it takes to learn the tool. He opens a requirements template on his laptop to capture what the purposeful architect needs.

The purposeful architect describes to the product manager what she needs from the tool, including specific use cases. The product manager asks her to slow down so he can fit what she’s saying into his template. The purposeful architect feels her frustration rise as she looks at her watch. She gives him a second red flag. She suggests the product manager record their conversation, so he can catch up later. He expresses concern that recording a conversation could violate company policy. 

The product manager asks the purposeful architect if she would write her use cases and send them to him. She replied that she had already told him her use cases and he missed the opportunity to capture them. She gives the product manager his third and final red flag. 

The purposeful architect sighs as she stands up. She cannot believe that the PM wants her to do his job. She cuts the meeting short, recommending the product manager shift his focus toward the company’s customers and what they need. 

Lessons Learned

The purposeful architect reflects on the mistakes the product manager made in the meeting. She had experience with customer stakeholders pulled by solution gravity, anxious to design a solution before covering all their needs. She had not seen a product manager gravitate to a solution before getting some idea of what the customer needs. The product manager was eager to please with what he had, instead of fulfilling the purpose of the meeting, listening to what the customer needed. 

The product manager disrespected the customer’s time and attention by leading with features and having an initial reluctance to learn what she needed from a diagramming tool. He didn’t ask the purposeful architect what she needed until she prompted him. Then he squandered more of her time trying to fit her needs into his template. He missed opportunities to follow up with her about what she needed, while making the template and company policy seem more important than her. She tried to help him by suggesting he record the conversation. He should have offered some means to capture her needs without wasting her time.  

The purposeful architect had enough when the product manager asked her to capture her own use cases. She had already taken the initiative for him to ask what she needed. She had to take the lead again, asking him to record their conversation instead of struggling with a template. If she provided him with her needs in writing, what initiative would he take to understand them?

The purposeful architect vows not to offer a solution prematurely in discovery, even in the rare case it turns out to be a perfect fit. She will capture customer needs efficiently without interrupting the flow of discovery. She will take any information the customer offers about their needs, taking responsibility for capturing the rest of their needs. Her regret for the meeting faded as she realized the experience gave her insight into how discovery looks from the perspective of a customer stakeholder.

Assuming the perspective of customer stakeholders through discovery results in a better understanding of their mindset and needs, leading to a more beneficial solution.