X = f(P + (C * T) / I)
One of the initial mistakes in the product development process is assuming that users know exactly what they need. This single assumption can derail the entire process. Here's how.
When you're working on a complex problem, if the user says they need X, you can be sure that the actual need is somewhere in the vicinity of X = f(P + (C * T) / I), where P, C, T, and I are unknown variables that no one is consciously aware of. And it's your job to figure out these variables, guide the user toward understanding their real need, sometimes to the point where they pay for a solution they didn’t even know they wanted, and deliver the X = f(P + (C * T) / I) solution with the simplicity of X so they are not overwhelmed by the complexity that you've navigated.
This becomes evident during conversations with users. They'll often begin by asking for a specific feature. As you dig deeper, they’ll explain the issues that led to this request. And as you probe even further, you’ll uncover that their real challenge isn’t the feature itself—it’s their broken processes, often caused by inefficiencies in how people are functioning within those processes.
It may not be your job to fix their people or their internal processes, but you'll need to find ways to mitigate the issues caused by them and bring their processes in line, all while serving the end feature requirement. You'll do this by creating a solution that seemingly operates at the end-user application level. You’ll bring in people who understand the nuances of processes and people best. And then, you’ll find the right fit—a balance that serves everyone's needs. Somewhere in this process, you’ll also develop the actual solution.
Sounds complex, right? It truly is. And the only way to manage this complexity is through active participation. You can apply whichever framework you need, whichever technology suits you best, but unless you have people who are committed to making things work, it won't work. It is people who'll make sure that everyone recognizes the need for your little solution. Their participation will ensure that correct understanding is passed through every level, making your solution viable.
But if you take what the users say at face value, you risk building something everyone thought they wanted, but no one actually needed. The result? Months of trying to convince stakeholders of the value, with little success. Eventually, even the people actively participating on your side will grow frustrated, leading to dissatisfaction across the board. Needless to say, the solution will require rework to fit the actual, persisting needs.
The way to avoid this pitfall is to abandon laziness. To understand that your role is to move beyond what the users think is right and get to the heart of the problem. That you must listen to what they think is the right solution. But then continue investigating. Dig into the whole story, including the seemingly irrelevant parts—like that one colleague who’s maintaining a master Excel sheet that no one talks about. That’s where the real solution often lies.
And somewhere in this process, you'll crack the X = f(P + (C * T) / I) equation.