From Junior QA to Product Owner: My Growth Story at EXANTE

Hi, I’m Nastya, the Product Owner of EXANTE’s desktop and web trading terminals. I began working at the company nearly five years ago as a Junior QA Engineer. Since then, I’ve advanced to QA Lead and ultimately to Product Owner. In this article, I’d like to share my growth journey within the company and the steps that helped me progress. I hope that my story will be helpful to those seeking to advance their careers but are unsure where to start.

Background

My career in fintech began in 2008 when I developed an interest in financial markets. Over the next decade, I gained significant experience trading various assets on trading platforms from numerous brokers. This hobby has persisted and has helped me preserve and grow my capital.

In 2019, while working full-time in e-commerce, I pursued QA training. After completing my training, I began job hunting and secured my first position at a well-known local search engine. There, I developed my testing skills while continuing to seek opportunities in fintech. A couple of months later, EXANTE reached out to me.

The company, at the time, was looking for a junior QA tester who would be passionate about testing and would have an advanced understanding of trading terminals and trading itself — so they found me. I was seeking a company where I could kickstart my QA career in an area that truly interested me — and I found it.

Part 1: The Winding QA Path

“Hands-on” with the Front End

For the first two years, I managed typical manual QA duties on the frontend, including:

• Test design

• Various forms of testing — requirements, regression, integration, and acceptance testing

• Maintaining the wiki

• Participating in all calls, communication and planning sessions.

Initially, my focus was on a single project — mobile applications. I thoroughly enjoyed the product, studying it in great detail and noting even the slightest deviation from expected results. My enthusiasm for quality significantly reduced the number of incidents in production, which did not go unnoticed. Gradually, I expanded my testing to include all other terminals — desktop and web. My frontend expertise grew rapidly, allowing me to influence the quality of all trading terminals. With each performance review cycle, I was entrusted with more responsibility across more projects.

“What’s inside?”

I started asking this question more often, which sparked a desire to go beyond just “touching” the front end of applications. The architecture of many of our projects is complex, often involving 3 or 4 internal services for end-to-end tests. As a result, I delved deeper into integration testing, aiming to identify the primary information source. My goal was to fully understand the project and help localize issues originating from production. This led me to interact more with backend developers and architects.

At one point, I approached my manager inquiring about the opportunity to test backend components. Although I wasn’t ready to leave the frontend team, I was worried I wouldn’t be allowed to work in both areas. However, my concerns were unfounded. I was heard, understood, and offered a compromise that satisfied everyone. I transitioned part-time from the interface QA department to the backend team for a couple of months.

This arrangement turned out to be a win-win situation:

• On the front end, I continued to diligently perform all required tasks,

• On the backend, my hours were counted on for task testing during scope planning,

• I satisfied my interest in internal projects while enhancing my hard skills (and soft skills too, as backend specialists tend to be more introverted).

Leadership

After nearly three years of working with trading terminals at EXANTE, I was entrusted with leading a small team of testers for desktop and web trading terminals. My new responsibilities included:

• Continuing to participate in project testing, though less actively;

• Focusing more on team development by providing both moral support and expertise;

• Assisting in expanding the testing team through interviews and candidate assessments;

• Mentoring newcomers;

• Writing project documentation, FAQs, and developing internal wikis for future generations.

Ultimately, my focus shifted from the product to the team. However, in less than a year, I realized I wanted to refocus my attention on the product itself — its content, appearance, and functionality.

Part 2: Transition to Product and a Complete Change of Activities

Start

At EXANTE, the product-oriented development phase was in full swing. A dedicated department had been established, assembling a product team responsible for multiple projects. Internal recruitment was prioritized before seeking external assistance. The department head took notice of me because:

• I consistently demonstrated passion for the project, frequently offering sound suggestions to enhance existing functionality, UX, and design.

• I pitched new product ideas.

• I bridged the gap between customer needs and technical requirements, ensuring clear communication between creative concepts and development teams.

These seemingly small steps produced results. The department head, along with top management representatives, suggested that I move from the QA department to the product owner team.

Experiment

I lacked previous commercial product management experience and was apprehensive about transitioning without the requisite knowledge, understanding of processes, and direct responsibilities. Moreover, I couldn’t simply abandon the QA department overnight. I expressed these concerns during a meeting with management while discussing potential obstacles to the transition.

