Everyone wins when product managers work in the open
Working in the open is hard and exposing when you’re doing it purposefully. But as a product manager in a new team it’s a great way to build trust and credibility — and confidence.
When I first became a product manager in government I found the sheer volume of information about what everyone was doing overwhelming. The office was wallpapered with patchworks of hi-vis sticky notes and user journey maps; tens of Slack channels dedicated to week notes from various people and teams; days of back-to-back show and tells. People called it working in the open, radical transparency.
While it was fascinating to see this part of the Agile governance process in action I did wonder what impact these efforts had, and for whom. Putting information out there and being understood are quite different things. When I started putting on my own show and tells, I realised how easy it can be to lose sight of the ‘why’ and focus instead on the performance. There’s value in both, but here I want to talk about the kind of working in the open that is almost the opposite of that performance.
To me, working in the open is about the small and deliberate efforts you make each day — asking for help and critique, making space to verbally process what you’re learning with colleagues — that mean you’re continually radiating your intent. It’s hard, exposing — and it starts at team level. But it’s the stuff that becomes habit.
3 habits to help you work in the open
- Get early input on your thinking — especially from quieter voices on the team. It’s a lot easier to build on (or knock down) someone else’s work than be the first to add a thought to an empty whiteboard or document. Try sharing an incomplete thought or idea, written or visual, and ask a question like:
- What’s missing here for you?
- Why doesn’t X look right?
- What would you add to Z?
- How do you think Y might work?
- Who do you think would provide more insight on X?
Notice that these are all open questions. It’s a small thing but it communicates that you’re asking someone to add their own ideas to yours, rather than look over an already-finished thing; they now have some skin in the game.
I used to ask my team to ‘throw rocks’ at early ideas for sprint outcomes. So when it came to planning, everyone already had a sense of where my thinking was, but they had the chance to clarify, add to and disagree before planning. It immediately felt more collaborative.
2. Create space to verbally process as a team. This works best with a smallish team. It’s amazing how we are capable of taking different things from the same information — for example, a discussion with a stakeholder, or a user research participant. Carving out time for your team to share what you’ve each learnt can be a great way of joining dots, getting to know each other’s ways of thinking, and building on each other’s insights.
These sessions can be pretty unstructured, but it’s useful to have someone take some notes. I would often do this myself as it forced me to listen and digest what others were saying, rather than being the dominant voice in the room. It’s a great place to think aloud, share what you think a particular piece of information may mean for your work as a team, or ask other members of the team to expand on their thinking. Using a simple agenda like ‘3 things you’ve learnt this week’ helps avoid an open-ended talking shop.
3. Ask directly and publicly for help from your team. This is the scary one if you’re new to the role of PM and are still trying to have all the answers. Nothing creates a bridge quicker than showing that you’re human and vulnerable. It’s an incredibly valuable behaviour to model, and may not come easily for all sorts of reasons. But for me, learning to ask for help was a game changer both in terms of my working relationships and my own confidence.
What else might you add to this list?
