Who Is a Product Manager: An Interview with a Traffic Squad Product Manager

Hi! Thank you for the invitation :)

Starting from the beginning — I'm from a small town called Borova, population 8,000, and I always wanted to "make it out into the world." I was an illustrator, but purely for myself — drawing for pleasure. It was and still is my way of switching off for a while.

Before affiliate marketing, I tried a lot of different things: I had my own online store, worked as a researcher at an outsourcing company, as a sales marketer, a PR specialist at a US startup, and even as a designer at a PR agency. 

On the side, I freelanced as a translator, hosted foreign guests at fashion week in Kyiv, and generally helped organize festivals and events. I absolutely love that kind of buzz.

TS wasn't my first :) Everything I know about affiliate I learned at the CPA network Cpamatica, where I worked as a brand manager. I still love and support them to this day. Those were an incredible 5.5 years.

I gradually learned about different verticals, the specifics of the market, and managed a few affiliates. TS were actually my partners at the time — I found Sit (ed. TS owner, Vitaliy Sytovskyi) in the network and reached out with a collaboration proposal. We've been friends ever since :)

We knew each other well — how the other worked, what skills they had. After Cpamatica, I was looking for new challenges, and Sit called me and said, "We have an idea for a project — do you want to run it?" For context: I had no management experience, no hiring experience either, and here I needed to do everything at once, in a vertical I hadn't specialized in, and on top of that in a market I knew absolutely nothing about. 

In short — complete uncertainty. At the time, I had an offer on the table from a well-known company with clearly defined tasks and "stability." But who needs that kind of stability. You jump in and figure it out as you go. I chose the project where nothing was clear but everything was exciting. And I'm grateful to Sit and TS for their trust and belief that it would all work out.

Like most managers — everything :) A product manager is responsible for the vision, creation, and development of the product. That's the core of it. Developers, analysts, designers, and QA engineers all support that work.

Most of my time I work with developers — coming up with features, products, defining how things should work, writing specs, digging through APIs, code, and services.

All tasks come from stakeholders: TS leadership or individual department heads. We discuss ideas, sign off on functionality, and then I plan the development with my team. I call them into a meeting, say "we've got a new product," and we break it down into details.

When it comes to tools, I can't imagine working without JIRA, Confluence, Figma, Slack, and Google Meet. These are a must for planning, communication, and keeping track of what's happening in the project. Services like Gitlab, Postman, and Sentry are also helpful — they cover the technical side of the products.

For me, these are qualitative metrics. For example, "release feature A by December 1st" or "build a product for buyers that helps them with something specific." There can also be quantitative ones — for instance, increasing data processing speed by 2x.

Honestly, not really — the development process is the same. A well-structured media buying company is just as much an IT project as any other. I talk to colleagues from other companies and our processes are barely any different. The main distinction, if anything, is the speed of feature releases. At large teams, shipping a feature can take a week, whereas for us it might be 1–2 days — simply because there are fewer approval stages and less bureaucracy.

Partly what I mentioned in my previous answer. I see the affiliate industry as a fully-fledged IT space — one with fewer shady operators and more competent professionals who know what they're doing and approach their work thoughtfully, where there are no shady schemes and honest work is the norm.

Through our own example, we're trying to push the market in that direction. It's a bit utopian, perhaps, but looking at the smart teams emerging right now, I genuinely believe it's achievable.

For a long time I was doing things the way they were supposed to be done "correctly." But I realized that's a narrow-minded way of thinking. By non-standard thinking, I mean that any task or situation has multiple ways to solve it. 

At school, we were taught that if there's a problem, there's one correct solution. In the life of a product manager — or any manager, really — that's not how it works. We need to be able to find 10 different solutions and process chaotic information, then structure it.

Example 1. Your CEO comes to you and spends 15 minutes talking about a new product idea or feature, then starts referencing fragments of conversations with other people, then mentions running into a friend at a conference who was talking about the same thing. There's an overwhelming amount of information, and you're sitting there completely fried. The conversation ends, and from all of that you draw one conclusion: "research the feature, estimate its cost and user demand." That's how your product manager brain needs to be able to bring order to the chaos of incoming information and extract what actually matters.

Example 2 (a simple one). You're tasked with conducting market research and presenting it. You could deliver it as a dry report in a Google Doc with numbers, charts, and so on. Or you could help your audience actually retain that information by putting together a vivid in-person presentation, highlighting the key figures and takeaways, and delivering it as a stand-up. Here you're thinking about the consumer and not just doing what's "correct" or what everyone's used to.

Well, it's not always strictly micro-tasking. It really depends on how much you trust your team. I can give a tech lead a high-level description of a feature and they'll execute it the right way. But when there's a detailed request from someone on the team to implement functionality in a specific way, that's when I write out a detailed specification.

Oh, this one. My favorite, because I get asked it all the time :) A product manager is more focused on strategy, consumer needs, and the market: conducting interviews, analyzing large volumes of data, and so on. 

A product owner is focused on product delivery — managing the backlog, running retrospectives, and prioritizing tasks. Since my team works for an internal department, we're more focused specifically on the products themselves.

Every business has its own specifics) Detailing has its nuances, AI products — theirs too. There are always details you need to account for. And just like in any industry where you're building process automation, you have to understand those processes. 

