I’ve been emailing myself about once a week, reflecting on my new position in Product. I officially moved over on March 31, finally getting my own desk in the Product/Engineering area instead of stealing desks while people were in meetings or working from home. At least one engineer thought I’d just conned the previous person who had that spot into getting a standing desk and monitor — took him about two days to ask me if my conning included a title change. 😀
So some notes from week 1 in Product (with the caveat that I’m learning everything on the job, and Product here might be nothing like Product elsewhere).
What a PM does
The answer, in short, is everything. On my first day, my new manager and the VP sat me down for a crash course in PM-ing. It started with this plot:
Most people within a company fall in one quadrant on these axes — a CEO is more strategic and creative, a software engineer is more technical and tactical — but a PM on any given day will get pulled in all four directions.
Learning to juggle these different areas has been the joy and the learning experience of this new job. Jumping around isn’t new to me, but shifting into new but sometimes painfully familiar territory has been an adjustment.
I might ruminate more on how a PM does everything, but at present, nothing says it better than this article my coworker Christine sent me last week.
My more seasoned coworkers tell me that PMs at different companies can embody different things — some are more in the trenches with the engineers, some are more involved in long-term strategy. Our Product team is still young (within the company) and pretty small, so our key values guide all levels of thinking.
Quick aside: without really getting into detail, I fully acknowledge that our current product is far from perfect, but you can’t really blame our Product team for that. We’ve inherited a lot of ad hoc bits and pieces, and we’re grappling with unifying (overhauling) everything to do it right. It’s a rough ride.
So what drives our team and our decisions then? The answer is deceptively simple, and it pole vaults over everything: we’re looking for the right solution for the customer. The decisions we make as a team shouldn’t be personal; it’s easy for ego to get tangled up in things when it’s your project and your idea, but the customer trumps your ego. We should challenge each others’ ideas and be ready to defend our own — and be open to a new direction.
Falling out from that, we aim to make informed decisions on just what that right solution is. Back things up with analytics, and do your research. These are the maxims we live by.
Everything about our process I learned through observation, and I have no idea how standard our process is. Maybe I just find it novel because we weren’t diligently doing things like this for a long time (and I think it showed). In a nutshell:
- Research – explore the problem, challenges, and best practices. White board. Brainstorm. Dig down to the root of the problem and the user “whys” (i.e. “why do I care?”). Pull metrics to better understand what’s going on. Write up a project brief — literally brief, keep it to 2-3 pages. Iterate on it. Include stakeholders and interested parties to bring everyone along for the decision-making and really cover all bases. (However, be wary of scope creep.)
- Design – build wireframes/PRD that covers how the implementation should look and what it should accomplish. The PM hands off UX/UI design to our Design team. Gather feedback and iterate again, keeping the PRD close at hand. At the end of this phase, we have a complete spec.
- Build – Engineering executes the spec. PM reviews implementation, manages workflow with the Program Manager (Project Manager? what’s in a title?), and sets deadlines along the way.
I’m currently entrenched in two different projects — one in the Research phase, and one in the Build/post-Build-cleanup phase — but more on that later. For now, I can sum up week 1 in Product like so: