From today's mentoring, talking about the need from leadership to constantly race forward and building new stuff (for competitive advantage / keep sales happy / make clients excited etc). It's a common problem that I've come to refer to as the Barbarossa problem
Operation Barbarossa was Hitler's attempt to overtake Russia by reaching Moscow at lightning speed. It was risky but had high rewards. It also failed spectacularly, as we all now know. The reasons were many, but I'll cherry pick the ones that make my point
A big part of the problem with Barbarossa was that Hitler's army moved faster than their supply lines could keep up. This meant that their troops were isolated and eventually cut off. They got within sight of Moscow but ultimately got bogged down and ultimately repelled.
Lessons from this. (1) I'm not a particularly good historian and it's probably riddled with inaccuracies (2) stretching your supply lines & failing to secure your rear is a really, really bad idea!
In product management terms, this means.. well, secure your rear! It's all well and good trying to build for the future but if you're building on shaky foundations it'll eventually collapse. We've all seen that one "MVP" that got immediately pushed to production!
Call this tech debt, or product debt or whatever you want to call it, but stuff will eventually break. You need to keep your solution together, maintain and improve it otherwise you'll eventually be stuck with a 6 month mitigation programme to emergency repair it
No one is happy with unglamorous work but it's absolutely essential to build scalable success. If caught in "faster! faster!" syndrome, consider assigning %ages to different efforts & operate more like a portfolio. You can make progress on multiple fronts if you don't rush!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Combining two mentoring sessions that had similar themes - that tricky situation where the engineering team and product team are misaligned, and this is affecting the progress of the product & dissatisfying customers
So in this age of empowerment & product trios we should call out the key responsibilities of the 2 teams, broadly:
• Product team owns the why & the when, based on market & customer understanding
• Dev teams owns the what & the how, what's possible and the effort involved
The "what" is more of a shared responsibility between dev & UX & product, but the key here is that we want devs to work with us collaboratively to define a solution that is technically feasible, business viable, customer usable (and ethically defensible)
From recent mentoring session, "I want to advance my #prodmgmt career and step away from individual contribution but am not sure how to do it in my current company". The eternal challenge! For me it's not (just) about job titles, but proximity to strategic decision making 🧵
If you have ambitions to be a product leader (and let's assume you know what types of thing that involves & have identified it's where you want to be) in your current company you have to ask yourself ... what's my path in this current company?
Job titles don't matter (idealistically) but job titles also really matter (in the real world). Who's in front of you? If you have a Senior PM then a Head then a VP then a CPO then, hey, there's a path but all the places are filled. You're probably in for a wait!
From mentoring session today - "is it normal for PMs to work 50-60 hours a week? how can I avoid burnout?"
I mean this is obviously a tricky one and a lot of it depends ony why you're so busy, but my biggest piece of advice is.. let go of some stuff! Wait, what?
• The company / team is understaffed
• You're being made to do stuff that isn't really your job
• You're going down rabbit holes and not giving up
All of these are solvable but they're all difficult to one degree or another
If you're understaffed and stuff needs doing, someone's got to do it right? You could argue you need more staff, or that you need less stuff. I'm always going to be in favour of less stuff because it's easier to make a big impact on fewer things than more things
From tonight's mentoring session, an interesting one with an education leader who is not "in product" (although thinking very much in product terms). Looking at making an impact with productising aspects of education and wondering how to apply product thinking
In this case I do my best @davidjbland impression (my mentee already had David's book!) and talking about the importance of finding out whether your idea is good, and that it's much easier to make a mistake of it's a small one
I've had situations in my product career where I've gone all in way to soon, with predictably disappointing results. The key rule of making bets; if you are off course by 1 degree, it's easy to correct sooner rather than later (by which time you're in a different State)
It's common to see people attacking PMs for being ineffective, or tending to micromanagement, or going too far into solution mode. Obviously we don't want to excuse poor behaviour, but we also have to call out that it many companies it feels like PM vs the world 🧵
In many companies, product managers are more like project managers, with little to no real control over their product roadmap, buffeted by client / sales demands & not even able to talk to customers
We can talk all day about ineffective leadership & ineffective companies, but let's concentrate on the effects on the PMs. PMs in these companies aren't empowered to actually define the direction of the product and are primarily pushed by management to "optimise engineering"
I had some learning budget to spend so I bought some books! I normally read on Kindle but thought I'd get a selection of classics I'd already read as well as some inspiring books I hadn't. Looking forward to diving back in, learning & relearning 🧵
Radical Candor by @kimballscott - the classic book about being a good boss by caring personally and challenging directly .. You can check out my podcast episode with Kim here oneknightinproduct.com/kim-scott
Utopia for Realists by @rcbregman - not read this before but seems like an interesting proposition! Always interesting to see how we might use tech for good