From how and where accounts are purchased, to how advertisers send invoices. When we were building account management automation, I had to learn everything under the hood — traffic buying with antidetect browsers, moms, kings, account sourcing, and cloaking. 

For upcoming tasks, I even took a Facebook traffic buying course by Myroslav Lyaskovets. And on top of that, I was partly an affiliate manager, so I know how everything works on the advertiser side. So yeah — I know my stuff :)

Media buyers often don't know how things could be done better. They're used to cobbling something together on the fly, for $0. When we present a feature that makes their work easier, saves time or resources — they're absolutely receptive to it.

When it comes to actual products, it goes like this:
1. Either the CEO, COO, or CRO comes to me saying "Kate, I've got an idea," or I go to them with the same line.
2. I do research and run the idea through three filters:
- Reality check (does this idea solve a real problem)
- Economy check (how much will it cost to build and how much profit will it generate, market and competitor analysis)
- Feasibility check (do we have the knowledge, technology, and resources to execute it).
3. I discuss the idea with the team and do high-level planning — how we'll implement it, how long it'll take, how many people are needed, and the technical specifics.
4. I align timelines and details with the stakeholder (CEO, COO, or CRO).
5. I write the technical specification.
6. We review the feature set with the team again based on the spec.
7. I write user stories and tasks for the team in Jira, and we kick off development on the planned date.

First, I talk to the product owner to understand their vision of the end result — what blocks should be there, what features, and who the users are. That can take more than one meeting. I research whether something like this already exists on the market (but most of the time it doesn't). 

Then I go to each of the users and run what's called a customer development session — I set up a meeting, bombard them with questions, ask them to show how they currently solve a particular problem and what would feel most convenient for them.

When we were building the CRM for media buyers, I held meetings with several teams, asked what they'd want to have, what functionality was a must-have, and so on. And I validated my hypotheses for viability.

Just one, I'm afraid.

Can't say, sorry)

The first and most significant optimization we had was around the number of tasks completed by farmers. The faster they complete tasks, the faster buyers can operate and have everything they need to run traffic.

Previously, we were handling around 800 tasks per month. Now, with automation, it's over 2,000. And where we used to have a team of 10 farmers, we now have 5. There's simply no need for that many people anymore. Through optimization, a smaller team can handle a much larger volume of tasks.

Buyers can now get an offer link in two clicks in real time, check the current cap, and start running traffic. If adding an offer to trackers used to take around 40 minutes, now it's a single click.

I can't) Every person in the process matters and plays their role. We're all pieces of one whole, working together.

What matters isn't the company, but the skills you gained there, what you learned, and what results you delivered. At TS, we focus more on soft skills. Because teaching someone arbitrage is far easier than, say, teaching them how to communicate with advertisers, speak English, or think critically. You can go from being a construction worker to a team lead (no offense to construction workers).

I believe we never truly start from scratch. You start from the experience you've built through previous work, education, or life situations. And depending on the project and the tasks at hand, any experience can be valuable. So a hard reset is a very rare thing.

Turbulence in the affiliate industry is a permanent fixture. Constant. We've been operating under instability and randomness for years — so it doesn't scare us.

Looking at the general product management market, a PM's salary range can start from $1,000–1,500. And there's really no ceiling.

For me, the best rest is a change of activity. And even better — a change of scenery. I try to switch to other things: home renovation, volunteering, learning, my own small pet projects or art, heading out of the city or to a spa resort of sorts. 

At this point in my life, I genuinely consider a trip to a spa resort a top-tier idea or an absolute f**king gift. Sports take up a lot of my time, and that's the time I dedicate entirely to myself — I disconnect and focus on what my body feels. I love that state.

On the hard skills side: research skills, conducting interviews, strategy building, product economics, a basic understanding of development stages, project technical architecture, design principles, and testing. Just for starters :)

As for soft skills, it's enough to not be a toxic a** and to know how to communicate :) Jokes aside: proactivity (a must), strong communication, empathy, results orientation, team management, critical thinking, and helicopter view (ed. the ability to look at problems from multiple angles). 

And logic — if you can't see cause-and-effect relationships, don't even try until you've worked on that.

It can be a big plus, but it's not a mandatory requirement. I also went and learned traffic buying myself, and I think it's incredibly valuable when a product manager understands all the processes. A little bit of a designer, a little bit of an analyst, a little bit of a developer and a media buyer. I can take it upon myself to test an API request, design a landing page, or run analytics.

The problem is when someone becomes a product manager without having any clue about the business, traffic buying, or basic tech — and just throws abstract tasks at the team. What do you even do with that person? All you can do is give them a hug and cry.

That I work in marketing and travel to conferences all over the world :)

It depends on the context and my mood. If I'm on a date or out with friends, I just relax and don't focus on it. If I'm burned out, I try even harder to switch off. But product thinking does bleed into your everyday life a bit — that's true. I wouldn't say it's specifically about a restaurant case, since there are all sorts of nuances there that people can feel differently about.

But as a user and a customer, I notice where the registration funnel could be simplified, where a site is a drop or freshly launched — you spot all the bugs and know how to fix them. I don't send unsolicited advice to those sites, but if something is critical, I do reach out.

Recently there was a case with one conference where the database was openly accessible from the website and you could edit all the data. Of course, I immediately contacted the organizers — and they sorted it out.

Ugh, why would you ask that! Probably a year without optimizations. I can always just build some charts and bots. But travel — that's non-negotiable :)