
Ask HN: Resources to learn to become a product manager? - justaguyhere
Anyone moved from programming to product management? How was the transition? What resources did you use?
======
ian0
Not programming but systems engineering (telco), though Ive programmed since a
kid. I ended up in a product by chance, I was working for a telco vendor and
at the time no-one was specifically focussing on product so I ended up doing
it. It was about 10 years ago and ive been mainly focussed on product since,
through to building and managing teams, both consumer & B2B products. Id argue
that the best resources for a product manager are the same as the best
resources for founders, ignoring the fundraising part. So:

\- Relevant YC How to start a startup lectures & other resources mentioned
here

\- Understanding of terms like Retention, CPA, CLV

\- Have at least an introductory understanding of what UI / UX, marketing
teams do (from their perspective)

As you will likely be working on a product that has already launched you will
have to catch up and become a domain expert. The non-obvious things you should
understand really well are:

\- Which users contribute the most to your product (by revenue or some other
key metric)

\- Why the users use your product, sometimes all is not what it seems!

\- What the sales process or acquisition funnel is like, from end to end

\- What the long term strategic goals are / "Why are we here"

I would take the time to generate a complete view of how your existing product
is used and continually update this. Tools like mix-panel, google analytics or
plain DB queries can work. Note the best views are the most descriptive but
the _least_ complex. Don't measure everything, you'll just get lost.

In terms of day-to-day work, the nice thing about product is that it straddles
multiple traditional departments. Take on board advice from marketing, design,
engineering & management and don't pretend your an expert there. Leave them to
it. But use your data to cull any crazy behaviour and keep things on track.

And finally, one thing that few people realise is that the best product
managers aren't "visionaries". Learn from your users, other teams, the data
and the answer to what you should be building will be screaming at you.

------
rahimnathwani
Some book and topic suggestions here: [https://www.encona.com/posts/product-
manager-resources/](https://www.encona.com/posts/product-manager-resources/)

------
Jugurtha
Some things that help: giving a damn about _every_ aspect of the product and
making coworkers' job easier in every way possible. Code quality (meaning
cleaning, documenting, and optimizing, if need be, the code).

Writing a template for issues that remove friction to write good, detailed,
issues. This is important as everyone notices how helpful this is and
productivity increases as when one in the team or the whole team is in flow or
on a sprint, you can slay a huge number of issues because everything there is
to know about the issue is there.

Writing deployment recipes. Automating the build process. Reducing the steps
from committing new code to code running.

Writing the tests. Refactoring. Factoring code out. Simplifying. Building
tools and utils.

Writing the documentation, for code and for the product (markdown, latex for a
slick pdf version).

Acquiring as much knowledge as possible on every aspect, and sharing it with
others. Read books / chapters relevant to an aspect and summarize key points
with a reference.

Helping with logging. Writing clear error messages or wrapping cryptic error
messages from third party code in nice error messages after a root cause
analysis. Find weird edge cases and quirks. Relentlessly poke holes in the
product.

Exceptional commit messages with root cause analysis and rationale behind the
diff: commit messages should teach us something and help with Chesterton's
fence.

Write the product pitch.

Audit the security of the code, with automated tools if there is no security
aspect for the product. At least remove blatant security holes.

Add CI tests/pipeline.

Work on the product's interface / ux. If there's a graphical component, nicer
icons, more refined styling, a better _font_.

Have people use the product without helping them and note all their struggles.
Fix that. (if the product is a library, have a programmer try to use it and
note _everything_. Observe their reactions, etc. I've had people who never
programmed try to use a library armed with a technical doc. I knew it was okay
when they could run the examples and said "it made sense".) If it's a product
for people, have people who'll end up using the product use it and watch them
like a hawk.

Take notes in meetings about the product and share them. Note every little
detail that bothers anyone and make sure it survives the meeting by creating
the proper issues. Assign everything to yourself.

Help make your code extensible and try to keep the core as small as possible.
If a new developer joins the team and is tasked to develop a feature, most of
their work should be on developing the feature, not digesting the code. The
feeling you get when a new developer comes to the project and can develop a
feature as fast as they can think and _code_ as opposed to as fast as they can
understand the _code_ is just amazing.

Constantly try to find a better abstraction and better data structures so the
code makes sense and people can guess the next step / line of code before they
read it.

Understand the value of the product, business value of the product to help
make better engineering trade-offs and avoid wasted effort.

Learning to write well. Technical writing. Explaining concisely. Making
points, exposing trade-offs, and recommending an approach.

Build it then pitch it. For example: there's a difference between talking
about an approach, and implementing an approach and pitching it. Team/CTO
might like it and it gets merged instead of an endless debate.

Be prepared to hear no and kill the branch while keeping the nice gems of code
written somewhere for later use after polishing. These gems will be merged at
a later time when you find another use for them, or the assumptions that
killed the idea/code change.

Own the product.

