Hacker Career Advice
We’re All Product People
Six months ago I told my boss that I wanted to do more Product work.
Initially, Management was reluctant to have two Product people on such a small team, because we really needed to ship code & meet deadlines.
Since then, I’ve had the opportunity to work on the roadmap, write epics, interact with external customers, do research, and make plans that affect our whole business.
Last week I asked our VP of Product how he felt, six months on, about having two Product people. His response? “Right now, we all need to be Product people.”
I think his point was that we all have a vested interest in building a successful product that meets user needs and delivers value. In other words, we all need to be proactive, and think beyond the sprint:
- If you’re working on a ticket / project that’s way more complex than originally scoped, break it into smaller chunks and get help.
- If you don’t understand the requirements or motivation behind a task, push back and ask why.
- If you find a bug, report it and write a ticket for it!
- If you have an idea that could improve revenue or reduce costs, write up your thoughts and make a case for it.
- Think you’re ready to lead a project? Ask for the opportunity.
Part of thinking like a PM is not letting your excitement cloud your judgement.
Even if you’re super geeked to ship a new feature, don’t promise or try to build it all at once. Manage expectations and build iteratively. I promise you, that ‘trivial’ feature will take longer than you think.
Whether you’re an emotional thinker or a die hard logician, switching from Engineering to Product mode can be tough.
For me, the hardest part of moving from Engineering to Product has been learning not to take product ideas personally.
Sometimes an idea will seem like an affront to your basic sensibilities and you’ll want to flip the table over it. For example: “Let’s make all of our widgets autoplay!”
Before you get on your high horse about how autoplay is morally bankrupt and user hostile (it is)—step back and separate the implementation from the idea.
Assume that ideas, and the people who propose them, have good intentions.
Autoplay → more listens → higher CPMs → more $$$. That’s a desirable outcome, right?
Even if you still think autoplay is a bad idea (it is), don’t pass judgement on the spot. Take it offline and look for other ways to achieve the same result.
If you succumb to your frustration, you’ll end up shutting out creativity and alienating your team. It doesn’t matter if you’re right.
Obviously, if your main role is writing code, you have to focus on that. But if you keep your Product brain warmed up, I think you’ll make better, more thoughtful decisions.