Who’s Your Customer?
All else equal, the Product Managers and Product Marketers who best understand their customers are the ones best positioned to do their jobs well. The ones who understand the customer and their business problems will be best able to define requirements for solutions, ensure the development organization meets the spirit of the requirements, create messaging that resonates with the buyer, enable the commercial teams to go win business, and ultimately succeed in the market. It doesn’t always work out that way, because all else is rarely equal. But entering the market with a poor understanding of your customer and their needs is like starting a race with your shoes tied together.
Unfortunately, the term “customer” is isn’t very granular, and in many cases simply saying “the customer” doesn’t say much about the complexity of the organizations that buy and use your products. Even within a given market segment, and there are usually multiple impacted groups within each “customer”, and across segments these groups may vary substantially. So in thinking about customers and customer needs, it might be better to think in terms of key stakeholders and what each of those needs. When the PM is out identifying market opportunities to pursue, it’s really incumbent upon them to also identify all of the important stakeholder groups associated with those opportunities.
In a very simple example, a PM might identify a single class of buyers that who are also the users. Games and personal productivity solutions might fit this example, but even with personal apps, that model can get broken by simple use cases like ad revenue or sharing with other people. It’s my guess that for most products, the definition of the “customer” is much more complex. Let’s go through an example.
I suspect most of you reading this can relate to buying public transportation tickets in some form, so a solution for fare payments for public transit might be a fun example to explore. Let me also keep this example simple and focus on commuter train operators, rather than also including bus, subway, boat and other transit types.
The most obvious stakeholders in a commuter train transaction are the rider and the conductor — the person who wants a ride, and the person responsible for ensuring the rider has paid for the service they receive. Google tells me that passenger railroads in the US and UK both began life in about 1830, and conductors first unionized just after the US Civil War, so the rider/conductor relationship has existed at least 150 years, and possibly closer to 200. From what I can tell, for most of its history that relationship has been facilitated by the very old technologies of paper, paper punches, and cash, but the move towards a cashless society have created demands to add new approaches to paying fares.
Beyond the rider and conductor, there are definitely other actors in the fare transaction process, such as ticket window agents and accounting clerks. And then there are probably operational, financial, and technical managers who have been charged with driving operational efficiency. And at the top, the CTO, CEO and CFO are all likely executive stakeholders or sponsors. This is all conjecture on my part, but it’s not hard to think there’s no single “customer”, here, but at least four direct stakeholders and two classes of managerial stakeholders.
Since I made the point about conjecture, let me also pause to say that to properly generate this list the Product Managers and Product Marketers need to avoid conjecture as much as possible. Rather, they should accompany sales people on calls, visit customers and prospects on their own, conduct interviews in person and over the phone, visit commuter train stations to conduct surveys, and even make direct observations of known stakeholders as they go about doing their jobs. And at the same time they are developing the list of stakeholders, they should also be developing lists of things these people care about in doing their jobs. It might even be appropriate for them to start gathering demographic and psychographic information about these folks to can create rich representative personas for them. I should add that getting out and having these conversations is some of the most rewarding work a Product person can do, so there’s really no reason not to do it, other than it takes time and a commitment of resources.
Back to my guesses. If I were to expand on our six stakeholders to include what I imagine they care about, I would come up with something like this:
The rider: They care about simplicity and payment flexibility for buying and redeeming tickets
The conductor: They need to be able to redeem tickets from riders in various forms, sell tickets using whatever payment methods the transit operator accepts, and they probably would prefer not to handle a lot of cash or deal with paper tickets
The ticket agent: They need to be able to sell tickets to riders using whatever payment methods the transit operator accepts, and then give the rider something they can give the conductor to redeem
Accounting clerk: Clerks need to manage cash levels for the ticket booths and conductors, and others account for and seek to balance the ticketing sales and redemptions
Operational, financial and technical managers: Their job is to constantly improve the efficiency and effectiveness of the department they manage, helping the business to meet its revenue and profitability goals
Executive leadership: Their job is to set revenue and operational goals for the business, and then drive the part of the organization they manage to achieve or exceed those goals, again all in the service of revenue and profitability
Since I’m already deep into making assumptions, let me try to now categorize these folks:
Sponsors: I suspect the Exec team members are the sponsors for buying this type of solution, signing off on a purchase, but not making the decision themselves
Buyers: I’m going to guess that the buyer is the group of operational, financial (including purchasing) and technical managers in this case — a buying group, rather than a buying individual. These are the folks who own the business problems (operational efficiency and increasing ridership) on behalf of the executive team, and they will be the ones looking for help solving those problems, and making a recommendation as to which solution to choose.
Users: I am guessing the rider and the conductor represent the two most common sides of most transactions in commuter train systems, and that their needs are the most important for a technology solution to streamline if it is to be fit for purpose
Other stakeholders: The ticket agent may or may not be a user group, depending on what problems the solution is trying to address. The accounting office is possibly a direct user of reports or an indirect user of data feeds from the solution, and I’d say the same for the Management and Executive leadership groups.
Which of these groups does the Product Manager care about? Who’s their “customer” in other words? For the Product Manager, the customer is all of these stakeholders. They need to have a solid understanding of all of the actors, their role in the transaction process, the challenges each face in doing their jobs, and the impacts of these challenges both on the both business and the individuals. If the Product Manager does the ongoing research required to understand and validate these stakeholders’ current problems well, s/he can formulate solutions to the most important and highest-value of these problems, ensure the solutions they formulate will truly address the needs of the target groups, and speak in an informed way about the value each stakeholder group will derive from the solution they’ve helped to create. If they haven’t done (and kept up with) the research, they’re just guessing, and their guesses may be no better than the ones I’ve made above.
The Product Marketing team needs to be familiar with all of these aspects of the “customer” as well, but the groups they need to care most about are the groups that make the buying decisions. Product Marketing needs to speak to the concerns of the buyer in the messaging, assets, and collateral they create, of course, but the buyer probably also cares about the needs of the other stakeholders as part of their decision making process. It’s also very common to need to create tools that address non-buyer stakeholder groups to help them understand why they should get behind your solution.
So who’s your customer? There is probably no simple answer, and you’ll only know how to answer if you’re out there engaging with the people who depend on the solutions you deliver.
As always, thanks for reading.
J
