How to keep Product Management Simple and Effective

Product Managers who work in organisations where needless complexity tend to be less efficient than those who work in companies who have simplified processes, procedures and best practice.

I worked for a company sometime ago that was able to produce ground-breaking cutting edge products, but found it difficult to put in place the most basic processes and workflows, needless to say I spent a lot of my time fighting to do the simple things in life.

I’ll be publishing a few blog post over the coming weeks on organisational complexity and simplicity and what product managers can do to assist in turning the complexity (processes and workflows etc) into simplicity and therefore boost productivity and be able to focus and give more time to the important matters in your product management work-life i.e. deliverables (strategic planning, high value projects, meeting deadline…).

E-mail Causes Complexity with in Organisations
But for today I want to have a rant on by pet subject: “email” or should I say the abuse of email! (Tackling the constant flood of e-mails that consumes much of my working day is one of the things I aim to do better in 2008).

Ron Ashkenas in his article Simplicity – Minded Management list email etiquette or lack of it as one of the causes of a company being unnecessarily complex. He writes:

“When you send a large number of people a message that discusses issues many of them don’t need to know about, you’re just burdening your colleagues with low value information that distracts them from important matters.”

I’m sure we’ve all experienced being CC(ed) in on pointless emails and have spent much of our valuable working-day ploughing through emails ensuring that someone has not buried an illusive request or piece of information that could be critical if not attended to.

Likewise I’m sure we’ve all been in meetings where critical issues are being discussed, with colleagues that work in the same office, and you hear those irritating words – “I sent you an e-mail” usually it’s the extra-long email that was sent to half the company – the bit pertaining to the product manager was buried somewhere in it. The email sender never thought to pick up the phone or come and see you in person about the issue. I often wonder if such people would handle their personal business (moving house, transferring large of money between bank accounts) with out following through with a 1 to 1 or a phone call illicit feedback.

Tips on handling E-mail
Brian Lawley in his podcast “How to Get Twice as Much Done in Half the Time” gives a number of good tips on how to be more efficient with your time – ironically managing e-mail is the first topic he deals with. Brian gives several email pointers:
1. Check email 3 times a day – not throughout the day.
2. Separate work and personal email
3. Turn off email notifications – when the alert pops up on your screen it a) interrupts your chain of though and b) tempts you be drawn away from the task at hand to read/answer the e-mail.
4. Process e-mail rapidly & empty your inbox
5. Keyboard short cuts – helps speed up using outlook.
6. Read large emails that need thought and a long response at a set time.
7. Turn emails into tasks by dragging the email into the task bar.
8. Avoid jumping into long and controversial threads – 50% of long threads burn themselves out.
9. Clear your inbox out – leave it empty – by close of business every Friday – it’s sure to leave your head clear for the weekend – knowing that you are returning to work on Monday morning to an empty inbox.

What I’ve experienced so far.
So far this year I’ve adopted number 4 and 7 and it has helped to keep things simple and boost (albeit by a small percentage) my over all productivity. I’m not convinced that all of the nine pointers that Brian mentions are appropriate to all product managers – however it’s always worth reviewing and challenging your own working practices to see if they can be simplified before attempting to simplify your teams, departments or companies working practice.