Lessons learned from a young product

Lessons learned from a young product

Hello everybody! My name is Yustyna Tsyga, and I am the IIoT product owner at Digital SIBUR. IIoT is, in general, the industrial Internet of Things, but now I want to talk specifically about the development of software – a platform for visualizing readings and setting up wireless sensors in factories.

I have been in this project since the beginning of my work at SIBUR, helped the previous product, replaced it, managed additional blocks of the existing solution, and everything seemed clear and familiar. But a year and a half ago, I became the sole owner of the product and went from the stage of inspiration and burning eyes to the realization that I was not coping.

In this article, I want to share my mistakes, their analysis and just a story that I hope will help young products not to give up and immediately pay attention to alarm bells.

Lesson one: now everything is your fault

So, I was left alone. The first thought, like many in my place, was: I will do everything right now! Your wings open, the alien product of visions that has been hanging over you all this time disappears, and you enter the nasnaga phase. You get into all the processes, because now it’s your product, you can’t bypass any of the problems and everywhere you put forward hypotheses about their solution.

In fact, I still believe that’s how any product should work. But if earlier some of your decisions could be “cut off” for some reason by a person above you, now you are that person.

The ability to make decisions consciously, thoughtfully, and based on data, not feelings, is your new unlocked skill. After all, if you told the customer that the feature will be ready in 2 weeks, and the backender had the flu, and he did not have time to answer you. Or if the designer suggested changing the color of the button, and it lost the user’s loyalty – answer to you.

But there is joy in this too. Yes, now you are forced to postpone the implementation of the super feature, which castdevil himself, because another, less beautiful for users will bring more effects to the project. But now you are a juggler and know how not only to prioritize cool features, but also to fulfill a functional contract with your actions, bring money to the company and justify expenses.

In my case, this juggler has to be reconciled with the internal UX designer, so it hurts me to hear from users and from the team that this or that feature would be so helpful and so cool. But we have to remind ourselves that now the optional upgrade will not improve our metrics, and we have not yet met the mandatory goals.

Lesson Two: Metrics

You always need to understand that your actions led to something and, depending on the result, determine the strategy. Even if no one has done this before you – especially if no one has done it before you. And just user interviews are not enough – they must be complemented by metrics, and it is important to approach their definition so that they really reflect our target indicators.

If you have just come to the project, the first thing you need to understand is what metrics the product has, whether they reflect the indicator the product is aimed at and whether they are achieved. Yes, feedback and in-depth interviews are great, but you need to measure your decisions somehow.

I faced the fact that my old metrics did not properly measure what the effect of the product was based on. And when we formed new metrics, a more serious task was revealed – it turned out that we needed to rebuild the business process as a whole.

The third lesson: the term named by the developers must be multiplied by two

Here, of course, I am exaggerating, but the point is this: you need to invest time in taking risks.

Let’s say you are planning a task for a quarter. You have identified the features and went to the technical team to find out how long it will take to implement them. He announces the terms, you prioritize the features and take them to the business.

This was high-level planning, and when sprint planning starts, it turns out that the feature will require a whole section page redesign, a database rewrite, and your tester is going on vacation for a month. And of course, you are responsible for this mistake.

It is not for nothing that there is a risk-oriented approach in management – even if you do not yet know how to work with risks, invest 20% of your time in freelance situations. After all, it is better to take something additional from the backlog than to not complete the goals.

Lesson four: the team must be happy

At this stage of self-discovery, sensitive products are sifted out. Or they find a good psychologist, that’s how lucky they are ☺ The product is a filter between the evil and scary world and the comfort in which the developers are used to living.

Ever since I got into product management, I’ve heard at times that the product isn’t good enough or doesn’t do the trick. For a person who sincerely considers the product to be his brainchild, this is a lot of stress, and no matter how much you want to discuss it with someone, in no case should you take it out on the developers. But it is definitely worth discussing with a mentor.

It would seem obvious, but it is still worth noting. Because the development team is creative and happy to make a cool product, and business problems presented on emotions can break this magical atmosphere. But of course, it is not necessary to hide the highlighted problems: if you are told that the product does not solve the task, this is a great reason for research and further improvements.

You just need to solve business problems at the business level in your area of ​​responsibility, and the development team needs to understand the goals, objectives and risks.

Lesson five: balance between team leader and project manager

There are different situations in life and every team member can face burnout. Your task as a manager is to monitor the efficiency and emotional state of the team, find out what is happening, help if possible and give corrective feedback related to work at such moments.

Sometimes the developer needs to change the direction of tasks, sometimes even the project. Talk to him, how he sees his development, what tasks he is interested in doing, offer something new. Sometimes a life situation requires going on a long vacation – offer the employee such an opportunity. Fortunately, this is an increasingly common practice in modern companies.

At the same time, it should be borne in mind that these efforts may not always be effective and you need to be morally ready to look for a replacement employee. Unfortunately, there is no “good guy” position in IT yet.

Lesson six: the sooner you admit that you’re not coping, the better

I had a difficult moment after 3 quarters of my independent work. Everything somehow went downhill: we made even more bugs, we didn’t meet the goals, in the middle of the sprint it turned out that we forgot about the blocking task for the feature.

It doesn’t matter what your role is on the team, if you see a problem, you need to highlight it. And if you are a product, then this is your primary task. As my mentor told me: “Do you know what makes bread a product? In problems and their solution.”

But if you understand that the problem is not being solved at the team level, do not be afraid to come to your manager or mentor and tell everything honestly. Senior colleagues can help with advice, and properly help take responsibility for the business if tasks are not completed, and involve other specialists if necessary.

My mentor really helped me the most in my situation. He said that if you go to the manager with the phrase “I think I’m a bad product and I need help” – it means rather that you are a good product. A bad one will sit still and ignore problems.

We were also helped by the involvement of a scrum master. We haven’t had it for more than two years (well, the processes are built), but any change in the processes can change the whole usual way of working, and scrum can help highlight risks and suggest changes that will benefit the team and the work .

Epilogue

Perhaps these tips are obvious to some, but I will be glad if they help the same product beginners to avoid mistakes and stay calm in stressful situations! Sooner or later we face harsh reality, and it is better to use someone else’s experience for this.

In particular, mine. So let me know if you want more materials on the topic! There may be many more insights from work 🙂

Related posts