» Frameworks help to spur thinking; they don’t provide the answers
» “I would be nothing without my dev teammates, but my devs would probably get on pretty well without me.”
» Use frameworks with discretion – and expect a bit less of them
» Identify the key stakeholders whom you need to trust you and collaborate with you regularly
» Understand the real reason for anger – whether in others or ourselves
» Remember where stakeholders’ help starts and ends
» To be trusted, you need to demonstrate your competence
You can learn all the theory you like, but at some point you just have to stop thinking about what the answer might be and dive in to find out. Product managers learn by doing.
Despite relying on each other for the success of their products, the Sales and Product teams often have a jarring relationship. This is far from ideal. By looking at where things go wrong we can identify a better way of working with each other. The prizes on offer: shorter sales cycles, more easily achieved targets and customers who are always happy to hear from you.
One of the easiest traps for a product manager to fall into is unquestioning routine or habit. I learned about this most through my time at university training to fly with the Royal Air Force. Let me explain how it applies.
You can run lo-fi usability testing in a single afternoon that will uncover 80% of the problems your product has, with only a pen, some paper and access to the software or website.
You expend a lot of effort getting people to buy your product and they’re happy with it.
Time passes.
You then go back to your satisfied customers and tell them what they have is now mediocre, so they have to move onto your latest and greatest product version. You see this everywhere, from washing powders to family cars, so it must work for enterprise software, right? So why are your no-longer-happy customers now chasing you with pitchforks and burning torches?
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.
There are many questions you need to be asking to determine the best course of action or to analyse underlying motivations. Of them, I use the following three questions most often:
1. So what?
2. Why?
3. What’s stopping us?
