Mike Lyons separates customers from stakeholders: customers use the product and have the problems it solves, stakeholders influence success but may not use it. A voter registration system's customers are election staff, not the Secretary of State. Ask who influences success and whose problems you're solving to build for the right people.
When you're creating products or services, knowing who you're really building it for makes all the difference. I don't know what you're talking about. Customers use your product, and stakeholders, well. They care about the product's success. These aren't always the same people, and that matters more than you might think. Understanding the difference between customers and stakeholders, it might seem straightforward, but it's a pretty important distinction. And product ownership. Sometimes you might hear customers described as users or end users, and that's because they're the people that use the product on a regular basis. For our purposes here, we're just going to refer to them as customers. When I was working on the statewide voter registration system, we had two distinct groups to consider. The Secretary of State and the county clerks. Well, they were our stakeholders. They controlled the budgets. They set policies and influenced the system requirements. The election staff, however. Well, they were our customers. They used the system every day. They used it to process registrations or update voter information to manage election records. They were the ones whose problems we really needed to solve. The distinction was pretty clear in that case. But let me break down how to identify these groups. In any situation, stakeholders are people or groups who have influence over your product's success, but they may not be direct users or beneficiaries. Think like executives or investors, regulatory bodies or department heads who control budgets. In Taskflow's case, Technova's CEO, Mark Ryans, and the company's investors. They're stakeholders. They care about revenue growth and market success. They influence the product through business goals and resource allocation. Some other stakeholders would be like the creative agency owners who pay for the subscription to Taskflow. They care about roi, efficiency metrics, and resource utilization for their agency. Customers, on the other hand, are the people whose problems your product solves directly. They're the ones who will determine if your product actually works by using it to accomplish their tasks. The creative teams using Taskflow, like the designers, project managers, and account executives, the ones who use the product every day, they're your customers. They need to track projects and tasks, collaborate with teammates, manage resources and meet deadlines. They're the people who are using Taskflow. Now, sometimes it gets a little tricky. Sometimes, like with Taskflow's creative agencies, people can wear multiple hats. Consider the small agency where the CEO is also the lead designer and uses Taskflow every day. Well, she might be a stakeholder in one sense and a customer in another. It's a subtle nuance, but don't let this blur the fundamental distinction. I'm a pretty simple guy. So I like to think of it this way. Whose problem are we solving? That's my customer. When analyzing any product situation, start with two simple questions. First, who has influence over the product's success? Those are your stakeholders. Second, whose problems does the product solve? Well, those are your customers. The power of understanding this distinction comes when you face competing priorities. While stakeholders might control resources and make purchasing decisions, successful products ultimately solve customer problems. Consider a current product you work with daily who influences its success but might never use it? Those are your stakeholders. And who relies on it to solve their daily problems? Well, those are your customers. Keep this distinction clear and you'll be better equipped to build the right thing for the right people at the right time.
