There’s two halves of product management. One half is strategy, research, scoping, shaping, customer interviews… broadly, figuring out what to work on. The other half is ensuring that what you picked gets correctly built, promptly shipped, and used as intended. Broadly, execution.
Most product management literature is about the first half, and if you read it you’ll come away thinking that the correct way to do product management is to go on a vision quest and come back with a perfectly written spec that you hand the devs.
The execution half is more interesting because it actually matters. You can do the first half totally wrong (eg. how I described above) but if you manage execution well you’ll still ship great stuff and look like a genius.
The best product managers I’ve worked with do this through what I describe as Product Management by Walking Around.1 What does this entail? Basically: meandering around in the vicinity of people building and designing things, asking them open ended questions about what they are working on, and answering whatever comes up.
Ask someone what they are working on, get excited about the answer, probe for a bit more, and it’s almost inevitable you’ll touch on something they aren’t sure about.
We don’t know if we need to include this widget, it’s in the spec but it’s way harder than we thought.
We think this button should say this, but maybe it should say that.
The spec says the button should say this, but that doesn’t actually make any sense. Still, we don’t want to go against the spec.
I think this is what users want this to do, but I don’t know for sure and I don’t know who to ask to get confirmation.
I need to access to this other system but I don’t know who the admin for it is.
I have no idea how this should work, and don’t even know where to start.
I think this is the right approach, but I don’t know if it will scale, so I’ve blocked myself while I stress about that [when in reality it will have 10 users max].
Someone said I need to add pagination, but it works fine with 5 records, do I need it? [when it’s likely the screen will need to handle thousands of records]
So much of the execution phase of product management boils down to answering questions that the spec didn’t answer very well. Often the answers are simple ones that you can answer immediately in an informal setting, like when you’re walking around. But if you don’t answer them immediately, they tend to bubble up into big problems that don’t get raised until much later.2
As a PM who walks around, most of your answers will be simple. “That’s important”, “That’s a good idea, but we can ship without it”, and “That doesn’t matter, you don’t need to build it ever” will cover a lot of questions. So it might feel like you aren’t contributing much. But remember: if you ship 2 weeks earlier, then spend those 2 weeks adding in some nice to haves you missed along the way, the world won’t end. But if you waste 2 weeks building something nobody needs, you’ll never get that time back.
As a developer, the most annoying thing in the world is being blocked. When you don’t know what to do next on a specific problem, and the answer lies outside the code, it sucks. It can grind a whole project to a halt. As you learn more about the problems you’re trying to solve and the customers you’re solving for, you get more confidence to make decisions yourself and unblock yourself. But how do you learn those things? I’ve found that a PM walking around and frequently, informally, nudging you in the right direction to be the most effective way to both unblock you, and to help you grow.
Sadly, most product managers don’t work this way. Now that I’ve convinced you why walking around is a great way to product manage, let’s dive into why it’s not a popular way to product manage.
Domain expertise
To do this well as a PM, you need to be able to answer any question correctly, confidently, and on the spot. The number of decisions that need to get made when building something is immense, and the number of different ways the same question can be phrased makes that even tougher.
Building this much domain expertise is really hard. There’s no silver bullet to learn quickly. To develop enough context to be able to answer any question on the fly, I think you need to do three things:
Spend a lot of time working closely with customers and understanding their problems as well as they do.
Spend a lot of time working closely with developers to understand their decision making processes and biases.
Spend some time writing code yourself, so that you can relate to the process of going from customer idea to shipped outcome.
On a large product, it’s easy to build expertise in one narrow slice of functionality, say, 5% of the product. If you spend 6 months only talking to customers about one feature, you’ll be able to speak their language about that feature. But that’s only 5%.
I think to give good answers on the fly you need to have great context about at least 75% of the product. To give great answers, you should have a great understanding of what customers use 100% of the product for, and have a good understanding of what lies under the hood.3
You will never get there by studying each narrow slice of the product 6 months at a time. To be a great product manager, you figure out a way to learn everything there is to know about a product an order of magnitude faster.
Fear of decision making
Why isn’t product management by walking around something everyone does? The first and most obvious reason is that doing it really well requires a lot of domain expertise, and that’s really hard to build.
The other big obstacle is a fear of making decisions that could be wrong. As a PM, if you don’t make decisions for developers, eventually they’ll pick something so they can move on. If they get it wrong, it’s tempting to believe that wasn’t your fault - you didn’t make the call. But it is your fault, if you should have made the call.
Since never deciding anything is a bad look, some PMs will instead organise a meeting every time any decision needs to get made. This wastes everyone’s time, and it leads to decision making by consensus, which always leads to less clear decisions. It’s just a complicated technique for avoiding taking responsibility.
Paradoxically, making more decisions makes it safer to make incorrect ones. If you decide something over lunch, and then a few hours later realise that was wrong, you can just change course while doing an afternoon coffee run. A few hours are wasted, but that’s much better than shipping the feature and then learning you were wrong. So by making more decisions faster, you’ll lower the downside to making incorrect decisions, and (through practice) you’ll get better at making correct decisions.4
This only works IRL
I have never seen PM by walking around successfully done virtually. The “walking around” bit should be taken literally. A lot of product management by walking around gets done during lunch. If you want to be a good PM, train yourself to walk a bit slower to and from lunch, and draw the meal out a bit more.
The best product managers are always tricking you into turning lunch into a tech scoping session.
Often the correct answer is “don’t worry about this, it doesn’t matter”. If you don’t give this answer, devs will worry about it, and suddenly you’ve built a lot more software than you needed to.
What lies under the hood can mean a few things, depending on what you’re building.
For example, we interface with accounting software, and accountants, a lot. If you don’t understand the difference between debits and credits, parts of the codebase are going to a really challenge to work in. Product managers that understand “how accounting works” make much better decisions, and are able to give much better answers, than those that just know what customers say they want.
For another example, a lot of product decisions are implicitly about scale. Realistically, how much data will this feature need to process? 10 records, 10k, or 10M? In many cases this totally changes the approach to building it. Rarely will developers ask that question directly, because they usually pick one number in their head and build just for that. A good PM will identify cases where context around scale matters, will give clear guidance around what scale to expect, and will call developers out when they’ve made an assumption that’s totally wrong.
This doesn’t mean that every decision should be made by a PM. This is where judgement comes in. If you’re getting put on the spot for stuff that’s obviously not your role - “should we enable this lint rule” - you should push back.