I spend a lot of time sifting through documents, positioning and stories – trying to figure out who we’re talking about. As a product manager, I think it’s my obligation to bring clarity and precision to discussions… so talking generically about customers or users can be exasperating. Especially in B2C or B2B2C markets where our tech is part of a long value chain: perhaps our software helps some employee collect data to tune a service that improves delivery of some consumer product…
Creating real-world value is a multi-step process involving many players. And it’s exhausting prefacing every conversation by (re)defining terms: “for this user story, the customer is the sys admin who configures our CAD software, not the architect sketching out buildings. See personas 4 and 7.” Wasted energy. So let’s abandon the words ‘customer’ and ‘user’ entirely, and be more explicit about who/what we mean.
If we’re building analytics software for brick-and-mortar retail chains, then we sell to retailers who have shoppers or consumers who visit those retailers’ locations or branches. Talking about the generic ‘customer’ generates unnecessary confusion among Sarah Sue Shoe Shopper; her sales associate in Nordstrom’s downtown Toronto shoe department; Nordstrom’s Seattle-based merchandise analyst tracking shoe fashion trends; and the Marketing VP invited to our Customer Advisory Board. Let’s say sales associate when we mean sales associate.
If our software helps Big Pharma speed up their FDA approvals of new blockbuster drugs, then we might sell to drug trial planners within Medical Affairs departments of major pharmaceutical companies, who recruit outside opinion leaders (researchers at famous medical schools) to influence health systems and medical practices (which employ doctors), who then identify patients qualified for clinical trials of new drugs. You say potato, I say WTF.
If we provide credit scores to our users, we’ll need radically different products when our target is an online consumer wanting to boost her FICA to qualify for a better home mortgage; or a bank compliance officer reviewing corporate line-of-credit applications; or an API feeding millions of credit scores to an algorithm at a credit card company that chooses which million consumers get pre-approved Platinum Card offers. Bonus points for clarity.
This isn’t (just) about precision or time savings or linguistic fussiness. I see much broader wins:
Our technical teams often make the “I am the user” mistake: we unconsciously assume that the people at the other end of our software are just like us. Frequent reminders about our specific audience (‘brick-and-mortar retail shoppers trying on shoes and clothes in stores’) can help our (mostly male, mostly online-shopping, mostly sneaker-wearing, mostly fashion-uninterested) developers notice that store associates know things we don’t – such as how much those red-lacquer-soled shoes cost. Or how to walk a mile in them.
- Being more specific also gives us an opportunity to connect our teams emotionally to our (ahem) users. Rather than tossing stories over the digital wall, we can talk about how our products help retail store managers or cancer drug scientists or credit card marketers meet their own goals. Connect the work-at-hand with WHY a specific audience needs it and HOW they measure success. (Will your team be more motivated if they come in tomorrow to write some SQL queries, or to help cancer genomics scientists isolate the next killer gene?)
- We encourage our teams to focus effort where it matters most. If corporate Accounts Payable managers and corporate Accounts Receivables clerks represent 98.5% of activity in our corporate finance application, then a once-per-year configuration option for the security administrator can be relegated to some obscure dialog box. I secretly love when my teams call me out for bikeshedding.
- The rest of our company adopts our internal language. If we call our internal prototype a Deterministic Unified Modulation Binary, then Sales will soon be telling prospects about Deterministic Unified Modulation Binary. Then immediately shortening it to DUMB. Terrific if we could instead call it Worldwide Onboarding Wizard from the very first discussion…
Let’s set up a Venmo tip jar, and fine ourselves $5 for every story that starts “As a user…” or “As a customer…” Proceeds got to pizza-and-beer-and-Pellegrino after the team’s next retrospective. Or a field trip for the whole team to meet some real live users customers sales associates.
Sound Byte
Clarity is free. And what we call things matters. Think about where vagueness and ambiguity are costing your team time or focus or emotional engagement. Then chose some more specific names and stick with them.
A Personal Sore Point
<soapbox>
I get frustrated when internal IT teams refer to their business unit stakeholders as customers. Nope. If we work at an airline, our customers are the passengers who pay us to fly them home for Thanksgiving. (Not our Marketing Department.) If we’re a bank, our customers are consumers with checking accounts; homeowners seeking mortgages; small businesses needing check deposit services; and multinationals doing overseas funds transfers. (Not our compliance team.) If we’re the water utility, our ratepayers need our service to cook dinner and bathe their kids. Customers are the outsiders who pay us real money in exchange for real services. In an ideal world, IT organizations would focus on delivering actual value or joy or improved experiences to actual customers – be they passengers or borrowers or cooks or genomic scientists.
(For clarity, most tech companies have Engineering organizations, and consider Engineering to be a profit center: the folks who build whatever software or hardware or cloud services that are sold to outside customers for money. Banks, railroads, pharmaceutical companies, retailers, utilities and other primarily non-tech companies have IT Departments and manage IT as a cost center: the folks who give profitable business units what those business units demand.)
I see a series of pathological behaviors that often hide behind IT organizations calling their internal stakeholders ‘customers’:
- Budgeting replaces prioritization. Business units can act like lunchtime buyers in sandwich shops: “If I have budget for X, then you need to make me an X.” IT can become a service bureau, taking orders for whatever ‘The Business’ says it wants. And since development resources are never sufficient to meet the stated needs of all internal stakeholders, IT priorities are set by those EVPs with financial clout.
- Scorekeeping is based on delivery dates, not outside customer success metrics. It’s typical for ‘The Business’ to give detailed solution designs (rather than problem descriptions) to IT, even though business stakeholders usually have a weaker understanding of underlying systems, technical dependencies, and application architecture. Likewise, it’s rare for these demands to include measurable outcomes for real outside customers. (“X should cut lost luggage by 5%” or “Y should speed up average drug trial patient identification by two weeks.”)
Instead, business units push IT on delivery dates. Which means that IT is graded on “did we deliver on time/on spec?” rather than “did we prioritize and deliver projects that boosted revenue or increased outside customer joy?” Tremendous waste when much of what we build is badly conceived or unimportant. - Short-term trade-offs accumulate over the long term. Business unit stakeholders correctly focus on their near-term deliverables, and there are never enough resources. So test automation, usability, technical debt and platform improvements are postponed to next quarter. Just this once. Over time, systems get brittle and additional development gets slower. Hard to convince our ‘customers’ to invest in sustaining technology or tooling improvements.
I’m heartened to see some tech-assisted companies where business units and internal IT apply outside customer success metrics as part of their project portfolio planning – building more of what matters most, and delivering more happiness to real customers.
</soapbox>