Together, we decided to experiment: I handed over the entirety of testing responsibilities to the QA team and utilized the newfound time to fully immerse myself in product responsibilities. Initially, the split was 70% leadership duties and 30% QA, but within a month, it balanced out to 50% for each.

The experiment lasted just under six months, and in the end, I confidently realized that Product Management was a path I wanted to pursue further.

Once again, it turned out to be a win-win situation:

• As a leader, I continued to diligently fulfil all required tasks.

• Within the developing product team, I began handling basic and sometimes entire discovery assignments.

• I overcame my fears, learned extensively, and prepared myself for new responsibilities.

Expectation vs Reality

The scope of tasks in product management at EXANTE differs significantly in volume and variety compared to classic descriptions found in books such as Kagan’s “Inspired” or Perry’s “Product Management for Dummies.”

While traditional books list tasks like market research, hypothesis testing, justification of business value for proposed features, close collaboration with designers, and collecting production feedback, our product team also emphasizes several additional major tasks.

Here are the key tasks I’ve been involved in:

• Detailed elaboration of tasks and setting requirements for developers.

I create detailed documents with behavior descriptions, BPMN diagrams, and references to prototypes of internal backend services. Why?

Firstly, it prevents developers from distracting themselves and spending extra time researching possible integration methods. Secondly, as the feature owner, I can ensure that the concept will be implemented according to the initial requirements.

• Continuous interaction with development and QA at all stages of the feature lifecycle.

A product manager is best positioned to understand how a feature should work and why. In case of technical implementation issues, we consider alternatives. What does this provide? Cohesion within the team, because everyone knows what and how things should work, and if they don’t know — there’s always a unified source of information shared by all.

• Description of features for internal employees.

Features are described not only as specifications for development but also as product descriptions for internal employees. This serves as an excellent basis for colleagues involved in creating customer instructions later on.

• And some others, which are in one way or another related to the three main points above.

Additionally, I’ve encountered a high volume of daily calls, which initially posed a challenge. However, we effectively reduced call durations while maintaining productivity through a structured agenda. Each call now follows a planned agenda, even if brief, and we meticulously document action items to ensure the outcomes of our discussions are not lost.

As a result, I’ve been able to structure the processes themselves and influence the overall flow and results of feature development. What stands out to me here:

• Reduced delivery time for features. Due to slightly increased discovery time, delivery time for features has been reduced without changing the overall estimate. From a budget perspective, it has become more cost-effective because detailed elaboration helped save developers’ time.

• Thorough documentation in Confluence. Features are now thoroughly described in Confluence, allowing any employee to log in and see how a feature operates.

• Consistency across platforms. The same feature operates on all terminals according to the same logic, even in corner cases, ensuring consistency where needed.

• More productive calls. Calls on any topic have become shorter and more productive, thanks to agendas and the documentation of decisions made.

Every week, our product team convenes to discuss ongoing plans for departmental growth, process improvements, communication strategies, common features, and various other aspects of our work. I feel I have something valuable to contribute to each of these aspects.

Our approach to product management diverges from the traditional model. I see the tangible results it brings — personal growth opportunities for me as an employee, streamlined and clearer workflows for the team, and enhanced potential for the product I am passionate about and help shape.

Conclusion

What I wanted to convey with all of this is: Growth within a company is always possible; you simply need to take action to thrive. It may sound simple, but sometimes, even obvious truths need to be emphasized. If you aim to grow — whether upward or horizontally — here are the key principles to consider:

• Be proactive and show initiative. Companies value engaged employees who go beyond their job descriptions.

• Cultivate a deep interest in the product beyond the basics. Mastering your role is essential, but expanding your expertise requires deeper exploration.

• Continuously develop yourself. Seek knowledge through conversations with experienced colleagues, reading books, listening to podcasts, blogs, and taking courses. Time for development can always be found, and many companies provide resources for this purpose.

• Stay passionate about your project. Long-term success is fueled by genuine interest and motivation in the product you work with.

• Don’t hesitate to communicate with management about your career aspirations. Discussing your goals can lead to opportunities that benefit both you and the business.

P.S. I understand that not everyone may agree with what I’ve written. This isn’t an instruction manual but rather notes on my personal journey with the product and my perspective on how growth should be approached — and how it has worked for me in my company.