How PMs Collaborate with Developers — Communication

I started my career as a PM at an AI startup with zero knowledge of development,

so early on I struggled a bit to communicate with developers.

It's embarrassing to admit, but to be precise, I was the kind of PM who frustrated developers. ?

If you're about to start as a PM,

or you've just joined as a junior PM and are doing the same things I used to do,

I'm writing this in the hope that, by sharing my experience, you can at least avoid becoming a PM who frustrates developers

— and that's exactly why I'm putting this down on paper!

1. Just get it done for me...

"Hey OO, the client says they need this, so you have to build it."

This is what I used to say to developers almost mechanically when I first joined.

And the developers would often look a little displeased and ask back:

"But why did we decide to do this?"

"Why do we even need to develop it this far?"

At first I thought, why are these developers reacting so aggressively? Why are they so upset?

I figured the meme that developers always say 'no' must be true,

but before long I realized that my whole way of communicating was completely wrong.

When you make a development request, the process of explaining in detail 'why it needs to be done' is more important than you'd think.

Because a PM is asking a developer to do work,

if you're not careful, from the developer's perspective it can feel like they simply have to do whatever the PM tells them

— a top-down decision being handed down to them.

That's why you need to explain in detail the background context and needs behind why that development is necessary,

so the developer can fully empathize with the necessity and direction of the work. is something you have to do.

In that process, you need to make them feel that this task is 'my work'— something they themselves need to solve.

Now, when I make a work request to developers,

1. I explain in detail the background context: exactly what development is needed,

2. what the reason for it is,

3. what value/importance this task carries,

4. and what thought process led me to conclude it would be good to implement it in this particular form.

I lay all of that out in detail.

On top of that, when talking to developers, I use a tone of seeking their advice and asking for their helpif you add a little

they sometimes burn with the determination to solve the problem for you. ?

2. (Bluntly) Get it done by this time...

After holding a kickoff meeting with a client who wanted quick results,

I looked at the company Google Calendar and put together a tidy schedule to deliver the results to the client a week later.

'Internal kickoff tonight, internal results sharing around 4 PM Wednesday,

check the improved results reflecting the internal-sharing feedback on Friday evening,

and deliver the results along with the organized documents next Monday.'

Satisfied with my own plan, I approached the assigned AI engineer and shared the schedule.

"We need to deliver the results to the client quickly by next Monday,

so let's do a quick kickoff tonight and proceed on the schedule I described."

The reply that came back was, of course, "(In a rage) Absolutely not..."

In particular, at our company, the structure is such that one AI engineer handles n projects,

so we have to carefully assess each project's progress and available resourcesand set an appropriate project timeline.

That's why it's important to regularly understand which projects each engineer is handling,

grasp how much resource each project requires, and coordinate schedules accordingly.

These days, the way I set and communicate timelines is as follows.

1. Sharing why a tight / generous development schedule was set

OO, since client A will be busy preparing for a new product launch starting next month,

they want to see quick results within this month, so it would be best to proceed with development as fast as possible.

2. Considering/adjusting the developer's other tasks and communicating priorities

I understand that projects B and C you're currently handling are more or less wrapped up.

When I asked PM Park, who's working on project D with you, it seemed that project isn't all that urgent.

So I asked to adjust the project D timeline.

You can make this project your priority and work on it!

3. Communicating the required level of implementation and completeness

Since this is about delivering results quickly, rather than a 100%-complete result,

I think it would be enough to show that this basic level of implementation is possible.

4. An attitude of seeking input on the schedule

I set the timeline considering development resources as much as possible—does it look okay to you?

Considering the development difficulty, if it feels too tight, feel free to let me know.

If it's difficult, I'll communicate with the client so we can take a bit more time to proceed.

Still, it would be great if you could try to keep to the schedule above as much as possible.

3. "It doesn't work..." "They say it doesn't work..." (with no context before or after)

Two months into the job, I got my first message from a client I was in charge of saying 'an error is occurring.'

After replying within a second that I'd check with the client,

I immediately DM'd the developer in charge, eager to fix it fast!

"Got a message from Client A that it's not working. Please resolve it quickly. 🙇‍♀️"

Then the engineer in charge checked, figured out the cause of the error, and solved the problem.

And for a while, whenever I got an error-related message from a client,

"Hi OO, Client XX says it's not working. Please resolve it quickly. 🙇‍♀️"

is how I'd reach out to the engineer in charge, complete with a polite emoji.

I'm doing great—requesting fixes quickly and politely!or so I thought.

Then one day, as I was speedily requesting a fix as usual,

I received some sharp feedback from the developer in charge:

'I wish you'd communicate the problem situation more clearly.'

Since the developers ultimately have to comb through the logs to identify the issue,

to solve problems more quickly and efficiently,

it turned out to be important to organize and convey the problem situation in concrete detail.

Since then, I've been conveying problem situations in the following format:

1. In Service B that we provide to Client A,

2. while performing ~~ action,

3. at around XX:XX,

4. a service outage or error occurred.

5. The urgency is 'highest,' so please resolve it quickly.

When I communicated the problem situation this clearly,

the developer in charge was also able to identify the cause and resolve the issue much faster.

The most important thing is...

Communication between PMs and developers is, after all, communication between people.

So in the end, its essence is a human bond—that's something I feel strongly.

If you're someone struggling with communicating with developers,

first empathize with and understandtheir difficulties, show that you're trying to,

and frequently express your gratitudeI'd really encourage you to give it a try.

Developers, too, the desire to solve problemsand the desire to be recognized—they're just people like you and me.

If you take an interest in the challenges developers are facing,

acknowledge their role,

and show that you're putting in real effort to communicate better (e.g., picking up basic development knowledge, asking for feedback, etc.),

I believe you can go beyond being a PM who doesn't anger developers to become a PM they actually want to work with.

Thank you for reading this long post. ?

Go to the AI Store