5 Principles I operate by as a Product Manager
By: Heily Hindrea
Tags: Product Development, Product Manager, Problem Solving, Software Development, Product Management

1. Assumptions are the mother of all f%!@-ups

Yeah, well, thats a fact.

Sometimes, when we want to move fast or we are pressured with timelines, we do not double check whether our own thoughts or someone else’s words are actually facts or are they unchecked assumptions.

The moment we over look this or forget to check, we may be on the path of making decisions based on assumptions, which, oh well, may lead to f%!@-ups.

So, best to keep yourself safe and always step back and ask yourself — am I assuming or have I really confirmed this piece of information?

2. Over communication is the best communication

In my craft of being a Product Manager, I have also become an excellent Project Manager — I keep my ducks in the row and are able to manage projects in great magnitudes. The moment the projects grow bigger and span over multiple teams across different locations, the risk of misalignment grows exponentially. In order to keep my stakeholders calm and my teams aligned, I have adopted the mindset — over-communication is the best communication.

What does it mean?

I always think “whatever I have worked on right now, spoken to someone — may it be also useful to someone else around me? If the answer is yes, I will make sure I share it.

Also, I do not allow my stakeholders to ask me questions “what’s the latest”, because I have already proactively given them updates. I do not wait to give updates about results, I give frequent updates about progress — sometimes a small message about simple steps you have taken can go a long way.

I do not wait for next meeting to share an idea of a solution or a (half ready) mockup screen — I will drop a line and say “hey, that’s how far I have came today — would appreciate your feedback!”.

Make yourself comfortable with asking feedback on half-cooked eggs, like I like to call it. Do not wait things to be perfect before you show it to someone — getting feedback early in the process will save you from wasting your time going into the wrong direction! Show that half written Confluence page, mockup, email draft etc, it will cost you nothing!

So, make your communication frequent and always know that the moment you do not communicate — you will give a way to a lot of assumptions. And we already know, what assumptions lead to 😉!

3. “No” to private messages, “yes” to common chats!

Ask yourself — is what am I about to discuss with someone online valuable to someone else? Could someone else’s point of view be valuable to this discussion I am about to have? Most often then other your answer will be “yes” — so use a group chat or channel instead a private message to communicate.

There are various benefits for it:

Someone else (whom you did not think of) may see your discussion and bring you valuable insights — it’s like someone hearing you talking with a colleague in a hallway and stops to add on to it. In order to create the same effect — choose common channels over direct messages. You do not need to repeat the same message all over again to someone and can share the link to the discussion easily. I just hate repetition, so I choose channels, always! And this ties to my 2nd principle about over-communication as well…

4. The “hit by a bus” theory

If I were to be hit by a bus today — what information would become unaccessible to someone who would need to take over my work?

Shared drives and repositories were created for a reason… if you are creating any kind of documentation at your work, it DOES NOT belong to your personal work email drive (if you use Google Drive) or in your personal laptop. What if you fall sick suddenly — how is the knowledge going to be retained in the team and be accessible to everyone? Or your computer crashes? How is, what is sitting in your personal resources, searchable and findable by other people in the future? It’s not — so it does not belong there. Be mindful and minimise (or even better — to eliminate) the “hit by a bus” factor!

5. Eliminate the “key-man” dependency

This derives and adds on to the “hit by a bus” theory — if you are in the team and you carry out certain tasks and procedures — are you the only one who knows how to do it? If the answer is yes, then you are saying yes to the “key-man” dependency.

The only way to build a strong team is to make the knowledge and procedures shared. I learned a trick from Eric Edmeades — write out the repetitive processes as user guides for your team members so that anyone can pick up the processes and follow through. That small investment of time you use for writing these guides will save your time as well in multitudes in the future as instead of needing to explain a process to someone, you are able to share the guide as a first point of reference.

The best example I had recently was the existence of my new employee’s on-boarding guide. I had a new PM joining on Monday morning and from the second half of the day I was going on a week long leave. However, because I have the written guide in place — with minimal handover time, I could pass the on-boarding to my team member and go on a leave with a light heart and mind.

Especially when you are a team lead — your job is to make sure that your team can run without you and whatever processes are needed to be executed, will be able to be done even without you.

Well, thats it — these are my top five.

Do you agree with these mentioned principles? Do you follow any of them yourself? What are your 5 you operate by?

Share your thoughts in the comment :)!

Cheers,

H.