For product managers, being "resilient" is a fundamental skill that everyone needs to cultivate in the workplace. This article will explore how resilient product managers approach three high-frequency scenarios, which may inspire you.

If you had asked ten years ago what the most scarce ability of a person was, you might have received responses like: extraordinary skills, the ability to articulate well, or being quick-witted and adaptable.

However, in today’s uncertain environment, everyone would unanimously say: resilience, the ability to endure and adapt.

The term "resilience" can be interpreted as being tough yet flexible, maintaining stable output under pressure, being undeterred in the face of setbacks, and possessing an open mindset with the ability to quickly adapt to changes. A good Product Requirement Document (PRD) should be clear, accurate, and detailed. It should not only describe the product's functions but also showcase its essence, such as interface design, user flow, and technical requirements—every detail must be accounted for.

Of course, writing a good PRD is just the first step. More importantly, you need to ensure that team members understand this document and are clear about their tasks and responsibilities. This requires the product manager to have excellent communication skills and a spirit of teamwork.

Scenario 1: Talking to Clients About Requirements

Imagine this is a client you have a good relationship with. Their requirements are difficult to turn down, and sometimes you may not have a valid reason to refuse.

What will you do?

As a resilient product manager, you need to focus on two key tasks: listening and writing, and make a note of your insights at the end.

There’s a great metaphor: when a client tells you they want to drill two holes, you need to consider the purpose of those holes. Document your assumptions—perhaps they want to hang a picture or use them for something else. Remember to incorporate the scenarios they describe as you dig deeper.

You should also have the courage to interrupt them at times, using questions and dialogue to validate your assumptions and document them. This represents that you’ve reached a “visible consensus” with them.

Finally, use clear and concise language to outline the scope of the request. If it's difficult to estimate the timeline on the spot, don't try to overpromise; provide the client with a specific timeframe for a response to reassure them.

Scenario 2: Creating Requirements and Writing PRD

After excitedly collecting all the requirements, your list might be a mess with inputs from clients, bosses, and leaders, alongside your own ideas. What do you do?

As a resilient product manager, this is an “exciting” moment where you can showcase your skills!

First, categorize the entire list of requirements, especially marking client requirements separately. Merge others' requirements into a collective group for better organization.

Next, like a detective, reflect on your communication with them, especially analyzing the authenticity of the client requirements. Always consider the real-world context and include genuine needs in the requirements list. For requirements from bosses or leaders, determine whether they are strategic needs or immediate demands. If they are immediate needs, add them to the list.

Finally, organize the requirements into packages. You can divide a list into multiple packages for iteration, prioritizing client requirements in the first package, followed by others, ensuring internal agreement.

At this point, you've completed your initial requirements analysis and can begin writing the PRD.

Scenario 3: Holding Requirement Review Meetings

Once you have prepared the PRD, you can schedule a review meeting with developers, testers, and other departments. This is a critical moment for your requirements.

You might feel nervous, worrying that your requirements will be criticized by developers or dismissed as unimportant by the business team.

As a resilient product manager, you must first have confidence in your design and remind yourself that "you are the best."

However, confidence alone is not enough; you need to conduct internal reviews with the business team before the meeting to ensure your requirements meet their needs. Also, pre-review the functional design with developers to check if it can be achieved with existing technology. Assess whether the expected launch date is feasible; if not, discuss what can be realistically implemented or if there are better alternatives.

With solid preparation and a valid design, your confidence will rise. What do you have to fear when you conduct the requirement review?

It’s time for you to shine…

However, if technical team members express doubts about your requirements during the review, or if they previously said they could do it but now claim they cannot, a resilient product manager does not get caught up in emotions (though you might feel a bit of anger internally).

Instead, focus on resolving their doubts and the feasibility issues. You should listen carefully to the technical team’s viewpoints and understand their challenges rather than simply insisting on your opinion or applying pressure.

You can say, “I understand your concerns about implementing this technology. Let’s delve deeper into this issue together.”

Next, actively seek alternative solutions or optimize existing ones. If possible, prioritize or break down functionalities so that critical components can be developed first, reducing the short-term implementation difficulty.

Simultaneously, proactively coordinate internal resources, seek external technical support, or even re-evaluate the product planning to ensure a balance between goals and reality.

With this set of strategic moves, your colleagues in development, testing, and business will surely think: "Impressive!"

Final Thoughts

If you compare a team to a vehicle, where is the engine located?

It’s definitely with the product manager, who bears the pressure of validating the authenticity of business requirements, assessing the feasibility of technical solutions, and ensuring the usability of functions through testing.

Thus, many experienced professionals embody a resilience that allows them to consider others' suggestions, accommodate different emotions, and earn the team’s affection. People enjoy working on projects with them.

In contrast, another type simply goes with the flow, executing requests without accountability and ignoring technical challenges, leading to frustration among the team.

The former group tends to rise with age and experience, while the latter often declines, ultimately facing "optimization."

These three high-frequency scenarios are essential for every product manager and may provide you with new ideas on how to approach your work.

Let’s go for it together!