5 Things Product Managers Should Stop Doing Immediately

1. Not trusting experts for their expertise

In order to create great products you need a great team and support network. Luckily, you’re surrounded by intelligent and able people. People who have expertise in areas you don’t, who know more than you in different domains and whose time is better utilized in ways yours isn’t. The secret to success is not to know everything. Instead it’s about influencing the people who do know the things that you don’t to come along on the journey with you and help you build something best in class because they share your vision and believe in what you’re doing.

We’ve all been guilty of trying to do everything ourselves. Were you one of those people in college who hated group assignments because there were always one or more people that did something in a way you wouldn’t have done it? I was that person.

Luckily for you, it’s likely that in your work environment there are a lot of talented people who do things in ways better than you. It’s probable that you’re surrounded by experts, people who are fantastic UX and visual designers or highly proficient in building awesome websites using advanced web frameworks. You’re testers are never more than a software application away from being able to test your product on every device imaginable and your scrum master is an expert at removing impediments to the team so that you don’t have to.

Top tip — afford yourself the time to rely on others to do their jobs well so that you can focus your time on the most important things you should care about as a product manager…the product and its users. You’re the CEO of the product but that doesn’t mean that you’re the person who does everything to make the product the best in class; you have a team of people to support you with that. Align them to your product vision and build trust with them to believe that you will guide them in the right direction but whatever you do, don’t do their jobs for them.

Listen to their feedback, incorporate it and challenge it. Encourage your experts to call you out when you’re heading in the wrong direction and create an environment of collaboration where every voice is heard. You’re the product manager and you make the final call but that call should be well informed and that’s why you need to trust your experts. You need to rely on others to inform you why your application should be built using Ruby on Rails vs. Python and Django or why the design of your product is the way it is…maybe your interaction design expert knows a thing or two more than you about the correct use of different easing and animations depending on different types of user interaction. Learn from your experts to become a better product manager.

2. Being a perfectionist

Perhaps the most important lesson I’ve learned in recent weeks is knowing how to focus myself on the things that matter and learning when to let go of things that’s don’t matter. I’m a perfectionist by nature. In my head I know exactly how I want everything to be done; I want perfect dashboards that consolidate all my data points, I want a well drilled scrum team who are all on the same page and I want faultless designs that solve for every scenario imaginable. It’s a fruitless pursuit — it’s hard for me to say so, but what you deliver and how your deliver it is as much an art as it is a science. The nirvana you have in your head for your product and the process by which you deliver is a vision to work towards but not one you will necessarily reach, so don’t let it frustrate you.

A few things that I’ve found helpful in my bid to stop being a perfectionist:

1. Ask yourself, what is your responsibility as a product owner?This is very important. I’ve found myself investing far too much time in 2015 tinkering away trying to make my teams agile delivery process a well oiled machine. I’ve dragged peopled to the water but not been able to make them drink. I’ve spent hours educating people on the benefits of test driven development, continuous integration and so on…without many bites. I’ve been left frustrated by 101 things and left wondering why no one else wants to change the world like I do. The reality is that there’s a capacity to how much you can change and there’s a limit to how much you can influence people.It’s not a bad thing to invest time in but when you start caring too much about things that are important but maybe not essential to moving towards your product vision then you need to abstract yourself and think about where your time really is best invested. If you’re like me you will probably need someone to pull you out of the weeds sometimes and pivot you so that you’re focused on the right thing. Ask yourself, why am I investing time in this? If your answer is, “it’s because it’s the highest value thing that will delight my end users and something I can learn valuable insight from”, then you should probably keep doing it. Otherwise, cut your losses and pivot yourself on to the things that really matter.
2. Ask yourself, what outcomes and goals I’m I trying to achieve? I mentioned above that sometimes you need to abstract yourself and pivot your attention on the things that matter. One of the best ways to understand what the things that matter are is by looking towards the goals and outcomes you’re trying to achieve and asking yourself, “Are the things that I’m doing moving the needle against these goals and outcomes?”. Also make sure that your product vision is displayed in a visible place so that the whole scrum team can see it. The product vision is you and your teams compass that keeps you on the correct path and ensures that all that you do is aligned to what you’re trying to achieve and what is best for the end user of your product?
3. Ask yourself, who is my majority user/persona type? There’s an icky heuristic used in corporate called the 80/20 rule. Basically the rationale is that you should worry about the 80% or the majority and less so about the 20% of the minority of users. Your persona’s (which will be data driven) should be able to give you a good idea of who your 80/20 demographic and where your time is best spent, however I don’t think it’s always as black and white as that but it’s a good rule of thumb nonetheless.A good example…let’s suppose you’re the product manager of a car rental website. Imagine 95% of your traffic hires cars for 1 or more days and that 5% of your traffic is interested in hiring cars by the hour. Let’s suppose you don’t offer the ability to reserve cars by the hour online but you do allow it via you phone channel i.e. customer service reps. You may think the next priority feature is to move the ability to book cars by the hour online. However, what if you have a 50% drop off on the review page of your website for those users trying to hire a car for one or more days. Maybe your time is best spent addressing the needs of the masses and fixing that CTA that’s hidden below the fold, adding in a progress meter to give users a sense of orientation or enhancing your nomenclature so that users are clear on transactions they’re about to perform.The latter areas of focus are probably going to delight the masses and may well be low hanging fruit that can give you some big wins. The reality is your vocal minority who aren’t happy they have to call in to book by the hour will still be left frustrated but your ‘weekend warrior’ persona types who hire cars for weekend escapes are now converting 30% higher than before and it’s probable increasing revenue is one of your major outcomes vs. call displacement.

