
Ask HN: What makes a product manager better than the rest? - jkkorn
Recently started a new job handling a larger team with tighter deadlines. What&#x27;s something a PM did that helped you out tremendously?
======
MrTonyD
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.

------
sharps_xp
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.

------
dbg31415
(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.)

~~~
dbg31415
Some tools I really like to help everyone create better bug reports:

* Marker - Visual Feedback & Bug Reporting Tools for Web Professionals || [https://getmarker.io/](https://getmarker.io/) (for GitHub)

* Capture for JIRA | Atlassian || [https://www.atlassian.com/software/jira/capture](https://www.atlassian.com/software/jira/capture)

