A competent PM is not a friend of the client.
Recently, I saw an interesting post in an IT community. It was a post by a PM from an agency, and it started with a complaint from a KakaoTalk message from the client at 8 PM after work. "Manager, I'm sorry for contacting you at this late hour. I suddenly had a great idea." The message went on endlessly with good ideas, making them stay up all night. The bigger problem was that the next morning, the client sent a Slack message asking, "You're progressing based on what we discussed yesterday, right?"
Many junior PMs have similar experiences. The vague thought that having a good relationship with the client will benefit our project and, ultimately, our company, or the mindset of not wanting to be an uncomfortable person, and that my actions shouldn't bring the project down, often leads to a failure to maintain professional boundaries, plunging the project deeper into trouble. Today, I want to talk about how, as a PM working in an agency, we can establish a healthy and professional relationship with clients so that we don't become "bad at our job" while trying to be a "good person."
1. The tragedy brought on by the illusion that “clients must be treated well”
In the early stages of a project, we strive to build a good relationship with the client. We comment on posts they've made on LinkedIn and drink coffee together after meetings. Of course, building human connections is important. However, the moment this relationship deteriorates into something resembling friendship, the problems begin.
One junior PM I observed had exactly that experience with their first project. The client contact was of a similar age and had similar hobbies, so they quickly became close. Afterward, it became common to receive unrecorded changes via messenger or calls after work, saying, "Mr. OO, I was thinking about it and this might be better, don't you think?" This junior PM seemed to think that they were maintaining a good relationship with the client and tried to accommodate them however they could.
What was the result? Designers and developers became exhausted from the constant changes, and without an official history, accountability became unclear. Ultimately, the project was delayed by three months, and in the end, when they said, "You clearly said you would handle it that way!" the junior PM had to lower their head without any rebuttal. This was a moment where intimacy became a poison that restrained the project.
When the boundaries of a professional relationship crumble, issues like the following arise.
Increase in unofficial requests: There is an increase in spontaneous requests via messenger or phone instead of official procedures (documents, emails).
Difficulty in managing history: Records of "when, who, and why" requests were made are not kept, making it difficult to respond to problems that arise later.
Decline in the authority of the PM: They become recognized as a person who fulfills every request of the client, undermining their credibility as an expert or their ability to coordinate schedules.
Confusion and burnout among team members: Unrefined requirements are passed directly to the team, causing frequent rework, and team members lose trust in the PM.
2. The first step of a professional: managing expectations
So how can we maintain this boundary? I’m not saying you should become a cold and rigid person. Rather, establishing clear rules for working together in a mutually respectful way at the start of a project is a true mark of professionalism.
There are three principles I make sure to adhere to when starting a project.
Principle 1: Clearly agree on what is not included (Scope-out) During the kickoff meeting, say something like, "For this project, we will exclude social media login and only implement email registration/login features," and clearly define what will not be covered in this version and keep it in the meeting notes. This will serve as a strong defense against comments later like, "I thought social login would be included with the login feature."
Principle 2: Formalize change requests Before starting the project, create a simple change request form and share it with the client. "From now on, all additional/modification requests must be officially submitted using this form for us to review and analyze their impact without omissions," you could state. This is not just a personal judgment of the PM but is very important in instilling the perception that work is handled by the system.
Principle 3: "Please be sure to get confirmation from the final decision-maker" Surprisingly, many projects proceed based only on the input from the practical staff, and everything is turned upside down by a single comment from an executive that appears late. It is essential to identify who the ultimate decision-maker on the client side is and to politely but firmly request that they attend important decision-making meetings.
3. Communication techniques that make uncomfortable conversations comfortable
Of course, even with these defenses in place, client requests will continue. As I mentioned earlier, rules are often easily ignored once the ultimate decision-maker from the client side starts to intrude, no matter how well the practical staff has established rules (sigh). At this time, PMs hastily saying "No" is the worst response. A professional PM is not just someone who accepts the client's requests, but also not someone who easily rejects them. Instead, they should become a negotiator who provides alternatives and helps clients make the best decisions.
If a client suddenly asks, "I've noticed that all the recent apps have a dark mode as a standard. Shouldn't we add it too?" how should you respond?
Client: "PM, I forgot to tell you before, but shouldn't we also add a dark mode? It seems essential these days."
Bad PM: "Ah... that's not included in the plan, so adding it now is a bit difficult. It's not feasible within the time frame." (A fact, but deflating for the other person)
Good PM: "Oh, a dark mode is really a great idea! It's an important aspect of user experience these days. I'll officially register your request, and we'll quickly analyze how much time and resources are necessary for design and development if we add this feature. Would it be alright if I got back to you tomorrow morning with a specific impact analysis along with a few options?"
Can you feel the difference? A good PM first positively responds to the other party's viewpoint, moving the conversation from a vague feeling to a clear process and data domain. The next day, they might present options like this.
Good PM: "I analyzed the dark mode implementation you mentioned yesterday.
Option 1: If we add the dark mode to the current schedule, it will require about two weeks more development time, which means it will delay the original opening date by about two weeks.
Option 2: If it’s important to open on the original schedule, we can consider postponing the slightly lower-priority my page settings feature to the next update and develop the dark mode first.
In our judgment... (expert opinion presented) ... Given the business goals of this project, it would be good to discuss which option is better together."
This way, clients feel not just that their request has been denied, but that they are being engaged in the project goals together. A potentially uncomfortable rejection process magically transforms into a trust-building negotiation process.
In conclusion: Now it’s your turn
Building a professional relationship with clients is definitely not about being cold or rigid. Rather, it closely resembles the process of clearly establishing navigational rules that everyone should follow to safely sail toward the final destination as the navigator of the project ship. It may seem good in the short term to easily agree with everything the client says, but it can ultimately endanger the project. However, a trustworthy partner PM, even if they sometimes need to face uncomfortable truths, will lead the project to success.
If you nodded reading this article, now it’s your turn to put it into practice.
Action Items for Junior PMs:
Create a change request form: Within this week, use Google Forms or a Notion page to create a simple 'change request' template for our team. Then, during the next project kickoff meeting, explain this process directly to the client.
Share failure experiences with colleagues: Talk about "experiences where the relationship with the client made the project difficult" with fellow PMs or in the community. Just sharing each other's failure stories will provide tremendous comfort and realistic know-how.
Practice saying "I will respond after reviewing": The next time you receive an unexpected request from a client, don't reply immediately. Practice saying just once, "Thank you for the good suggestion. I will respond after reviewing it by tomorrow." And the image of you bringing back a clear impact analysis within a day will make you a much wiser expert.
Back to list