Since I created it five years ago, I’ve served in a somewhat product management capacity for an internal automation testing tool that enables our non-technical QA Engineers to create test scripts and carry out previously impractical production automation tests (with all the power of code, but no need for knowledge outside of Selenium IDE and SoapUi).
The most difficult component, in my opinion, is keeping up with consumer feedback and feature/enhancement requests, determining if they are the consequence of a tier 1 issue for the market or customers, are merely nice to haves, or are wholly superfluous.
Having imposter syndrome as soon as you explain what you do to the society, that’s the worst part of your job as a Product Manager. The society’s expectations and the constant comparisons to others can often make people feel like they don’t deserve what they have. I’ve been through it and believe me it’s not a good feeling at all.
The hardest thing I’ve done was definitely improve my stakeholder jiu-jitsu. Do you have suggestions for enhancing it other than by using it actively at work? The best way to develop your skills is to actively apply them during a real-life conflict. The stakes are high, and the pressure is on, so you’ll have plenty of opportunity for practice. IMO
Hello everyone. I’ve just joined Prowess and am trying to get the hang of it.
It seems like many don’t follow active listening with “asking why.” One stakeholder group has frequently thrown a feature at the product team, and you need to ask why in order to go back and identify the issue. Only after that is it possible to create a solution that benefits all parties involved.
Although it seems simple, it’s the most difficult part. Well, that’s what I think.
You may try bringing your product strategy (and, if necessary, your roadmap) up front during stakeholder engagement sessions, making it very apparent which business outcomes you have prioritized and are concentrating on achieving. By doing this, you at least have an opportunity to make sure that any features and concepts they come up with are more likely to be in line with one another and possibly valuable.
In addition to its various applications, I adore using impact mapping to engage stakeholders because it cleverly and effectively shifts the focus from deliverables to impacts.
The toughest part of being a product manager is saying no without hurting egos. Product management is a tough role. On one hand you want to say yes to every opportunity, on the other you have to know when to say no to requests. It’s hard not disappointing people, but it’s also hard knowing when enough is enough and the product can’t handle any more features.
Agree @CarolynMiles, I believe that rapidly testing the assumptions is the most effective, so when I’m talking to others, my perspective isn’t just anecdotal; it is supported by facts and data. I believe that there is sufficient evidence to support the validity of the assumptions, although they can never be 100% perfect. I believe that the consequences of making an assumption are both positive and negative. When we make an assumption, we limit our ability to fully observe and understand the situation, but there’s more information available than what is obvious. In other words, assumptions are not always a bad thing.
I would say that dealing with people is the most difficult aspect of my job. This can be due to engineers not meeting deadline commitments, a manager giving me a lot of work, or upholding standards with the rest of the company. wanting to go about things “properly” on your own, but having two or three others in your ear telling you what THEY want.
Hello @BrandonMilme, welcome to the community. Hope you’re loving it being here.
People issues, speaking with others, working with others, and patiently and empathetically explaining things are tough parts of being a Product Manager. If you can’t collaborate with people, you’re doomed because collaboration is such a crucial component of any successful project.
@AngelaBlue I believe that when working together, opinions supported by research help to reduce the disagreements.
Every decision I make as part of a team of developers and quality assurance engineers is based on “how does it benefit the customer?” If doubtful, we wait until we notice a pattern in the feedback we receive from clients.