Image by Flickr user 42614915@N00

It would be a shame if growing in your career took you further away from having an up-to-date perspective of what’s happening with your product.

You can quickly forget what life is like in the trenches. If you want to be an effective product manager, you need to actually work on the product. Some people estimate you should spend 30% of your time with hands-on work in engineering roles.

I would suggest that it’s paramount for product managers of all levels to be “do-ers”.

It’s crucial for managers in the Product space to:

• Get out of meetings
• Walk away from product roadmaps and strategy
• And lead by example by consistently getting into the weeds

How to get your hands dirty

Write a Spec

Product Requirement Documents drive the efforts of the entire product team. It’s hard to come by a more important, higher leverage piece of work for a company. Every quarter I make sure to take one project or feature and write the entire PRD and spec for it.

This includes writing up wireframes, mockups, business case, scenarios, technical discussion, and timeline. I also put it through the same process  my PM’s need to go through: review, iterations, sign-off, etc.

Teardown a Competitor

When I see a competitor that seems interesting or a technology that could be useful to our products, I will spend an hour on a Friday performing a teardown.

A good teardown will involve – where possible – getting hands on time with the tech or product in question, taking relevant screenshots, and writing up evaluative feedback. I then provide some ideas about how we can either beat the competitor or, failing that, integrate with them. I post these ideas into our wiki and share with the team. 

Triage Bugs

About once a week I will jump into JIRA, pick a product, and review the Priority 1 and 2 bugs. Do they match my expectation of priority? Great. If there are any questions, I will sit down with the individual PM and ask them about it.

Attend Individual Scrums

There are too many projects on my team to go to every scrum, so instead I pick one day each week to attend a different product’s meeting. I usually sit and listen quietly, then afterward will use my one-on-one with that PM to ask questions about what I heard. There’s a lot you can tell about a team just by occasionally showing up to their daily standup.

Why would you do this?

Respect

Students in my Product Management class at General Assembly this semester heard me start every lesson with some form of “This stuff is so cool! I love building products.” One of the first things I look for when hiring PM’s is their raw passion for wanting to build cool stuff.

Doing individual work like this shows your team, your peers, and your management that you are fired up about building products. You’ll earn their respect, which can be especially helpful when onboarding into a new team.

Improved efficiency

The first time you write a spec as a newly promoted manager (especially if you haven’t written one in a while), you’ll instantly discover what in the spec process needs improvement. Fixing these issues will make your entire team more efficient.

On our team, I realized that we had four different flavors of PRDs. I worked with Alex (one of our Directors of Product Management) to unify them into a single format. We then came up with a template for the new PRDs and put it into our wiki. That’s the spec process we use on all of our products today.

A Dose of Realism

It’s easy to think projects and products will execute extraordinarily well. As a manager in the Product organization, your goal is to balance your optimism for completing a project against your pessimism, your previous experience telling you how complex it is going to be.

Periodically writing a spec, attending a scrum, and triaging bugs can help you stay much closer to what’s actually happening inside your products and code.

Spend your time wisely.

Which will be more expensive: time spent on non-managerial work, or the risk of failure stemming from a knowledge gap between strategy and execution?