Features Requiring Complexity—An Answer on Quora
An answer I posted to a question on Quora about protecting complexity when it is required received positive feedback. The question and my answer follow.
The Question
As a Product Manager who is technical, what are the best ways to protect a feature that requires additional complexity from the Simpletons? I have external influences in my product organization that tend to oversimplify features to a point that results in the final result being insufficient to meet the required needs of my customer. What is the best way to manage these influences and preserve the integrity of my feature and future integrations. We practice Agile in my organization and tend to under-develop a feature in order to release it, but end up having our lunch eaten by our competitor when it comes to capability?
My Answer (with minor edits)
I’m sorry, but my experience is exactly the opposite: you should listen very carefully and attempt to please the “simpletons” as much as possible. They are invariably trying to tell you something useful. It may not seem so, or it may not be easy to hear, but it’s almost always worth the time to explore.
If I get pushback that a design is too complex, I try to go back to the drawing board. Re-examining the data and assumptions about the problem leading to the current design invariably yields new insights. I would also examine each element of the component design and how it maps back to the problem. A careful analysis pretty much always leads to alternatives that had not been considered (or not enough).
Surprisingly often, improvements on the original design come out of this process. Occasionally an entirely new path becomes apparent. The old design is thrown out in favor of something better. The most infrequent case by far is a conclusion that the current feature was perfect as is and should be left alone.
If doing this process transparently, you will often have reached a compromise with the outside influences by now, and they are satisfied. Even if the feature is justified as is, going through this process will help you clarify and simplify your thinking. Often, pushback is just the result of insufficient or unclear communication. Clearly communicating the problem, rather than the feature, and then clearly communicating the feature in simple terms, can be enough to put the issue to bed.
Before you start re-examining, the most important step is to simply listen. And by listen, I mean listen carefully. As a technical PM, you may suffer from the same problem that many other technical people do. You’re a problem solver and your mind moves quickly. You may be good at listening, but invariably your mind races ahead of others. If you’re not careful, you steamroll what they are trying to tell you before they get a chance to say it. Shut up and listen. They are not “using it wrong” or “thinking about it wrong,” they are simply trying, in their own way, to communicate to you how they think about the problem. Understanding how they think is important. Furthermore, listening carefully will help others feel hear and that their needs are being considered. This alone can go a long way towards bridging the gap.
I would also suggest that you watch Geoffrey Moore’s points on core vs. context as they relate to your feature: http://blip.tv/business-of-software/geoffrey-moore-at-business-of-software-20…… Are you battling over core or context? If it’s context, your probably better of focusing on core. If you’re not sure, then you probably need to spend some time to define core and context for your product.
In summary, I would suggest that you: * Listen carefully to the needs of those influencers. They are trying to tell you something that you should not get in the habit of ignoring. Don’t talk over them. Just shut up, listen, and ask lots of questions when they stop talking. * Reexamine the problem and solution, especially from the point of view of your users, to uncover your assumptions and clarify your thoughts such that you can communicate them clearly and simply. * Iterate the design to find potential improvements or new designs. Document the iterations where necessary. Just seeing a document where you’ve outlined a feature analysis can be enough to convince others that you’ve done your homework, and allow them to trust your decision. * Think about your product and whether the problem you are struggling with is core or context. If it’s context, ask yourself if it’s worth it.
One last thing. The final call should be that of the product manager in charge of that product, perhaps with veto power granted to a product executive such as the founder. Nonetheless it’s important to take all stakeholders views into consideration and, as much as possible, get consensus. Consistent failure to do this can and will lead to bad, bad things.
