Dear new Product Managers, you should do these little things more
Being a Product Manager doesn’t have to be following a set of rules or only caring for certain groups of people.
In the short years of my professional life as a person working on various software product developments, I’ve seen many types of Product Owner/Manager. Some more successful than the others but many share the same charismatic vibe that believe it or not, made them somewhat more successful than most.
These are the most basic things you could do, to quickly adapt into this new position, that sometimes more “Manager” than “Product”. OK, here goes:
Walk around more
This is the first thing that I have to emphasise because even some veteran PMs I used to work with don’t even do this often.
Naturally, as a PM, you are very most likely will have to work with a lot of people. You are not the only person working on this product, most typically so. Remember, you are a “Servant Leader”. As much as I hate that term, it is true. You are a servant first before you are a leader. You work for your team just as much as they work for you. This is the basis for many other professions but for PM, I think it is just as important.
Talking to people is easy. Getting to know them is a bit harder but genuinely make them feel like you belong there takes real effort. I’ve seen so many PMs only communicate via group chat and email, those who give out commands in the form of Jira tickets. Their pristine documents are their crystal clear instruction to the dev team. Their well-organised Backlogs are their vision for the stakeholders. Their streamlined workflow and communication channels make them disconnected from the human part of the job that they make this job as boring as a brick. That kind of distance is what you should definitely avoid.
I usually just stand up and stretch, then use that as an excuse to walk around the floor. It will seem like I want to spy on people because you just walk around in the middle of working hour for apparently no reason. Don’t be afraid of what people think of you. That’s what you want to change. Find a good time to do so too. If a developer is on his/her headphones, I usually don’t want to disrupt their trance, unless it’s something urgently related to them. Sure you will have to spy on their screens, but that’s a useful cue for you to pick up a quick chat.
This is where walking around plays a huge part. Don’t spy at them from your desk, do that when you randomly walk around. It makes you look like you have something you need help with and most people are more comfortable knowing that than, trust me. And don’t make the conversation longer than 2–3 minutes. Ask if your requirement for something was clear enough, or how the person is doing, any blockage. Those should get you to a good start. Identify the friendly ones amongst the grumpy ones. That way, even if you are an introvert, the conversation will start more naturally and you won’t feel like jumping out the window afterward. In my short years of working in product, I couldn’t count how many times I cringe to the core when I see another PM try to chime in a conversation or an inside joke with his team.
After all, talking is a part of your job, to understand your users. Your team members are obviously also users, not that it strictly means they are the one you have to serve. But you will have to talk to your users eventually, so why not practice with the most willing people at your disposal. Also if you don’t have a tech background, this is most likely the quickest way to learn something too.
Summary:
- Talk to your team more, even if it’s just chit chatting.
- Start with work related then work yourself to more personal conversations.
- Keep each session to around 2–3 minutes to not disrupt everyone.
- Pick your target carefully.
(A bit of walking around is good cardio workout too, don’t be a desk potato!)
(While you’re at it) Listen more, too!
For new, non-tech background PMs, so many things said by the dev team in general will be pretty much non-sense to you. Even though most PMs aren’t even required to know how to code, and some with programming background even forget how to (they do, yeah, shocking?!), it is still preferable for a PM to at least be able to communicate with developers on some basic technical level.
You are working in tech, even without a tech-degree, eventually you will have a vocabulary in tech and the ability to talk jargon. The best way to quickly have that ability is to listen. Combined with the above activity of constant communication with your team, a bit of self googling in your own time, and you’ll soon be confident enough to talk about whatever you are working on, on a technical level.
Again, you will eventually have to listen to your users’ feedback , do focus group, usability testing and all that jazz, so why not practice with some easy targets first. Make eye contact as often as possible. You listen to empathise, to learn about the person you are talking to. Nod often to signal that you are active listen. Occasionally, repeat them to ensure you’ve heard them and signal a level of understanding. Genuine listening is a great skill I’ve seen in so many successful PMs, and is crucial to both your work and career.
Summary:
- Actively listen from teammates, co-workers, stakeholders.
- Pay attention, listen actively. Nods, repeat occasionally.
- Make use of the information, study, explore.
(Everyone prefers a good listener, duh)
Read your Product Requirements again
Self reflection or self assessment play important part in development of both the individual and the establishment. In this case, maintaining the integrity of product documents helps the PM to re-evaluate any short-coming of designing something the first time.
No matter what you write, keep in mind that it’s not the final. Even after the feature is done and released, there’s still improvements that could be done in your requirements/documents. This may seem like a waste of time, really. “It’s not codes, you don’t necessarily have to leave a beautifully written document for someone to read in the future”. Well, you really should though.
For as long as I could remember, starting a new job as a PM, the first thing I look for is something to read. I don’t care if it’s PRDs, or a word file, some Jira ticket descriptions. Hell, even some scribbles on a piece of paper are fine, as long as I have information to form a comprehensible set of ideas of the product I will be working on. Having a good collection of records of what’s been done (and to-do) is the best way to understand the development of the product. A good kickstart to any PM is fully understand the product inside out, and using a product intensively everyday won’t cut it.
So I always appreciate and admire those who love to leave a legacy for the next person to pick up the work. And even more admirable when the information left behind are clearly written, well arranged and indexed. Of course, for most startups, that might be too much to ask. Nonetheless, being document-driven is just as important as being data-driven. And while the latter sounds sexy and timely, the former is often overlooked, even in long-established companies.
Even in a few months, my understanding of the products can change drastically. The documents I write are filled with vastly more useful information that the “past me” overlooked due to lack of knowledge. So read it all again, fill in the gap, make it more clear and leave your legacy. Heck, even if the feature turned out to be a disaster, I’m sure the next person would still appreciate that you documented everything.
Summary:
- Read it again, everything you wrote.
- Make it better if possible.
- Think of the next person, this is your legacy.
(I’ll be damned if I don’t revise this blog post at least a couple times in the future)
Oh, write more too!
Writing is a part of your job, and it does push you to actually have to be good at writing. So write a blog, a journal, a fiction, anything.
The PM job requires a lot from you. It needs you to be empathetic, creative, tech savvy, data-driven, be a go-getter and be an entrepreneur. It doesn’t require you to be a scholar yet your job is to study. There are sciences behind everything you do daily, so approach it with a mind of a scholar: ready to study, make assumptions, question everything and have evidences ready.
And write more! Like I am right now. Share the knowledge, the experience, the passion. That will keep you going in the world of product.
(No summary needed)
Thank you so much for reading! Here’s a cute gif.
Do you have any comment/advice? Is there any other little things you think PMs should also do more? I’m always happy to hear more from you. Always!