daniel's domain

The hands-on product manager

People say that a good product manager writes great documents, figures out the product strategy and plans the roadmap. These things matter, but they're proxies to the actual goal of making your business successful.

Here I'll cover the specific hands-on practices I believe lead to greater product quality, a more effective team and consequently a more successful business.

Move things forward every day

Tactics is knowing what to do when there is something to do. Strategy is knowing what to do when there is nothing to do.

— Savielly Tartakower, Chess GM

A common failure state I’ve seen is to over-anchor on strategy and leave tactics to the wayside. Until you're running the department, you need to get the day-to-day work right - and even when you're at the top the ability to be a hands-on operator is invaluable.

There is always something to do and you’re the person responsible for getting those things done well, and on time. The hands-on PM is much better positioned than one that can only work at a birds-eye view.

You can write beautiful docs, set piercing objectives and key results (OKRs) and conduct insightful user research. But if the bricks aren’t being laid or the fires extinguished in the metaphorical house that is your product, that house will burn down along with all those beautifully written documents.

Understand how the product you’re building serves the customer and how your organization is structured to build it. Then position yourself to be able to fill any role in that process:

Being hands-on builds empathy. You rely on talented engineers, designers, marketers, and more to get things done. Putting yourself in their shoes helps understand their work, which in turn allows you to work better together.

Use your product - a lot

If you're responsible for onboarding, sign up for a new account on your platform every week. Make a note of what’s broken and what doesn’t feel good. Fix it yourself if you can. Ideally you're as competent with your product as any of your power users are. Depending on what you're building, sometimes it's impossible to use your product the same way a customer would. The next best thing then is to shadow your customers as much as you can. Read tickets that your customers are submitting to support. Join customer onboarding calls.

Take copious notes and screenshots. You'll build your own list of things that need to be done, and if your skillset is diverse enough, you'll be able to take care of some of them yourself.

Build a diverse skillset

Be a jack of all trades (and ideally a master of some). A PM should be able to build, sell and understand. Keep a mindset of continuous growth and don’t limit anything as outside your job description.

You should still be a great delegator, but it’s a huge boon to be able to do and critically review the things you delegate. Having skill overlap with the operators you delegate to also allows you to validate the quality of their output, and work together to make improvements where needed.

Also, there will come a time where the person you delegate to will not be there (see the bus factor). And that will be the thing that needs to be done that day. Wouldn't it be great to be able to do that thing yourself?

If it’s a role on the Go-to-market or Product side of the company, you should aspire to be able to do it.

Bugs, bugs, bugs

Bugs are a great way to get hands on.

You should be the filter for bug reports on your product before they go anywhere else.

It protects your engineering team from unnecessary context switching and encourages you to fix things on the spot where they're small enough to do so.

It also forces you to see the patterns in the side of the product that is often not visible to the PM - what needs maintenance, what needs replacing, what needs deprecation. This in turn builds trust with your engineering team. It gives you visibility into all four corners of the product, not just the shiny upcoming feature. It helps you appreciate the hard work from people working on the equally important but less visible maintenance and improvement work, and the value created from it. It shows you care.

Just do it

If there's something that needs to be done, and you can do it, do it. Don't spend 15 minutes writing a ticket, another 10 minutes in planning getting it assigned for someone to do, and then another few days for it to get to the top of the queue. Just do it yourself.

You get a shorter backlog, your team continue focusing on the technically tougher things, and you can enjoy the surprised face on your happy customer or colleague or manager when the thing they asked about was done an hour after they asked.

This applies to bugs, feature improvements, and any other small task that might sit in a backlog for weeks before getting done. The most valuable things to just do fall into the important, but not urgent bucket.

Planning and sprint cycles are an important part to protect the deep focus that engineers need to do their work. But PMs are constantly context switching, and filling in loose half hours here and there with impactful, tightly scoped changes is a powerful use of that time.

I like to see the just do it bucket of work as the PM equivalent of making your bed in the morning. It starts everyday on the right path for good work. Working in this manner may contribute to more illegible work, but it's exactly this kind of work that builds great product quality over time.

Finally, audit your direction. Perfect tactics is no good if it's not directionally correct. Take the time to verify that what you're doing is building towards a cohesive goal. Being in the right ballpark is fine, it doesn't have to be perfect.

When you're hands-on, you're hearing about what needs doing directly from customers and your go-to-market counterparts. You're feeling the technical debt when you try to ship a simple fix. This direct contact with reality is your compass and guiding star over any “best practice process." Be a builder alongside your team and you will have a more effective team and happier customers.

Further reading

Some pieces from others that helped supplement my own thoughts here: