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.
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.
3 comments
[ 1.9 ms ] story [ 12.2 ms ] thread- 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.
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.