I have been working in Product for 7 years now.
I don't consider myself skilled as I believe I will never stop learning.

However, if there is one type of individual that seems to enjoy how I work, how I approach my job, and how I interact with them, it's engineers.
I decided to reflect, both personally and with some fellow engineer colleagues, and try to understand the reasons.

I hope that this article will give some leads to fellow product managers about how to work well with engineers.

Here are the key messages of this article:

• 💪 Do everything you can to empower your engineers so they own problems and not only solutions.
• 💡 Be curious and learn their language.
• ⚛️ Shield your team from the outside noise.
• 👩‍💻 Know your product, even its dark side.
• 📣 Align by communicating.

💪 Empowerment

The first and most important lead I would like to give to fellow product managers would be to empower your engineers as much as you can.

Non empowered engineers own solutions and have little interest in the "whys" that are behind these solutions (The users & customers, the problem to be solved, etc).
Empowered engineers own a problem. They leverage technology and context to figure out the best solution.

Non-empowered engineers are mercenaries.
Empowered engineers are missionaries.

Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer.
Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.

Missionaries vs. Mercenaries

Marty Cagan considers empowering engineers is The Most Important Thing

Extracted from the Spotify Engineering Culture

Your goal as a product manager is to make sure everyone in your team gets why they work, and why your company believes in what your team is pursuing.

They need to understand the company's vision, and how your team's vision ties to it.
They need to understand the company objectives, and how your team is contributing to them.
They need to know their users, their wishes & pains, through accessible user feedback.

Empowering engineers is far from easy.
If not done right, it can lead to a lot of noise & overhead, and would be counter-productive.
It's a delicate balance.

My goal is to make sure the team is a great understanding of how we take decisions about what problem to focus on while maximizing the time the team has to find and build the best solutions.

Some tips on how I keep my engineers empowered:

• I take bottom-up inputs to revise the company product vision from each team member as part of a recurring event called the Rolling Strategy Process happening every 3 months.
• We shape the team product vision together as a team.
• I try to make sure that our contribution to the company objectives can be easily understood and tracked via accessible dashboards.
• I make sure user feedback is accessible by everyone in the team. I spend some time reading it weekly, and share a digest with my team.
• Once we know which problem to solve, we always ideate together in order to find potential solutions.
• When I plan to do some user interviews, I usually invite some of my engineers to one of them.
• If I need to talk to a third-party partner (for example we are actively looking for our next payment partner), I either involve some of my engineers or share updates regularly with them if I consider the session will be too high level.

💡 Curiosity

I believe that you need to be curious and learn what software development really means.

Admittedly, this may be a bit simpler for me: I have a master of engineering, I have a hacker mindset, and try to cultivate it with side projects every time I get a chance.

I cannot give you the scope of what you need to understand, as it vastly depends on how your company operates, and your affinity with learning technical topics.

Try to learn at least the following terms and concepts

• A front end
• A back end
• An API
• A data model
• A persistency layer
• A pull request
• A repository
• A deployment
• A rollback (or fallback)

I believe these will always be useful regardless of where you work.

Try also to learn

• The review & approval process (How engineers are making sure that issues are surfaced and fixed before reaching your customers)
• The deployment process (How a piece of software code transitions from done to available to your customers)
• The programming languages used by your engineers.
• The high-level architecture of your product

🤔 But ... how?
Start somewhere, book some slot with your engineers and ask them to explain something you don't know.I try to do a ☕️ Tech coffee every week to keep myself up to date on technical concepts.

Build something! There are so many resources online, it would be a pity not to use them.
It can be as simple as a slack bot if your company uses slack.

🤨 But ... why?
There are so many advantages to speaking the same language as your engineers.

Being able to grasp the challenges faced by your team, you'll be able to communicate them much more efficiently to your stakeholders.

Let me give you a real example.
Last week one of my front-end engineers told me "We should migrate one of our applications to NextJS".
I had no idea what it was nor why it was needed. I sat down with him and asked him to explain.

During our next planning event, this is how I will pitch it:

