I strongly believe that all software companies should have a manifesto or a set of guidelines which set out in practical terms how they will ensure that their products are intuitive for the types of user for which they’re intended.
For product managers, even if your company or Development team doesn’t “get” usability, you can build these into your product requirements and use your Quality Assurance team to check the requirements have been delivered.
As a product manager, how do you know you’re doing your job well?
Depending on your personal motivations you may want to know for your own satisfaction, to give your boss evidence at your next pay review, or to give your résumé some teeth for your next job. This article outlines the problem with traditional metrics for product managers and offers some better alternatives for measuring success: communication, ideas, roadmapping, launch and end-of-life.
Your developers may be happiest when they’re hacking gnarly code, leaving you to get on with engaging with the market, but this doesn’t mean you can ignore their need for context – the ‘why’ of their project.
Over the years, I have spoken to many disgruntled developers over a beer after work. This isn’t entirely coincidental as they tend to dwell in the kind of pubs I enjoy: real ale, good selection of crisps, ability to hear oneself think, minimal bar fights, that kind of thing.
What tends to be a recurring theme of their disgruntlement is that they don’t see the point of their current project. They feel aggrieved that they’re not doing something more interesting instead. And you know what, if it’s your project, it’s your fault. Bad product manager.