🔑 Habits of Product Managers That Make a Big Difference

It's the little things that separate the good PMs from the truly great ones

In the hectic, yet intensely rewarding, career of Product Management, there are a lot of habits you can adopt that will help you in each hurdle, support each sprint, and keep development moving forward

What are some good habits that you’ve picked up as a PM that has tremendously changed the way you work? Improved relationships with your team? Helped you focus?

I can name a few
:busts_in_silhouette: Dedicating time with your team, customers, and product
:walking_woman: Taking a walk to clear brain fog

What do you do?

To learn more check out this indepth blog post : https://prdct.school/3b77Upr

:brain: Embrace the fact I do not know everything and ask for help and opinions

3 Likes

@robertzalme I love this! If anything seeking help is a sign of strength. Staying curious and open to new perspectives is essential for PMs and folks in general. Would you share with us the moment when you came to this realization? When do you normally find yourself asking others for their opinions? Is it in moments of doubt or certainty?

There is a saying: if you want to go fast go alone, if you want to go far go together. I came to realise I’m more of a “go far” type of person instead of a “go fast” type, hence I need others to reach my goals.

In moments of doubt, I’ll ask for help, in moments of certainty I’ll ask for opinions.

Beside, I simply do not see why you wouldn’t use the knowledge and skills available thanks to the people around you.

5 Likes

Tip for Managing Stakeholders:

I have gotten into the habit of creating a competitive analysis and empathy map for each of my stakeholder groups. It has saved me lot of headaches by allowing me to adjust my communication style to come to an understanding, and allow for easier negotiations. Another added benefit I have noticed is the ability to be able to address different request and concerns from stakeholders in meetings more effectively.

2 Likes

I love this tip! Work smart, not hard. Effective communication with your stakeholders in the right way can play a vital part in keeping them “on board” and on your side :muscle:t4:

Acceptance Criteria is a team effort.
I’ve been doing ACs by myself for a long time, but at my current job they taught me to create it along with the QA, and I couldn’t be happier.

I can focus on the value, QA focus on “unhappy” paths, and the devs help with the technical part of the AC.

By the end of it, we are left with a solid User Story, clear tasks, and clear ACs that will allow the dev team to prepare for the QA merciless testing.

1 Like

Perfectly suits my vision @h.auler! You really need the input of others to complete all AC’s.

You probably learned at the time you’ve been doing the AC’s by yourself, a lot of stories were delivered with a different outcome than you had in mind?

@robertzalme It was a funny thing, when doing ACs by myself, I could perfectly predict the “happy path” outcome, it would come as I predicted IF the User followed exactly what I envisioned, and we all know that that’s a myth.

Anything else would warp into something entirely different, especially when relating to roles and permissions, deletion, abandoning the path, or even trying to achieve a different goal.

I could predict the expected outcome, but after that, it would be a wild west scenario, with outcomes that sometimes were better than what I figured out, sotimes would create system breaking bugs.

I can give you an easy example, I worked on a civil construction project and we had a huge database of materials orders, with something like 3 years of data collected. We created an EXPORT tool, to allow the Supervisor to download as an Excel spreadsheet what orders he had to inspect. The happy path would be the 1-month range I designed, but they could be flexible on the range… My QA decided to try an “all the database” range and it crashed the system :joy:

A User later asked us why he could not Export for more than a year and we found that this block was really necessary as it actually happened outside the testing environment. That was an easy data loss “whole server” crashing bug that was avoided by carefully creating the AC together with the QA.

1 Like