Product Manager is a key position in the overall business strategy. As a PM, your responsibilities are to identify business requirements and communicate them as clearly as possible to developers, designers or marketers for implementation or production.

In order to be successful as a PM you have to constantly improve yourself not only from the technical perspective but also from a communication skills perspective.

In this article I will share with you a few simple yet effective hacks that will help you become a better communicator and sharpen your ability to convey ideas clearly and motivate people behind it.

Let’s get started!

1) Learn The Fundamentals Of cross functional communication

To become a great product manager you should learn first what is going on in your team? Does everyone know that they should know about their tasks? How much do people know about the things that are being built?

It is your primary goal to turn every single person in you team into a subject matter expert. You want to understand what makes people tick, how they work together as a unit and what are the obstacles they are facing.

You have probably heard this sentence hundreds of times already but it’s soooo true – ‘The key to success is communication’!

I’m not talking about formal meetings or yelling out loud during times when everybody should be focused on their work, instead I’m suggesting that you focus more on informal conversations with others. Ask them about their tasks, personal life, questions related to the product etc. It will help you uncover issues faster before they escalate, save a lot of time and probably even save money.

What I’ve learnt from being part of different teams is that everybody has their own style of doing things which tell a lot about the person. Some people love organising everything before they start working, others – fail to do so and waste half a day looking for lost tools or information. If you understand those preferences you can help those people avoid those issues by providing what they need from the very beginning instead of waiting until the last minute when it might be too late.

2) The goal is extremely simple, yet it’s the most common mistake I’ve seen people make. Think about what you want to achieve and how much time you have to do so.

Let’s suppose you work as a QA tester for a software company and they asked you to release 100 bug reports within 3 days. How are you going to achieve that? Create priorities based on severity level or target those highest priority bugs first instead of spending two days trying to reproduce a medium priority issue? Set 10 hours per day including breaks or even allocate some time for yourself to prepare for future tests instead of working around the clock with no sleep? If your goal is too big – break it down into smaller pieces which could be more achievable in a shorter period of time.

Let’s take another example – you are spending 3 days in a row working on that same 100 bug reports. It will probably increase your productivity if you fix 5 bugs per day compared to 10 or more, because after the 3rd day of non-stop work you’re going to be tired and not focused anymore. Try to avoid long hours of work – it doesn’t mean that a big amount of work can’t be done in a shorter period of time – try to set some reasonable deadlines for yourself. If for some reason this is impossible, check out our article about smart ways to stay productive when you want to study at least 8 hours per day.

3) Don’t focus on quantity of bugs

Don’t be afraid to work on a few bugs at the same time! If you see that 5 bugs are similar and it’s going to take you the same time to fix them, don’t go for all of them – try to group them and fix just one part. This way you will save yourself a lot of time and your code is going to be less buggy. It’s hard for some developers but if you want to deliver quality products it has to be done. If this isn’t possible check out our article about how you can keep your focus when working on multiple projects at the same time .

4) Don’t be afraid to ask people around

In the world where most companies use agile development as their common way of working, this is something you are probably used to already. But sometimes there are things we don’t exactly know and we think we know everything. Let’s make an example: let’s say you work on a project and there is one guy who has been working on it for like four years (he knows the business rules, he knows what to do and how to do it). You see your boss and he says: “Hey yeah I want this new feature done ASAP”. So you sit down, you code it up and now this guy comes along with his manager saying that he wants some changes in the business rules (because they changed) which basically invalidates your work.