First, third choice
At work, there will always be conflicts between product managers’ changing needs and project managers’ deadlines on key points. And for the developers who ultimately execute things, these conflicts can become personal to you if they are not handled well.
As the programmer who finally implemented the feature, you don’t want to be labeled as a developer who couldn’t meet deadlines, do you?
These problems, in fact, can learn from the idea of the third choice to solve. Third Choice is a book by Stephen Covey, and I want to mention another book by Stephen Covey, which more people should know about, the 7 Habits of Highly Effective People. In “Third Choice,” he condenses those seven habits into one thing, and it’s safe to say that third choice is the key to solving all problems.
When we face conflict, what is the normal way of thinking to resolve it?
- I beat you.
- I’ll take it. You beat me.
With third-choice thinking, you have a choice: let’s find a mutually acceptable solution and achieve a win-win situation.
Notice that the third option here is definitely not a compromise or a compromise, but the idea is creativity. How to reach a better outcome through the third option.
Like two people sharing an apple, one half? I owe it to both of us, because I get a whole apple if I win. What’s the third choice? We take the apples out and exchange them for something, and then we divide them, or we plant them into apple trees, and if we’re willing to invest for the long term, eventually each of us can harvest half the apples of the tree. These are all third options, as long as both sides can reach an agreement, it’s a win-win situation.
Second, facing the conflict of product manager
So what conflicts do we typically face when working with product managers?
2.1 Requirements that cannot be realized technically at this stage
You can’t expect all product managers to be technical, and when product managers don’t understand the technical details, there will always be some fantastic product ideas. Of course, some of the problems are not that the technology cannot be realized, but that your team will struggle to realize them at this stage and may face some unknown obstacles, which will make the progress of the whole project difficult to control.
When faced with such a need, you don’t want to reject it outright, especially if you don’t reject it out of hand by saying it’s impossible to do, which pushes the other person into a conflict situation. You refuse to do the need, or he persuades you to force the need, that’s not what we want to see.
Why don’t you calm down and think about third choice?
I think most product solutions are not the only solutions, you always think of something that’s easier to implement.
Instead of rejecting an offer, ask what the other person really wants and offer a proposal that you can do.
2.2 Mismatch between requirement complexity and development time
When you are faced with an overly complex requirement, you may not have the time to implement the feature for a variety of reasons.
What about this time? Do you work overtime to finish? Everyone is a programmer. I think you should have some points in mind about the specific quality of the code written overtime. Because you work overtime to write the code quality is bad, so the increase in the number of bugs after launch, still need to take time to deal with, and new cycle demand also immediately follow up, find code expandability of quality is bad, want to refactor the time, and do not allow only patches, more dry more slowly, more dry more bad, more and more bugs, so you pressure is more and more big, Being complained about more and more.
Technical debt now must always be repaid later, otherwise in the long run, it will only be a vicious circle.
At this time directly say yes or no, will fall into the situation of conflict. Think about third choice. You don’t just say “no”. You should first understand, why does he do this need? Where is the starting point? What is the purpose? Once you understand the product manager’s true intention for the requirement, you can either come up with a solution that is acceptable to you from a technical point of view, or discuss a more cost-effective solution with the other party.
It’s great to be able to discuss a solution that everyone can agree on, but what if the requirements are still complex and there is still a mismatch between time and complexity?
You can choose to split requirements. You can say, the demand on careful analysis, I need to do A, B, C, in distribution of time now, I can only do it barely A, B, and B does not guarantee the quality, you see this feature, you can we split into two phases, adjust the demand, so that I can ensure the quality of the code, the first phase to ensure the basic function, The launch allows users to verify requirements, and the second phase adjusts details according to user feedback.
Trust me, the product manager is under pressure to make sure that progress is being made, and in a complete and perfect choice, I don’t think it’s difficult.
Here’s the trick: When I can’t satisfy you completely, I can choose to satisfy you conditionally.
The nice thing about this is that you leave the choice up to him, and some of the pressure is on both of you. If anyone has any objection to this extended cycle, your product manager will defend you and say that he has a very detailed requirement design, so we decided to do two phases, which also shows that he has a strong control over the details of the requirements.
2.3 Demand changes too frequently
As a developer, sometimes when I write code, I may find that the initial scheme or selection is not appropriate, so I will take the initiative to adjust the code and reconstruct the code. Product managers have the same problem when designing requirements. It may be that he did not consider it in detail at the beginning, or he may be under pressure from a third party, etc., and a variety of reasons eventually lead to the need for adjustment, but he cannot adjust the product solution by himself during the development cycle, and the work pressure will be transferred to the development to realize the demand.
The first thing I want to say is that demand change is going to happen, so embrace change.
Developers should allow some time to deal with these changes when the requirements are scheduled, but this does not prevent the product from changing too often, or even too much to be closed tomorrow, and still changing the requirements today.
In this case, what you need to do is to bundle the pressure with him as far as possible. Since the other side gave you the pressure, you should find a way to return the pressure and let the other side share the pressure with you.
What I usually do is:
1, first use a quick way to achieve and online, and then take time to repay the debt
I think a lot of features, there’s always some crude and inelegant way to implement them, and that’s technical debt, and then it takes time to pay off technical debt.
The product manager needs to claim the technical debt and must be given time to pay it off immediately.
The simplest option is that I can work overtime to complete the requirement in a rough way, but the problem is that there may be efficiency problems later, scalability problems, etc. After that, I need an extra week in the next cycle to optimize this piece of code, which is the immediate payment of the technical debt.
2, split changes
As with the previous idea, minimize changes to the existing base and make them as streamlined as possible.
If it can’t be streamlined, find a way to break it down into two phases.
3. Increase variable costs and put pressure on the other party
While all changes in requirements ultimately affect developers, that doesn’t mean there’s nothing else to do. Find ways to increase the variable costs of the product manager so that he shares the burden.
Such as:
- With the addition of this function, the UI also needs to be changed. Could you please communicate with the designer that we should not deduct too many UI details in this issue? — Reduce communication costs
- The change in this requirement affects the original development schedule, so see if you can postpone another (less important) requirement. Replacement is something that is not important, but takes time to do
- Is there no way to handle this requirement if it encounters such a situation? — Remind him to refine the requirements and avoid changing them again
- There are still some “data” to deal with this requirement, could you please help me deal with it manually? — Give him something to do. Not recommended
Write in the last
At work and in life, don’t think the solution to everything is: no (first choice, to win) or yes (second choice, to lose). If there are only two options, it’s easy to get into a push-and-pull environment and actually consider the third option.
The third option is not about compromise on either side. It’s about creativity, finding a way out, getting both sides to work together to find a new solution that everyone can live with.
Said so much, is actually “the third choice” thought, recommended reading.
Today, I reply to “grow up” in the background of the official account, and I will get some learning materials sorted out by me. I can also reply to “add group”, so that we can learn and progress together.
Recommended reading:
- Talk about Airbnb’s Lottie from the perspective of Android development
- Comics: Git binary Debug, quickly locate the error code!
- Looking for a Bug all day? Try Git dichotomy!!
- How to search open source libraries on Github more accurately? You need these skills!
- Android development, Emoji headache?
