5 harmful tips and anti-cases

I'll tell you how to destroy empire product team, break down its interaction with other departments, and illustrate the text with real stories. Be careful, you may have Vietnam flashbacks.

A little background

Product teams come in different forms. The ideal type is the unicorn team, where there is a dedicated person for each function. But this is not the case everywhere.

Many product managers, especially at the start of their careers, go through a stage of working in small teams. Often, the product manager works for himself and for that guy – he also covers the functions of a marketer, an analyst, and a project manager for unique experience and cookies in the office. Therefore, some stories may make you think, “That doesn't happen!” I'll answer briefly, it does.

5 Ways to Destroy a Product Team

1. Break communication between specialists

Teamwork is a luxury. Build interactions as if all specialists were disparate tribes in warring territories, who occasionally trade spears for beads.

Forget about meetings and discussing the understanding of tasks, let colleagues throw projects at each other like huge flaming balls. Those who do not dodge – get overtime, in the hope of meeting the deadline.

This can be done with the help of strict deadlines, a complicated approval system, and constant work in a sprint format. If each specialist has a ton of tasks, there will be no time left for communication and clarification. To make a combo, replace part of the team with newcomers who, no matter how hard they try, will not be able to immediately immerse themselves in your processes.

A story from practice:

One of the projects had an absolutely crazy approval system: it was necessary to PRINT out all the materials, including presentations, then take a clearance sheet and sign it from each decision maker. By the way, there were 9 of them, like the circles of hell in Dante.

Getting something approved by so many people is quite a quest. The most unexpected reason for refusal that I can remember: “Why am I lower on the list than another decision maker?”

The same system of checklists worked for release approval. The last straw for me was this situation: we released a new feature, thought out the concept, conducted custom developments, wrote down business and system requirements. In short, we did everything we could. We signed the checklist, but, as it turned out later, we forgot one of the nine.

The new feature worked for 2 days. On the third day, one of the decision makers burst in on us in a rage and demanded that “everything be returned to the way it was” because nothing had been agreed upon with him.

The application was rolled back to the old version and approval was launched again. But another decision maker from the bypass list just happened to fly away on vacation. As a result, the fully completed update was released only after 2 months.

2. To hell with project planning and management

Planning is a complex process that requires time and effort. It is much more effective to use the old-fashioned method: if you need to determine deadlines or indicators, stare at the ceiling until the answer appears. Then give the task to work and, as for the first time, be surprised why your colleagues cannot do everything on time.

You can act even more simply: any task is urgent and important, it must be completed immediately, preferably yesterday. Set a high priority for everything and make sure that employees always have 5-6 such tasks.

Remember, not urgent and not important according to the Eisenhower matrix is ​​about lunch breaks and working without overtime – something that can be safely excluded from the life of the team. Let colleagues work like robots on a conveyor until the bolts fall out of them. All of them will soon be replaced by AI anyway.

A story from practice:

One week the team had an interesting week: in 5 days, 3 decision makers approached the product manager with a request for new features. All urgent and important, needed “yesterday”, but, so be it, it can be done by tomorrow. An immortal classic.

The product accepted all the requests and went off to think. Making 3 features with a deadline of “tomorrow” is a mission impossible, so all the decision makers were called to a meeting and asked to decide what was more important. As a result, they started arguing among themselves, and their conflict, like the deadlines, dragged on for another week. During this time, the team calmly completed the current tasks of the sprint.

This is a story with a happy ending: the decision makers made peace and set priorities. And the team did not have to work in fire mode, thanks to the product manager, who filtered the requests and did not miss the blazing tasks that were not actually blazing.

3. Writing detailed technical specifications is too boring

The postulate “without a clear technical task – the result is unknowable” was invented by people without creative thinking. Stop doing the work for your colleagues and explaining every step to them, let them think with their own brains. Your maximum is to indicate the name and deadline of the task in the task manager.

Give your colleagues a chance to be smart, find the inputs themselves and guess what result you want to get. If they do come with questions, answer them verbally and dissolve in the textures. When the task is completed, be surprised why everything was done incorrectly and give new conditions. You can repeat this cycle endlessly.

A story from practice:

We needed to do onboarding for a new feature. The decision maker's technical specifications only vaguely indicated that onboarding was simply needed. We ask clarifying questions, spend time compiling an understanding of the task and a brief. We send it back, and in response there is silence – the decision maker has gone on vacation.

Upon returning, the team pushed him almost every day, but he was busy with post-vacation messes and almost did not respond. We did not receive any specifics in response to requests.

A month later, the classic Tarantino dialogue took place:

— Where is the onboarding?

— What onboarding? You haven't looked at the task understanding yet.

— What is the understanding of the task?

In the end, of course, we synchronized, but there were only a few days left to develop onboarding.

4. Lifelong chains of approvals

Few things kill motivation more than multiple iterations and edits that contradict each other. To achieve this, create an environment where everyone involved in the approval process must speak up to show that they are engaged in the project and are passionate about the outcome.

The key detail is that the task should not have a main approver: such people only shorten the fun and the path of searching for the Holy Grail of the ideal. Explain this by saying that you are all here to make a great product, which means that absolutely every opinion can be useful.

Don't forget about your role: you are the star who closes the concert with the final song. Or rather, opens it anew. Keep quiet and wait until they give you the result, and then make edits to each element. You want the best, after all, and people don't get paid for nothing – they should work, not just sit out their working day.

A story from practice:

This story is a continuation of the epic from the previous point. Briefly: it was necessary to do onboarding, the technical task turned out to be so-so, clarifications and brief could not be looked at for 1.5 months. Then they woke up and with a burning head ran to do the task.

Then the era of edits began. The number of iterations multiplied, the product team argued among themselves and could not agree with related departments. Several times, heads came and made their edits under the auspices of “Why didn't you agree with me?”, which rolled the work back even more.

When everything was already moving towards completion, a twist from a Turkish TV series happened: a lost twin brother appeared on the screen – a decision maker from an adjacent department, who decided that he also needed to join the task and see everything. As a result, the team spent more time on approvals than on the feature itself.

5. The team's time is priceless. It costs nothing.

Everyone is the architect of their own happiness. This means that you need to do more of your own business and think less about others. You should not worry about how the team manages their time and what their workload is. The main thing is that your wishes are fulfilled immediately.

If you have a new idea, write the task quickly. If you want to discuss something, schedule an urgent call. Don't be afraid to take up your colleagues' time: it was sold to the company when they accepted the offer. Don't let them even think about complaining about your involvement in the work and concern for the overall result.

A story from practice:

At the beginning of his career, an acquaintance had to work with a team whose team leader tried to control everything and, at the same time, maintain the illusion of freedom and flexibility. Because of this, paradoxes occurred.

For example, there was no clear beginning and end of the working day, but there were daily meetings with a floating start, which lasted 45 minutes. The water from them could be squeezed into a bucket, and some employees who decided to start working later that day joined the meeting from the metro or taxi.

The team worked in 1-month sprints, but the lead continued to staff the sprint the entire time — urgent unplanned tasks were regularly added. At the end of the sprint, the team discussed its inflexibility and the reality of the existence of unforeseen factors each time, then began a new cycle.

The cherry on the cake was the review and demo of the sprints, which meant a 5-hour non-stop call. The friend experienced this little death only a few times, then his patience ran out, and the team changed along with the company.

Conclusion

By using these tips, you will suck out all the joy of work from specialists like a dementor and make people wait for the weekend like manna from heaven. And if you manage to combine the methods, then the team will very quickly be reduced to smoking embers.

Have you ever had anything like this at work? Or maybe you know of more ingenious ways to destroy a product team? Please share in the comments.