PMs: Share Outcomes With Your Team – Hacker Noon

Product Managers … when was the last time you shared a real win (or a real miss/learning) with your team?

Sure, getting something out the door is a win of sorts. But how did your team’s hard work move a meaningful needle for the business? What did it make possible for your customers? Did you end up proving/disproving any important assumptions? What can the team learn from actual impacts/outcomes?

Product managers tend to focus so myopically on what is “on deck” and in progress, that they fail to close the loop on prior work. The second something is shipped — with fanfair and some success theater — the focus shifts to the next thing.

When the team doesn’t speak up, it is (wrongly) assumed that the team doesn’t care beyond getting the work out the door. Meanwhile they’re swamped ramping up on the next thing and don’t have much time for small talk. At least in my experience, software developers care deeply about outcomes, but aren’t neccessarily the most vocal when it comes to advocating to see them. Don’t assume silence means indifference.

The challenge is that sharing ongoing outcomes is a muscle. You need to practice and make it a regular part of the team’s cadence of rituals, artifacts, etc. Otherwise, you’ll always be stuck pulling adhoc reports, or just ignoring it altogether.

A good forcing function is to arrange a monthly lunch meeting to share data, stories, anecdotes, and context. Free food (it’s worth it). Return to the same dashboards whenever possible to minimize ramp-up and repeat questions. Don’t be afraid to share qualitative data too — real customer/user stories can be incredibly impactful. Invite a customer if you can. Challenge yourself to really own presenting this stuff with confidence, and engaging the team. And finally, and perhaps most importantly, do not be afraid to share negative or disconfirming information…you’ll get far more respect that way vs. being a “know it all PM!”

The developers don’t want another meeting! They want more time to code!

Please, try it. I’ve yet to find a software developer who was bored at a meeting sharing actual impacts/outcomes, especially if it was backed with some quantitative data.

No magic tool will replace this kind of open and reflective communication. How you spend your time as a team is a good reflection of what you care about. You have to stick with it and allocated time/attention. The first meeting may be rough. You’ll improve. Solicit feedback and keep iterating on the meeting itself. Just a bit of context can be incredibly powerful for the health and effectiveness of team. It can even boost retention.

I’ll end with a quote from a software developer friend:

I hop between companies, and look for who is using interesting technologies. That is usually worth a couple good years. Of course, I had always dreamed of helping people with technology, but we never discuss whether any of this works. Sure I can retreat back into the tech, and I do, but that gets old pretty quickly.

This type of apathy is not uncommon. After getting burned a couple times, people retrench to what they can control.

So…don’t wait or ask for permission. Just do it. It helps everyone.

Bonus: Come resume time, you’ll have some outcomes to share 🙂

read original article here