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)
So far so Cagan, but what do we find in some companies?
🤮 Shadow roadmaps where devs maintain their own tech initiatives
🤮 Devs who want / expect overly specific requirements
🤮 Total disconnection between devs & business outcomes
This is a cultural problem!
Shadow roadmaps are ridiculous, a sign of a total breakdown between engineering & product. I'm sorry, but it's true. Product people are not the ones to decide whether postgreSQL needs upgrading or a security feature implemented, but they absolutely are responsible for when
Not dictatorially, but in collaboration with the dev team. Let's be transparent & open about the impacts of tech work, the urgency & any mitigations. It's all very well doing important tech work but if you don't have any customers at the end of it you're in trouble
Further to that, we don't want devs to feel disconnected from the business. It's our job to help bridge that gap. Do they feel that they own the problem? Do they understand the business & customer context? Did you ever tell them?
Getting devs involved in discovery, or watching playbacks of customer interviews, or aware of all the complaints coming from CS is crucial. We want to protect devs from distractions but these people are grown ups & need to be treated as equal partners, not a service department
If there is a lack of trust between teams this needs to be worked on too. Devs may struggle because they believe PMs don't understand the tech implications & won't make good decisions. Make sure your non-tech PMs are given technical training!
Ultimately, we need the collaboration to be just that, a collaboration, between equal partners. But devs don't get to just tell product people that things aren't important! Driving a culture of ownership & shared understanding can help bridge the gap but it's a long journey
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.
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