Our checkout application contains 3 pages : a delivery section, a payment section, and a success screen.
Today most of the code needed to run the 3 pages is loaded when our users reach the first page.
It increases the response time on a very critical flow of our product.
With NextJS, we will automatically load only the right code at the right time, decreasing the response time and optimising the overall user experience of our checkout.
On top of that, migrating to NextJS will reduce the number of dependencies that our front-end engineers have to tediously handle manually.

Did I totally understand this concept? Of course not.
Do I believe that the above pitch will be more convincing than: "We need to migrate to NextJS because my engineers told me so and I trust them 🤷‍♂️ " ? Yes. 100% yes.

⚛️ Entropy

Being able to grasp technical concepts will also help you to shield your team from the noise.

I'll quote Lenny Rachitsky

It’s your job to shield your teams from stupid shit. Like time-sucking questions, unnecessary drama, and the whims of execs. People outside your team have no idea how much impact their ad hoc asks and “quick” questions have on the team. It’s your job to help them see this, and to protect your team from them. Help your makers (e.g. engineers, designers, etc.) stay focused and in flow. Unfurl your shit umbrella.

See twitter thread

And I believe that the best way to shield your team from these quick questions is to be able to answer them yourself.

Then, consider the current iteration (sprint, cycle, whatever its name) unbreakable.

If your company has a good understanding and implementation of agile, you should rarely learn things that are going to jeopardize what your team is doing right now (ie, in the current iteration).

🤔 Why?
Because agile teams either build to learn if they are on a discovery phase, or build safe bets that are already validated if they are on a delivery phase.
Plus these safe bets are very small: the size of the iteration (usually short).

If a new piece of information makes your current goals irrelevant then:

• Either you are building something that was not validated in a discovery phase
• Either your iteration is so long that context changed

Even bugs are usually not interrupting our iterations...
Bugs are not more important than everything else by default.
If a bug is extremely severe (a crisis, an outage), then we drop everything and fix it. No question asked.
Otherwise, it waits until the next iteration (That is very short)

At Ricardo, we plan work in 6 weeks cycles. (Each cycle is composed of 3 sprints of 2 weeks)
We now reached a point where bugs are planned during each cycle, like everything else.

It's aligned with how Basecamp deals with bugs

There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare. The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.

Shape-up

👩‍💻 Knowledge

This next statement is going to blow your mind :
As a product manager, you need to know your product 🤯

Pretty self-explanatory...
Or is it ?! (VSAUCE vibes)

It's one thing to know your product.

It's another thing to know

• Your product
• Its history
• Its bugs
• Its funky business rules
• Its quirks
• Its edge cases
• Why were certain decisions taken a few years ago
• What was already tested
• What failed
• etc.

A product is like an onion, and your users only see the outer layer.
A product manager should know the whole onion.

A good product manager should be able to break his own product by pressing exactly where it hurts, and then explain to everyone why the team never worked on this specific edge case.

This is super useful for your engineers. You can point them towards potential pitfalls, dark edge cases that may cause a problem a few iterations down the road, and so on.

A small tip:
I keep a list of onboarding challenges that I use every time a newcomer is joining my team.
It consists of a list of tasks (or jobs) to be done on our product, as a user.
Each job is more complex than the previous one and builds on top of the learnings of the previous jobs.

It's a very fun way to learn your product and its intricacies as an engineer.

Example of an "onboarding challenge"

📣 Communication

As a product manager, you also own the newspaper that talks about your product, and you need to keep it alive.

Document and communicate every major decision the team is taking, so that you don't have the repeat why you are not working on that-pet-project-your-CTO-always-talks-about.
🎯 It's a great way to shield your team even more from the noise.

Share your team's success and its learnings.
Share what your users think about your new features.
Share the impact you are making, and why it is instrumental to the company's success.
🎯 It's a fantastic way to remind engineers why they work and empower them.

When it comes to communication internal to your team :

Document how features are built (Usually in a document called the product requirements document [PRD])

• The assumptions
• The tests you made, and their results
• The business rules
• The design choices
• The wording choices
• The edge cases that are considered out of scope
• What you decided to track, and why.

🎯 This will be extremely useful to the team for future increments (Nobody will remember everything after a few iterations)