Product Manager is one of the most common and sought after types of Product roles. This allows for more diversity in skills, capabilities and experience than many other product roles such as a UX Designer or UI Developer.
As such there is no one set path to becoming a Product Manager, but what all successful PMs have in common is excellence in communication. Also he should be aware of his team’s strengths and weaknesses.
Below I’ll discuss some simple tips and tricks on how to communicate effectively with your team:
1) Identify the problem, then build consensus around it
You’re likely too close to the situation that needs solving to see clearly what the actual problem is — use meetings, 1:1s and group discussions to get everyone onto the same page about what you need to achieve together.
2) Be specific
Don’t ask for “more feedback”, instead give specific instructions on what kind of insight you need. For example: tell your team to focus on which features users are struggling with or where they seem confused. If possible, talk to the relevant people (e.g. designers, analysts etc.) first and get them thinking about how to address any issues they identify before you meet as a whole team .
3) Don’t over-promise
This is an easy trap to fall into when you feel passionate about solving a problem – but your enthusiasm may result in committing too early to deliverables that are not feasible given the time/resources available. Before verbalising any high-level ideas, always engage with developers to see if there are any constraints that could impact the feasibility of your suggestions.
One way you can reduce over-promising is by sharing just a couple of detailed insights from your user testing in each discussion. By focusing on a few problem areas per discussion, you can ensure everyone starts off on a level playing field and also covers more ground . It may be useful for someone to facilitate this part of the process – simply use their presentation skills to make sure everyone receives the information you want them to have.
4) Synchronise Inbox contents with team members
One commonality between many UX professionals is having multiple projects going at once! Even though this may result in extra work, it can be really useful to spread the feedback you receive across your projects. Your UX mailing list can be a great way to help with this.
5) Work with your team to process and prioritise feedback
After you’ve gathered all of the feedback, it’s time to get everyone together and discuss what you’re going to do with it. Again, there are a number of ways this can be done – you could set up a meeting, or just get everyone on Skype at once. It depends how many people need to be involved and their geographical location. You should also work out if any stakeholders or subject matter experts (SMEs) need to be present; for larger projects this is often the case.
Once everything has been discussed, create some form of action plan: identify which issues will make it into your next sprint/milestone and give them each a priority level (for example: P1, P2, P3). The sprint/milestone should have a deadline to aim for – stick to it! You can also use this method with agile project management tools like Jira if you want more automated functionality.
The issues that aren’t being dealt with any time soon will be stored away in the backlog to review again later. Again, this is an area where Agile project management tools are particularly useful because they allow you to create backlogs and assign them tasks, so everyone involved knows what’s coming up next.
After getting sign-off from everyone on your action plan, get started! Implementing technical debt reduction is something which has an immediate effect on your codebase/application – unlike refactoring which might not be that noticeable until the end of a project.
Just keep in mind to pay attention to additional questions which might come up as you’re going through the process, and ask again if you’re not sure what to do. It’s neutral, it won’t make anything worse – but it might improve your application even more!
You could suggest that each team member provides a brief introduction to their project and then invites everyone to do one of two things:
1) Reply directly to the email thread – synopsis of problems/problems found, who they affect most etc.
2) Forward it on as an FYI email to someone else involved in another project – perhaps they’ll have additional insights or thoughts on the problem(s).
It’s likely that people will choose option 1 more often than not, but I think everyone will appreciate having a second perspective on any given problem if for nothing more than validation! This way you’re ensuring that everyone is appraised of each problem and more importantly, you can have a second data point to compare your findings against. In the event that someone else has already been working on this issue independently of you, they will likely be able to add additional insights or perspective on what you’re seeing.