top of page

Блог про продакт менеджмент

Практичний досвід та професійні інсайти від продакт менеджерів Wix для української професійної спільноти.

8 common relationship mistakes all Product Managers do



Do you feel a lack of support from your team? Is it hard for you to motivate them to start working on a new feature? Do they just follow the instructions and never suggest anything? Maybe that’s because you’re doing something wrong.


The good news — there are few professions where making mistakes is part of the process. Product Managers are literally paid to make mistakes. We try and fail to innovate and find growth opportunities.


I listed some mistakes that I have made (and still make sometimes ;)) so that you can avoid them.


Not fully explaining why your team needs to work on a specific feature


PM sets tasks for the entire team. They give a clear and detailed spec while the team makes sure to implement what is written the best way and within the allotted time frame.


This division of labor can become so accentuated that the development team just does whatever they’re asked to do. As a result, the team loses motivation and interest in their work. They become unable to contribute to making the product better.


What to do instead?

  • Share user pain points and real-life examples. Explain how this particular feature could make a difference.

  • Talk about the end goal. If your team understands what the result should be, they’ll be able to make correct decisions during the development, i.e., know if a bug is critical or not.

  • Mention numbers and data like how many users will benefit from the feature, how big the impact on profit will be.

Not sharing complaints, suggestions and other user feedback with your dev team


The development team is all about engineering. So why should they care about what a frustrated user wrote in an App Store review?


When PMs are shielding the team from negative user feedback or even just internalising the recent survey results, they deprive the team from feeling their involvement in the product they build.


It’s important that they’re also exposed to this feedback because they’re actually building the product for these users, not just moving cards on a Jira board.


What to do instead?


  • Be the link between users and the team by sharing key findings from your product research.

  • Share both the good and bad feedback to give a realistic picture of what’s happening with your product.

  • Make sure not to overwhelm the team with details. Explain where they can find user feedback if they want to know more.

Don’t express doubts around product decisions


Unless you’re a product-genius, you’ll make good and bad decisions.


The chances to make mistakes are higher if you’re on your own. Your team is the second most valuable source of opinions after your users.


What to do instead?

  • Share all of the available options and ask for the team’s input on the pros and cons of each. You’ll get a new unbiased view of your options.

  • While you focus on the product value, ask your team to provide a tech assessment and possible risks for each option.

  • Acknowledge your mistakes and ask your team what could help avoid them in future.

Putting yourself in the center: “My product”, “My team”, “I decided”…


At the end of the day, the PM is the one who bears the final responsibility for the product.


But the team is the one who makes the product happen. So “I” phrases may sound like you’re appropriating the team’s results.


What to do instead?

  • Use “we” instead of “I” to shift the perspective from self-focused to team-focused.

  • Praise the achievements of others. Show your team that you pay attention to their hard work.

  • Encourage your team members to present the results of their work during demos or at company meetings.

Not caring about how your product works under the hood and what keeps it afloat

Maybe you heard that you need to think like the user a lot.


Users don’t care about how the product works, they just need it to work properly.


Knowledge of the inner workings of your product can be your secret weapon. It can help you predict how long the feature development will take or foresee potential risks. Also keeping your product healthy requires some regular maintenance that won’t be visible to your users, but you as the PM need to be a part of.

What to do instead?

  • Know the high-level architecture of your product. It’ll help to understand what the devs are talking about. But be aware of the opposite extreme and try to find a balance between digging into tech details and keeping the broad product vision.

Not there when things go wrong

If you’re a PM, there isn’t much that you can do if there is a production incident. You can’t debug code and fix things, but that doesn’t mean you can’t help at all. The worst thing that you can do is relax while your team works all night fixing bugs.

What to do instead?

  • See if a product decision can help. Help your team to assess user impact.

  • Coordinate the process. Help to find the right people who can solve the issue. Make sure those people talk to each other.

  • Talk to Customer Support, Business Intelligence and other teams that could give additional info about the issue.

Exhaust your team with too many recurring meetings

Whichever methodology of the software development you’re following, it usually has artefacts and mandatory meetings. They’re made to maintain the process and make sure that important stuff is discussed. But doing everything by the book won’t help if you’re ignoring what’s useful for your team.


What to do instead?

  • Make sure you have talking points before the meeting. If you can’t think of a proper agenda — cancel the meeting.

  • Don’t fall into formal reporting. “Yesterday I did that, today I plan to do that…” Talk about what matters to all people present.

  • Pay attention to the meeting length and frequency. Keep your meetings as short as possible.

Talking only about work-related stuff


Being a PM is often about getting work done, and under pressure we all risk getting tunnel vision, seeing only the work around us and talking exclusively about it. But it’s good to be reminded that we are all people who work with people and may share common interests with each other.


Friendly small talk can be tough, especially during COVID when there are no more coffee breaks or team dinners, but there is always room — waiting for your teammates to assemble for a meeting, or having some extra time left at the end.

As complicated as small talk can be for the shy ones (myself included) believe me — you don’t need to read a management book or take a course to talk about other stuff. Simple things are actually the most effective to break the ice — weather, traffic on your commute or bad wi-fi connection during your meeting. Try sharing what you feel with your team and they will come back to you.


At Wix, we believe that we do a better job (it’s also more fun too) if we communicate openly, honestly and frequently with each other, and it always pays off.

bottom of page