Ask HN: What makes a product manager better than the rest?

I've consistently found that strategy had far more impact on schedules and success than the frenetic approach I've seen at companies in the past decade. Over and over again, I see companies with poor product or poor marketing or poor sales or poor management that are trying to coax more from their employees - claiming that hard work will solve their problems.

Just as consistently, I've found well managed companies to have more sane hours (with occasional exceptions of course - eg. greedy founders) and that good strategy leads to successful tactics and markets that can fund a more sane work life. I should add that I'm over 50 and spent my entire career in Silicon Valley - lots of startups and a couple of Fortune 50s. I've had the Product Manager title three times. Had my share of both successes and failures.

As an engineer I'm most impressed by a PM when their insight/experience/analysis leads to high quality hypothesis that when implemented have high impact on the business. I find myself in anticipation for the features based on someone's expertise with the product and industry. It also adds a lot of purpose to my dev time.

Conversely, a streak of incorrect direction can make the PM lose credibility hard and fast.

(Not a dev, but these are things I get positive feedback on from my team.)

Ask a lot of questions. If you don't understand something, don't just pass the buck on to the next person who opens the GitHub / JIRA ticket. Do all you can to make sure it's clear and documented. A general rule, the ticket needs to have enough information for a new hire to grab it and work on it independent of any other information -- you never know when a new person on the team will have to look at the issue. You want to make sure you are very kind to your future self so that 6 months from now when you've long forgotten what the original intent was, you can go back and read things that make sense.

Create clear, consistent requirements. Your template for new features / changes should include things like a user story (with personas the team agrees upon), annotated wireframes and / or visual designs, acceptance criteria, steps to reproduce / test, and any dependencies or special needs that have to be taken into consideration. If it's a bug, make sure you are explicit with what the expected resolution is. "A stitch in time saves nine." The more of this stuff you can think through, the more control you'll have on the finished product, and the smoother your team will be with their estimates. Do your best not to skip over the imperfect path stuff... Always have a list of what a form requires, and what every possible error trigger is, what the error message should be. Make sure you include things like if something has to be tested with a specific change in the database, or after a change has been made to a third-party tool. Do what you can to keep everyone using a shared and agreed upon vocabulary.

Aggressively go after scope creep. If someone wants to change or add something mid-sprint... make sure it's a trade-off so the production team doesn't get stuck carrying more than they signed up for when you asked them to estimate the work. Set deadlines for the people upstream in order to set deadlines for the people downstream... (I realize this bleeds more into project management... but often process does play a significant role in the outcome.)