I’m Not Just the Product Manager, I’m Also the Secretary
The power of scheduling, email introductions and meeting notes
Product Managers like myself can have big egos. Prioritizing others’ work, crafting a roadmap, ‘managing customers’, ‘leading by influence’, and storytelling- all this can get to their heads, and make them think they’re important. Too important for menial administrative tasks.
But sometimes, the most important work of Product Managers — and Product Owners — is to do administrative work. Schedule meetings, send intro emails, and write summaries.
Scheduling a meeting
Meetings suck They are distracting, boring, and usually inefficient. .Why must the Product Manager/Product Owner schedule meetings?
Communicating complex issues is tougher in writing
Because in some situations a messy problem can be most easily resolved when key people communicate directly. Not through emails. Not through messaging like slack. Not through long comments on Confluence or Jira. But by communicating synchronously. And the right people have to be communicating.
So, for the love of God or whatever you believe in — why does the Product Manager have to schedule the meeting? Why can’t one developer schedule with another?
Because no one else will actually do it. As a Product Manager and Product Owner, I have literally scheduled meetings that I did not attend so several people could speak. But we were able to move forward because of these meetings.
Why will no one else do it?
Scheduling is an exercise in masochism
Because the act of scheduling is painstaking. You have to check with someone, and then with another person, and then you have to know how much time it will take, and then the first person invites a third person, but she can’t make it then, so you have to move it to next week, but there’s a holiday, and actually there’s a slot in 5 minutes so maybe you can do a last minute meeting? So you check with the second person, but he can only make it for the last 10 minutes, so fine, but then actually it turns out that the first person has to leave 5 minutes early, and the whole point was to get these two people to talk about this question, which is blocking another team from advancing on a separate topic which also impacts a third team… and so on and so forth. And then when you finally do manage to find a time in two weeks, you get a message 3 minutes before the meeting from one of the key participants that something came up last minute, and she can’t make it. So Sisyphus must again push the rock up the hill.
Talk is cheap, dev costs are expensive
Another reason is that developers don’t like to talk. I’ve noticed that sometimes developers would rather write ten thousand comments on tickets back and forth, rather than having a two minute conversation to resolve it. The underlying symptom of this phenomenon — dont-wanna-talkism — is not yet clear to me.
Social risk of sending an invitation
Inviting people is awkward and socially risky. What if you invite the wrong person? what if the person you invite, has nothing to contribute? What if the person you invite retaliates and starts inviting you to meetings that you don’t want to be at? What if the ‘mandatory’ participant won’t show? What if people come late? Meetings are impositions, and asking someone to attend is like asking for a favor. So, the Product Manager has to be that jerk who invites people.
Email intros
The ‘secretarial’ administrative work is not relegated to scheduling meetings. It’s also for simple connecting people for email, for example. In my capacity as a Product Manager/Product Owner I have found myself sending an ‘intro’ email. Connect a developer to a system architect. One tech lead to another. A developer to a PO. A front-end end developer to a back-end developer. The pairings go on. The Product Manager does generally interact with more functions than an average developer, so these interactions give legitimacy for instigating email intros, or even inviting someone to a meeting.
When I send such emails I try and write the reason for the intro in my own words, even if I know the technical professionals will dive way deeper when they communicate. Even if my description is wrong, it helps socially as a starting point for the interaction.
Meeting summaries
It is tempting to assume that super smart people — engineers, developers, system architects — also have phenomenal memories. This, I have found, is not the case. Indeed, without concrete meeting notes to reference, there can be quite some disparity in how each participant remembers a meeting. It’s way easier to jot down a few lines rather than spend the time and effort recreating conversations or conclusions that were made in previous meetings. No one else will summarize a meeting and send the minutes/notes. So guess whose job it is?
Recap
Product Managers like myself need to get over ourselves, and do this nitty gritty administrative tasks in order to move forward faster. Of course, there are automated tools to help, but that’s the topic for another time.
Thanks for reading.
About this series
This article which is part of a series on product management based on my experiences.
About the author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
