I’ve been working as product manager for a venture backed startup, at Seed Recruit we aim to disrupt the recruitment market building a product who leverage big data matching and intuitive interface. I’m synthesising my personal learning in the last three months.
Think big – PM’s thinking won’t be constrained by the resources available to them today or today’s market environment. They’ll describe large disruptive opportunities, and develop concrete plans for how to take advantage of them.
Communicate – PM can make a case that is impossible to refute or ignore. They’ll use data appropriately, when available, but they’ll also tap into other biases, beliefs, and triggers that can convince the powers that be to part with headcount, money, or other resources and then get out of the way.
Simplify – PM knows how to get 80% of the value out of any feature or project with 20% of the effort. They do so repeatedly, launching more and achieving compounding effects for the product or business.
Prioritise – PM knows how to sequence projects. They balance quick wins vs. platform investments appropriately. They balance offence and defence projects appropriately. Offence projects are ones that grow the business. Defence projects are ones that protect and remove drag on the business (operations, reducing technical debt, fixing bugs, etc.).
Forecast and measure – PM is able to forecast the approximate benefit of a project, and can do so efficiently by applying past experience and leveraging comparable benchmarks. They also measure benefit once projects are launched, and factor those learnings into their future prioritisation and forecasts.
Execute – PM grinds it out. They do whatever is necessary to ship. They recognize no specific bounds to the scope of their role. As necessary, they recruit, they produce buttons, they do business development, they escalate, they tussle with internal counsel, they *.
Understand technical trade-offs – PM does not need to have a CS degree. They do need to be able to roughly understand the technical complexity of the features they put on the backlog, without any costing input from devs. They should partner with devs to make the right technical trade-offs (i.e. compromise).
Understand good design – PM doesn’t have to be a designer, but they should appreciate great design and be able to distinguish it from good design. They should also be able to articulate the difference to their design counterparts, or at least articulate directions to pursue to go from good to great.
Write effective copy – PM should be able to write concise copy that gets the job done. They should understand that each additional word they write dilutes the value of the previous ones. They should spend time and energy trying to find the perfect words for key copy (button labels, nav, calls-to-action, etc.), not just words that will suffice.