3. Doing too much at once

Last week I begun writing a series on agile charts and how to read them. One of the most fascinating charts was the cumulative flow diagram and a lot of readers (and I mean a lot) got in touch with me afterwards asking why their charts looked nothing like the ‘ideal’ cumulative flow I detailed. The reason — too many developers in their scrum teams were taking on lots of work in parallel and not getting anything ready for test until the latter days of the sprint. This left the testers idle for the first three quarters of the sprint and then overloaded for the last quarter. It means defects couldn’t be solved quickly enough.

It got me thinking about my own working habits. I looked up at my product backlog and saw the top 10 features I was working on were all about 20% defined…some were missing design, some had poor acceptance criteria and others were a few compliance calls away from meeting the definition of ready. I was juggling 10 things at once and doing a pretty mediocre job pushing them towards the definition of ready because I just had too much in flight. The issue with this is that it’s a cascading effect…my designers were also trying to design 10 features at once and as a result there were gaps in the design and oversights made, which were picked up by developers mid sprint…you get the point.

In lean manufacturing this inefficiency is called Muri i.e. the waste caused by overloading or overburdening a single resource. I was on a noble pursuit…I wanted to change the world and make an awesome product but I was shooting myself in the foot by focusing on too many things at once. The best thing I’ve done recently has been to focus myself and the team on the 1 or 2 things that matter most — everything else is just a distraction.

4.Missing Agile Ceremonies

As a product manager you need to lead by example and attending agile ceremonies is an important part of your role and it’s important to the team. Often times your agile ceremonies are the only times your product team get to interact with you outside of e-mail, especially if you’re not part of a co-located team.

Your stand ups are a chance to understand how the team is progressing and if they have encountered any barriers to progressing that you may be able to assist with. The grooming session is your opportunity to tap into your team’s expertise in order to blast through complexity and write high quality user stories that are low in ambiguity and will present no confusion when they’re moved into the sprint backlog. Sprint planning is your opportunity to set the teams priorities for the sprint to ensure that you’re working towards moving the needle on your highest value outcomes. Retrospectives are your opportunity to praise good practice, call out opportunities going forwards and be made aware of anything you can do better going forward. Finally, sprint demos are extremely important — it’s the team’s opportunity to show all of the value they’ve delivered and the work they’ve taken pride in to a wider audience. It’s important for team moral.

Attending ceremonies is important. There’s something’s that just can’t be hashed out via email or instant messenger. If you don’t work closely with your team you should expect churn when they misinterpret acceptance criteria or don’t deliver due to remove able impediments.

5. Getting it all your way.

As a product manager you have final say over the order of the product backlog and what goes into the sprints. No one can contend that. You are the guardian of the end user and people count on you to make the decisions that are in the best interest of your users. Decisions that are data driven and that are drawn from your experience creating exceptional products and user experiences.

However, that does not mean that your team can’t influence the priority. They can. You will prioritize your backlog with data driven insight from numerous sources, to pursue your product vision and to move the needle on the outcomes your team has defined to achieve organizational goals and deliver a best in class product. You should also be prioritizing the backlog considerate of what your broader teams is informing you is important.

Enjoy this? Join the community at www.productmanagerclub.com or follow us on Twitter at https://twitter.com/