Confession of a product manager

I work in a grocery company. What does it mean?

We do not develop projects to order, we make a product that we sell to customers.
For my teams, I form a product vision, decide which users we want from users, and explain to the team (sometimes on ducks) why they are needed. I describe tasks in terms of business value, formulate and test hypotheses.
My requirements for development are often not clearly defined, features often have to be redone or modified after launch.
')
By this I prevent developers from writing the perfect code. I know that many product managers do this.

And I want to tell you why I do it again and again.

The product must solve the pain

The product manager has a vision of what is needed to create companies in order not to waste time and effort of expensive (in every sense!) Developers.

This does not mean that we do only what we like, and then we try to “push” it to the end user. The task of any product is to solve a problem, not create a new one.

Product team

Previously, we had functional teams that make only their own part of the features (for example, they write frontend). We were not satisfied with the speed of development, disruption of communication, the process of transferring tasks between teams and tracking their status.

We went to the grocery teams that are responsible for the product as a whole and can do any functionality on their own.

Our product team includes product and project managers, several backend and front-end developers, testers.

Each team member fulfills his role. A product manager does research, backs up and prioritizes. Developers write code. The tester monitors the quality. The project manager details the requirements, organizes the interaction between the teams and helps eliminate obstacles, for example, finding test equipment, markers and a board, book a meeting, organize rallies, etc.

My dream, like any product manager - a team that will understand its user and its needs, will validate tasks and think about the benefits each feature will bring to the client.

But dreams come true very rarely. My developers rarely think about those for whom and why they write their code. Their main task is to build an ideal architecture, to use the most top tools, to try new technologies.

And this contradiction becomes the most frequent cause of disputes between me and the developer.

MVP VS Ideal Architecture

We work in an area that is changing very quickly. The number of abstractions is constantly increasing. New products appear and die. Users do not want to learn how to work with our software, they want to make a minimum of effort and solve their problem. At the same time, we often forget that the user does not know how he wants to solve this problem. He just wants her not to be.

And it is even more difficult - the user may not know that he has a problem. He lived for so many years, struggled with difficulties and considered it the norm. And if I ask: “And what is your problem?”, I often hear in response: “No, I'm fine.”

The task of the product team is to understand the pain of the client, give him the best solution and tell how his life will become magical with our tool.

We realized that without customer development it is almost impossible to create software that would happily buy. My task as a product manager is to search for the target audience, conduct interviews, identify needs, describe characters and their pain. But even this does not always guarantee success. I am also a man and I can be wrong too.

To make mistakes less, I describe hypotheses and to test them, I need the team to create an MVP — a minimally viable product. To succeed, I want to constantly experiment , as most food companies do. After all, the more hypotheses I check, and the sooner I do it, the greater the chance that the company will produce exactly the product that the user will appreciate.

But often, when I come to the team and say that we need to make the functionality “on the knee” and launch it into work in a week, in response, I hear that this is impossible. Need to think about the architecture! Need to consider all the scenarios! You need a complete TZ with a description of all the functionality! And what will happen if one of the 1000 users does not do what we expected, and everything will break? It is impossible to write and conduct a review of the code in such a short time!

I understand the concerns of the developers, but communicating with users, I understand that most of them do not need an ideal architecture. They will never see the perfect code. They are ready (in the first stages, of course) to tolerate bugs if they get a solution to their problem.

Work at the table

And so, we still have a functional that is not needed by the user.

It is good if we spent a little time for this and it is not a pity to part with it. But if the developer has put his soul into it? At nights I didn’t sleep, drew perfect buttons with “selling green”? Did you learn and process all the scripts? Made a flexible architecture that can be painlessly covered with tests ? He wrote an article and told all his colleagues about how cool he was using the latest technology?

And then I come in and say a phrase that all programmers hate: “We need to redo this feature.” And it happens in response to hear what all the managers hate: “I tried, I did everything according to TK, and you did not appreciate it with the users. I will not redo anything. ”

So begins the most frequent conflict of the developer and product manager. And everyone thinks he is right. After all, my task as a manager is to test as many hypotheses as possible, and the task of a developer is to write beautiful code that he will be proud of.

When I hear from the developer the phrase “Well, we’ve worked the table again”, I try again and again to explain that this is not the case, his work brought the company benefits - we tested the hypothesis, did not spend a lot of money on it, and realized that need not this. We have taken a step forward. The developer helped not to make a mistake.

Grocery thinking

I used to constantly communicate with end users, saw their problems. But the trouble is that I did not think about telling my team about my research. But the task of the guys - as soon as possible to do something that will solve the pain of the client.

And then I thought: “How can a developer think about a person whom he has never seen and with whom he did not speak?”

He did everything so that any user could use his software as flexibly as possible - made a maximum of different settings for all occasions, added many buttons, each of which does its own action - you only need to press them at the right moment, wrote a detailed 25 page manual. And he could not even think that someone might not want to spend a few hours studying all of this. He likes to deal with complex projects!

He has never seen who uses his product and under what conditions. In his world, everything is obvious - the client must understand all the settings himself. And the client for some reason is angry.

And no one told the developer that his program is used by a cashier girl who just came to work. Before it stands a line of 20 people, and she needs every time to achieve the result, press 10 buttons in the correct sequence. And so, she is already crying from powerlessness, because people in the queue start screaming, and she got off several times.

I know about this and I understand that the functionality needs to be improved - to remove unnecessary settings, reduce the number of actions, add new scenarios that we did not anticipate before. But the developer resists. He does not want to alter the same thing several times, inserting new “crutches”. “Why it was impossible to do it right away?” - I hear from him.

Because in complex products you never know whether the new functionality will be in demand. A client can say that he cannot live without this feature, and then does not use it, because it is easier (or cheaper) to do everything the old way.

Because the client didn’t tell me about the complicated use cases for an interview (or I couldn’t get it out).

Because you forgot to “hang” the analyst.

Because the manager can be wrong too.

Therefore, I try to establish communication in the team. Because I try to teach all team members to think first about the product and how the client uses it.

You can accuse me of shifting responsibility, but I, like most people, have cognitive distortions, blurred eyes. I may not see the obvious solution, because I have been thinking about solving this problem for too long. I can miss something in the chain of reasoning. I can simply reject a good idea, because I consider it technically unrealizable or very complex, but it turns out that there is work for 2 hours.

And very often someone needs to ask the right question, take a fresh look, offer a non-standard solution.

And I constantly wonder why developers rarely ask me why and for whom we make a feature? Why not try to put yourself in the client's place? Why don't they always tell me about the technical duty, but just quietly do refactoring instead of grocery tasks?

And just as often I find myself thinking that I do not always share with the team how the client uses their product. I forget to tell the developer that he is now “sawing” is not a full-fledged functional, but only MVP, which may not take off. I do not explain what problem their feature solves, but simply throwing tasks into backlog, hoping that the team itself will come to me with questions.

Dreams Come True

I'm still ashamed of the task of processing some feature or request to cut out the functionality. I still feel hurt when developers point to an unworked task. And I am happy every time the team offers its solutions to the task, argues with me and asks questions about how to use their tool.

I believe that if everyone in the team thinks about the product and how it is used, we will be able to solve the problems of our customers together, make a lot of money (what business doesn’t want it?) And make people’s life a little better. If each team does the same, spends its strength on solving someone’s problems, we will live in a fantasy world that exists only in books so far.

And I persistently continue to test the hypotheses, ask me to cut something in a quick way, learn to “sell” the task team and transfer feedback from the user. And I expect that they will stop hating me for stopping them from writing the perfect code.

PS: The author of the article is Stratanovich , she is still readonly, and we really wanted to publish.