Product Managers shoulds and shouldn’ts
If you opened this text expecting me to tell you what you should, or should not do as a PM, I’m sorry to disappoint you, but I won’t. However, stick around. You should read this. (See what I did there?)
This text is not just about PMs. It is about Developers, BAs, QAs, UXs, Managers, HR etc. It’s about building a team. There’s a lot of articles out there that try to tell you what, how, when and why to work at a job. However, I’ve come to understand that the only perfect answer to any question (what a PM should do, for example) is: it depends.
First, let’s talk about context
Context drives, or at least it should drive, the answer to every question. It’s easy to find contexts in which a method doesn’t work. For example, in a war, if you use a naïve Agile method, your soldiers will, in small batches, go to the trenches, in a continuous delivery. At the end, you’ll probably be the last survivor, holding post-its…
The same way it works for process, it works for team building. You cannot create high-performance teams with the same tool, in different companies or even in the same one. Each environment needs different skills from different people working in different roles with different engagement levels.
The famous Venn Diagram
When trying to search on the internet how to improve your PM skills, the first thing you’ll find is this:
People usually say that you should be in the middle, at the three circles’ intersection. If you spot a team that has skills evenly distributed enough so that you can improve all those needs at the same time, and in the same proportion, to be in that central point, you’re a lucky one!
However, if you are like me, an average person, who usually doesn’t win on lottery twice in a row: it depends. A team is, at the end of the day, a set of different skills at different levels. Therefore, instead of focusing on narrowing your abilities into what you think a PM should do, concentrate it on improving your team’s outcomes.
But how do I do that?
It depends. Ok, I’ll stop doing that. But one thing that you can do is measure. Check your process, what is going wrong? What could be better? Focus on improving that. Don’t you know how to do that? Then that is the first skill I’d suggest your team to acquire. You can either study about it, have someone to understand more about it, hire someone with the skills to do so.
Data is not a method, is a principle we need to follow in order to achieve success. Once you have data to show what your team is missing, you can act on acquiring the skills you need to prosper.
“As to methods there may be a million an then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble”. — Ralph Waldo Emerson
So should we ignore roles, and ignite chaos?
It depends. Ok, I just can’t stop it. To that question, the answer is actually no. The frameworks and rules that define what a PM does are, in fact, useful. Wait, what?
I never said they weren’t. I think there are priorities. The same way the agile manifesto states “working software over comprehensive documentation,” I’d say “effective team over job descriptions.” Remember, it is not because it is on the right side of the phrase, that it isn’t necessary.
In this case, those definitions are the utopia we need to follow. They are the direction. Just don’t let them become a burden and, instead of helping you out, lead your team into an endless frustration.
