There are a great many different corporate cultures to be found in the world, but one consistency among far too many of them is decision-making processes that rely more on gut-level instinct and whomever yells the loudest rather than on hard data. For some companies, this has served the CEO well — a small, nimble startup can’t always waste time doing detailed validation or data-gathering in a “stop moving forward and you’ll die” environment. In other companies, it’s become the de facto standard due to strong personalities who may prefer authoritarian leadership styles over more democratic and empowering styles. Regardless of the reason, though — companies like this eventually wind up struggling because they make the wrong choice one time too many, based on the leaderships “market instinct”. And it’s our job as Product Managers to shepherd these companies into a more modern-day, data- and hypothesis-driven approach. Here are three major reasons why data-driven management is far more effective than management by gut or personality.
It’s time for the next installment of my ongoing series of “Ten Questions” for thought-leaders and colleagues from the Product Management world! This month I’ve reached out to Paul Jackson, a longtime Product Manager from the UK who showed up on my radar a few years ago when he started to feature some of my posts in his articles and in his newsletter. Since then, we’ve exchanged thoughts on a wide variety of topics, and he was high on my list when I started up this ongoing series.
As Paul describes himself:
Paul is the publisher of Pivot Product Hits, a monthly newsletter on product strategy and a regular writer on all things product.
As a Product Manager and user-centred design practitioner, Paul has been building digital products and services for over 15 years. Currently Managing Director of Castle in the UK, he was Head of Product Management for The Times and The Sunday Times and Director of Product at Newsmart, an edtech SaaS that leverages premium news content from the Wall Street Journal.
There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
One of the more common challenges that growing companies face is balancing the needs and goals of the company with the needs and goals of its employees. And, unfortunately, all too often decisions are made with a business perspective that don’t take into account the potential effects on the personnel side of the equation. The simple fact is, people will do what we incent them to do and what we reward them for far more often than they will do what we want them to do, if there is any misalignment between the two. This applies across the business — from high-level executives to entry-level employees, and even out to our products — how we position, package, and price our products can often drastically affect how people will perceive and use the product.
While people always seem to nod their heads when you tell them this, it’s rather insane to realize just how often we create competition between these two things. Here are some things to consider when you’re trying to figure out how to get people to do what you want, or why they’re not doing what you expected.
I’ve talked before about the dangers of a “cargo cult” mentality when it comes to Agile practices, but in this instance I’m going to take a Devil’s Advocate position, at least it will appear that way. All too often, people and companies start their Agile transitions with training about the “theory” of Agile — what it means, how it should work, what glorious and wonderful benefits are, and to attempt to indoctrinate people into concepts that may be entirely foreign to them and how they’ve done their work in the past. The problem is, nobody really cares about theory — and all too often the theoretical underpinnings are lost as soon as people get back to their desk and start their next day of work. Here, however, I’m going to propose a plan to implement Agile practices without the theory, and without creating a “cargo cult” mentality where you’re just going through the motions without understanding why…
Back in 2015, after about a year into my work on this blog, I put together a reading list that encompassed the fundamental books that I thought every Product Manager should read — and I still stand by the list: A Product Management Reading List. But, that was almost two years ago and a lot of good books have crossed my path between then and now. So, without further ado, I give you an updated list of PM reading materials for you to peruse to your hearts’ content (and, as always, there are no referral codes on these books, and only one was provided to me free of charge — noted in its listing).
Many people are aware of the famous quote from Peter Drucker, “What gets measured, gets managed.” But what people don’t often consider is that what’s being measured and managed might actually not matter at all at the end of the day. When we measure things that don’t actually drive us to improve, we’re just acting like a cargo cult — going through the motions and expecting something magical to happen that never will. Instead of just picking some popular or standard metric, we should instead make sure that we understand what direction our measurements are going to give us, and what change they’re going to drive in our behavior or in our products. Only by being thoughtful and deliberate in our choices will we find the right metrics to use and rely on in our choices.
Here are a few things to watch out for and to take into account when considering what metrics we want to put into place…