Transcription
At the beginning, I mentioned that I would tell you a bit more about my family later, and now the time has come.
My name is Natasha Baika. Some of you may know me because I have been helping the Buy community with analysis for five years now. Perhaps some of you have met me at offline events a long time ago, or you might have seen me online, or at someone's birthday as a host, just like today.
However, my achievements in breathing don't end there. I have over five years of experience in business analysis and product management. Currently, I am the Head of Product at the company Viggo, which is a service for photographers, a website builder, and a platform for delivering shoots to clients. If you're interested, you can Google it.
Today, I will share my personal experience of transitioning from business analysis to product management. I will discuss all the stages of my journey, what I did at each position, what drove my growth, and I will provide some conclusions and recommendations for you.
The reason I decided to share my experience is that I hope each of you who is considering a transition to a product manager position can see a bit of yourself in my journey, perhaps alleviate some fears about what comes next, or maybe even provoke some conflicting emotions, like "that's not how it is for me," or something along those lines. That's also great because we are all different, and the companies we work for are different.
So, the main goal today is to share my experience and give you some recommendations based on my path.
Let's start. Since I am talking about my family, all the characters are real, and any coincidences are not accidental.
Once upon a time, there was a junior business analyst named Natasha. We won't discuss how she became a junior business analyst; the fact is that she already was one and worked in a small company with fewer than 50 employees. The company developed B2B solutions for the American market and had 150 large clients, but there was only one product or project, so to speak. The development was custom, meaning the company did not own the product but had been developing custom products for over ten years.
This context is necessary to understand the environment in which our junior analyst Natasha lived.
What did junior analyst Natasha do? Well, nothing out of the ordinary for junior business analysts. Many of you may have gone through this path. Natasha communicated with the so-called clients, who could be referred to as investors or managers—people on the client side. Natasha clarified the technical details of the solutions proposed by these clients for specific problems and accompanied tasks from implementation.
Essentially, Natasha's daily routine looked something like this: she was part of the development team and spent a lot of time preparing well-described requirements and effectively communicating them to the team. She also had some communication with clients who came with ready-made solutions and simply asked, "Please, do this."
However, Natasha had a nagging doubt while working in this mode because she understood that there should be some business context. She wanted to see what lay behind these solutions and priorities. She did not make decisions and did not know the purpose of the features requested by our investor or client, and she did not communicate with real users because access to real users was unfortunately closed to her.
This nagging doubt led Natasha to start asking the client questions like, "Why are we doing this or that? Who will benefit from it?" She tried to learn from various sources about the real users of the product. She searched for their profiles on LinkedIn, trying to develop some empathy and understand the context in which these people used the product.
Natasha understood that they were solving a final problem, and even if the client refused to provide context for some reason, she needed to try to extract it. When Natasha managed to extract this context, she and her team tried to immerse themselves in it because they understood that team engagement was crucial and motivated the team to solve problems more effectively.
In the end, they wanted their users to be satisfied, even though the users were not Natasha's or her team's but the client's. Natasha also tried to convince her fellow business analysts of the importance of understanding the "why" and "how."
As a result, Natasha's role began to change. She started to step out of the development team circle and beyond just understanding features and technical requirements. Finally, she was granted access to real users because the client realized that there were questions even he could not answer.
This allowed Natasha to peek over the client's shoulder into the business world and see at least a small piece of why they were doing what they were doing and what could bring them money and what could benefit the user.
Through these simple explorations and attempts, Natasha grew into a business analyst or product owner. However, she continued to feel that nagging doubt and wanted to be more involved in the business, so Natasha changed companies.
The new company was large, employing tens of thousands of people. Its main profile was custom development, but there were also projects that were products used for the company's internal needs. Natasha was attracted to the prospect of bringing one of these products to market. She was very interested in working with the market and the business and understanding how technical requirements influenced revenue.
What new things did Natasha start doing as a business analyst or product owner? Since she was a lead, she managed the business analysis team, which involved various managerial activities. She began to make strategic decisions about the development priorities of the so-called product or project.
She participated in global planning about where the product should go, what it should be for market entry, and so on. Finally, she had constant access to real users and the opportunity to lead discussions about whether the product was solving real users' problems, even if only within the company.
This was a significant breakthrough and progress. In the context of launching the product to the market, Natasha researched the market and communicated with potential future buyers. Since this product was for large businesses, she had to talk to top managers of big companies and tried to understand what problems they faced, how they were trying to solve them, and how the product could be positioned in the market.
At this point, Natasha's role looked something like this: she had not completely detached from the development team, but she had clearly stepped out of that context. She had team members she managed who were closer to the development team. She had finally entered the world of business, business goals, money, and the world of end users, which was equally important.
However, Natasha faced challenges because her competencies were lacking. It was a rapid growth that Natasha could not keep up with in terms of her competencies. Unfortunately, there were no experienced product managers nearby, nor did her colleagues have experience in launching products to the market. The nagging doubt continued to linger because, even when the product was on the market, there was still a client on their side, and it was still unclear how to monetize it.
So, Natasha went to learn. Since she was struggling to keep up with her growth in competencies, she actively attended various training events on product management, including conferences and events like the one we are having today. She also studied all available free information, various Telegram channels on product management, podcasts, and many YouTube videos.
She absorbed everything she could find for free. Natasha also found a mentor and began interviewing for product manager positions, completing test assignments. This helped Natasha because each interview and test assignment highlighted gaps in her knowledge, and she humbly worked to fill those gaps.
She also completed the Product Star course, which is a product management course that covers a lot of well-known material for senior business analysts, including working with teams and prioritization, but also includes aspects related to product management. This was very useful, and Natasha did not regret taking this course at all.
Thus, she grew, filled her competency gaps, and changed companies again, becoming a product lead. The new company was already a product company with a product on the market for over ten years. It was a SaaS solution for the small and medium market, and Natasha's team was small, around 50 people—essentially a startup.
What new things did Natasha do as a product team lead? Of course, she managed the product managers, which is an integral part of any team lead's job. She also made decisions about the priority directions for the development and promotion of the product.
The product was already on the market, and Natasha needed to make decisions about how to position and promote it, as well as how to grow it. She conducted market research as before, but now it was for an existing market with an existing product.
She also conducted user research, including customer development and in-depth interviews, and much more. She researched competitors, both direct and products operating in other markets similar to theirs. Natasha constantly communicated with users but now with a greater understanding.
Using various techniques like in-depth interviews, she developed a metrics system and worked on continuously monitoring user success in solving their tasks with the product. She tracked how each update addressed user problems and whether anything needed to be adjusted.
Of course, she also monitored financial metrics, revenue, and profit, as well as product metrics, such as how users activated and how they used the product.
Once again, Natasha went back to learning because, after all, working with a real product meant a lack of competencies. So, Natasha completed two Go Practice simulations, one of which this year focused on product growth. The first simulation was related to metrics and data-driven product management.
Natasha also completed a very important and interesting course on how to create products that customers will love to buy. This course primarily focused on user communication, customer development, and various user research techniques.
As Natasha learned quickly, she advanced to the role of Head of Product.
What does Natasha do now as the Head of Product? The most important thing she does is take responsibility for the company's profit and revenue. This was something she had always lacked and was eager to learn more about business and how it works, about all those business goals she had read about in books.
Finally, she is responsible for this. She also develops the company's growth strategy for both short and long-term periods, determining how the company will win in the market, where the products will develop, and whether new ones will emerge.
She works closely with the marketing team on market positioning and attracting new users, as well as their activation and further movement through the funnel. This is a part of the job Natasha had not encountered in any of her previous positions, and a new world opened up for her in marketing.
Most importantly, the nagging doubt that had once troubled Natasha has ceased because this is exactly what she has always wanted and what she has always been interested in—being close to the business.
Today, Natasha can say that she walks side by side with clients and investors, representing the business. There is, of course, constant communication with the team, where Natasha conveys all the important metrics and the strategy for how the product will develop and how the company will grow.
She shares with the team what the revenue and profit are, and of course, Natasha communicates closely with clients and investors. Today, she probably has the most communication with end users she has ever had.
If we summarize Natasha's journey and look at it in one picture, it can be represented approximately like this: the further Natasha progressed in her career from business analysis to product management, the more she moved into the context of business, clients, investors, and end users.
This is a general description of the path Natasha has taken and how her activities and responsibilities have changed at each stage.
Of course, it cannot be said that she completely detached from the team; that is certainly not the case. However, the way she looks at the team now is different, and that is a fact.
This is neither good nor bad; it is simply a transformational journey that Natasha has undertaken.
As a summary, I will conclude and provide some advice from Natasha, who has gone through this entire journey.
For those who want to grow in product management, you need to grow there if you want to directly influence the company's profit and your salary.
You may have heard at the beginning of our session that Galina mentioned that everyone thinks product managers earn a lot. Well, unlike business analysis, product managers earn based on how well the product grows and succeeds.
If you can see the connections and influences of each specific cause on the final result at the business level, you should also grow in product management.
When you understand how the business achieves its goals through product updates, see all these chains, and can communicate this effectively, that makes you a strong candidate for product manager.
If you excel at being the glue that connects marketing, development, sales, and support teams, you are that social glue. This does not mean you are a messenger; rather, you should be the person directing the efforts of all your teams toward a single, most important goal. Only then will you succeed in growing your product and making a lot of money.
If you are comfortable in a state of constant uncertainty, product management is for you. There is never a clear action plan for product managers in small companies. It is always about testing, making assumptions, gathering facts, and making decisions based on what you learn.
You must constantly learn and lead to continue improving your product. There will never be a clear action plan.
If you possess a high level of empathy, product management is also for you because it will greatly help you understand your end users.
Situations can vary; you may have direct access to end users, or it may be difficult to find them. You must be able to feel the user's pain as if you were that user, understanding the context they are in.
To grow a product, you need to create a product that your users will love. This sounds simple, but it is challenging.
If there is something that indicates you should not grow in product management, it is if you feel uncomfortable or uneasy.
First, if you enjoy diving into detailed requirement descriptions, this is more relevant to small companies. When you work in a small company as a product manager, the quality of your requirements is no longer a priority because you are not focused on delivering features but on making money.
Therefore, your requirement descriptions may be optimized or even worsened, but as long as it does not affect the final result, there is nothing wrong with that.
If you love a well-structured process and documentation for every situation, product management is not for you, especially in a small company.
If you are not interested in diving into marketing and sales, product management is also not for you. If we talk about career growth to Head of Product or Product Lead, marketing and product management are inseparable and must work together.
You need to be aware of how your product is promoted, through which channels users come, and how it is monetized.
Lastly, if you do not like people and communication, product management is also not for you. This may not be evident from me, but I do not particularly enjoy being around people and often need to spend weekends alone to restore my balance.
However, I love stepping out of my comfort zone, which I consider growth. Each interaction with end users is an excellent way for me to step out of my comfort zone.
If you prefer to work alone and do not want to step out of your comfort zone, product management is likely not for you.
These are my pieces of advice. Thank you very much from me and Natasha, who is a big boss and a constant learner. I hope you enjoyed this narrative.
You can find my contact information on the slide. If you have any questions later or want to connect or get some consultation, I would be happy to help.
Now, I will stop sharing and go through the questions in the chat. You probably asked some.
Let me scroll through.
We probably have three minutes, if I am not mistaken, for questions.
Oh, eight minutes left? Thank you for the reminder. I will try to answer as many as possible.
I was worried about the nagging doubt. Yes, guys, thank you; it has been crushed but not defeated. It has probably gone to bother another business analyst.
There is a question: "Is there ever a conflict of interest for a product manager when it comes to prioritizing profit over user happiness?"
In my experience, this has not been the case because, for me, user happiness directly translates into revenue. It may not be immediate, but I have a clear understanding that if users are happy, they will stay with us and pay us.
The thing is, I work on a product for photographers, and the decision to purchase our product is made by the end user, the photographer, who also pays us and uses the product.
In my world, this conflict does not arise because if the photographer who pays us is happy, our revenue increases.
However, when it comes to products for the B2B market or enterprise companies, it is essential to communicate important aspects to different stakeholders.
For example, when selling through a sales team for large products, you emphasize how your product solves significant problems. You do not just talk about a user-friendly interface; if it is a solution that speeds up the work of end users, you highlight that convenience.
However, sometimes there are conflicting goals, and you need to communicate those goals while ensuring the product remains user-friendly and solves end-user problems.
Eventually, the end user will find out if the product does not meet their needs.
Another question: "If the product manager is the glue that directs and stimulates everyone, who controls the delivery and deadlines?"
This is more about role distribution. The product manager can do this, depending on the processes established in the company.
There were times when the product manager acted as the project manager and set up processes within the team. In that case, the product manager's role included controlling delivery and ensuring tasks were completed.
However, currently, in our case, the project manager role is fulfilled by the technical director, which has yielded better results.
When the product manager focuses on users and revenue, they do not have the time or capacity to delve deeply into technical details.
Control over delivery usually implies investigating why there are delays and finding simpler solutions.
So, in our case, it works this way, but it can vary depending on the product.
If any of you have worked in business analysis, you may have noticed that different companies have different interpretations of the role of a business analyst.
Another question: "Is a product manager needed if the core product is already implemented and only new customers are added with minimal customization?"
It depends on how processes are set up. In our fast-paced world, if you do not continue to develop your product, you risk falling behind competitors.
You cannot just create a product and leave it as is. Competitors will emerge, and disruptors will change your market.
If you stop developing your product, you automatically give an advantage to competitors who continue to innovate.
In my opinion, a product manager is always needed to explore how the product can improve in the market and what opportunities it can provide.
If you have a solid customer base and are just customizing for them, you might not need a product manager, but I have not encountered such products in the market.
Did we work with SAFe? Is there a difference from Scrum in my role?
I will not delve into the specifics of processes within the team because it is very individual.
In general, I believe the worst thing that can happen is to implement a process for the sake of having a process.
When a product manager or project manager imposes a methodology without understanding the current process issues, I am against that.
Methodologies are made for people and can be customized.
I do not want to get into specifics, but we do not work with SAFe or Scrum. Our team is small, and we are in a constant startup mode.
Today, we do not need a specific methodology to organize everything but rather to work more effectively in this mode.
I hope I answered your question.
We are approaching the end of our time slot, with just a minute until the next presentation.
Perhaps it is best to address the next question asynchronously. I will try to answer questions in the chat as we move on to the next presentation.
Thank you all for listening, and I hope you enjoyed it!