Slava Ukraini, the importance of mentoring, and engaging with engineers

No one signed up to this newsletter for political commentary, so I’ll keep this brief but I’ve been really struggling to focus recently because of the situation in Ukraine. I had a few trips to Ukraine with school in the mid 90s and have fond memories of the place, the culture and the wonderful people. Seeing places ablaze that I visited at such a formative time of my life is devastating. I’m obviously as powerless as most of us, but I’ll be donating to the Red Cross to help the innocent civilians of this beautiful country.

Given the delay in getting this newsletter out, there are actually two new podcast episodes out!

First up we have the one and only Melissa Perri, author of “Escaping the Build Trap”. I’ve been wanting to get Melissa onto the podcast for some time now and was delighted to have the chance to speak with her about product operations, that Marty Cagan article, and why strong product organisations need strong CPOs.

Yesterday, I released an episode with Richard Awe. Richard is a senior business analyst at the European Central Bank and also founder of a new side hustle Requstory. We spoke about the pros & cons of user stories, and what business analysts actually do.

Later this week I’ll be releasing an episode with Dan Olsen, author of “The Lean Product Playbook”. Dan and I are both interactive fiction nerds with a love of old-school text adventures, and we had an RPG-tinted look at product management. Coming soon!

I also participated yesterday in a round table Twitter Space about mentoring. Those who know me will know how passionate I am about the concept of mentoring, the benefits it brings and how it’s one of the highest-leverage ways to benefit your product management career. We had a great chat with some wonderful contributions and I definitely recommend giving it a listen on playback.

Also, because I’m really bad at scheduling I also participated in a UXDX panel “Is The Product Manager Part Of The Team Or Outside The Team?” with Leonard Kongshavn and Fanny Krebs-Pinto. We chatted about all things product management and how you might set your teams up for success. It was a great chat and I was really grateful to Catherine & the UXDX team for bringing me on.

I’ve had a few discussions recently about that critical relationship between the product management team & the engineering team. Now, it’s fair to say that sometimes this relationship is too close, in the sense that PMs spend all their time with engineering and almost none with marketing, sales, CS etc (not to mention users!). But we can all agree that this relationship is absolutely crucial to building effective, scalable products.

There have been a few comments that have stuck with me and I wanted to reply to a few of them with my thoughts. To paraphrase…

Obviously 10x, 100x, 1000x developers do exist out there. The kind of people that seem to have an answer for everything, can solve any problem, rustle up new MVPs in 10 seconds flat. These people sound great, and sometimes they are great, but they can also completely disruptive if…

• They have their own ways of working & refuse to meet anyone in the middle

• They have strong opinions strongly held and refuse to be budged because of personal preference

• They write stuff fast, don’t test or document anything, don’t share knowledge and become a silo

• They eventually leave the company and no one can work out how anything they did works

Now, to be clear, I’m no saying all of these people are like this but I’m also definitely not saying none of these people are like this. For me, a true 10x (100x etc) developer is one who collaborates, shares knowledge & truly contributes to the team. After all, great software is written by great teams.

It’s fair to say that engineers in many companies get a bad deal - they’re thrown requirements over the wall with little to no context, expected to deliver too many things all at once, with no clear idea about what happens once they’ve delivered the things. In many companies, engineering is still seen as a factory resource where people are just constantly typing and code comes out the back for the grownups to go and sell.

Don’t be one of these companies.

We have to see engineering as a key strategic partner in our product development, not a production line. We need to get engineers involved as early as possible to help to understand why they are building what they’re building, and also give them feedback after products are released. Get them some customer quotes, or even on a call with an early adopter so they can see how they’re changing people’s lives.

More than anything, any engineering team that thinks that it’s not working on the most important stuff doesn’t trust the product team and you need to work on that.

This goes back to that production line mentality; the idea that the only measure of an engineer’s time is the number of lines of code that they write. And, in many cases, this is probably the reality for engineers working in such conditions.

Don’t get me wrong, it’s never fun to give up on something that seemed promising but didn’t work out. That new feature or product line didn’t land? It’s a shame, but it happens. We can soften the blow by working small and ensuring:

• We learned something along the way to improve future decision-making

• We learned something new about how we can (or can’t!) use technology to serve our needs

What I’m not saying is that we should leave loads of rubbish cluttering up the code base - when I say “thrown away” I mean let’s just get rid of stuff we don’t need anymore and focus on the essential.

Hopefully this is somewhat interesting to you 🙂 If it is, please consider sharing it with your friends. It’s truly my pleasure to contribute even just a little bit to the product management community, and I hope you have a good week!