» Rather than focusing on engineering team productivity, examine the causes of their low / negative value work
» When asked for development estimates, ask why they need the information and what they’ll do with the answer
» Different development tasks need varying amounts of user story detail
» Treat your developers with the same thoughtfulness as your users
» Decisions should be the result of rational and deliberate reasoning, but not all are perfectly rational
» Almost every decision has associated downsides or compromises
» Avoid trying to please people or to allow individuals to dominate the decision-making process
» It’s easy to conflate transparency on the decision-making process, with transparency on the actual decisions
» The best moment to teach a user to use a new feature is when it is valuable for them
» Uncompleted tasks stick in a person’s memory, completed tasks are more easily forgotten
» Provide a safe, controlled environment to help users experiment and learn a new skill
» Developers and managers often have conflicting views of what constitutes value in software
» Software engineers should ideally understand both what they are building and why
» Unforeseen edge cases can cause headaches at roll-out, but provide valuable lessons
I strongly believe that all software companies should have a manifesto or a set of guidelines for usability.
As a product manager, how do you know you’re doing your job well? 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.
