3 ms·
I moved from engineering to product management precisely because I realized that the problem of "what should be built" is often harder than building the thing.
by xyzelement 5y ago
I moved from engineering to product management precisely because I realized that the problem of "what should be built" is often harder than building the thing.
Asking users what features they want is pretty much not fair - because most people don't have the skills to think through and answer that question, nor is it their job to do it. It's like asking a novel reader what they'd like to see in the next chapter. It's a cop-out with guaranteed suboptimal outcome.
Obviously product management is half art half science but in a nutshell, much better than asking an individual what features they want would be asking them - especially on a senior level - what problems they have and what keeps them up at night. Getting an understanding of that and then thinking about how those problems/risks can be addressed by your system is a much better starting point.
The reason I say that it's important to partner with your users on the senior level is the difference in perspective on the class of problems they want to tackle.
For example I used to work on a trading platform. If I went to my heaviest users and asked them what their problems were, they would probably say "I do 1000 trades a day, and I have to tweak each one manually - can you make that process faster" and maybe even have an idea of what that could look like. So let's say I did that and shaved a second off each trade handling so my user is happy cuz I saved them 16 minutes a day. Sounds like a job well done.
But if instead (or in addition) I talked to their boss, I might hear a very different story. Eg: "we do 1000 trades here every day, but 900 of them are straight forward. I wish I could automate those so trader can focus on the 100 complicated ones. But instead, he's so busy doing the 1000 trades that a lot of them get fucked up especially the complex ones."
That's a major change of perspective, from optimizing an existing workflow to optimizing the entire operation. The implementation is quite different - one is a UI optimization and the other is establishing some sort of automation capability that can be extended to all my clients over time. One may be doable with the team you have, one may require standing up a new group, etc.
At the end, the end user is happy (they get to do 10% of their previous load but this is the high value 10% they really want to focus on.) The key point is that neither the user nor their boss could tell me exactly what to build, but the high level perspective allowed me to understand their problem in a deep way and figure out a scalable solution for them and other clients.
Anyway that's just an example but yeah, your users can't tell you what to build and yeah you need a good product manager - or someone who can play that role well.
- phkahler 5y ago>> That's a major change of perspective, from optimizing an existing workflow to optimizing the entire operation. Automating a workflow is the best optimization from the users point of view.
- foldr 5y ago>It's like asking a novel reader what they'd like to see in the next chapter. I love this analogy.
- rawoke083600 5y ago>Asking users what features they want is pretty much not fair - because most people don't have the skills to think through and answer that question, nor is it their job to do it. 100%, Usually early in the "project discussion" I try to boil it down to just ONE CORE PROBLEM they have. For example: If you had a magic wand that could generate ANY SOFTWARE to SOLVE ANY problem in your business (but restricted to ONE problem). What would that problem/solution be ? From there it's usually easier to generate a feature-list(requirements) as long as you solve the damn core problem :P