Discover more from Pedunculate
Half a Year of Product Management
Reflections on six months of daytime drinking
I have now been a product manager for six months. As is frequently said of parenting: "The days are long, but the years are short."
One notable feature of the new role is the massive increase in spam I receive. I spent five years with god-admin access to what is arguably the most important market in Europe, with a dozen direct reports and control of an entire department... and as far as LinkedIn recruiters were concerned the most notable feature of my CV was that I once spent a month pretending I knew how to administer a Sharepoint installation for a hedge fund almost a decade ago. But within days of updating my job title to ‘Product Manager’ I was receiving job listings, conference adverts, and, my GOD, so much 'educational' material.
I get why - knowing what to do as a PM is really hard. If I fucked up in my old role I found out in near-realtime; as a PM there's a good chance you won't find out for months, or years. Even the relatively simple concept of 'fucking up' can be hard to define. Often your job is not deciding between a good and a bad option, but picking the best (or sometimes just least-bad) option from a probability space that you likely had some control over defining to begin with. Even if, per miracolo, everything appears to work out OK, maybe it should have gone better. Minor decisions can have unpredictable long-term consequences, blocking some paths and opening others far past your horizon of perception. It's like playing the Witcher 3, but with fewer sexy witches and even less predictable outcomes (and that was a game, let me remind you, in which one of the most interesting characters tops himself if, on the other side of the map, you turn an evil tree into a horse. Well, now it sounds obvious. I say 'unpredictable', but you're always haunted by the knowledge that this was, in fact, predictable, but you were just too stupid to see it.
So, I understand why there is a big market for articles like "The Top 5 Mistakes all New Product Managers Make" and 90-minute YouTube Webinars about the "Technical Extreme Lean MVP-Agile Product Management Framework" or whatever is hot right now. I wish they worked! At one point the YouTube algorithm moved me from "A Modern Approach to Discovery" to "Best Catan Strategies for low-wheat boards" and it took me several minutes to realise we'd changed genres. One thing all these 'resources' have in common, apart from tortured pop-culture analogies, is that they contain maybe one practical piece of advice that you can actually use (if you're lucky), surrounded by 90 minutes of high-rising terminals.
Well, let me give you more than one half-pennyworth of bread to this intolerable deal of sack. Here are a handful of practical things I've learnt over the last six months and intend to keep doing.
Practise your presentations, however short. If they're remote, script them.
Do this even if (like me) you've done a lot of public speaking and are confident in your ability to 'wing it'. Especially if you fall into that category. For a lot of the meetings at which I have to present (SMT project pitches, sprint snapshots, etc), keeping the presentation short is really important. Working from a script makes it easier to consistently hit a time limit (I set myself 2-4m depending on the situation) if you aren’t extemporising; you cut down all the ‘umms’ and ‘errs’ and ‘you knows’ that naturally fill your speech and reduce the risk of losing your place or getting side-tracked (when speaking from memory or cue-cards I have a bad tendency to give too-expansive examples, or spend more time stressing minor points than I should).
If you're WFH and presenting over video chat, you have the added bonus of being able to put your script on screen directly below the camera and thus maintain 'eye contact' while reading it, which you can’t do in person and is one of the many reasons I normally dislike scripts.
In either case, for important presentations (and really, as a PM *any* presentation you bother giving is probably important), you should probably practice. Again, WFH gives you the advantage of being able to do lots of demo runs in front of a camera without embarrassing yourself. Record, watch it back, and work out the weak points.
When writing a project proposal for the business, lead with the client benefits
Client comes first, however small or tangential the benefit, followed by internal money/time/effort savings, followed by any long-term/foundation-building benefits.
Treat credibility like currency
As a PM, you have responsibility without authority. Why, and whether that's really a good thing, is a conversation for another time, but that's your starting position. Consequently, everything you want to do is dependent on other people *choosing* to cooperate, and this will depend largely on how much they trust that you're making good decisions - how credible you are to them.
Every good presentation, every bit of knowledge demonstrated, evidence of dilligence and hard work, will earn you some small amount of credibility; big successes and big wins will earn you more. Each person you work with has their own currency, and in this metaphor FX can have high transaction costs. Meanwhile, bad guesses, stupid questions, signs of laziness or flippancy can all cost you credibility, and every time you propose an idea you're locking that credibility away in an investment that won't pay out until the idea is validated. Depending on your career to date, you may not be used to working under this kind of system - I certainly wasn't - and may not realise how much your access to the levers of power is dependent on your ability to pay. Watch your mouth - it may cost you more than you think.
Two small caveats to the above:
Your relationship with your tech leads should be different - they're your partners, and you should be able to drop the mask with them in a way you can't with anyone else. Trying too hard to preserve credibility with them is likely counterproductive, and you'll get better results from being completely open.
If you already have a high level of credibility with a person or group, you can get away with some dumb/silly questions without paying a penalty. At some hard-to-define point, the logic flips from 'this question was stupid, therefore Roxton was stupid', to 'Roxton is not stupid, therefore that apparently stupid question must really have some hidden depth'. Of course, this doesn't last forever.
These are all things I've found to be true and will try to continue doing. Here's one more thing I'm not entirely sure about and with which I'm gently experimenting:
Use people's objections against them
Not in an obvious, petty way, of course. What I mean is: people tend to have go-to objections or worries that come up in multiple situations. A really obvious one is devs saying 'We can't do X, we're blocked', or 'We had to do Y, because Z is blocked until we do.' Once you notice something like this, you can start using that same reason as a motivating tool.
For example, I recently suggested that some small item of work I needed from a dev team for another project should be brought forward 'because so-and-so is blocked until this feature is in place'. A huge amount of effort goes into ensuring that devs aren't 'blocked' (i.e. they don't face an issue that might require them to context-switch, which is... a whole other topic) and devs are heavily conditioned to avoid it, so just mentioning this magic word was enough to trigger unquestioning compliance. For obvious reasons I'm not sure that exploiting this is a great idea. Normally I’d be more worried about devaluing the thing I’m abusing once others catch on, but in this case I have a strong suspicion that the ‘I’m bloooooooocked’ whinging is a bit silly anyway, so that might even be a good thing. But, again, I don’t think I’m quite confident enough in that assertion to take the risk. Gervais-Principle-Sociopaths probably don’t consider that kind of thing at all, but I’m in the Clueless camp for now. I’ll report back in six months, if I make it that long.