Collect colleagues assessments to keep product expectations in check
As a rule, when products go wrong, everyone has contributed in some important way. I was asked how I’ve had so much success keeping product expectations in check?
There are as many product management approaches as there are weight loss programs. Most will help, many will keep you stranded in a world of theory and make you forget that software development is mostly about cultivating personal relationships. The key is to start any initiative’s first encounters with the assumption that you don’t know squat about it. That approach will help you see the other side’s perspective more accurately. Some call it customer research, customer listening, internal expert interviews. I call this your opportunity to understand various perspectives. A chance to get inside heads; customer heads, influencers, internal visionary and colleagues heads and see the world through their eyes.
Perspective seeking can help you intentionally cultivate more positive emotions with colleagues. Which, in turn, will help you move them throughout the product journey you’ll next define.
Find the problem. Define the "why".
Research is the center around which all of the other dynamics of product management find their orbit. You need to see what the problem really is. But before you jump in to solve it -- are you able to frame the problem in interesting ways to your colleagues?
Don’t anchor too heavily on the customer's vantage point. Put some effort in eliciting from internal stakeholders what their goals are for themselves. These can be interpersonal, technical or related to a company’s style of communication and processes. One of the most effective ways of inspiring colleagues to follow you on a product journey is to uncover challenges they may not know they have.
You should then spend a great deal of time writing documents that describe the problem and challenges. Often referred to as the "why are we doing this?" document. It needs to describe, educate and persuade colleagues as they are constantly evaluating you based on how interestingly you framed the problem.
If they know the problem, they can likely solve it.
It is, in fact, the discovery and creation of problems rather than any superior knowledge of customers, industry or UX/technology skills that often sets the product person apart from others in his field. What are your thoughts? Have you built a product and solved a colleague's problems?
- - - - - - - - - - - - - -
Would you like our Product Management Premiere E-book? Visit our Download page →
- - - - - - - - - - - - - -
