Confession Product Manager

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

We do not develop custom projects, we make a product that we sell to customers.
For my teams, I shape the vision of the product, decide which of the “Wishlist” users we will make and explain to the team (sometimes on the ducks) why they are needed. I describe the tasks in terms of business value, formulate and test hypotheses.
My development requirements are often formulated vaguely, features often have to be redone or modified after launch.

This prevents me from writing perfect code for developers. I know that many product managers do this.

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

The product should solve the pain

The product manager has a vision that it is necessary to create companies so as not to waste time and effort of expensive (in every sense!) Developers.

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

Product team

Previously, we had functional teams that do only their part of the feature (for example, write the frontend). We were not happy with the speed of development, communication disruption, the process of transferring tasks between teams and tracking their statuses.

We moved on to product 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 frontend developers, and a tester.

Each team member fulfills his role. The product manager conducts research, forms a backlog and prioritizes. Developers write code. The tester monitors the quality. The project manager details requirements, organizes the interaction between teams and helps to remove obstacles, for example, find equipment for tests, markers and a whiteboard, book a meeting room, organize meetings, etc.

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

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

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

MVP VS Perfect architecture

We work in a field 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 put a minimum of effort and solve their problem. However, 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 can be even more complicated - the user may not know that he has a problem. He lived for so many years, struggled with difficulties and considers this the norm. And if I ask: “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 magical his life will become with our tool.

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

To make fewer mistakes, I describe the hypotheses and to test them I need the team to create MVP - a minimally viable product. To succeed, I want to constantly experiment , as most grocery companies do. After all, the more hypotheses I check, and the faster I do it, the greater the chance that the company will release 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 put it into operation in a week, in response I hear that this is impossible. Need to think over architecture! You need to consider all the scenarios! We need a complete ToR with a description of all the functionality! And what will happen if one of the 1000 users does not what we expected, and everything breaks with him ?! You cannot write and review code in such a short time!

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

Work at the desk

And now, we still have washed down functionality that the user does not need.

It’s good if we spent a little time on it and it’s not a pity to part with it. But if the developer put a soul into it? Didn’t sleep at night, drew perfect buttons with “selling green”? Considered and processed all the scenarios? Made a flexible architecture that can be painlessly covered by tests ? I wrote an article and told all my colleagues about how cool he applied the latest technology?

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

Thus begins the most frequent conflict between the developer and the 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 developer's task is to write beautiful code that he will be proud of.

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

Product thinking

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

And then I thought: “How can a developer think of a person whom he has never seen or talked to?”

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 a lot buttons, each of which does its own thing - they only need to be pressed at the right time, wrote a detailed manual of 25 pages. And he could not even think that someone might not want to spend several hours studying all this. He then loves to deal with complex projects!

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

And no one told the developer that his program is used by a cashier girl who just came to work. In front of her is a queue of 20 people, and every time she needs to press 10 buttons in the correct sequence to achieve the result. And now, she is already crying from powerlessness, because people in the queue begin to scream, and she lost several times.

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

Because in complex products you never know whether new functionality will be in demand. The 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 in the old way.

Because the client did not tell me about complex use cases in an interview (or I could not pull it out).

Because they forgot to hang analytics.

Because the manager can also be wrong.

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

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

And very often someone is needed who will ask the right question, take a fresh look, offer a non-standard solution.

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

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

Dreams Come True

I am still ashamed of the task of processing some feature or request to cut out the functionality. I still feel offended when the developers point to an unfinished task. And I am happy every time the team offers their 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 can solve the problems of our customers together, make a lot of money (which business doesn’t want this?) And make people's lives a little better. If each team does the same, spends its energy 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 hypotheses, ask to fasten something fast, I learn to “sell” tasks to the team and pass feedback from the user. And I expect them to stop hating me for stopping them from writing perfect code.

PS: The author of the article Stratanovich , she has readonly so far, but we really wanted to publish.