Mayan 4.
Mayan 4. (source: David Spencer on Flickr).

This week, I sit down with Matt LeMay, product coach, consultant, and author of Product Management in Practice. We talk about the four guiding principles of product management, what he has learned about himself as a product manager, and how to conduct meaningful research.

Defining product management

To me, being a product manager is all about being the connective tissue, the glue that connects whatever the different roles are within your organization. The specific organizational roles might vary, depending on where you are. You might be working more closely with technical people. You might be working more closely with marketing people, but whoever those different players are, your job as product manager is to be the aligner in chief or translator in chief, the person who is ultimately responsible and accountable for everybody having a shared language and a shared sense of purpose.

CORE product management skills

The four guiding principles came out of the four CORE skills, which is an acronym for communication, organization, research, and execution. I wrote a piece on Medium a few years ago, which was my attempt to challenge the traditional three-way Venn diagram of product management with business, technology, and UX. Having worked at a lot of enterprises and companies where people might not actually be that close to the technology side or might not be thinking about user experience as a day-to-day concern, I felt like those three areas captured a common set of subject matter knowledge that product managers will encounter, but not the actual skills they'll need to connect between those different subject matter ideas. Some people commented and rightly pointed out that something seemed to be missing from it.

That thing seemed to be an element of research, or the ability to actually glean information from the outside world. Erika Hall, in the book Just Enough Research, says that, "Research is just applied critical thinking," which I love as a way of defining research. I like using the word ‘research’ because it also makes it clear that it's not just about being smart; it's about actually doing the work of seeking out alternate perspectives, and explanations, and ideas. These four skills—communication, organization, research, and execution—each one comes with a guiding principle, and I stand by these four guiding principles. For communication, the guiding principal is clarity over comfort, which is really going back to what I was talking about earlier, about this idea that there are times as a product manager when you will have to state things that might seem painfully obvious or ask questions that you know are wading into really difficult political challenges for the organization, but if there is not absolute clarity in your team and in your organization about what people are working on and why, then you cannot succeed as a product manager.

If people don't know what they're doing and why they're doing it, and know that really clearly, then it doesn't matter how good the thing is that you ship or how quickly you ship it; the team will eventually start to fragment and fall apart because that understanding is so fragile and so susceptible to miscommunication and to tomfoolery by people who are trying to steer the product direction one way or another.

For the organization principle, we have ‘change the rules, don't break the rules.’ This was another one that took me a long time to understand. I come from music. I am not a process person. I think a lot of folks who start out as product managers are like, "Yeah. All this stuff is stupid. We shouldn't have 800 steps to do everything. We'll just work really fast. We'll move fast and break stuff, and it'll be awesome," but there's a downside to that, which is that when the rules don't work and people work around the rules, you're basically incentivizing rule breakers and people who are not communicating well. The people who figured out how to game the system accomplish the most, and the people who are trying to go through the system are dinged for not shipping enough software or not being performant enough in whatever way.

For research we have to live in the user's reality, which is pretty straightforward, but also very difficult. When you work in an organization, you live in that organization's reality. That is your day to day. You believe the things people in that organization believe, and it's shockingly easy to become fundamentally misaligned with the reality of your customer, especially when the metrics are telling you you're doing an okay job, but your customers are actually not that engaged. Living in your customer's reality is about getting beyond just looking at isolated metrics, particularly vanity metrics, to understand your customers and really understand their perspective, their world view, how it's changing, how it's evolving, so you can continue to meet their needs as they change and evolve, rather than getting stuck in the way things have always been and the status quo of your organization.

Finally, for execution, this is one one my favorite ones: no work above, no work below. This means that as a product manager, you have to do whatever it takes for your team to succeed. It's pretty well documented that there can be no work below you or beneath you as a product manager. Right? If you have to bring coffee and donuts to the team, that's what you do. If you have to learn how to do something that isn't super fun and exciting to you, that's what you do. Product managers who say, ‘That's not my job,’ or, ‘That's not something I like to do,’ do not generally succeed.

Living in your user’s reality

I'm a firm believer in qualitative research generally, but within that set of qualitative research, I'm a firm believer in talking to people who are not your best customers. I'm a firm believer in talking to people who are considered casual users or users who abandoned your product. There's a tendency, when companies do qualitative research, to over index on the power users and the good customers and to just keep building things for them, but when you talk about living in your user's reality, you're really talking about living in multiple realities for multiple users. In a lot of cases, the people you're talking to need to be the people you're most afraid to hear from or who you initially feel have the most tenuous and least passionate understanding of your project, because those are often the people who are going to make or break your product's success and who are going to be where your growth opportunities come from.

When I talk about living in your user's reality, a lot of that has to do with getting outside of the closed feedback loop of looking for the vanity metrics that support that you're doing a good job and talking to the good customers who will tell you how much they love your product and also have a million product ideas. It's the people who don't really have any product ideas who are just like, ‘Yeah. I don't know. It's fine. Sometimes I use it. Sometimes I don't’—those are the people whose perspective you really need to understand the most because their perspective is probably the farthest away from yours. Not taking those people seriously, not considering them, is a very dangerous thing that I've seen a lot of product organizations do and fall into.

It's funny. I was at a training with a financial services company a few weeks ago. We were walking through some qualitative research, and people were getting very tense, ‘Well, I'm talking to somebody, but they went totally off into left field, and they're not talking about my product anymore. They're talking about their life.’ I get that concern. Right? Because you're there to do a job, but there's an element, and this feels sort of esoteric, but I think it's true, there's an element of faith that goes into those kinds of conversations, where if you really trust and follow somebody's own line of thinking, there will be value in it, but if you go in trying to steer a conversation back to your assumptions or the things that you want to be true, that is exactly where the conversation will go.

Related resources: