Piotr Wiśnioch has several years of experience working as a Product Manager. He currently works at BinarApps, a software house based in Łódź.

Grzesiek: Hi Piotr, first of all, thank you for wanting to talk with me and share your experiences. Tell me how it all started.

Piotr: Hi, thanks for the invitation! It all started over 5 years ago in Łódź. I was sitting peacefully on the sidelines, at a desk rented from BinarApps, creating interactive exhibitions and city games. I started observing them even back then. BinarApps had 8 people when it started. I joined the software house when it had 50 people. The company now has 200 employees.

I started as a Project Manager (because that’s what they needed). Those were still beautiful times when you didn’t need 6 years of project experience and IT experience. Initially, we created products at the client’s dictation rather than based on user needs. This caused major problems with such clients later on. It motivated me to implement a “unit in the company” that additionally handled client needs analysis—an extra consulting service. Our department is responsible for understanding what the client really needs, sometimes challenging what they want—being a smart critic, a partner. Not just technologically, but also from a business perspective.

Currently our department has seven consultants and seven designers. With each of our clients, we conduct a so-called “zero workshop” where we try to learn about their needs and motivations. We show how we work, and only then do we create a proposal that we present to our clients. We’re not like 90% of software houses that jump straight into delivery. Most of our clients have been with us from the beginning because we care about value.

Of course, sometimes a client gets stubborn and refuses to cooperate. They think they’re the smartest and don’t need to discuss their clients’ problems. This approach usually ends very badly.

Grzesiek: What changes in a software house when the company scales from 50 to 200 people?

Piotr: When a company’s scale increases, the scope of client expectations grows proportionally. Clients expect the company to be professional, not amateurish—it matters not only that something works technically, but also that the end users for whom our client builds will want to use the solution.

Having just developers isn’t enough anymore. You also need designers, marketers (who can advise on go-to-market strategy and run campaigns for clients). We combine all these competencies and depending on the project stage we’re handling, we can address them appropriately. This makes us more professional.

Grzesiek: What are you responsible for as a Product Manager?

Piotr: In a software house, each of these seven consultants isn’t 100% dedicated to a single project. I have projects where I’m more in an analyst role, but I also have ones where I support the development team or conduct only discovery work. It’s quite a challenge not to waste time context-switching between projects.

As a Product Manager, I’m currently responsible for a product that allows distributing video clips on film sets—fairly complex. In my team I have iOS developers, backend developers, QA testers, a designer, and an analyst, so you could say it’s a cross-functional team.

My main task is to validate hypotheses with users and deliver appropriate features on time according to established timelines. You first have to ideate, validate, plan, and work through the problem. I run workshops with users to learn what problems they have and how we can solve them through implemented features.

Grzesiek: What methodology do you use in your company?

Piotr: There’s no top-down requirement that you must work in Scrum, Kanban, or any other agile approach. The most important thing is that we deliver things effectively. Clients need concrete results in a specific timeframe and budget—it sounds like a typical constraint, but we try to maintain flexibility in all this.

In several projects we work in monthly cycles because we determined that’s the optimal timeframe for us to deliver something that can be a feature and bring value to clients. We tried shorter cycles (2 weeks), but unfortunately it didn’t work out. During the month we set a base scope and extended scope. Base scope is something that brings users the desired value, while all additional elements are nice-to-have and fall into the extended scope. After two weeks we check where we are and what we’re doing: we adjust the scope (while still delivering value) or stay on track. Then after a month we do a release, followed by a week of “cleanup.” During this time we do some analytical or technical spikes and refine the scope for the next cycle.

Grzesiek: Do other things fall into this cycle? Any surprises?

Piotr: We work closely with a given client, so if we agree on a specific feature, new/different things don’t get added because we have a different goal. Of course in practice it looks a bit different because the product is constantly evolving and if a bug comes up during a sprint, we always check the priority and criticality of the issue to decide whether to add it to the sprint or backlog. If we add it to the sprint, we need to decide what gets removed from the scope we committed to. Usually we don’t touch the main scope—only the additional one (extended scope).

Leave a comment

Grzesiek: What was your biggest challenge in your product role working in a software house?

Piotr: I’ll talk about two. One is specific to software houses, the other to the product role. I’ll start with the software house challenge. Generally, a software house lives off its clients—we need many clients and many people who can deliver value to those clients. In our case (the product role), we’re very often assigned to multiple projects at once, which sometimes means we lack focus due to frequent context changes. Lack of focus causes us to make mistakes sometimes. To reduce mistakes, we work in pairs—we have a captain and a so-called wingman. One person leads the project while the other acts as a sparring partner.

The second challenge is that clients often want to see results right now and it’s very hard to explain to them that value comes from organized work. They don’t understand the need for a Product Manager. Currently this is changing significantly because clients are becoming increasingly aware that it’s worth investing more time to think before we move into the execution phase.

Grzesiek: What are the top 3 skills a person should have if they want to become a Product Manager in a software house?

Piotr: I think the ability to earn respect from developers and build an internal team based on relationships and authenticity. Second is the ability to treat the client as a person with needs, not as just another person coming with their problems. Third is time management and working in a structured way—combining different threads in a way that won’t drive you crazy—because you do have multiple projects at once, and a day only has 24 hours.

Grzesiek: So how do you stay productive and manage your time properly so you don’t go crazy?

Piotr: The worst thing that can happen is constant context switching—I read once that a person needs a minimum of 20 minutes to switch to another task. So I try to block calendar slots that allow me to enter FLOW mode and work effectively. These slots have the names of the topics I’m trying to figure out.

Another thing is how I take notes on my thoughts. For me, a pen and paper work best. I also use Remarkable because I can easily digitize what I have on “paper.”

I really like arranging things backwards—so-called reverse engineering. For example, if I know a feature should look a certain way, I start from the end—if the user clicks a button at the very end, I think about what must come before it, what must come before that... and I work my way back to the beginning.

It’s also worth finding during the day the time interval when you work best—mine is from 6 PM to midnight. Each of us has such a slot.

As for tools, I use products like Asana for managing various projects, Airtable for interviews, Miro for online workshops, Notion for notes, and a Remarkable tablet for jotting down thoughts. It all serves working notes. The end result is a Confluence page that pulls it all together and you can easily refer back to it—it’s the single source of truth for us and the client.

Grzesiek: Can you share an interesting place on the internet you regularly visit and learn from?

Piotr: I read Teresa Torres’ blog passionately because it helps me develop my discovery skills. Recently I also came across growth.design, which presents various case studies in a graphic way—really great stuff.

Grzesiek: Last question. What would you recommend to people who want to start their career in Product Management?

Piotr: I’d definitely recommend looking at apps we use every day and asking yourself “How did they do that? Why this way and not another?”—pure curiosity. You can even skip the digital stuff and think about the devices we have at home—like a robot vacuum—and wonder how it works.

Another way is to practice our product thinking, which lets us present our vision of a given process, like buying a train ticket. The idea is to force yourself to think and ask the right questions: “How would I change this process? What would I improve?”

This really helps later when working with different clients—it teaches product thinking, which is very important in daily work.

Grzesiek: Thanks for a valuable conversation!

Piotr: Thanks!

If you enjoyed this interview, click the 💙 and leave a comment.

If you’re not yet part of the Product Art community, I invite you to subscribe.

🇵🇱 Wersja polska / Polish original

Piotr Wiśnioch ma kilkuletnie doświadczenie w pracy jako Product Manager. Obecnie pracuje w łódzkim Software House - BinarApps.

Grzesiek: Cześć Piotr, na wstępie dziękuję, że chciałeś ze mną porozmawiać i podzielić się swoimi doświadczeniami. Opowiedz jak to wszystko się zaczęło.

Piotr: Cześć, również dziękuje za zaproszenie! Wszystko zaczęło się ponad 5 lat temu w Łodzi. Siedziałem sobie spokojnie z boku, przy wynajmowanym od BinarApps biurku i tworzyłem interaktywne wystawy i gry miejskie. Już wtedy zacząłem ich obserwować. W BinarApps pracowalo 8 osób. Ja dołączyłem do Software House, gdy miał 50 osób. Obecnie w firmie pracuje 200 osób.

Zacząłem jako Project Manager (bo takiego potrzebowali). To były (jeszcze) piękne czasy gdy nie trzeba było mieć 6 lat doświadczenia w pracy z projektami i doświadczenia w IT. Na początku tworzyliśmy produkty pod dyktando klienta, a nie pod potrzeby użytkownika. To wszystko powodowało, że później było bardzo dużo problemów z takim klientem. Skłoniło mnie to do wdrożenia “komórki w firmie”, która dodatkowo zajmowała się analizą potrzeb klienta - taka dodatkowa usługa konsultingowa. Nasz dział jest odpowiedzialny za to żeby zrozumieć o co chodzi klientowi, czasami podważyć to co chce - być takim mądrym krytykiem - partnerem. Nie tylko technologicznym, ale też biznesowym.

Obecnie w naszym dziale jest siedmiu konsultantów oraz siedmiu designerów. Z każdym z naszych klientów odbywamy tzw. “warsztat zero”, w trakcie którego staramy się dowiedzieć o jego potrzebach i motywacjach. Pokazujemy jak pracujemy,a dopiero później tworzymy ofertę, którą przedstawiamy naszym klientom. Nie jesteśmy jak 90% Software Housów, które od razu przechodzą do delivery. Większość naszych klientów jest z nami od samego początku bo dbamy o wartość.

Oczywiście czasami zdarza się, że klient się uprze i nie chce współpracować. Myśli, że jest najmądrzejszy i nie potrzebuje rozmawiać o problemach z klientami. Takie podejście najczęściej kończy się bardzo źle.

Grzesiek: Co się zmienia w Software House gdy firma skaluje się z 50 do 200 osób?

Piotr: W momencie w którym wzrasta skala firmy, wprost proporcjonalnie wzrasta też skala oczekiwań klientów wobec danej firmy. Klient oczekuje, że będzie profesjonalna, a nie chałupnicza - chodzi o to, że nie tylko zależy mu na tym, że coś będzie działało w kontekście technicznym, ale też że, klienci dla których buduje nasz klient, będą chcieli używać tego rozwiązania.

Nie wystarczy już tylko posiadać deweloperów. Trzeba mieć też designerów, marketingowców (którzy podpowiedzą jak stworzyć strategię GTM i np. poprowadzą kampanię dla klienta). Łączymy te wszystkie kompetencje i w zależności od etapu projektu, którym się zajmujemy - możemy je odpowiednio zaadresować. To powoduje, że jesteśmy bardziej profesjonalni.

Grzesiek: A za co jesteś odpowiedzialny jako Product Manager?

Piotr: W software House, każdy z tych siedmiu konsultantów, nie jest dedykowany w 100% do jednego projektu. Mam takie projekty, w których jestem bardziej w roli analityka, ale mam też takie gdzie jestem wsparciem zespołu deweloperskiego lub prowadzę tylko discovery. To jest dość duże wyzwanie, aby nie tracić czasu na przełączania się pomiędzy projektami.

Jako Product Manager jestem obecnie odpowiedzialny za produkt, który pozwala dystrybuować klipy na planie filmowym - dość skomplikowany. W zespole mam iOS developerów, BE developerów, Testerów QA, designera i analityka więc można powiedzieć, że taki zespół cross funkcjonalny.

Moim głównym zadaniem jest zwalidowanie hipotez z użytkownikami i dostarczenie odpowiednich featerów na czas zgodnie z wcześniej ustalonymi timeline’ami. Trzeba najpierw wymyślić, zwalidować, zaplanować i rozpracować problem. Prowadzę warsztaty z użytkownikami, aby dowiedzieć się, jakie mają problemy i jak możemy je rozwiązać, za pomocą zaimplementowanych później funkcjonalności.

Grzesiek: W jakiej metodologii pracujecie w firmie?

Piotr: Nie ma odgórnego wymogu w firmie, że musisz pracować w Scrumie, Kanbanie czy w jakimś innym podejściu zwinnym. Najważniejsze jest to, abyśmy dostarczali rzeczy skutecznie. Klienci potrzebują mieć konkretny efekt w konkretnym czasie, w konkretnym budżecie - brzmi jak typowy fix, ale staramy się zachować elastyczność w tym wszystkim.

W kilku projektach pracujemy w miesięcznych cyklach bo ustaliliśmy, że to dla nas optymalny czas, aby dostarczyć coś co może być feater’em i przynosić wartość dla klientów. Próbowaliśmy z krótszym czasem (2 tygodnie), ale niestety nie udawało się. W trakcie tego miesiąca określamy sobie base scope i extended scope. Base scope to coś co przyniesie użytkownikowi pożądaną wartość, a wszystkie dodatkowe elementy są nice to have i zawierają się w extended scope. Po dwóch tygodniach sprawdzamy gdzie jesteśmy i co robimy: zmieniamy zakres (ale żeby nadal przynosił wartość) czy jesteśmy “on track”. Następnie po miesiącu robimy wydanie, a potem mamy tydzień na “sprzątanie”. W tym czasie robimy jakieś spike analityczne lub techniczne i dogrywamy zakres na kolejny cykl.

Grzesiek: Czy w tym cyklu wpadają jakieś inne rzeczy? Jakieś wrzutki?

Piotr: Pracujemy blisko z danym klientem, więc jeśli umawiamy się z nim na daną funkcjonalność to nowe/ inne rzeczy nie wchodzą bo mamy inny cel. Oczywiście w praktyce to wygląda trochę inaczej bo produkt cały czas żyje i jeśli wchodzi jakiś bug w trakcie sprintu to zawsze sprawdzamy priorytet i krytyczność danego zgłoszenia, aby zadecydować czy wrzucamy go do sprintu czy do backlogu. Jeśli wrzucamy go do sprintu to musimy zastanowić się co zostanie usunięte z zakresu do którego się zacomittowaliśmy. Zwykle nie ruszamy tego głównego zakresu, tylko ten dodatkowy. (extended scope).

Leave a comment

Grzesiek: Jakie było Twoje największe wyzwanie w roli produktowej pracując w Software House?

Piotr: Opowiem o dwóch. Jedno dotyczy stricte Software House, a drugie roli produktowej. Zacznę od SH. Generalnie SH żyje z klientów - musimy mieć dużo klientów i dużo ludzi, którzy są w stanie dostarczyć wartość dla tych klientów. W przypadku naszej roli (produktowej) jesteśmy bardzo często przypisywani do wielu projektów na raz, co powoduje czasami, że brakuje czasu na skupienie ze względu na częste zmiany kontekstu. Z kolei brak skupienia powoduje, że czasami popełniamy błędy. Aby zmniejszyć ilość błędów, działamy w dwójkach - mamy kapitana i tzw. skrzydłowego. Jedna osoba prowadzi projekt, a druga jest trochę jak taki sparing partner.

Drugim wyzwaniem jest to, że często klienci chcą widzieć efekty tu i teraz i bardzo ciężko jest wytłumaczyć im, że wartością jest uporządkowana praca. Nie rozumieją potrzeby posiadania Product Managera. Obecnie to się mocno zmienia bo klienci są coraz bardziej świadomi tego, że warto poświęcić więcej czasu, aby pomyśleć, zanim przejdziemy do etapu robienia.

Grzesiek: Jakie są top 3 umiejętności powinna posiadać osoba, która chce zostać Product Managerem w Software House?

Piotr: Myślę, że umiejętność zdobywania szacunku developerów i budowanie wewnętrznego zespołu w sposób oparty na relacji i prawdziwości. Druga to umiejętność traktowaniu klienta jako człowieka w potrzebie, a nie jako kolejnej osoby, która przychodzi ze swoimi problemami. Trzecia to umiejętność zarządzania czasem i pracy w sposób ustrukturyzowany czyli łączenia różnych wątków w sposób, który nie pozwoli Ci zwariować - bo jednak masz kilka projektów na raz, a doba ma tylko 24h.

Grzesiek: Zatem jak być produktywnym i odpowiednio zarządzać czasem, aby nie zwariować?

Piotr: Najgorsze co może się wydarzyć to ciągłe zmiany kontekstu - czytałem kiedyś, że człowiek potrzebuje minimum 20 min czasu, aby przełączyć się do innego zadania. Staram się zatem blokować sobie sloty w kalendarzu, które pozwolą mi wejść w tryb FLOW i pracować efektywnie. Te sloty mają nazwy tematów, które próbuje rozgryźć.

Kolejną rzeczą jest sposób notowania moich myśli. U mnie najlepiej sprawdza się długopis i kartka papieru. Stosuje też Remarkable bo w prosty sposób mogę od razu zdigitalizować to co mam na kartce “papieru”.

Bardzo lubię układać sobie rzeczy od tyłu czyli tzw. reverse engineering, np. jeżeli wiem, że funkcjonalność ma wyglądać w taki,a nie inny sposób - to sobie idę od tyłu - jeżeli user na samym końcu klika w dany przycisk, to zastanawiam się co musi być wcześniej, co musi być jeszcze wcześniej…i tak dochodzą do samego początku. ‘

Warto też znaleźć w trakcie doby przedział czasowy w którym pracujemy najlepiej - ja mam taki okres od 18 do północy. Każdy z nas ma taki slot czasowy.

Jeśli chodzi o narzędzia, to korzystam z produktów takich jak Asana do zarządzania różnymi projektami, Airtable do wywiadów, Miro do warsztatów online, Notion do notatek oraz tablet Remarkable do notowania myśli. To wszystko służy do tzw roboczych notatek. Efektem końcowym jest strona w confluence, która zbiera to wszystko w całość i można w łatwy sposób do niej wracać - jest jedynym źródłem prawdy dla nas i klienta.

Grzesiek: Możesz podzielić się jakimś ciekawym miejsce w internecie, które regularnie odwiedzasz i czerpiesz wiedzę?

Piotr: Czytam namiętnie bloga Teresy Torres bo pozwala mi to rozwijać swoje umiejętności związane z discovery. Ostatnio również trafiłem na stronę growth design, która przedstawia w sposób graficzny różne kejsy - super sprawa.

Grzesiek: Ostatnie pytanie. Co byś polecił osobom, które chciałyby rozpocząć swoją karierę w Product Management?

Piotr: Na pewno poleciłbym, aby spojrzeć na aplikacje, które używamy na co dzień i zastanowić się “Jak oni to zrobili?, Dlaczego tak, a nie inaczej” czyli taka czysta ciekawość. Można nawet olać ten cały digital i podumać nad sprzętami, które posiadamy w domu - np. robot sprzątający - i zastanowić się jak działa.

Innym sposobem jest próba ćwiczenia naszego produktowego myślenia, która pozwoli nam przedstawić naszą wizje danego procesu np. zakup biletu do pociągu. Chodzi o to, żeby znowu zmusić się do myślenia i zadawania odpowiednich pytań: “Jak bym zmienił ten proces? Co bym w nim ulepszył?”.

To bardzo pomaga później w przypadku pracy z różnymi klientami - uczy produktowego myślenia, które jest bardzo ważne w codziennej pracy.

Grzesiek: Dzięki za wartościową rozmowę!

Piotr: Dzięki!

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.

Damian Winczewski works at STXNext, Europe’s largest Python Software House, as Head of Agile Center of Excellence.

Grzesiek: Hi Damian, thanks for taking the time to chat with us. Could you introduce yourself and tell us what you do?

Damian: Hi Grzegorz, I currently work at STX NEXT as Head of Agile Center of Excellence—I’m the direct line manager for Product Owners and Scrum Masters. Over the past three years, I’ve held various roles in the organization, including Product Owner, Scrum Master, and consultant. Eventually, we came up with the idea to optimize this internal company product, and I became the “Product Owner” of the Agile Center—that’s how this new department came about. Since January this year, we’ve been developing it with the goal of advancing our product-building approach and soft collaboration with clients.

Grzesiek: That sounds like a serious responsibility for the organization. Can you tell us more about it?

Damian: When I started, we had 29 people on the team. At that point, I could still manage it and meet with everyone at least once a month. Now we have over 40 people, and we’ve “streamlined” the structure. We introduced an additional role of Agile Team Leaders who took over the responsibility of supporting people’s development and conducting one-on-ones with them.

This allows me to focus on what we can offer our clients—what new services we can provide, like product analytics, for example.

Grzesiek: Can you tell us more about the structure? Who makes up these 40 people?

Damian: Currently, I have 3 Agile Team Leads. Each Agile Team Lead has their own team of about 15 people, and the roles (Product Owner, Scrum Master) and experience levels in these teams are diverse so that each team can solve problems independently. Our goal is to solve our clients’ challenges in an agile way.

Grzesiek: So if I understand correctly, each Product Owner has their own cross-functional team?

Damian: Yes, the POs work on client products—unless we have some internal product, but that’s rare.

Grzesiek: As a Software House, do you specialize in any specific domain?

Damian: We’re Europe’s largest Python Software House. Of course, there are other technologies that support this, and sometimes we go in a completely different direction. But Python is our foundation—it allows us to develop products quickly and with high quality for clients around the world, from the United Arab Emirates through Germany and the UK to the United States.

As for products, there’s quite a wide range—from the events industry to steel manufacturing to finance and crypto. I think we could find something in almost every sector.

Grzesiek: Do you have Product Managers or Product Owners?

Damian: For us, PM and PO are the same role. We believe the competencies of both roles are actually identical, so regardless of what our client wants to call the role, we try to cover both areas. Our POs are also involved in creating discovery work, strategy, and roadmaps. Each Product Owner is assigned to only one PRODUCT—with emphasis on product, not project, because we build products, not projects. The exception is fixed-budget products, where one PO might work on two products—but that happens quite rarely because we still don’t want to mindlessly deliver features; we want to solve our clients’ problems. We mostly work in Scrum.

Grzesiek: Can you walk us through the process from when a client arrives to when you deliver a solution?

Damian: We have different paths because clients come to us either with an idea or with an existing product. The latter group is looking for support in developer resources. Very often the product is internal to their company—in that case, we accept their “expertise” and move to the delivery phase, but we carefully review the features being delivered.

On the other hand, we have clients who have an idea and think they just need developers to build it—then we “step back” and start with them from the beginning with what we call initial discovery. We try to identify what makes this product a key differentiator and whether the idea is actually viable.

Most often, we sit down online with the client for workshops and share our knowledge and experience from other products, discussing what’s worth trying and what isn’t. We want to create a vision and strategy, then launch our first experiment to validate the client’s problem as quickly as possible.

The whole process can take anywhere from one to four weeks. The end result is the discovery process output along with user story mapping, which shows what we want to deliver first, along with a time-boxed estimate (max three months because that’s too long—we can come back a month later with new findings).

So essentially, we want to discuss MVP or MMP with our clients only within a three-month window or shorter.

Grzesiek: Let’s set product aside for a moment and talk about your career development. Can you tell us about your path before your current role?

Damian: I studied Automation and Robotics at the Faculty of Electronics, Telecommunications and Informatics at Gdańsk University of Technology. I started as a programmer but lasted only four months. I realized I enjoyed programming, but it didn’t fulfill me at all.

Because I’d taken a Scrum Master course during my studies and passed the certification on Scrum.org, I got the idea to return to that area. Instead of talking to machines, I wanted to communicate with people and take care of how they work—because I myself had been switched between different threads constantly, several times a day. I was aware of what that meant for productivity and well-being.

I joined a startup that didn’t have Scrum, and from the beginning, I worked closely with the business side. I was a Scrum Master who cared for teams and worked with them, but on the other hand, I supported the PO in understanding what mattered to the client, which direction to head, and why. I even ended up acting as Product Owner on some products—initially during the PO’s absence, and later on smaller products at the next company. I was part of a team developing a mobile game that was advertised on Times Square’s largest billboard.

After the startup and game dev, I eventually joined STX Next because they were looking for a Scrum Master. There I switched frequently between SM and PO roles.

Leave a comment

Grzesiek: How do you develop your skills?

Damian: Ever since I became a Scrum Master, I’ve been building my network on LinkedIn, which helped me create a pipeline that continuously delivers content written by industry experts. That’s where I start—when I see something I don’t know, I’ll research it, maybe talk to that person, and broaden my horizons.

Beyond that, of course I use, and continue to use and invest both my own and my company’s budget in various workshops, training, and coaching sessions.

Grzesiek: What does your typical week look like?

Damian: My week starts with an hour of “focus time” on my calendar. It’s a moment to pause and review notes from the previous week—and despite using many tools, I’ve gone back to pen and paper (I love Oxford notebooks) and a good pen (Flexi). This lets me review meetings, action items, and things that carried over from the previous week.

Monday is also when I summarize our projects, check risks, and allocate people to new products and projects.

In between, I moderate and run meetings with internal STX stakeholders—making sure those meetings have good ROI. These might be conversations with a Product Owner about lessons learned or with others about collaboration—generally solving problems that have come up recently. In other words, it’s Scrum Master work at the organizational level.

I’m always open to someone putting a 30-minute block on my calendar to discuss current challenges, or for me to be a rubber duck, a sparring partner, or simply grab a coffee together.

Grzesiek: You mentioned that one of your responsibilities is checking whether meetings bring value—managing meeting ROI. Can you expand on that?

Damian: Sometimes I might be too direct, and when I walk into a meeting, I ask straight questions like: “What’s this for and what do we want to learn here?” I hope questions like that have reduced the number of meetings, not just freed up my time. ☺

Another important aspect is whether these meetings are actually moving us toward a goal—whether they’re just meetings for the sake of having a meeting and wasting time.

Grzesiek: What do you consider the top skill for a Product Owner and a Scrum Master?

Damian: For a Scrum Master, it’s the ability to have conversations about team effectiveness—so we don’t fall into the trap of only counting story points and measuring output, because that information shows something but obscures the bigger picture.

For a Product Owner, I’d say it’s the ability to step back and look at the product from the outside. So we can disconnect from all the chaos and say: “Okay, let’s pause—what’s our biggest challenge right now in this speeding train?”

Grzesiek: Thanks so much for this valuable conversation!

If you enjoyed this interview, click 💙 and leave a comment.

If you’re not yet part of the Product Art community, I’d love to have you subscribe.

🇵🇱 Wersja polska / Polish original

Damian Winczewski pracuje w największym w Europie, Python Software House STXNext na stanowisku Head of Agile Center of Excellence.

Grzesiek: Cześć Damian, dzięki, że zgodziłeś się porozmawiać. Czy mógłbyś się przedstawić i opowiedzieć czym się zajmujesz?

Damian: Cześć Grzegorz, Obecnie pracuje w STX NEXT jako Head of Agile Center of Excellence czyli jestem bezpośrednim line managerem dla Product Ownerów i Scrum Masterów. W ciągu wcześniejszych trzech lat, pracowałem w organizacji na różnych stanowiskach np. w roli Product Ownera, Scrum Mastera czy jako konsultant. W końcu padł pomysł, aby zoptymalizować ten produkt wewnętrzny firmy i zostałem “Product Ownerem” Centrum Agilowego - w ten sposób powstał nowy dział, który od stycznia tego roku rozwijamy i jego zadaniem jest rozwój naszego podejścia do budowania produktów, ale też soft workingu z klientami.

Grzesiek: Brzmi jak poważna rola dla organizacji. Możesz coś o niej powiedzieć?

Damian: Jak zaczynałem, to było nas 29 osób w zespole. Wtedy byłem jeszcze w stanie ogarnąć to czasowo i z każdym spotkać się choć raz na miesiąc. Teraz jest nas ponad 40 osób i “usprawniliśmy” strukturę. Wprowadziliśmy dodatkową rolę Agile Team Leaderów, którzy przejęli ode mnie tę część dotyczącą wspierania rozwoju ludzi i spotykania się z nimi 1on1.

Dzięki temu mogę skupić się na tym, co możemy oferować naszym klientom - jakie nowe usługi np. analityka produktowa.

Grzesiek: Możesz opowiedzieć coś więcej o strukturze? Kto wchodzi w skład tych 40 osób?

Damian: Obecnie mam 3 Agile Team Lead-ów. Każdy Agile Team Lead ma swój zespół, który składa się z około 15 osób, a role (Product Owner, Scrum Master) jak i doświadczenia w tych zespołach są zdywersyfikowane, aby każdy z nich był w stanie rozwiązywać problemy. Naszym celem jest rozwiązywanie zwinnie problemów naszych klientów.

Grzesiek: Czyli rozumiem, że każdy Product Owner ma swój zespół cross funkcjonalny?

Damian: Tak, PO’s pracują już na produktach klienckich - no chyba, że mamy jakiś produkt wewnętrzny, ale to rzadko.

Grzesiek: Czy jako Software House specjalizujecie się w jakiejś specyficznej domenie?

Damian: Jesteśmy największym Python Software House w Europie. Oczywiście są też różne inne technologie, które to wspierają, albo faktycznie idziemy w całkowicie inną technologię. Natomiast Python to nasza baza, która pozwala nam w szybki i jakościowy sposób rozwijać nasze produkty dla klientów z całego świata, od Emiratów Arabskich, przez Niemcy, Wielką Brytanię, a kończąc na Stanach Zjednoczonych.

Jeśli chodzi o produkty to również rozstrzał jest dość szeroki bo od branży eventowej, przez hutniczą do finansowej i krypto - myślę, że w każdej byśmy coś znaleźli.

Grzesiek: Macie Product Managerów czy Product Ownerów?

Damian: Dla nas PdM i PO to są role tożsame. Uważamy, że tak naprawdę kompetencje tych obydwu ról są takie same, więc my niezależnie od tego jak klient chce nazywać tę rolę, to staramy się wchodzić w oba obszary. Nasi PO’s są również zaangażowani w tworzenie discovery, strategii czy roadmapy. Każdy Product Owner jest przypisany tylko do jednego PRODUKTU - z naciskiem na produkt, a nie projekt, bo my robimy produkty, a nie projekty. Wyjątkiem są budżetowe produkty i wtedy jeden PO może występować na dwóch produktach - co dzieje się dość rzadko bo w dalszym ciągu nie chcemy bez sensu dostarczać funkcjonalności tylko rozwiązywać problemy naszych klientów. Pracujemy w większości w Scrumie.

Grzesiek: Możesz opowiedzieć jak wygląda proces od momentu pojawienia się klienta, aż do dostarczania rozwiązania?

Damian: Mamy różne ścieżki bo pojawiają się klienci z pomysłem lub z gotowym produktem. Ci drudzy poszukują wsparcia w zasobach programistycznych. Bardzo często produkt jest wewnętrzny w ich firmie - wtedy powiedzmy, że akceptujemy ich “eksperckość” i przechodzimy do fazy delivery, ale ostrożnie przyglądamy się dostarczanym funkcjonalnością.

Z drugiej strony mamy tego klienta, który ma pomysł i myśli, że potrzebuje tylko developerów, którzy mu go dostarczą - wtedy go “cofamy” i zaczynamy z nimi od początku od tzw. initial discovery. Staramy się odkryć to co jest kluczowym wyróżnikiem tego produktu i czy faktycznie ten pomysł jest realny.

Najczęściej “siadamy online” z klientem na warsztatach i dzielimy się z nim naszą wiedzą, doświadczeniem z innych produktów, co warto lub czego nie warto próbować. Chcemy stworzyć wizję oraz strategię, a następnie wystartowanie z pierwszym eksperymentem, aby w jak najkrótszym czasie zwalidować problem klienta.

Wszystko może trwać od tygodnia do nawet 4 tygodni. Efektem końcowym jest rezultat procesu discovery wraz z user story mappingiem, który pozwoli pokazać co chcemy zrealizować w pierwszej kolejności wraz z estymatę ograniczoną czasową (max 3 miesiące bo jest to zbyt długo - możemy za miesiąc przyjść z kolejnymi odkryciami).

Wychodzi na to, że generalnie chcemy dyskutować z naszymi klientami o MVP czy MMP jedynie w przestrzenii 3 miesięcy i krótszej.

Grzesiek: Odstawmy na chwilę temat produktu na bok i porozmawiajmy o rozwoju Twojej kariery. Możesz opowiedzieć o swojej ścieżce rozwoju jeszcze przed obecną firmą?

Damian: Skończyłem kierunek automatyka i robotyka na wydziale ETI na Politechnice Gdańskiej. Zacząłem jako programista, ale wytrzymałem jedynie 4 miesiące. Stwierdziłem, że lubię programować, ale mnie to w ogóle nie realizuje.

W związku z tym, że jeszcze w trakcie studiów zrobiłem kurs Scrum Mastera i zdałem certyfikat na Scrum.org, wpadłem na pomysł powrotu do tego obszaru. Chciałem zamiast rozmawiać z maszynami - komunikować się z ludźmi i zadbać o to jak pracują bo sam byłem przerzucany z jednego wątku na drugi - praktycznie kilka razy dziennie. Zdawałem sobie sprawę z tego jakie to ma konsekwencje.

Poszedłem do Startupu gdzie nie było Scruma i tam od początku poruszałem się blisko biznesu. Byłem takim SMem, który dba o zespoły i pracuje z nimi, ale z drugiej strony wspierałem PO w tym, co dla klienta jest ważne, w którą stronę warto zmierzać i dlaczego. Doszło nawet do tego, że w niektórych produktach pełniłem nawet rolę Product Ownera - na początku podczas nieobecności PO, a potem przy mniejszych grach w następnej firmie . Byłem w zespole tworzącym grę mobilna reklamowaną na tym największym billboardzie na Times Square.

Po startupie i gamedevie już trafiłem do STX Next bo akurat szukali Scrum Mastera. Tam już częste zmiany stanowisk pomiędzy SM, a PO.

Leave a comment

Grzesiek: W jaki sposób podnosisz swoje umiejętności?

Damian: Od momentu, kiedy zostałem Scrum Master zacząłem budować sieć kontaktów na Linkedin i to pozwoliło mi zbudować lejek, który ciągle dostarczał mi treści pisane przez ekspertów z branży. Od tego zaczyna się drążenie tematu - coś, o czym nie wiem - poszukam, może porozmawiam z tą osobą i poszerze horyzonty.

Oprócz tego oczywiście wykorzystywałem, wykorzystuję i inwestuję swój oraz firmowy budżet na różnego rodzaju warsztaty, szkolenia czy spotkania z coachem.

Grzesiek: Jak wygląda Twój tydzień?

Damian: Tydzień zaczyna się w moim kalendarzu od godzinnego “focus time”. Jest to czas zatrzymania się i obejrzenia kartki/kartek z poprzedniego tygodnia bo mimo stosowania wielu narzędzi wróciłem do papieru (z moich ulubionych zeszytów z Oxfordu) i długopisu(Flexi). Można wtedy przejrzeć spotkania, akcje oraz rzeczy, które zostały z poprzedniego tygodnia.

Poniedziałek jest też dla mnie dniem w którym podsumowujemy swoje projekty, sprawdzamy ryzyka, alokujemy osoby na nowe produkty/projekty.

Pomiędzy tym wszystkim jest moderacja i prowadzenie spotkań ze stakeholderami wewnątrz STX - dbanie o “ROI” tych spotkań. Mogą to być rozmowy z Product Ownerem na temat lessons learnt czy z innymi osobami na temat wzajemnej współpracy - generalnie rozwiązujemy problemy, które ostatnio były sygnalizowane - inaczej mówiąc jest to działanie Scrum Mastera na poziomie organizacji.

Nadal jestem zawsze otwarty na to, żeby ktoś wbił mi pół godziny w kalendarz i żebym z nim porozmawiał o aktualnych wyzwania, a czasami abym był gumową kaczką, sparing partnerem czy po prostu wypił wspólnie kawę.

Grzesiek: Powiedziałeś, że jednym z Twoich zadań jest sprawdzenie czy dane spotkanie przynosi wartość - dbanie o “ROI” spotkań. Możesz to rozwinąć?

Damian: Czasami może jestem zbyt bezpośredni i jak przychodzę na spotkanie to zadaje pytania wprost typu: “po co ono jest i co chcemy się tutaj dowiedzieć?”. Tego typu pytania (mam nadzieję) zmniejszyły ilość spotkań, a nie tylko mnie ze spotkań :)

Kolejnym ważnym aspektem jest to czy my dzięki tym spotkaniom zmierzamy do jakiegoś celu - czy te spotkania nie są tylko po to, żeby się spotkać i przepalić czas.

Grzesiek: Co uważasz za topową umiejętności dla Product Ownera oraz Scrum Mastera?

Damian: Scrum Master to umiejętność rozmowy o efektywności zespołu czyli żebyśmy nie wpadli w pułapkę i nie liczyli story pointów oraz tego ile dostarczamy, itd bo ta informacja coś pokazuje, ale rozmywa obraz.

Jeśli chodzi o Product Ownera to mam na myśli umiejętność patrzenia z boku na Produkt. Tak abyśmy byli w stanie wyłączyć się z tego całego otoczenia i powiedzieć: “ok to teraz przerwa - co obecnie jest naszym największym wyzwaniem w tym pędzącym pociągu”.

Grzesiek: Dzięki za wartościową rozmowę!

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.

Product Manager with several years of experience in SaaS startups and scaleups. Focused primarily on discovery and validation as the shortest path to building products that deliver value to users. Currently works at Tidio, a customer communication management tool for e-commerce. Outside of work, a digital nomad traveling mostly throughout Europe—lived in 7 countries over the past year.

Grzesiek: Hi Piotrek, thanks for agreeing to talk as part of the product conversations on Product Art. Tell me, who are you?

Piotr: Hi Grzesiek. I’m currently a Product Manager at Tidio, where we offer a customer communication product for e-commerce. Our portfolio includes live chat, chatbots, and a ticketing system.

I’m specifically responsible for the ticketing system. It’s a relatively new product we’re launching to market, so my work revolves around discovery—which will soon wrap up with the release of the first public version.

Grzesiek: What was your journey before becoming a PM at Tidio?

Piotr: I’ve been a Product Manager for 5 years now—that’s 20% of my life.

I started working at the beginning of my studies. I attempted to launch two startups, but both failed within a few months. As for “commercial” experience, I started as a Customer Success Manager at Survicate.

At that time, the company had just one person on the product side—the Head of Product. We worked very closely together, which is what’s expected of a good CSM—product involvement. I collected and organized customer feedback. Then I was offered a promotion to Product Manager.

I think this is one of the best paths to a product role in SaaS (though not the only one), because as PMs we especially need a lot of customer contact. Plus, we need to understand customer problems, and few people in a company work as closely with customers as a CSM does.

After that, I worked for over a year at Prowly, a startup offering a PR management product. Since December 2021, I’ve been a Product Manager at Tidio.

Grzesiek: Okay, so tell me what your work looks like as a Product Manager at Tidio.

Piotr: My goal is to maximize the value delivered by our product to our customers. I work with developers more in a coaching and inspiration capacity, sharing our product vision and strategy with them. I operate from the assumption that if they understand this clearly, I’m not really needed for day-to-day product management. We have great developers who are not only technically excellent but also great communicators. I can also say they know our customers and are often able to make simple product decisions on their own. Meanwhile, I can focus on discovery and validation.

Validation is very important to me because as a Product Manager, I want to avoid building things that don’t make sense for us (like features for one or two customers). We use a full range of validation techniques—Concierge MVP, dry wallets, fake doors, and so on. Basically, we use everything that helps us make sure what we’re doing makes sense and will actually be used by our product users.

Grzesiek: Can you go deeper into your collaboration with the development team?

Piotr: Of course. It’s worth noting that it’s not the case that I only interact with them to “sell” our product vision and strategy.

We set priorities together, I attend Daily Standup, and we have joint refinements and planning sessions. There’s a huge difference between how I collaborate with the development team now versus what I experienced earlier, where they’d ask me about practically everything—even the smallest, most basic change.

Now I try to share customer feedback with them so they understand what our customers expect from us.

I come to developers with what I call a “broken story”:

“There are this many customers who have this need and can’t fulfill it.”

I focus on the problem, and the developers’ side is to present, say, three solutions. Then very often I go back to customers to validate the proposed solutions. I check whether the proposal solves their problem and delivers value. If it does, we move in that direction and the developers are very much engaged in the feature planning process. At Tidio we plan quarterly, so we establish a backlog (with a fairly large buffer and room for changes) before the quarter even starts.

Grzesiek: Who else do you collaborate with?

Piotr: The structure at Tidio is quite flat—between me and the CEO, there’s only the CPO.

Of course, we have marketing, customer support, customer experience, and we’re just now building out our sales team. Until now, we’ve acquired customers through conversion and inbound. Customer support helps our customers, and customer experience onboards them. It’s very important to us that customers understand what our product is about from the start. People from the Customer Success department are very engaged in collecting feedback and categorizing it.

We want to make good decisions, and access to well-prepared data allows us to reduce the risk of mistakes.

I regularly meet with the head of sales, who tells me about deals we’ve lost and why we lost them. We think together about how to increase conversion in our sales funnel and how we can better help solve our customers’ problems.

Grzesiek: At what level of the product do you work?

Piotr: As product people, we at Tidio are engaged in product strategy that contributes to company strategy. We then decompose the product vision and strategy into smaller products. We come up with ideas and vision, and our CPO supports us in making various decisions through consultation.

Grzesiek: Do you have a backlog of validated ideas you want to try to deliver?

Piotr: When you talk regularly with customers and listen to their feedback and ideas for new features, your job is to figure out how many people would actually benefit from what customer X or Y is proposing. We often run experiments using the Fake Door approach—we show some value and tell customers “hey, if you want to integrate with this tool, click here,” and then we inform them they’ll have to wait a bit before we build that feature. We also use many other techniques that help us estimate the value of features or how painful a problem is for customers. We measure everything in Amplitude so we can see at what point in the user “journey” people drop off.

All of the above relates to validation at the need level, but we also do validation at the solution level.

For example, we know that analytics will be needed in the product, but we’re not entirely sure what form they should take, so we let our customers create email reports with the information they ask for. All those reports they receive—that’s my manual work extracting data from the system. When I send the generated report, I ask whether this solution fits the problem they want to solve and what we can do to help them extract maximum value from these analytics.

Sometimes it’s easier to release an MVP and decide what worked and what didn’t—that’s the most costly approach because it requires significant development investment.

For a new product (like mine), we try to work only on validated ideas because (especially at the beginning) there are so many hypotheses! We always choose the path that tests the riskiest assumption.

Grzesiek: Do you work with any metrics?

Piotr: Our CEO has specific metrics they’re responsible for. Then we work our way down—for example, our CPO has their own metrics that contribute to company metrics. Then we, in our product teams, contribute to what’s above us—it creates a kind of tree structure.

We don’t have OKRs in the company, but we work with what we call OITs—Objective, Indicator, Task.

The Objective is a description of the product’s vision and strategy. Then we have the Indicator—a number we want to achieve in full alignment with vision and strategy. We also have Task—what we want to do to reach that point. This way we have a connection between vision, strategy, and the backlog.

When we’re thinking about which feature to focus on, we always come back to the metric and goal and ask whether this feature will bring us closer to achieving our goal and metric. If we agree that it will, we move in that direction—otherwise we abandon the idea in favor of another, because the backlog of ideas is always infinitely large.

Grzesiek: What methodology do you use?

Piotr: At Tidio, each Product Manager works differently—we haven’t set up any product ops because our teams are different. Each of us is a completely different Product Manager and we work very differently. In my team, we work in SCRUM, but from what I know, Przemek works in SHAPE UP.

In my team, we focus on finding product-market fit for the rest of the customers who don’t yet have public access to this product. We try to prepare an appropriate number of features that we want to deliver in the next quarter and make the most of the time while working in that quarter. To be clear, this isn’t about pushing developers, but about planning work on what’s most valuable for our customers at any given time.

Grzesiek: What does the development team do during the discovery phase?

Piotr: We work similarly to Dual Track Agile. We have 3 refinement sessions during one sprint, each lasting an hour. Usually one is very operational, while the others focus on vision and the long term.

I want to know what’s happening in the development team so I can predict when we’ll be ready to go to production or tackle the next problems. On the other hand, I want them to know exactly what I’m thinking about, because the more they understand my thinking, the better solutions they can deliver with an eye toward the future.

Developers often can’t participate in the discovery process, but I’m their proxy—someone who can answer their questions or route them appropriately.

Example.

Developers ask me whether if we deliver 10% of a given solution and it works in this specific way (they describe the process), will the customer be happy?

Through these conversations, we’re able to find the sweet spot between effort and impact we can deliver. Previously, I would come to the development team with a scope of what needed to be done—that wasn’t the best approach. Now we try to understand together what we can do to reach a given goal while using the development team as efficiently as possible.

In this process, I’m like a ping-pong ball between customers and developers—it’s an ongoing process.

If we start a new quarter in October, the discovery phase happens in August. In August, the first outline of things we’ll focus on in the next quarter already appears. I deliberately don’t call it a set of features, but a set of problems we’d like to solve in the next quarter. Developers often meet separately and analyze what they can do to deliver the best solution, then they provide their analysis.

They say:

“We can do thing X in 2-3 days, but it will be weak for customers. We can do range Y in 1-2 sprints, or we can deliver the ideal solution, but it will take this long.”

Then we sit down together and make a decision based on our quality definition—so we can say this is a good and valuable product for our customers.

We always leave ourselves some room for uncertainty, meaning we don’t want to create a perfect specification. Of course, there’s also time for coding and building solutions, but we don’t have some 80/20 or 50/50 split—it’s relatively fluid and depends on where we are in the cycle.

Sometimes we already know we won’t deliver, and we negotiate with stakeholders. There are also situations where we cut scope ourselves because we know certain things aren’t necessary. We have a Data Analyst and UX Researcher on the team who provide us with additional information to confirm our assumptions.

Leave a comment

Grzesiek: We ended the previous part when you started talking about working with the Data Analyst and UX Researcher. Can you expand on that?

Piotr: The UX Researcher works on two things. First is work with the team or teams, and second is more strategic work.

The strategic part includes questions we want to ask ourselves about the product—like how we want to develop it and which direction to take. It involves a lot of customer conversations.

The part that involves working with teams (we have UX Researchers assigned half-time to the team) is more consultative in nature.

Example.

I come to Asia and ask:

“Hey, I see problem X. I’d like to investigate it and answer a set of questions I have about it.”

The UX Researcher suggests a way I could answer those questions. She often prepares an interview scenario or a list of questions that meet basic research criteria.

During interviews, I’m supported by the Designer (not the Researcher), who helps me set up User Tests (we use user testing as a tool for discovery or hypothesis validation).

After the conversation, I deliver everything to the UX Researcher. She’s the one who supports me in synthesizing the information we gathered during conversations with customers.

To sum up, the UX Researcher is with me at the beginning and end of the journey, while in the middle phase I work with the Designer (or alone).

When it comes to working with Judyta, who is a Data Analyst, we mainly focus on numbers and metrics. Judyta provides me with a set of metrics and data that we’ll be looking at, and she answers questions we ask ourselves while building our product — for example, which customers were interested in a specific fake door? Sometimes we have a problem but can’t gauge its scale, and only diving deep into the data can give us any insight.

I usually don’t ask for raw data, but rather a ready-made answer based on the numbers we have. Sometimes we need to do a few deep dives to make sure we’re interpreting our data correctly — we simply ask more and more questions that help us refine what we’re trying to answer.

Working with Judyta and Asia, I’m 100% confident that I can rely on their conclusions because they have much greater expertise in their domains than I do.

Grzesiek: Could you tell us something about the User Testing tool?

Piotr: User Testing is a tool for testing prototypes and mockups. It allows us to find out whether people understand the interfaces we’ve designed. One of the more interesting studies we conduct using User Testing is card sorting research, which helps us understand information architecture. The goal is to make sure the content we present in the product is understandable to our customers.

User Testing works like this: we ask a specific set of questions and present a pre-programmed scenario. Then people from around the world can access the User Testing tool and perform a specific set of tasks. In the next step, we ask a list of open-ended questions. Depending on what feedback we get, we learn whether we’re satisfied with the results or if we want to change something.

It’s worth remembering that we don’t always reach our target audience, so we need to account for that when interpreting the results. But it’s definitely a tool that makes our work easier and allows us to gather insights very quickly without focusing on recruiting people for the study.

Grzesiek: How do you communicate when you can’t deliver on things you committed to earlier?

Piotr: We generally avoid making commitments to external customers. Sometimes we do it for our internal stakeholders — they know what we’ll be working on in a given quarter. Our roadmap isn’t public, so customers don’t see it and don’t know what we’re working on.

Whenever a customer comes to me and wants a specific feature that we don’t have, I say:

“Thank you, we’ll think about how to solve your problem”

I never give a direct answer that we’ll build something, and I consider that approach a strong anti-pattern for how a Product Manager should work.

Even when we run a fake door test, the customer sees the message after clicking: “Thanks, we’ll let you know if this feature becomes available.” This helps us avoid frustrating customers and manage their expectations appropriately.

With internal stakeholders, we solve it simply through communication. Good internal communication is key. We hold regular sprint reviews, we have a whole page where we track the progress of each of our OKRs, and we communicate regularly where we stand.

Both the sales team and customer support have a huge understanding of the unpredictability of product work, which gives us tremendous comfort in our work.

Grzesiek: What do you do when the sales department comes to you and tries to force you to build feature X — otherwise the customer will leave?

Piotr: TIDIO’s subscription cost ranges from $20 to $50 per month, so one sale doesn’t change much. We have large customers we want to reach in the market, but our sales team is very aware and knows that building things specifically for one customer is a bad path we shouldn’t follow.

At Tidio, the huge plus is that we’re all playing toward the same goal and we’re aligned on our shared objectives. It’s a unique and comfortable situation because often sales pressure the product team and force many features through if the Product Manager isn’t assertive enough and isn’t empowered in the company.

Grzesiek: I thought the perfect company doesn’t exist… but apparently it does :) Do you have dependencies between teams?

Piotr: Yes, of course. On one hand, there are product dependencies, and on the other, there are code dependencies. With the latter, there’s communication between developers in different teams — we know who’s working on specific areas across teams. We don’t have a formal process, but we communicate quite a bit when various dependencies arise.

As for product dependencies, we also try to communicate with each other. We resolve most dependencies during quarterly planning. When planning sprints, we also try to communicate our goals and agree on what we’ll be doing and what we might depend on.

It’s also worth mentioning that at Tidio we have five Product Managers (and we’re always looking for more :)), so we don’t have as much of a communication problem or difficulty mapping dependencies. Marcin, our Chief Product Officer, also supports us strongly.

Grzesiek: What tools do you use in different areas?

Piotr: For discovery, we use Hotjar, User Testing, Maze, and Zoom to talk with customers. We collect all information in Airtable, and we document our findings in Notion.

I’ve built a habit of documenting every decision I make, so I later know under what circumstances it was made. The reason is to prevent anyone from coming and saying we built something and suddenly another feature doesn’t work for certain customers. I always note what the potential consequences of a decision might be, what trade-offs we’re making, and why I think they’re acceptable.

Moving on to other tools, we obviously use JIRA for backlog management. As for documentation, that’s handled by developers and stored on GitLab.

Grzesiek: Let’s move to a different set of questions. How do you manage your time and maintain productivity?

Piotr: My decision on what I’m currently working on is also a product decision. I delegate a lot of things because I’m usually not the smartest person to handle a given area. As I mentioned earlier, we have the right person for UX Research, another person for data analysis, documentation is created by the dev team, and so on.

I always have a TO DO list that I try to update regularly, because of course there are things on it that become outdated. I try to set one specific goal for each day. If I manage to achieve it, that means my day was worthwhile.

I’ve also tried to block time for deep work, but I’m not sure if that’s the right approach for our role — it often doesn’t work out for me. There are many meetings and conversations with customers, but it doesn’t interfere with my daily work, so I think blocking my calendar isn’t an ideal solution for me.

Grzesiek: What do you think are the most important skills for a PM?

Piotr: Communication for sure, because it’s very important in daily work. As I said earlier, I think of myself as a ping-pong ball bouncing between developers, customers, users, and who knows who else :)

I think it’s also worth adding the ability to ask questions in a way that gets you valuable answers.

Let’s not forget about the art of prioritization and time management either. In fact, managing your own time and managing a product are very closely related, in my opinion.

Grzesiek: What would you say to people who want to become product managers?

Piotr: I’d say there are a lot of product gurus out there saying how difficult this work is, but I think it’s work that brings a lot of joy. I’ve worked in many different roles (operations, support, sales, finance), and there are few roles that can put a smile on your face like product does.

It’s important to take the first steps and break through to this position. There’s a lot of Product Manager knowledge available on the internet.

It’s also worth looking for entry-level positions in young organizations, because you can grow together with the company.

I definitely wouldn’t spend huge amounts of money on courses because practice is much more valuable and shapes your understanding of what kind of Product Manager you want to be and what kind you don’t.

Grzesiek: Thank you very much for this valuable interview!

Piotr: You’re welcome. If anyone has any questions, feel free to reach out to me on LinkedIn :)

If you enjoyed this interview, click the 💙 and leave a comment.

If you’re not yet part of our Product Art community, I invite you to subscribe.

🇵🇱 Wersja polska / Polish original

Product Manager z kilkuletnim doświadczeniem w SaaSowych startupach i scaleupach. Skupiony przede wszystkim na discovery i walidacji jako najkrótszej drodze do tworzenia produktów, które przynoszą wartość użytkownikom. Aktualnie pracuje w Tidio, narzędziu do zarządzania komunikacją z klientami w e-commerce. Prywatnie digital nomad, choć podróżuje przede wszystkim w Europie - na przestrzeni ostatniego roku mieszkał w 7 krajach.

Grzesiek: Cześć Piotrek, dzięki, że zgodziłeś się porozmawiać w ramach produktowych rozmów w Product Art. Powiedz mi kim jesteś?

Piotr: Cześć Grzesiek, Obecnie jestem Product Managerem w Tidio, gdzie oferujemy produkt do komunikacji z klientami w e-commerce. W skład naszego portfolio wchodzi livechat, chatboty i system ticketowy.

Ja odpowiadam właśnie za system ticketowy. Jest to produkt stosunkowo nowy, który dopiero wypuszczamy na rynek, więc moja praca związana jest z obszarem discovery, która już za niedługo zakończy się wypuszczeniem pierwszej wersji do publicznej przestrzeni.

Grzesiek: A jak wyglądała Twoja droga zanim zostałeś PMem w TIDIO?

Piotr: Jestem już Product Managerem 5 lat czyli można powiedzieć, że 20% mojego życia.

Zacząłem pracować już na początku moich studiów. Miałem próby założenia dwóch startupów, które dość szybko upadały bo w przeciągu kilku miesięcy. Jeśli chodzi już o takie “komercyjne” doświadczenie to zacząłem od roli Customer Success Manager’a w Survicate.

Wtedy w firmie od strony produktu była jedna osoba - Head of Product. Współpracowaliśmy bardzo blisko, bo w sumie tego wymaga się od dobrego CSM - zaangażowania w produkt. Dostarczałem i organizowałem feedback od klientów. Następnie otrzymałem propozycję awansu do roli Product Managera.

Uważam, że jest to jedna z najlepszych ścieżkę przejścia do roli produktowej w SaaS (ale oczywiście nie jedyna), bo jako PM’s szczególnie potrzebujemy mieć dużo kontaktu z klientami. Dodatkowo musimy rozumieć problemy klientów, a mało jest osób w firmie, które tak blisko współpracują z klientami jak CSM.

Następnie pracowałem ponad rok w startupie Prowly, który oferuje produkt do zarządzania PR’em. Od grudnia 2021 roku jestem Product Managerem w Tidio.

Grzesiek: Ok, to opowiedz w takim razie jak wygląda Twoja praca w roli Product Managera w TIDIO?

Piotr: Moim zadaniem jest maksymalizowanie wartości oferowanej w produkcie dla naszych klientów. Z developerami pracuje bardziej w formie coacingu, inspiracji i dzielenia się z nimi wizją i strategią produktową bo wychodzę z założenia, że jesli oni będa mieli to zrozumienie to ja tak naprawdę nie jestem potrzebny do zarządzania produktem day to day. Mamy świetnych developerów, którzy nie tylko są bardzo dobrzy technicznie, ale też komunikacyjnie. Dodatkowo mogę powiedzieć, że znają klientów i są bardzo często w stanie podjąć proste decyzje produktowe. Ja w tym czasie mogę zająć się obszarem discovery i walidacją.

Walidacja jest dla mnie bardzo ważna bo jako Product Manager chcę uniknąć robienia rzeczy, które nie mają dla nas sensu (np. dla jednego lub dwóch klientów). Wykorzystujemy cały wachlarz technik walidacyjnych np. Concierge MVP, dry wallety, fake doory, itd itd. Tak naprawdę korzystamy ze wszystkiego, co pozwala nam upewnić się, że to, co robimy ma sens i będzie używane przez użytkowników naszego produktu.

Grzesiek: Możesz pogłębić temat współpracy z zespołem developerskim?

Piotr: Oczywiście, warto dodać, że to nie wygląda w taki sposób, że ja nie mam z nimi kontaktu poza “sprzedawaniem” wizji i strategii produktowej.

Wspólnie ustalamy priorytety, przychodzę i uczestniczę w Daily SU, mamy wspólne refinementy oraz planningi. Jest duża różnica między współpracą z zespołem developerskim obecnie vs to co doświadczyłem wcześniej, gdzie dostawałem pytania praktycznie o wszystko - nawet najmniejszą, podstawową zmianę.

Obecnie staram się dzielić z nimi feedbackiem od klientów, po to, aby zrozumieli czego oczekują od nas klienci.

Przychodzę do developerów z tzw. złamanym story:

“Jest tyle i tyle klientów, którzy mają takie potrzeby i nie mogą ich zrealizować”

Ja zajmuje się problemem, a po stronie developerów jest przedstawienie np. trzech rozwiązań, po czym bardzo często wracam do klientów, aby zwalidować zaproponowane rozwiązania. Sprawdzam czy propozycja rozwiązuje ich problem i dostarcza im wartość. Jeśli tak, to idziemy w tym kierunku i developerzy są bardzo mocno zaangażowani w proces planowania featerów. W Tidio planujemy kwartalnie, a więc ustalamy backlog (z dość dużym buforem i przestrzenią na to, że coś może się zmienić) jeszcze zanim zacznie się kwartał.

Grzesiek: Z kim jeszcze współpracujesz?

Piotr: Struktura w Tidio jest dość płaska bo między mną, a CEO, jest tylko CPO.

Oczywiście mamy dział marketingu, customer support, customer experience i dopiero budujemy zespół sprzedażowy. Do tej pory klientów pozyskaliśmy za pomocą konwersji oraz inbound’u. Customer support wspiera naszych klientów, a customer experience ich onboarduje. Jest dla nas bardzo ważne, aby klienci wiedzieli już na początku, o co chodzi w naszym produkcie. Osoby z działu Customer Success są mocno zaangażowane w zbieranie feedbacku i kategoryzowanie go.

Chcemy podejmować dobre decyzje, a dostęp do dobrze przygotowanych danych, pozwala nam zmniejszyć ryzyko błędów.

Regularnie spotykam się z headem sprzedaży, który mówi mi o dealach, które straciliśmy oraz dlaczego je straciliśmy. Zastanawiamy się wspólnie jak zwiększyć konwersję w naszym lejku sprzedażowym i jak możemy pomagać jeszcze lepiej rozwiązać problemy naszych klientów.

Grzesiek: Na jakim poziomie produktu pracujesz?

Piotr: Jako Product People jesteśmy w Tidio zaangażowani w strategię produktową, która kontrybuuje do strategii firmy. Następnie dekomponujemy wizję i strategię produktową na nasze mniejsze produkty.To my przychodzimy z pomysłami i wizją, a nasz CPO wspiera nas przy podejmowaniu różnych decyzji poprzez konsultacje.

Grzesiek: Macie jakiś backlog zweryfikowanych pomysłów, które chcecie spróbować dostarczyć?

Piotr: Rozmawiając regularnie z klientami, wysłuchujesz ich opinii i pomysłów na nowe funkcjonalności. Twoim zadaniem jest zastanowienie się jak dużo ludzi skorzystałoby z tej właśnie rzeczy, którą proponuje klient X, czy Y. Często robimy eksperymenty na zasadzie Fake Door - pokazujemy jakąś wartość i mówimy klientom “hej, jak chcesz się zintegrować z tym narzędziem to kliknij tutaj”, a potem informujemy, że jeszcze muszą trochę poczekać, zanim zbudujemy daną funkcjonalność. Korzystamy też z wielu innych technik, które pozwolą nam oszacować wartość danych funkcjonalności albo jak bardzo problem jest bolesny dla klientów. Wszystko mierzymy oczywiście w Amplitude bo pozwala nam to zobaczyć na jakim etapie “podróży” odpadają użytkownicy.

To wszystko powyżej dotyczy walidacji na poziomie potrzeby, ale mamy też walidację na poziomie rozwiązania.

Dla przykładu. Wiemy, że w produkcie będzie potrzebna analityka, ale nie wiemy do końca jeszcze jaka, więc pozwalamy naszym klientom stworzyć raporty mailowe z informacjami, o które pytają. Te wszystkie raporty, które otrzymują to jest moja manualna praca i wyciąganie danych z systemu. Wysyłając wygenerowany raport dopytuję, czy to rozwiązanie jest dopasowane do problemu, który klient chce rozwiązać i co możemy zrobić, żeby wyciągnęli z tej analityki jak największą wartość.

Czasami łatwiej jest wypuścić MVP i zadecydować co zadziałało, a co nie - jest to najbardziej kosztowne rozwiązanie, bo wymaga dużej inwestycji developmentu.

W przypadku nowego produktu (takim jak mój), staramy się pracować tylko nad zweryfikowanymi pomysłami bo (szczególnie na początku) tych hipotez jest ogrom!!! Wybieramy zawsze taką ścieżkę, która testuje tą najbardziej ryzykowną tezę.

Grzesiek: Pracujecie na jakichś metrykach?

Piotr: Nasz CEO ma konkretne metryki za które jest odpowiedzialny, następnie schodzimy w dół i np. nasz CPO ma swoje metryki, które kontrybuują do metryk firmowych. Następnie my kontrybuujemy w naszych produktowych zespołach do tego, co jest wyżej - tworzy się takie drzewko.

Nie mamy w firmie OKRów, ale pracujemy na tzw. OITach, czyli Objective, Indicator, Task.

Objective to jest opisanie wizji i strategii produktu, później mamy Indicator, czyli liczbę, którą chcemy osiągnąć w pełnej zgodzie z wizją i strategią. Mamy też Task czyli to co chcemy zrobić, żeby dojść do tego miejsca. Dzięki temu mamy połączenie między wizją, strategią a backlogiem.

Kiedy zastanawiamy się nad jakim ficzerem mamy się właśnie skupić to zawsze wracamy do metryki i do celu i zadajemy pytanie, czy ta funkcjonalność przybliży nas do osiągnięcia naszego celu i metryki. Jeśli mamy zgodność, że tak jest to idziemy w tym kierunku - w przeciwnym razie porzucamy pomysł na rzecz innego, bo backlog idei jest zawsze nieskończenie duży.

Grzesiek: W jakiej metodologii pracujecie?

Piotr: U nas każdy Product Manager działa inaczej - nie mamy zasetupowanych żadnych product ops, bo nasze zespoły są różne, każdy z nas jest zupełnie innym Product Managerem i pracujemy zupełnie inaczej. W moim zespole pracujemy w SCRUMIE, ale z tego co kojarze to Przemek pracuje w SHAPE UP.

U mnie w zespole skupiamy się na znalezieniu dopasowania do reszty klientów, dla których ten produkt jeszcze nie jest dostępny publicznie. Staramy się przygotować odpowiednią ilość ficzerów, które będziemy chcieli dostarczyć w kolejnym kwartale i wycisnąć na maxa czas podczas pracy w danym kwartale. Żeby była jasność, nie chodzi tutaj o ciśnięcie developerów, ale o to żeby zaplanować pracę nad tym co jest najbardziej wartościowe dla naszych klientów w danym czasie.

Grzesiek: Co robi zespół developerski podczas fazy discovery?

Piotr: Działamy podobnie jak w Dual Track Agile. Mamy 3 refinementy podczas jednego sprintu, które trwają po 1h. Zazwyczaj jeden z nich jest bardzo operacyjny, a pozostałe to skupienie się na wizji i na długim terminie.

Chcę wiedzieć, co się dzieje w zespole deweloperskim, żebym był w stanie przewidzieć to, kiedy będziemy w stanie wejść na produkcję lub zająć się kolejnymi problemami. Z drugiej strony chcę, aby oni wiedzieli dokładnie, o czym ja myślę, bo im bardziej oni będą w mojej głowie, tym lepsze rozwiązania mogą dostarczać tym myśleniem o przyszłości.

Developerzy nie są często w stanie uczestniczyć w procesie discovery, ale ja jestem dla nich proxy osobą, która jest w stanie odpowiedzieć na ich pytania lub je dalej przekierować.

Przykład.

Developerzy pytają mnie czy jeśli dostarczymy 10% danego rozwiązania i będzie to działać w taki sposób (tutaj opisują proces) to czy klient będzie zadowolony.

Dzięki takim rozmowom jesteśmy w stanie znaleźć złoty środek pomiędzy effortem, a impactem, który jestesmy w stanie dostarczyć. Wcześniej wyglądało to w taki sposób, że przychodziłem do zespołu developerskiego z zakresem co należy zrobić - nie było to najlepsze podejście. Teraz staramy się wspólnie zrozumieć co możemy zrobić, aby osiągnąć dany cel, a zespół developerski był wykorzystany w najlepszy możliwy sposób.

Ja w tym procesie jestem taką piłeczką ping pongową między klientami, a developerami - to jest proces, który trwa.

Jeśli zaczynamy kolejny kwartał w październiku to faza discovery zadziała się już w sierpniu. W sierpniu pojawił się już pierwszy zarys rzeczy, na których będziemy skupiać się w przyszłym kwartale. Specjalnie nie nazywam tego zestawem ficzerów, a zestawem problemów, które chcielibyśmy rozwiązać w kolejnym kwartale. Często developerzy spotykają się sami i analizują co mogą zrobić, aby dostarczyć najlepsze rozwiązanie, a później dostarczają analizy.

Mówią:

“Możemy zrobić rzecz X w ciągu 2-3 dni, ale to będzie słabe dla klientów, możemy zrobić zakres rzeczy Y w przeciągu 1-2 sprintów lub dostarczyć idealne rozwiązanie, ale będzie to trwać tyle i tyle”.

Wtedy wspólnie siadamy i podejmujemy decyzję na podstawie naszej definicji jakości - tylko po to żebyśmy byli w stanie powiedzieć, że to jest dobry i wartościowy produkt dla naszych klientów.

Zawsze zostawiamy sobie taką przestrzeń niepewności, co oznacza, że nie chcemy tworzyć idealnej specyfikacji. Oczywiście jest też czas na pisanie kodu i tworzenie rozwiązań, ale nie mamy jakiegoś podziału 80/20 czy 50/50 - ten podział jest w miarę płynny i zależy od momentu w którym obecnie jesteśmy.

Czasami jest tak, że wiemy już, że ich nie dowieziemy i prowadzimy negocjacje ze stakeholderami. Są też sytuacje, że sami obcinamy scope bo wiemy, że pewne rzeczy nie są potrzebne. Mamy w zespole Data Analysta i UX Researchera, którzy dostarczają nam dodatkowych informacji, aby potwierdzić nasze przypuszczenia.

Leave a comment

Grzesiek: Poprzednią część skończyliśmy, gdy zacząłeś opowiadać o współpracy z Data Analystem oraz UX Researcherem. Możesz rozwinąć ten temat?

Piotr: UX Researcherka zajmuje się dwiema rzeczami. Pierwsza to praca z zespołem albo zespołami, a druga to jest bardziej praca strategiczna.

Część strategiczna zawiera pytania, które chcemy sobie zadać w obszarze produktu np. jak chcemy go rozwijać i w którym kierunku podążać. Wiąże się ona z dużą ilością rozmów z klientami.

Część, która dotyczy pracy z zespołami (mamy przypisane UX Researcherki na half time do zespołu) wiąże się trochę bardziej z obszarem konsultingowym.

Przykład.

Przychodzę do Asi i pytam:

“Hej, widzę problem X, chciałbym go zbadać i odpowiedzieć sobie na jakiś zestaw pytań z którym przychodzę”

UX Researcherka sugeruje mi sposób w jaki mógłbym na te pytania odpowiedzieć. Często przygotowuje scenariusz wywiadu, albo listę pytań, które spełniają podstawowe kryteria badawcze.

Podczas wywiadów wspiera mnie Designerka (nie Resercherka), która pomaga mi ustawiać User Testy (korzystamy z user testingu jako narzędzia do discovery lub weryfikacji hipotez) .

Po rozmowie wszystko dostarczam do UX Researcherki. To właśnie ona wspiera mnie w procesie syntezy informacji, które zebraliśmy podczas rozmów z klientami.

Podsumowując UX Resercherka jest ze mną na początku i na końcu drogi, a w środkowym etapie jestem wspólnie z Designerką (lub sam).

Jeśli chodzi o współpracę z Judytą, która jest Data Analytską to tutaj głównie skupiamy się na liczbach i metrykach. Judyta dostarcza mi zestaw metryk i danych, na które będziemy patrzeć oraz odpowiada na pytania, które zadajemy sobie podczas budowania naszego produktu np. Jacy klienci byli zainteresowani konkretnym fake doorem? Bywa też, że mamy jakiś problem, ale nie jesteśmy w stanie uświadomić sobie jego skali i tylko spojrzenie głęboko w dane jest w stanie nam coś podpowiedzieć.

Zazwyczaj proszę nie o dane, ale gotową odpowiedź w oparciu o liczby, które posiadamy. Czasami musimy zrobić kilka deep dive’ów, aby dowiedzieć się czy dobrze interpretujemy nasze dane - po prostu zadajemy coraz więcej pytań, które doprecyzowują pytanie, na którą chcemy poznać odpowiedź.

Współpracując z Judytą oraz Asią jestem w 100% pewny, że mogę polegać na ich wnioskach bo mają dużą większą wiedzę w swoich domenach niż ja.

Grzesiek: Mógłbyś opowiedzieć coś o narzędziu User Testing?

Piotr: User Testing to narzędzie, które służy do testowania prototypów i makiet. Pozwala nam dowiedzieć się czy ludzie rozumieją zaprojektowane interfejsy.Z ciekawszych badań, które robimy za pomocą user testing to badania card sortingowe, które pomagają nam zrozumieć architekturę informacji. Chodzi o to, aby content, który prezentujemy w produkcie był zrozumiały przez klientów.

User testing działa w taki sposób, że zadajmy konkretny zestaw pytań i przedstawiamy scenariusz, który jest zaprogramowany. Następnie ludzie z całego świata mogą wejść do narzędzia user testing i wykonują konkretny zestaw działań. W kolejnym kroku zadajemy listę pytań otwartych. W zależności jakie informacje otrzymujemy - dowiadujemy się czy jesteśmy usatysfakcjonowani z wyników, czy chcemy coś jeszcze zmieniać.

Warto pamiętać, że nie zawsze trafi się w swoją guropę docelowa więc trzeba brać poprawkę na wyniki tych badań, ale jest to narzędzie, które zdecydowanie ułatwia nam pracę i pozwala zbierać insighty w bardzo szybkim czasie bez skupiania się na rekrutacji osób do badań.

Grzesiek: Jak komunikujecie, gdy nie jesteście w stanie “dowieźć” rzeczy, które wcześniej ustaliliście?

Piotr: Raczej unikamy commitmentu dla klientów zewnętrznych. Czasami robimy to dla naszych wewnętrznych stakeholderów - oni wiedzą co będziemy robić w danym kwartale. Nasza roadmapa nie jest publiczna, więc klienci jej nie widzą …i nie wiedzą nad czym będziemy pracować.

Zawsze gdy przychodzi do mnie klient i chce danej funkcjonalności, a my jej nie posiadamy to mówię:

“Dziękuje, zastanowimy się jak rozwiązać Twój problem”

Nigdy nie daję bezpośrednio odpowiedzi, że daną rzecz zrobimy i uważam takie podejście za mocny anty pattern pracy Product Managera.

Nawet gdy stosujemy fake door, to po skorzystaniu klient widzi komunikat: “Dzięki, damy Ci znać jeśli pojawi się ta funkcjonalność”. Pozwala nam to unikać irytacji klientów i odpowiednio zarządzać ich oczekiwaniami.

Jeśli chodzi o wewnętrznych stakeholderów to rozwiązujemy to po prostu komunikacją. Dobrze działająca komunikacja wewnątrz firmy jest kluczowa. Robimy regularne spotkania sprint reviews, mamy całą stronę na której trackujemy progres każdego z naszych OITów i komunikujemy regularnie gdzie jesteśmy.

Zarówno zespół sprzedażowy jak i customer support ma ogromne zrozumienie nieprzewidywalności pracy w produkcie, co daje nam bardzo duży komfort pracy.

Grzesiek: Co robisz gdy przychodzi do Ciebie dział sprzedaży i próbuje Cię zmusić do zrobienia funkcjonalności X - w przeciwnym razie klient odejdzie.

Piotr: Koszt subskrypcji TIDIO wynosi miesięcznie od 20 do 50 USD, więc jedna sprzedaż nie zmienia aż tak dużo. Mamy dużych klientów z którymi chcemy być obecni na rynku, ale nasz zespół sprzedażowy jest bardzo świadomy i wie, że robienie rzeczy typowo pod jednego klienta jest złą drogą, którą nie powinniśmy podążać.

W Tidio ogromny plusem jest to, że wszyscy gramy do jednej bramki i mamy alignment jeśli chodzi o nasze wspólne cele. Jest to wyjątkowa i komfortowa sytuacja bo często zdarza się tak, że często sprzedaż naciska zespół produktowy i wymusza wiele funkcjonalności, jeśli Product Manager nie jest wystarczająco asertywny i umocowany w firmie.

Grzesiek: Myślałem, że idealna firma nie istnieje… a jednak :) Macie jakieś zależności między zespołami?

Piotr: Tak, oczywiście. Z jednej strony są to zależności produktowe, a z drugiej zależności w kodzie. Jeśli chodzi o to drugie to tutaj następuje komunikacja między developerami w różnych zespołach - wiemy kto zajmuje się konkretnym obszarem w różnych zespołach. Nie mamy ustalonego procesu, ale dość dużo komunikujemy się między sobą, gdy pojawiają się różnego rodzaju zależności.

Jeśli chodzi o zależności między produktowe to również staramy się ze sobą komunikować. Najwięcej zależności rozwiązujemy na etapie planowania kwartalnego. W przypadku planowania sprintów również staramy się komunikować cele i ustalać co będziemy robić, i od czego możemy zależeć.

Warto też wspomnieć, że w Tidio mamy pięciu Product Managerów, (cały czas szukamy więcej :) ), więc nie mamy aż tak dużego problemu z komunikacją i z mapowaniem zależności. Bardzo mocno też wspiera nas Marcin, nasz CPO.

Grzesiek: Z jakich narzędzi korzystacie w różnych obszarach?

Piotr: Z obszaru discovery to między innymi: Hotjar, User Testing, Maile oraz Zoom, aby rozmawiać z klientami. Wszystkie informacje zbieramy w Airtable, a nasze wnioski spisujemy w Notion.

Zbudowałem u siebie nawyk notowania każdej decyzję, którą podejmuję, aby później wiedzieć w jakich okolicznościach została podjęta. Wszystko po to, aby nikt nie przyszedł i nie powiedział, że coś zrobiliśmy i nagle nie działa inna funkcjonalność dla pewnych klientów. Zawsze notuję jakie mogą być konsekwencje danej decyzji, jakie podejmujemy trade-offy i dlaczego uważam, że są one do zaakceptowania.

Wracając do kolejnych narzędzi to oczywiście korzystamy z JIRA do zarządzania backlogiem. Jeśli chodzi o dokumentacja to jest ona po stronie developerów - zapisywana na Gitlabie.

Grzesiek: Przejdźmy do innego zestawu pytań. Jak zarządzasz czasem i dbasz o produktywność.

Piotr: Decyzja nad czym obecnie pracuje, jest dla mnie również decyzją produktową. Dużo rzeczy deleguję, bo zazwyczaj nie jestem najmądrzejszą osobą, aby się zajmować danym obszarem. Tak jak wspomniałem wcześniej, do UX Researchu mamy odpowiednią osobę, do analizy danych mamy też inną osobę, dokumentacja jest tworzona przez zespół developerski, itd itd.

Cały czas mam TO DO listę, którą staram się regularnie aktualizować, bo oczywiście są na niej też rzeczy, które przedawniają się. Staram się stawiać określony cel na każdy dzień - zazwyczaj jeden. Jeśli uda mi się go zrealizować to znaczy, że mój dzień był wartościowy.

Próbowałem też bookować czas na deep work, ale nie wiem czy w przypadku naszej roli jest to odpowiedni sposób bo często mi nie wychodzi. Jest dużo spotkań i rozmów z klientami, ale nie przeszkadza mi to w codziennej pracy, więc uważam że rezerwowanie kalendarze nie jest dla mnie idealnym rozwiązaniem.

Grzesiek: Co uważasz za najważniejsze umiejętności PMa?

Piotr: Na pewno komunikacja bo jest bardzo istotna w codziennej pracy. Tak jak wcześniej powiedziałem, traktuje siebie jak taką piłeczkę ping pongową pomiędzy developerami, klientami, użytkownikami i jeszcze nie wiadomo kim :)

Myślę, że warto dodać też umiejętność zadawania pytań w taki sposób, aby uzyskać wartościowe odpowiedzi.

Nie zapominajmy też o sztuce priorytetyzacji i zarządzania czasem. W ogóle zarządzanie swoim czasem i zarządzanie produktem są według mnie bardzo sobie bliskie.

Grzesiek: A co powiedziałbyś osobom, które chciałyby zostać product managerem?

Piotr: Powiedziałbym, że bardzo dużo jest produktowych guru, którzy mówią o tym jak ciężka jest to praca, a ja uważam, że jest to praca, która dostarcza bardzo dużo radości. Pracowałem na wielu różnych stanowiskach (operacje, support, sprzedaż, finanse) i mało jest takich ról, które są w stanie spowodować tak wiele uśmiechu na twarzy jak w produkcie.

Ważne jest, aby zrobić pierwsze kroki i przebić się do tego stanowiska. Bardzo dużo wiedzy jeśli chodzi o Product Managera jest dostępnej w internecie.

Warto też szukać takich początkujących pozycji w młodych organizacjach, bo można rosnąć razem z tą firmą.

Na pewno nie wydawałbym ogromnych pieniędzy na kursy bo praktyka jest dużo bardziej wartościowa i kształtuje nas w przekonaniu jakim Product Managerem chcesz być, a jakim nie.

Grzesiek: Dziękuje bardzo za wartościowy wywiad!

Piotr: Również dziękuje. Jeśli ktoś ma jakieś pytania to zapraszam do siebie na LinkedIn :)

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.

Marcin Jędrzejczak has spent the last 7 years building B2C and B2B products in fashion, dating, and cloud-based solutions for enterprise clients. He started his product career by learning from mistakes on his own startup. Currently, he works in Berlin as a Lead Product Manager, co-creating a portfolio of SaaS products at SAP. He’s a passionate advocate for building effective product systems. In his free time, he’s dedicated to triathlon and cycling.

Grzesiek: Hi Marcin, thanks for agreeing to talk as part of our product conversations initiative. I met Marcin a few years ago during the first Product Academy. Tell me what’s changed for you since then?

Marcin: Hi Grzesiek. At first, I worked in various startups. After two years of “playing” with small products, I ended up founding my own startup in the tech-fashion space. I was one of two founders, so all product-related topics fell on my shoulders: from ideation, through validation, product creation and launch, to fundraising and much more.

Unfortunately, after two and a half years we had to shut down the product, but I stayed in Product Management and ended up at NordCloud. That’s when we met during the Product Academy. I was building various products for corporate clients and was one of many Product Managers there. The products I worked on were more technical in nature and their main purpose was automating processes.

After about two years at NordCloud, my personal situation changed and I moved to Berlin looking for new growth opportunities—which led me to SAP. I never in my life expected I would work with such a product.

Grzesiek: Why is that?

Marcin: Anyone who’s had experience with SAP probably understands what I mean. It’s a product built by specialists for specialists—and you can see it everywhere. Of course, there are pros and cons to this. You work for a giant that’s a market leader in ERP management systems, which is undoubtedly a huge plus.

I didn’t join SAP directly, of course. I worked for a company that was essentially SAP’s VC arm, and our product fit the market so well that SAP, within a year’s time, absorbed our company into its structure.

We were thrown into the deep end because we had to quickly integrate with SAP’s core products while maintaining lightness in user experience—something SAP has never really had. It’s a very interesting and challenging wave of experiences because you’re joining a corporation with established structures and processes, yet you still need to work agile and preserve your uniqueness.

Grzesiek: Can you tell us more about SAP?

Marcin: One really interesting thing about SAP is that the company employs largely product specialists. You’re rarely hired as a Product Manager or Product Owner—much more often as a product specialist whose job is to care for the strategy and development of a given product.

In large companies, it’s typically the case that you have different specializations, and depending on how much you care about your career development in the company, you advance to higher levels in the organization. Of course, you can specialize in product, or you can become a manager of people who cares for the development of other product managers.

SAP is a very large organization with 100,000 employees, but in this division of mine—the one building cloud products—we have about 5,000 people. We have a lot of people responsible for product, along with various kinds of engineers, designers, and other roles.

Grzesiek: Can you tell us something about product roles at SAP?

Marcin: When it comes to product structures, here’s how it works: we have product specialists who work in roles like Product Owner or Product Manager.

The Product Manager and Product Owner work within a single cross-functional team. The PO is more technical and manages a 90-day backlog with their own roadmap—they’re responsible for hitting deadlines.

The Product Manager, on the other hand, cares more about product strategy over a 90-180 day horizon. They’re responsible for the discovery part and focus on stakeholder management—and there are many of those at SAP. Just understanding the sales structures alone is quite complicated because there are presales, sales, customer success departments, and as product people it’s important for us to understand the problems they’re trying to solve for clients and the goals they want to achieve.

Grzesiek: And what does your role look like?

Marcin: I work as a Lead Product Manager, so I’m responsible for product strategy on a roughly 2-year horizon. My job is to develop the product and manage the strategy of product teams. I work with six other Product Managers who manage roadmaps, and together we set goals that impact the roadmap in their areas.

My role comes down mainly to setting goals that are then executed according to the established roadmap. A well-constructed roadmap allows me to work better and communicate with stakeholders in such a complex environment as SAP.

Above me, I have a Head of Product who’s responsible for a given product or slice of a large product. One of the goals set by the HoP was to take 3 or 4 products that are sold separately and create one unified product that meets our customers’ needs. Another goal is to completely change the persona for our product—we want SAP to be usable by normal users, not just highly specialized SAP experts. That’s a pretty significant change because many processes and interfaces need to be heavily simplified.

Grzesiek: How do you work?

Marcin: We’re constantly trying to improve and learn from mistakes—basically continuously. This is because we currently have about 500 people working on this product across roughly a dozen teams. We’re combining three different work cultures because we’ve absorbed three different organizations over the last few years, each with their own processes, habits, and approaches that worked.

We currently work in monthly iterations that we call “Tactics.” Before each quarter, leaders meet to set the biggest goals we want to invest our time and energy in. All teams that contribute to this delivery plan must present their plan, and the Product Manager must “sell” this investment plan for the upcoming quarter. This is challenging because there are many teams and there are lots of dependencies. Although we try hard to be as independent as possible, they still exist.

Leave a comment

Grzesiek: How do you manage the Product Managers on your team?

Marcin: I try to operate at the intersection of coaching and mentoring. Every employee at SAP is evaluated twice a year based on goals set by their People Manager. It’s the same in my team.

We’ve established that we focus on three goals: two related to career development and one related to the product area. Twice a year we do competency reviews and evaluate ourselves using a 360-degree feedback approach.

Additionally, I try to have 1-on-1 meetings with each PM weekly or biweekly. These serve to share problems and exchange feedback. Feedback is a very important element of the meeting. I think it’s worth learning how to give and ask for feedback because that’s how we navigate our careers—especially now when we work remotely and I’m not always able to participate in the same meetings.

Grzesiek: You’ve mentioned a few times that remote work is somewhat different from office work. Can you say more about that?

Marcin: It’s mainly about different processes and communication.

Product Management, in my view, is largely about communication between people. Before, you could grab a coffee or cigarette after a meeting and sort certain things out. Remote work makes this a bit harder because mostly it would mean you’d need to stay in meetings all the time.

When we work remotely, new “tricks” emerge for Product Managers to ease communication—for example, by creating separate Slack channels that allow a given group to communicate properly in an asynchronous way. You wouldn’t think that by creating a Slack channel you could be more appreciated because you reduce the number of meetings.

You have to learn different new “tricks” that will help you save time, delegate tasks, and focus on your work. Otherwise you’ll drown in a sea of meetings and other unnecessary activities.

Grzesiek: What tools do you use during daily work?

Marcin: All delivery teams work on JIRA and that’s the so-called single source of truth. For discovery, we use a tool called craft.io which has similar functionality to AHA. It allows us to collect feedback from users and organize it appropriately. We can communicate with users through it, and on the other hand, people from the sales department also have access to it and can see everything clients report and how the entire communication looks.

We’ve divided discovery into two steps: problem shaping, where we try to understand the problem. Once the problem is defined, we move to solution shaping, which is the phase of delivering the functionality.

Teams also collaborate on Mural, and Teams is used for communication.

Grzesiek: What advice would you give to people who want to start a career in Product Management?

Marcin: For me, Product Management is kind of a life philosophy. I’d recommend thinking about what interests you in life and whether you have an instinct that can deepen that curiosity.

The thing is, no matter where you get hired—whether it’s a B2B product or B2X—your job is to find the problem that matters most, because that’s the only way you can win in the market. Without curiosity and the desire to dig deeper, you definitely won’t succeed, and that’s probably the main task for a Product Manager—solving your customers’ problems.

The second important skill is communication, but that probably doesn’t need additional comment since we’ve already discussed it during our conversation.

Grzesiek: How do you take care of your productivity?

Marcin: Productivity is an art of living for me. I try to minimize the number of things I have to do at once. In practice, this means I block out time on my calendar when I’m focused on work—this is my most productive time. I also dedicate it to conceptual work.

On the other hand, we set priorities together as a team. We always meet at the beginning and end of the week to set goals and come back to them.

Grzesiek: Thanks for this valuable conversation!

Marcin: Thanks!

If you liked this interview, click the 💙 and leave a comment.

If you’re not yet part of the Product Art community, I invite you to subscribe.

🇵🇱 Wersja polska / Polish original

Marcin Jędrzejczak przez ostatnie 7 lat pracował przy tworzeniu produktów B2C i B2B w branży mody, datingu czy produktów clodowych dla klientów enterprise. Swoją karierę produktowa zaczynał od uczenia się na błędach na własnym startupie. Aktualnie pracuje w Berlinie jako Lead Product Manager, współtworząc portfolio produktów SaaS w SAP. Jest dużym entuzjastą tworzenia skutecznych systemów produktowych. Prywatnie poświęcam się pasji do triathlonu i kolarstwa.

Grzesiek: Cześć Marcin, dzięki, że zgodziłeś się porozmawiać w ramach naszej inicjatywy produktowych rozmów. Z Marcinem poznałem się kilka lat temu podczas pierwszej Akademii Produktowej. Opowiedz co się zmieniło od tego czasu u Ciebie?

Marcin: Cześć Grzesiek, Na początku pracowałem w różnego rodzaju startupach. Po dwóch latach “zabawy” z małymi produktami, skończyło się to tak, że sam założyłem swój startup w branży technologiczno - modowej. Byłem jednym z dwóch founderów więc wszystkie tematy około produktowe były na mojej głowie: od pomysłu, przez walidację, stworzenie i wypuszczenie produktu, aż po finansowanie i jeszcze wiele innych tematów.

Niestety po dwóch i pół roku musieliśmy zamknąć produkt, ale ja dalej zostałem w Product Managemencie i skończyłem właśnie w NordCloud. To jest moment w którym się spotkaliśmy podczas Akademii Produktowej. Budowałem tam różnego rodzaju produkty dla klientów korporacyjnych i byłem tam jednym z wielu Product Managerów. Produkty, którymi się zajmowałem były bardziej techniczne i ich głównym zadaniem było automatyzowanie procesów.

Po około dwóch latach w NordCloud moja sytuacja życiowa się zmieniła i wyjechałem do Berlina szukając nowych możliwości rozwoju - po czym wylądowałem w SAPie. Nigdy w życiu nie podejrzewałem, że będę pracował z takim produktem.

Grzesiek: Dlaczego?

Marcin: Ci, którzy mieli styczność z SAPem chyba rozumieją dlaczego tak mówię. Jest to produkt tworzony przez specjalistów dla specjalistów…i to widać wszędzie. Oczywiście ma to swoje plusy i minusy. Pracujesz dla giganta, który jest liderem na rynku systemów do zarządzania ERP, co jest niewątpliwie dużym plusem.

Do SAPa oczywiście nie trafiłem bezpośrednio. Pracowałem w firmie, która była jako takim VC SAPa, i tak dobrze trafiliśmy z produktem na odpowiednim rynku, że SAP w perspektywie roku, wchłonął naszą firmę w swoje struktury.

Zostaliśmy rzuceni na głęboką wodę bo musieliśmy się szybko zacząć integrować z corowymi produktami SAPa, zachowując lekkość w user experience (czyli coś czego w SAPie nigdy nie było). To jest bardzo interesująca i pełna wyzwań fala doświadczeń bo dołączasz do korporacji z ułożoną strukturą i procesami, a nadal masz pracować zwinnie i zachowywać swoją unikatowość.

Grzesiek: Powiesz coś więcej o SAPie?

Marcin: Mega ciekawą rzeczą w SAPie jest to, że firma zatrudnia w dużej mierze specjalistów od produktu. Rzadko kiedy jesteś zatrudniony jako Product Manager lub Product Owner - dużo częściej jako specjalista od produktu i Twoim zadaniem jest dbanie o strategię i rozwój danego produktu.

W dużych firmach jest przeważnie tak, że masz różne specjalizacje i w zależności od tego jak bardzo dbasz o rozwój swojej kariery w firmie, tak szybko jesteś w stanie awansować na wyższe poziomy w organizacji. Oczywiście możesz iść w kierunku specjalizacji dotyczącej produktu, albo zostać managerem ludzi, który dba o rozwój innych product managerów.

SAP to bardzo duża organizacja i zatrudnia 100 000 ludzi, ale w tym dziale (moim), który buduje produkty chmurowe powiedzmy, że jest około 5000 osób. Mamy bardzo dużo ludzi odpowiedzialnych za produkt oraz różnego rodzaju inżynierów, designerów itp ról.

Grzesiek: Możesz opowiedzieć coś o rolach produktowych w SAPie?

Marcin: Jeśli chodzi o struktury produktowe to wygląda to w ten sposób, że mamy specjalistów produktowych, którzy pracują w rolach jako Product Owner lub Product Manager.

Product Manager i Product Owner pracuje w ramach jednego cross funkcjonalnego zespołu - PO jest bardziej osobą techniczną, która zarządza backlogiem 90 dniowym i ma swoją roadmapę - jest odpowiedzialny za to żeby dowozić terminy.

Natomiast Product Manager dba bardziej o strategię produktu w ujęciu 90 - 180 dni. Jest odpowiedzialny za część discovery i skupia się na zarządzaniu stakeholderami - w SAPie jest ich mnóstwo. Samo zrozumienie struktur sprzedażowych jest dość skomplikowano bo są działy presales, sales, customer success, a jako ludzie od produktu ważne jest dla nas zrozumienie ich problemów, które próbują rozwiązać dla klientów i celi, które chcą osiągnąć.

Grzesiek: A jak wygląda Twoja rola?

Marcin: Pracuje jako Lead Product Manager więc odpowiadam za strategię produktu na około 2 lata. Moim zadaniem jest rozwój produktu i zarządzanie strategią zespołów produktowych. Pracuje z sześcioma innymi Product Managerami, którzy zarządzają roadmapą i wspólnie ustalamy cele, które wpływają na roadmapę w ich obszarze.

Moja rola sprowadza się głównie do wyznaczania celów, które później realizowane są zgodnie z ustaloną roadmapą. Dobrze stworzona roadmapa pozwala mi lepiej pracować i komunikować się ze stakeholderami w tak złożonym środowisku, którym jest SAP.

Nad sobą mam Head of Product, który odpowiada za dany produkt lub wycinek dużego produktu. Jednym z celi postawionym przez HoP było to, żeby z 3 lub 4 produktów, które są sprzedawane osobno - stworzyć jeden, który jest unikatowy i zaspokaja potrzebny naszego klienta. Innym jest całkowita zmiana persony dla naszego produktu, czyli chcemy aby SAP mógł być używany przez normalnych użytkowników, a nie wysoko wyspecjalizowanych ekspertów SAP - to dość duża zmiana bo wiele procesów i interfejsów trzeba bardzo mocno uprościć.

Grzesiek: W jaki sposób pracujecie?

Marcin: Cały czas staramy się udoskonalać i uczyć się na błędach - w zasadzie w sposób ciągły. Jest to spowodowane tym, że mamy obecnie około 500 osób, które pracuje nad tym produktem łącznie w kilkunastu zespołach. Łączymy trzy różne kultury pracy bo wchłoneliśmy w ciągu ostatnich kilku lat, trzy różne organizacje, które miały już swoje procesy, przyzwyczajenia i podejścia do pracy, które działało.

Pracujemy obecnie w miesięcznych iteracjach, które nazywamy “Taktami”. Przed każdym kwartałem, liderzy spotykają się, żeby ustalić największe cele, w które chcemy zainwestować nasz czas i energię. Wszystkie zespoły, które kontrybuują do tego delivery planu, muszą przedstawić swój plan, a Product Manager musi “sprzedać” ten plan inwestycji na najbliższy kwartał. Jest to o tyle trudne, że zespołów jest dużo i istnieje masa zależności. Mimo, że staramy się jak najmocniej uniezależnić od innych to jednak one istnieją.

Leave a comment

Grzesiek: Jak zarządzasz Product Managerami, którymi masz w swoim zespole?

Marcin: Staram się działać na pograniczu coachingu i mentoringu. Każdy pracownik w SAPie jest oceniany dwa razy w ciągu roku na podstawie celów, które wyznacza People Manager. Tak samo jest u mnie w zespole.

Ustaliliśmy w zespole, że skupiamy się na 3 celach: dwa dotyczą rozwoju kariery, a jeden obszaru produktowego. Dwa razy do roku robimy rewizje kompetencji i oceniamy się w wg podejścia feedbacku 360 stopni.

Dodatkowo z każdym z Pm’ów staram się mieć spotkania 1-2-1 (co tydzień lub co dwa). Służą one do dzielenia się problemami i wzajemnym feedbackiem. Feedback jest bardzo ważnym elementem spotkania. Uważam, że warto nauczyć się dawać i prosić o feedback bo to dzięki niemu możemy nawigować swoją karierę - w szczególności obecnie gdy pracujemy zdalnie i nie zawsze jestem w stanie uczestniczyć w tych samych spotkaniach.

Grzesiek: Kilka razy już powiedziałeś, że trochę inaczej pracuje się zdalnie niż stacjonarnie. Możesz powiedzieć coś więcej na ten temat?

Marcin: Chodzi przede wszystkim o inne procesy i komunikację.

Product Management wg mnie to w dużej mierze komunikacja między ludźmi. Wcześniej można było wyjść na kawę czy papierosa po spotkaniu i dogadać pewne rzeczy. Praca zdalna odrobinę tę kwestię utrudnia bo w większości wychodziłoby na to, że musielibyśmy siedzieć cały czas na spotkaniach.

Gdy pracujemy zdalnie pojawiają się nowe “tricki” Product Managera, aby tą komunikację ułatwić np. poprzez zakładanie osobnych kanałów na Slacku, które pozwalają się danej grupie odpowiednio komunikować w sposób asynchroniczny. Nikt by nie pomyślał, że poprzez założenie kanału na slacku możesz być bardziej doceniany bo ograniczasz ilość spotkań.

Musisz nauczyć się różnych nowych “tricków”, które pozwolą Ci zaoszczędzić czas, wydelegować zadania i skupić się na swoich sprawach. Inaczej utoniesz w morzu spotkań i innych niepotrzebnych aktywności.

Grzesiek: A z jakich narzędzi korzystacie podczas codziennej pracy?

Marcin: Wszystkie zespoły delivery pracują na JIRA i to jest tzw. jedyne miejsce prawdy. Jeśli chodzi o discovery to pracujemy na narzędziu, które nazywa się craft.io które ma podobne funkcjonalności do AHA. Pozwala nam zbierać feedback od użytkowników i w odpowiedni sposób go kolekcjonować. Możemy dzięki niemu komunikować się z użytkownikami, a z drugiej strony, osoby z działu sprzedaży również mają do niego dostęp i widzą wszystko co zgłaszają klienci i jak wygląda cała komunikacja.

Discovery mamy podzielone na dwa kroki: problem shaping w której staramy się zrozumieć problem. Gdy problem jest już zdefiniowany, przechodzimy do solution shaping i to już jest faza dostarczania danej funkcjonalności.

Zespoły również współpracują na Muralu, a do komunikacji służą Teamsy.

Grzesiek: Co poradziłbyś osobom, które chciałyby rozpocząć karierę w Product Management?

Marcin: Dla mnie Product Management to trochę taka filozofia życia. Poleciłbym zastanowić się nad tym co Cię ciekawi w życiu, czy masz w sobie instynkt, który potrafi pogłębiać tą ciekawość.

Chodzi o to, że gdziekolwiek nie zostaniesz zatrudniony, czy to będzie produkt b2b czy b2x to Twoim zadaniem będzie znalezienie problemu, który jest najbardziej istotny bo tylko w taki sposób możesz wygrać na rynku. Bez ciekawości i chęci drążenia, na pewno Ci się to nie uda, a to chyba główne zadanie stawiane przed Product Managerem - rozwiązywać problemy swoich klientów.

Drugą ważną umiejętnością jest komunikacja, ale to chyba nie wymaga dodatkowego komentarza bo już poruszaliśmy ten temat podczas rozmowy.

Grzesiek: Jak dbasz o swoją produktywność?

Marcin: Produktywność to dla mnie sztuka życia. Staram się zminimalizować ilość rzeczy, które muszę robić na raz. W praktyce sprowadza się to do tego, że dodaje w kalendarzu bloki czasowe, w których jestem sfokusowany na pracę - jest to dla mnie najbardziej produktywny czas. Poświęcam go również na pracę koncepcyjną.

Z drugiej strony ustalamy wspólnie z zespołem priorytety. Spotykamy się zawsze na początku i na końcu tygodnia, po to, aby ustalić cele i do nich wrócić.

Grzesiek: Dzięki za wartościową rozmowę!

Marcin: Dzięki!

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.

Piotr Radziwon holds the roles of Head of Marketing and Head of Product Design at ULAM LABS. He’s passionate about new technologies, the crypto world, and exploring Asia. Over his more than decade-long career, he’s worked for brands like PlayStation, Electronic Arts, and InfoSHARE.

Grzesiek: Hi Piotr, thanks for joining the product conversations initiative, where we share our experiences. Tell me what you do and what your career has looked like so far.

Piotr: Hi Grzesiek, thanks for the invitation! I started my career about 10 years ago—initially as a mobile app designer, during the huge boom driven by smartphone market growth. Along the way, I became interested in related fields like product management and marketing, which are deeply connected to UX in many ways. This naturally led me to launch my own tech service in Southeast Asia. I wound down that venture at the start of the pandemic, and then became interested in fintech and the cryptocurrency market development.

Grzesiek: Can you tell me more about the tech service you developed in Southeast Asia?

Piotr: Sure, it was a fashion marketplace. We built a mobile app because the emerging middle class in Southeast Asia typically owns a phone but rarely a computer. We combined this with a recommendation engine that made it easy to search for and select clothing that matched each user’s taste on their phone.

Everything worked really well, and we were even planning to relocate to Asia for a while—until the pandemic hit and disrupted our plans. That market remains a fascinating place and in some ways reminds me of Poland in the 90s—a place full of opportunity.

Grzesiek: What happened when you wound down that operation?

Piotr: Having various experiences with partners around money transfers, I became interested in the money transfer space and technologies related to sharing money internationally, especially in combination with cryptocurrencies. That’s when my path crossed with Konrad, the founder of ULAM LABS, and we decided to work together.

Grzesiek: What do you do at ULAM LABS and how did you advance to the position of Head of Marketing & Product Design?

Piotr: At ULAM LABS, I hold two roles. One is Head of Marketing, where I’m responsible for developing marketing and sales strategy. The other is Head of Design, where I help develop our designers’ skills and assist them in building applications. Naturally, I also started developing my sales and marketing skills. Running my own service showed me how deeply connected UX is to marketing, and vice versa.

Grzesiek: What does ULAM LABS do?

Piotr: Our company creates cryptocurrency products. We’re an agency that primarily partners with international clients interested in building FinTech or blockchain-related services.

Share

Grzesiek: Do you have Product Managers on your teams?

Piotr: Yes, we have Product Managers who coordinate teams and maintain client relationships. Since our crypto projects are quite complex, Product Designers work very closely with Product Managers. This pair is responsible for gathering business requirements for the product. We run a lot of workshop sessions with clients, designed to confront their ideas with people who’ve already built similar products.

Grzesiek: Can you describe what these client workshops look like?

Piotr: Because we have people in the company with experience building crypto projects, we try to translate that into value for our current clients. The first thing we do is share our expertise with them. At the very beginning, it’s critical to map the entire service and gather all requirements—capturing this in a diagram that visualizes the complexity.

We spend a lot of time identifying areas that could be problematic for users, especially those just getting into crypto. I mention this intentionally because from experience, we know this is crucial in crypto projects. Many obvious things aren’t so simple in crypto (yet).

When it comes to testing our products, I believe market validation is the most valuable. You can spend a lot of time talking to different people, but you still might not get a definitive answer on whether the service will catch on or if people will actually use it at scale. On the other hand, spending a year or several months building an MVP can be very risky—especially in the crypto space, which is highly dynamic.

That’s why at ULAM LABS we try to create pilot versions with stripped-down functionality that are ready to ship to market. We remove almost everything beyond the product’s core, but this still allows us to invite users to test the app and gather feedback.

Grzesiek: How do you find the target audience to gather feedback from? Do you have any good methods for this?

Piotr: Our client relationships help us a lot. To build complex products in crypto, we need to stay very close to clients because they’re often deeply embedded in the communities around which they’re building their products. That’s because these are people united by a shared idea or fascination with a particular topic.

By working with a client, we can reach a specific community. And only by staying close to a group of enthusiasts can we understand them and identify their problems and goals.

So to answer your question directly—often our clients help us find our first testers.

Grzesiek: What’s it like building blockchain products, and how does it differ from other digital products?

Piotr: What characterizes crypto projects is that they’re financial services offering complex instruments, operating somewhat like banks, but they’re incredibly modern at the same time. This makes designing such products a challenge for designers and product managers—they need to analyze a complicated problem and wrap it in something very accessible that’s far ahead of banks and other financial institutions.

It’s a very interesting mix, and I think it’s quite unique and characteristic of crypto products.

In blockchain projects, you need to focus on and pay close attention to tiny details that in “regular” digital projects we’d handle automatically.

Building mass-adopted services is easier because people already have habits learned from other services. In crypto products, there’s a lot of difficult terminology and new financial mechanisms. Even simple things can be complicated. Take login mechanisms, for example—in crypto they’re often solved differently (like using a crypto wallet) than in standard services (email/password or SSO).

For people not in crypto, logging in with a digital wallet is completely new. It often takes many hours to learn how to access the app.

As the market matures, the scene will be taken over by players who deliver functionality in the easiest way possible—something that currently requires users to invest significant effort in education. That’s when adoption of blockchain-based apps will increase dramatically.

Leave a comment

Grzesiek: How did you acquire knowledge about crypto?

Piotr: Acquiring knowledge is another challenge for people trying to enter a new domain. I was fortunate to be in tech and have people around me who could explain a lot of new things.

I think I’d have had a much harder time learning about crypto and the market if I did it alone. This is another area that will definitely be addressed in the coming years.

On the other hand, as new services develop and gain adoption, less knowledge will be needed. Services will become simpler and more intuitive. We’ll be able to apply knowledge we already gained using standard apps.

Many of my friends outside IT bought their first cryptocurrencies through Revolut—this shows that actually, the simplicity of an app matters more to people than acquiring new knowledge and educating themselves. There aren’t that many enthusiasts in the market willing to jump into innovative apps. Nobody wants to spend hours listening to podcasts or watching educational videos before buying some crypto—that’s a huge barrier, and well-designed apps should combat it effectively through in-product communication.

For people who want to create crypto projects but don’t have prior experience, I think they should consider whether it aligns naturally with their approach to technology and developing new technologies.

Often, a big obstacle for people building these services is that they weren’t previously big technology enthusiasts, and now they’re struggling to cross a certain acceptance barrier or build fascination with the fact that this is a new market segment with a long road ahead (much is changing), while simultaneously much is incomprehensible. I think to work in this, you need to feel what it’s about—that it’s a highly technological approach to finance. I’m somewhat against people forcing themselves or jumping on the train just because there’s hype or a market for it. I think it could be a rough ride for them.

For people who want to think about crypto from an investment perspective, I’d definitely recommend a calm approach. But ultimately, everyone should find their own path in investing, and the more people I meet who build crypto services, the more I see a very measured approach to cryptocurrencies. There’s very little hype-driven behavior about new products hyped by various influencers—rather, there’s a long-term approach: investing in Bitcoin, for example, which isn’t backed by any institution, or other major projects. That seems like a sensible approach to me, one that resonates with me, although as I mentioned earlier, in investing everyone should find their own path and be responsible for their decisions.

Grzesiek: I understand that if you weren’t an enthusiast, you’d need to spend a lot of time acquiring that knowledge. Can you recommend something besides hard work and staying up-to-date with these developments to understand the language people in this space use?

Piotr: A lot of community gathers around Twitter—that’s a good place to follow different channels. It’s worth spending some time reading about major services, watching YouTube videos or content on other platforms that explain how financial services work in simple terms. Sometimes you need to check Investopedia to see what certain terms mean—a lot of knowledge acquisition, a lot of following news to stay current. If we found learning other areas of technology easy, we’ll probably find this topic equally easy to get hooked on.

Beyond the technical aspect, there are ideological and philosophical layers in crypto related to decentralizing finance—which you can agree or disagree with. The rest is mostly reading, listening, and educating yourself.

Grzesiek: You mentioned you have Product Managers at your company—what’s their background? Is it typically from building financial products or domain-related, and how did they end up as product managers at your company?

Piotr: Actually, we have very diverse backgrounds, and we’ve stopped thinking that prior crypto knowledge is a mandatory requirement. We bring in people who see potential in financial technologies and understand it. We place significant emphasis in the company on educating and sharing knowledge related to crypto within the team.

Grzesiek: Can you wrap up the topic of working on blockchain projects?

Piotr: Sure. What’s interesting is understanding why building crypto products is genuinely a significant challenge for the team creating such a project. First of all, it’s not one single factor—it’s a combination of factors.

Let’s start with the fact that these are financial services, so security is paramount. Smart contracts form the core of crypto financial services. These are relatively small programs that define the flow of money. Beyond creating them, they should also be audited, which is often time-consuming or expensive, but very important because it essentially defines the flow of money that users and our clients have invested.

Second, there’s a different type of security—one that designers should pay attention to, namely the sense of security. Because there’s a difference between a service actually being secure and it feeling secure and building trust. If a newly created product wanted to convince me to leave a lot of money there, I need to trust that product at every stage. From when I first encounter it to when I transfer money—everything must make me feel that at no point would I think it’s a flawed, unpolished, or even scam service. This puts more effort on Product Managers and Product Designers.

Another thing we discussed earlier is knowledge. It’s worth remembering that when we set out to build a service that resembles a bank in some way, we need to understand how all those financial mechanisms work. We need to acquire a lot of knowledge to operate comfortably with technical terminology during conversations with clients—which is a significant challenge, especially for PMs and designers, because they’re often on the front line of client interactions and they need to understand very well what the client means.

They also often have to propose optimal solutions that will work well from the users’ perspective, and this aspect requires an appropriate level of knowledge and expertise.

Another layer of complexity is that the market is quite fresh and there aren’t many design patterns to draw from. This means we can’t look at competitors and their solutions uncritically. Really, every competitor solution should be examined carefully, analyzed, and we should think about what gaps it has and what it does well, then apply the things that work while simultaneously rejecting things we expect could be problematic for users.

We talked earlier about login. And this is an example that’s easy to illustrate. Many services that require wallet connection for login have a button simply called “connect”—not “Sign up” and “Log in.” We need to think about what someone who’s always used “sign up” or “log in” buttons is thinking—how are they supposed to interpret “connect”? Is “connect” for me? Is this logging in, or is this creating an account? New and ambiguous terminology is a very problematic issue. There’s always a risk that even a beautifully designed service will repel many potential users because of such things. They might even think the service isn’t working yet because they can’t create an account there.

Grzesiek: You summed that up really well! Thanks for today!

Piotr: Thank you as well for an interesting conversation!

If you liked this interview, click the 💙 and leave a comment.

If you’re not yet in our Product Art community, I invite you to subscribe.

🇵🇱 Wersja polska / Polish original

Piotr Radziwon pełni role Head of Marketing i Head of Product Design w ULAM LABS. Pasjonat nowych technologii, świata krypto i eksploracji Azji. W ponad dziesięcioletniej karierze, pracował dla takich marek jak PlayStation, Electronic Arts czy InfoSHARE.

Grzesiek: Cześć Piotrek, dzięki, że dołączyłeś do inicjatywy produktowe rozmowy, gdzie dzielimy się swoimi doświadczeniami. Powiedz mi czym się zajmujesz i jak wyglądała Twoja dotychczasowa kariera?

Piotr: Cześć Grzesiek, dzięki za zaproszenie! Swoją karierę rozpocząłem około 10 lat temu - początkowo jako projektant aplikacji mobilnych - wtedy przeżywały wielki boom związany z rozwojem rynku smartfonów. W międzyczasie zacząłem interesować się pokrewnymi dziedzinami, takimi jak prowadzenie produktów czy marketingiem, które są w wielu obszarach powiązane z UXem. To wszystko, w dość płynny sposób, doprowadziło mnie do otworzenia własnej usługi technologicznej w Azji południowo-wschodniej. Jej rozwój zakończyłem na początku pandemii. Wtedy zainteresowałem się usługami finansowymi i także rozwojem rynku kryptowalut.

Grzesiek: Możesz coś więcej opowiedzieć o usłudze technologicznej, którą rozwijałeś w południowo wschodniej Azji?

Piotr: Jasne, to był marketplace odzieżowy. Stworzyliśmy aplikację mobilną, ze względu na to, że obecnie klasa średnia, która rozwija się w Azji południowo-wschodniej bardzo często posiada telefon, a rzadziej komputer. Co więcej połączyliśmy to z silnikiem rekomendacyjnym w taki sposób, aby na telefonie można było w łatwy sposób wyszukiwać i wybierać produkty odzieżowe, które pasują do gustu użytkownika.

Wszystko bardzo fajnie działało i planowaliśmy nawet zamieszkać przez jakiś czas w Azji… do momentu wybuchnięcia pandemii, która pokrzyżowała nasze plany. Tamtejszy rynek jest w dalszym ciągu bardzo ciekawym miejscem, który w pewnym sensie przypomina trochę Polskę w latach 90 - czyli miejsce wielu możliwości.

Grzesiek: Co wydarzyło się gdy zakończyliście tamtą działalność?

Piotr: Mając różne doświadczenia z partnerami na temat przesyłania pieniędzy, moją uwagę zwrócił obszar transferów pieniędzy i rozwój technologii związanych z dzieleniem się pieniędzmi w ujęciu międzynarodowym, a w szczególności w połączeniu z kryptowalutami. Wtedy moja droga z Konradem (założycielem ULAM LABS) po raz kolejny się skrzyżowała i postanowiliśmy ze sobą współpracować.

Grzesiek: Czym się zajmowałeś w ULAM LABS i jak awansowałeś na stanowisko Head of Marketing & Product Design?

Piotr: W ULAM LABS pełnię dwie funkcje. Jedna to Head of Marketing gdzie odpowiadam za tworzenie strategii marketingowej i sprzedażowej. Druga to Head of Design, gdzie pomagam podnosić kompetencje projektantów i pomagam im w tworzeniu aplikacji. Dość naturalnym powodem było dla mnie to, że zacząłem również rozwijać swoje kompetencje sprzedażowe i marketingowe. Prowadzenie własnej usługi uświadomiło mi jak bardzo UX jest połączony z marketingiem i na odwrót.

Grzesiek: Możesz opowiedzieć czym zajmujecie się w ULAM LABS?

Piotr: Nasza firma zajmuje się tworzeniem produktów krypto walutowych.Jesteśmy agencją, która współpracuje głównie z zagranicznymi klientami, którzy są zainteresowani budowaniem FinTechów lub usług związanych z blockchainem.

Share

Grzesiek: Czy macie w swoich zespołach rolę Product Managera?

Piotr: Tak, mamy Product Managerów i to właśnie oni zajmują się koordynacją zespołów oraz kontaktem z naszymi klientami. W związku z tym, że nasze projekty krypto są dość mocno skomplikowane, to Product Designer bardzo blisko współpracuje z Product Managerem. Zespół stworzony z tych dwóch osób odpowiada za zbieranie wymagań biznesowych w produkcie. Mamy bardzo dużo spotkań warsztatowych z klientami, które mają na celu skonfrontowanie pomysłu klienta z osobami, które już zjadły zęby na robieniu podobnych produktów.

Grzesiek: Opowiesz jak wyglądają takie warsztaty z klientami?

Piotr: Ponieważ mamy w firmie ludzi, którzy mają doświadczenie w tworzeniu projektów krypto, staramy się przełożyć je na obecnych klientów. Pierwsze co robimy, to dzielimy się naszą ekspertyzą z klientami. Na samym początku bardzo istotne jest zmapowanie całej usługi oraz zebranie wszystkich wymagań - zamknięcia tego w jakąś mapę, która obrazuje skalę złożoności.

Dużo czasu poświęcamy na znalezienie obszarów, które mogą stanowić problem dla użytkowników podczas korzystania z usługi - w szczególności dla tych, którzy dopiero rozpoczynają przygodę z kryptowalutami. Mówię o tym nieprzypadkowo, bo z doświadczenia wiemy, że w projektach krypto jest to bardzo ważne. Wiele oczywistych rzeczy, w projektach krypto (jeszcze) nie jest tak proste.

W kwestii testowania naszych produktów - walidacja rynku według mnie jest najbardziej wartościowa. Można poświęcić sporo czasu na rozmowy z różnymi ludźmi, ale ostatecznie wciąż nie dostajemy definitywnej odpowiedzi na to, czy usługa się przyjmie oraz czy ludzie będą masowo z niej korzystać. Z drugiej strony spędzenie roku czy kilku miesięcy na pracę nad MVP może okazać się bardzo ryzykowne - przede wszystkim w obszarze krypto, który jest bardzo dynamiczny.

Dlatego w ULAM LABS staramy się tworzyć wersje pilotażowe, które są okrojone z funkcjonalności na tyle, że nadają się do wypuszczenia na rynek. Usuwamy prawie wszystko co jest generycznym rdzeniem produktu, ale w dalszym ciągu pozwala nam to zaprosić użytkowników do skorzystania z aplikacji i zbierać feedback.

Grzesiek: A możesz powiedzieć skąd bierzcie swoją grupę docelową, od której zbieracie feedback? Macie na to jakieś fajne sposoby?

Piotr: Pomagają nam w dużej mierze nasze relacje z klientami. Aby tworzyć złożone produkty w branży krypto, musimy być bardzo blisko klientów bo bardzo często, to właśnie oni są mocno osadzeni w społecznościach, wokół których tworzą swoje produkty. Dzieje się tak dlatego, że są to osoby, których łączy pewna idea lub fascynacja nad danym tematem.

Współpracując z klientem jesteśmy w stanie trafić do konkretnej społeczności. A tylko dzięki byciu blisko danej grupy entuzjastów, możemy ich zrozumieć oraz sprawdzić jakie są ich problemy i cele, do których dążą.

Zatem wracając do pytania, często zdarza się, że to właśnie klienci pomagają nam zdobyć pierwszych testerów.

Grzesiek: Jak wygląda budowanie produktów w blockchain i czym różni się od pozostałych cyfrowych produktów?

Piotr: Charakterystyką projektów krypto jest to, że z jednej strony są to usługi finansowe, które oferują bardzo często złożone instrumenty finansowe i działają w trochę podobny sposób do banków, ale z drugiej strony są niezwykle nowoczesne. To wszystko sprawia, że projektowanie takich produktów jest wyzwaniem dla Designerów i Product Managerów bo muszą przeanalizować skomplikowany problem i opakować go w coś bardzo przystępnego, co znacznie bardziej wyprzedza banki i inne instytucje finansowe.

To jest bardzo ciekawy mix, wydaje mi się dość unikatowy i charakterystyczny dla produktów ze świata krypto.

W projektach blockchainowych trzeba skupić się i pochylić nad bardzo drobnymi szczegółami, które w “zwykłych” projektach cyfrowych tworzylibyśmy z automatu.

Tworzenie masowo zaadoptowanych usług jest dużo prostsze, bo jednak ludzie mają pewne nawyki, które poznali w innych usługach. W produktach ze świata krypto jest bardzo dużo trudnej terminologii i nowych mechanizmów finansowych. Nawet proste rzeczy mogą okazać się skomplikowane. Weźmy na przykład mechanizm logowania, który w świecie krypto jest bardzo często inaczej rozwiązany (np. za pomocą portfela kryptowalutowego), niż w standardowych usługach (za pomocą emaila/hasła lub SSO).

Dla osób, które nie obracają się w obszarze krypto, logowanie cyfrowym portfelem jest czymś zupełnie nowym. Wymaga nierzadko wielu godzin, aby zdobyć wiedzę jak dostać się do aplikacji.

Wraz z dojrzałością rynku, scenę zaczną przejmować gracze, którzy w najłatwiejszy sposób dostarczyli funkcjonalności, które obecnie wymagają od użytkowników bardzo dużo wysiłku w postaci edukacji. Wtedy adopcja aplikacji opartych o blockchain bardzo mocno się zwiększy.

Leave a comment

Grzesiek: A jak zdobywałeś wiedzę z obszaru krypto?

Piotr: Zdobywanie wiedzy to kolejne wyzwanie dla osób, które chcą dołączyć do nowej domeny. Ja miałem sporo szczęścia być w branży technologicznej i mieć wokół siebie ludzi, którzy mogliby mi wytłumaczyć bardzo dużo nowych rzeczy.

Wydaje mi się, że miałbym znacznie większy problem ze zdobyciem wiedzy na temat krypto oraz rynku, gdybym robił to sam. To jest kolejny obszar, który będzie na pewno adresowany w przeciągu najbliższych lat.

Z drugiej strony, wraz z rozwojem i adopcją nowych usług - tej wiedzy będzie coraz mniej potrzebne. Usługi staną się prostsze i bardziej intuicyjne. Będziemy mogli skorzystać z wiedzy, którą już zdobyliśmy podczas korzystania ze standardowych aplikacji.

Dużo moich znajomych spoza IT kupiło swoje pierwsze kryptowaluty przez Revolut - to pokazuje, że tak naprawdę prostota użycia aplikacji jest dla ludzi ważniejsza niż zdobywanie nowej wiedzy i edukowanie się. Na rynku nie ma zbyt dużo entuzjastów, którzy chętnie sięgają po innowacyjne aplikacje. Nikt nie chce spędzać wielu godzin na słuchaniu podcastów czy oglądaniu filmów edukacyjnych zanim kupi jakąś kryptowalutę - to jest bardzo duża bariera i dobrze zaprojektowane aplikacje powinny ją zwalczać skutecznie poprzez komunikację wewnątrz produktu.

Jeśli chodzi o osoby, które chciałyby tworzyć projekty krypto, ale wcześniej nie miały z tym doświadczenia, myślę, że powinny zastanowić się, czy to naturalnie współgrałoby z ich podejściem do technologii i do rozwoju … nowych technologii.

Często sporą przeszkodą dla ludzi, którzy tworzą takie usługi jest to, że wcześniej nie byli wielkimi entuzjastami nowych technologii i teraz mają problem, żeby przeskoczyć pewną barierę akceptacji czy zbudowania fascynacji tym, że jest to nowy segment rynku, przed którym jeszcze długa droga (wiele się zmienia), a jednocześnie wiele rzeczy jest niezrozumiałych.Wydaje mi się, że żeby pracować w tym, trzeba poczuć z czym się to wiąże. Czyli właśnie z tym, że jest to mocno technologiczne podejście do świata finansów. Jestem trochę przeciwny temu, żeby ludzie zmuszali się, czy na siłę wskakiwali do pociągu tylko dlatego, że teraz jest jakiś hype lub jest na to rynek. Myślę, że wtedy może być dla nich ciężka przeprawa.

Natomiast dla ludzi, którzy chcieliby na przykład od strony inwestycyjnej pomyśleć o krypto, to zdecydowanie doradziłbym raczej spokojne podejście. Aczkolwiek każdy tak naprawdę w inwestowaniu powinien znaleźć własną drogę i myślę, że im więcej spotykam ludzi, którzy tworzą usługi krypto, tym więcej widzę bardzo spokojnego podejścia do kryptowalut.Bardzo mało jest nakręcania się na nowe produkty, które są wychwalane przez różnych influencerów, raczej jest podejście długofalowe – inwestowanie, np. w Bitcoina, za którym nie stoi żadna instytucja lub inne duże projekty. I to wydaje mi się takie rozsądne podejście i takie, które ze mną rezonuje, aczkolwiek jak wspomniałem wcześniej, w inwestowaniu każdy powinien znaleźć własną drogę i być odpowiedzialnym za swoje decyzje.

Grzesiek: Rozumiem, że jeśli ktoś nie był entuzjastą, to musi poświęcić bardzo dużo czasu na zdobywanie tej wiedzy. Czy możesz coś jeszcze polecić, oprócz ciężkiej pracy i bycia na bieżąco z tymi nowinkami, żeby rozumieć język, którym się porozumiewają osoby w tym obszarze?

Piotr: Sporo społeczności skupia się wokół Twittera – to jest fajne miejsce, żeby śledzić różne kanały. Warto spędzić trochę czasu czytając o dużych usługach, oglądając video na YouTubie czy innych platformach, które wytłumaczą w prosty sposób, jak działają usługi finansowe. Czasami też trzeba zajrzeć na Investopedię, żeby zobaczyć co znaczą niektóre terminy - sporo przyswajania wiedzy, sporo śledzenia nowinek, żeby być na bieżąco. Jeżeli coś takiego przychodziło nam łatwo w innych obszarach technologii, to prawdopodobnie z tym tematem też będzie nam łatwo się zarazić.

Poza obszarem technologicznym w kryptowalutach są też warstwy ideowe i filozoficzne związane z decentralizacją finansów - z którymi można się zgadzać, ale można się też nie zgadzać. Reszta to już raczej czytanie, słuchanie i edukacja.

Grzesiek: Mówiłeś, że macie w swojej firmie Product Managerów – jaki oni mają background czy to jest background typowo związany z budowaniem produktów finansowych, czy związanych typowo z domeną – jak oni trafili do was, na jakiej zasadzie zostali product managerami?

Piotr: Tak naprawdę background mamy bardzo różny i przestaliśmy już myśleć o tym, że wcześniejsza wiedza w krypto jest obowiązkowym wymaganiem. Ściągamy do siebie osoby, które czują potencjał w technologiach finansowych, i które go rozumieją. Przykładamy sporą wagę w firmie na to, żeby wyedukować i przekazać wiedzę związaną z krypto, wewnątrz teamu.

Grzesiek: Czy możesz spiąć klamrą temat pracy nad projektami blockchainowymi?

Piotr: Jasne. Ciekawym aspektem jest zrozumienie, dlaczego tworzenie produktów krypto jest naprawdę sporym wyzwaniem dla zespołu tworzącego taki projekt. Przede wszystkim nie ma jednego czynnika, który to powoduje, jest raczej zespół czynników.

Zacznijmy od tego, że to są usługi finansowe, więc bezpieczeństwo jest bardzo ważne. Takim rdzeniem usług finansowych w kryptowalutach są smart kontrakty. To są stosunkowo niewielkie programy, które definiują przepływ pieniędzy. Poza tym, że można je stworzyć, to powinno się je także audytować, co jest często czasochłonne lub drogie, ale bardzo istotne, bo to w pewien sposób definiuje przepływ pieniędzy, które zostały zainwestowane przez użytkowników i naszych klientów.

Druga sprawa to jest inny typ bezpieczeństwa. Takie, na które powinien uwagę zwrócić projektant, czyli w zasadzie poczucie bezpieczeństwa. Bo jedną sprawą jest to, że usługa jest bezpieczna, a druga sprawa jest taka, że ona powinna budzić poczucie bezpieczeństwa i budować zaufanie do siebie.Jeśli nowopowstały produkt chciałby mnie zachęcić do tego, żebym zostawił tam sporo pieniędzy, to ja temu produktowi muszę ufać na każdym etapie. Od kiedy się z nim spotkałem po raz pierwszy, po przelanie tam pieniędzy - wszystko musi spowodować, że w żadnym momencie nie pomyślę, że to jest wadliwa usługa, wstępna, niedopracowana - lub nawet scam. Narzuca to więcej wysiłku po stronie Product Managerów i Product Designerów.

Kolejna rzecz, o której wcześniej rozmawialiśmy to wiedza. Warto pamiętać, że kiedy siadamy do zrobienia usługi, która w jakiś sposób przypomina bank - musimy poznać funkcjonowanie tych wszystkich finansowych mechanizmów. Musimy przyswoić sporo wiedzy, żeby swobodnie operować technicznym językiem podczas rozmów z klientami, co jest sporym wyzwaniem, szczególnie dla PM-ów i dla projektantów, bo to oni są często na pierwszej linii rozmowy z klientami i to oni muszą rozumieć bardzo dobrze, co klient ma na myśli.

Często muszą też zaproponować optymalne rozwiązania, które będą dobre z punktu widzenia użytkowników i ten aspekt wymaga odpowiedniego poziomu wiedzy i eskperckosći.

Kolejną warstwą komplikacji jest to, że rynek jest dość świeży i nie ma zbyt dużo wzorców projektowych. To sprawia, że nie możemy patrzeć na konkurencję i ich rozwiązania bezkrytycznie. Tak naprawdę każde rozwiązanie konkurencji powinniśmy wziąć na warsztat, przeanalizować, zastanowić się jakie one mają dziury, a co robi fajnie i zastosować te rzeczy, które robi dobrze, a jednocześnie odrzucić te rzeczy, które spodziewamy się, że mogą być problematyczne dla użytkowników.

Rozmawialiśmy wcześniej o logowaniu. I to jest taki przykład, który łatwo zobrazować. Wiele usług, które wymagają połączenia portfela do logowania na swojej stronie ma przycisk, który nazywa się po prostu „connect”, a nie ma “Załóż konto” i “Zaloguj”. Musimy zastanowić się co myśli sobie osoba, która wcześniej zawsze używała przycisku „załóż konto” lub „zaloguj się” – jak ona ma interpretować „connect”? Czy to “connect” to jest coś dla mnie? Czy to jest zalogowanie, czy to jest założenie konta?Nowa i niejednoznaczna terminologia jest bardzo problematyczną kwestią. Zawsze jest ryzyko, że nawet najlepiej zaprojektowana usługa, przez takie rzeczybędzie odbijała od siebie wielu potencjalnych użytkowników. Mogą nawet pomyśleć, że ta usługa jeszcze nie funkcjonuje bo nie da się tam założyć konta.

Grzesiek: Bardzo fajnie to podsumowałeś! Dzięki za dzisiaj!

Piotr: Również dziękuję za interesującą rozmowę!

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.

Krzysztof Heyda has been building digital products for 8 years. He’s most passionate about mobile, retail, and high-volume B2C products. He’s led apps like Sizeer App, Mój Tauron, and żappka.

Grzesiek: Hi Krzysiek. Thanks for sharing your product-building experience with us today.

Krzysiek: Hey Grzesiek. Thanks so much for the invitation. I’ve been a Product Manager for about eight years now. I’ve carved out a niche for myself in mobile technologies, and retail is my favorite industry. I’ve had the chance to work on some great large-scale apps—for example, Sizeer, which was innovative and integrated with beacons. Beacons were all the rage worldwide back then, and we became the second company in Poland to implement that solution.

I also worked on an app for Tauron, Poland’s largest energy company. In my opinion, Mój Tauron is the most beautiful app in that industry.

I was also the Product Owner for the żappka app and products around it—like Żappka Pay and Żappka Post.

For a while, I was Head of Product at uPacjenta—a medtech startup—and now I work with both startups helping them launch products and with large retail companies.

Grzesiek: Could you tell us more about each of these products?

Krzysiek: Nine years ago, I saw myself working in internet marketing and that’s the kind of job I was looking for. That’s how I ended up at Marketing Investment Group—a company that owns the Sizeer, Timberland, Umbro, Lotto retail chains and a few other brands. It’s a Polish company based in Krakow with hundreds of stores across Poland and Central Europe. I landed in their marketing department, but when my boss noticed my passion for new technologies (I’m a gadget geek 😊), he decided to take a risk and let me build a mobile app. Back then, I didn’t even know the term “product management”—it was completely foreign to me. We knew we wanted to build a mobile app for a loyalty program.

It was built against every best practice we now try to promote, but somehow it worked. The app was created by a small Software House team. It’s worth noting that we built it for three operating systems back then, because Windows Phone still existed.

The app was innovative for its time—it was the second app in Poland integrated with beacons that served content based on where the person was in the store. Each location had three beacons covering men’s, women’s, and branded zones.

That was my first venture into product management—even though I didn’t know the terminology yet 😊

Grzesiek: What year was that?

Krzysiek: That was about eight years ago, so 2015. At Marketing Investment Group, we also built something called the Virtual Shelf—a product created together with Nike. It was a network of 40” touchscreens with a barcode scanner connected under each one. When no one was using the screen, it displayed marketing materials. Customers could scan codes from shoes or shirts to check available sizes, other colors, or styling suggestions on the screen. We also created interactive content for the screens—like a photo editor that was the basis for contests in our stores. Interestingly, the screens were also integrated with gyroscope-enabled beacons that detected movement. When a customer picked up a shoe, related materials appeared on the screen.

After leaving Marketing Investment Group, I realized I was good at these “tech building blocks,” which allowed me to transition to Tauron, where I was recruited as a smart home specialist. They were planning to build a mobile app, so they encouraged me to join that team. At Tauron, I heard terms like “Product Owner” for the first time and went through various trainings that taught me best practices, mainly focused on Scrum.

I’d had good experiences working with external software houses before, and it was the same there. At Tauron, we had a much larger team of about 10–12 people. We had very talented developers, even though they were young. Our Scrum Master was demanding and made sure everything followed the Scrum Guide. I can confidently say I worked in a team that knew how to self-organize perfectly—we’d now call that an empowered team. We created what I believe was the best, and certainly the most beautiful, energy utility app in Poland. By that point, I knew I wanted to pursue a career building digital products—preferably mobile. That’s how I ended up at Żabka.

Grzesiek: Do you think a good environment and the right mindset from developers convinced you to go down this path?

Krzysiek: Absolutely, because building products was simply incredibly fun. Of course, there were sometimes tough moments, problems, stressful situations where you were almost afraid to open your laptop, but overall I had a blast creating mobile apps. Even today I stay in touch with most of those people, both professionally and personally.

Grzesiek: Let’s move on, because I think we’re entering the phase of your career you’re most proud of. Am I right?

Krzysiek: Yes, exactly. We’re getting to Żabka. Now I think over 10 million users use the żappka app (according to an article I read). The product adoption has been incredible.

At Żabka, I encountered this approach for the first time: the business team was dedicated to a specific app. As the product owner, I was responsible for the frontend and what we called the shallow application backend layer. There was another product owner handling the backend. Above us was my manager who coordinated our work.

Within our team was a UX person who handled everything related to user experience in our app—she looked at the entire user journey from when someone walks up to the checkout with their phone. We also had a designer at our disposal.

We had a dedicated marketing person (just for our app) who coordinated with the broader company marketing team to align all marketing goals.

We also had a content creator and data analysts who handled analytics. In short, we had a very complementary team that allowed us to work end-to-end with the product.

Grzesiek: That’s great. It’s not common to have a marketing person assigned to your product. Usually it’s a separate stakeholder you have to “deal with” and align goals with.

Krzysiek: Exactly, and it definitely helped that their goals were aligned with mine. The dedicated marketing person supported us in acquiring new users and creating campaigns specific to our app.

As the app grew, I had to bring in people from outside our team. When we built Żappka Post—a service that let people pick up packages via the app at Żabka stores—we had a stakeholder embedded in those structures at Żabka. When we needed to make changes related to checkout software, that was a different department and completely different people.

Another player was the design firm that created the look and feel of our product. They were a firm that designed the UI for Slack, Uber—top-shelf apps. I say “were” because Twitter bought them a year ago.

Leave a comment

Grzesiek: Before we move on, can you tell me what working with them was like?

Krzysiek: For example, they’d walk through stores and observe how everything worked in detail—they helped shape the entire “żappka model.” Their role wasn’t just designing interfaces, but also discovery in the broadest sense—they conducted interviews with Żabka customers and employees to map the entire process.

We worked with them in roughly three-to-four-month intervals. When we knew what we wanted to build in the upcoming quarter, we’d meet with them (later just online) for two-to-three-week design sprints where we’d design the relevant features.

Grzesiek: What level were you operating at in Żabka? It sounds like you had a lot of ownership. Who was responsible for vision, strategy, roadmap, and backlog?

Krzysiek: In that structure, the digital director was responsible for the vision. Everyone I mentioned earlier reported to him in some capacity, directly or indirectly. He was the person who understood the vision and set the main direction. Product Owners owned their individual backlogs and helped co-create the roadmap.

Grzesiek: Is there anything else you want to add about żappka?

Krzysiek: I have two more things. First, we had an in-house lab that let us test everything we wanted from a UX perspective and validate whether our hypothesis was correct, even at the mockup stage.

Second, the development team was external, so once again this setup worked very well, and I felt very comfortable working with an external Software House.

Grzesiek: What’s it like working with a Software House from the client perspective?

Krzysiek: In Żabka’s case, it was based on a Time and Material model. We worked in two-week Scrum sprints, maintaining all the ceremonies. Reviews let us show internal stakeholders what we were actually working on 😊

I really enjoy working with an external Software House, even though I know many people might disagree. I think I just got lucky and chose a really good partner. In this model, you completely eliminate all HR issues and management headaches, because there’s always a Project Manager on the other side handling that.

What matters in working with a Software House is having an engaged team that cares about what they do. At some point (in Żabka), we started involving developers more directly in creating requirements so they weren’t just a delivery partner. This approach enabled two-way collaboration—the team came to us with ideas for solving problems rather than just waiting for finished tasks.

We also had a business analyst on the Software House side whose job was to break down problems into smaller pieces. I’ll admit, I’m much more business-oriented than technical. I understand technology, but I’ve never coded, and having an analyst who was a step closer to the technology could spot any gaps in requirements.

Grzesiek: What happened after Żabka?

Krzysiek: I left Żabka two years ago, and the last two years have unfortunately been a bit of jumping around between different companies and positions. During that time, I was searching for my path a bit.

At one point, I got an offer to be Head of Product for uPacjenta startup. The company has a product that lets you order blood tests at home—mainly blood draws at home. The sample is then taken to a lab and the next day you can see the results online and consult with a doctor virtually.

It was a Head of Product role combined with a Product Manager role, since I was the only product person at the company. I managed a team of about 15 technical people. There were mainly backend, frontend people, testers, and designers.

The uPacjenta ecosystem has several different products. The main one is obviously the entire blood test ordering process—the whole purchase journey. There’s also a product for medical staff that helps them manage their work throughout the day and informs them about what, who, and where to test. Beyond that, I had to oversee things like APIs for partners and admin panels.

At some point, our main goal was optimizing the customer’s ordering journey—increasing conversion in the number of tests ordered. When I arrived, a new ordering flow (already prepared before) was launching. It didn’t fully meet our expectations, so we started experimenting—step by step analyzing where people were dropping off in the funnel. We looked for places we could improve.

Grzesiek: Can you tell us about these experiments? What did they look like?

Krzysiek: We experimented the most in the ordering area.

These were mainly A/B tests or sometimes even A/B/C tests, where we had a few versions we wanted to check. We gradually tested the funnel to understand how people used our product step by step.

We directed the appropriate percentage of traffic to the appropriate user segments and watched how they converted. We saw where people dropped off and where they converted better.

Experiments ran for about 2 weeks—you had to wait a bit to see concrete trends.

We used a tool that let us edit a lot without needing to involve developers.

At some point, we created a team dedicated solely to conversion optimization—a business-technical team that day-to-day fought to increase it.

Share

Grzesiek: What came after uPacjenta?

Krzysiek: I landed at Future Mind, the company that built żappka with me 😊 I work there as a digital products consultant. Future Mind is a software house where we build many large apps—for example, for LPP, e-obuwie, Super-Pharm, Hebe, and Żabka.

Future Mind has lots of great projects focused on retail (but not exclusively). It also delivers not just in the delivery phase, but can create a product from concept through definition to delivery and growth.

Grzesiek: Okay, let’s shift gears a bit. What competencies do you think are key for a Product Manager?

Krzysiek: Definitely assertiveness, because usually people have many needs and even more ideas. What’s worse, they don’t just bring needs, but ready-made solutions. The art of saying no and properly arguing your decisions is crucial.

Another important aspect is domain expertise, because it genuinely makes a huge difference. Of course, many people will disagree with me again, but I see a real difference in my performance and the way I work when I’m doing things in an area where I actually have deep knowledge.

I also think it’s crucial not to view a product as this monster that must have tons of features and constantly build something new — instead, look at what we’ve already implemented and leverage existing solutions to solve a problem differently.

Grzesiek: If not for Product Manager, then what?

Krzysiek: Definitely something creative — that’s really important to me. What I love most about product management is that something I create (obviously not alone), I bring to life — I have real impact on it. It’s great that when I go to Żabka, I see someone scanning the app at the checkout, or people picking up packages. I feel like I’m solving a real problem that customers actually face.

If not for product management, I’d probably end up in marketing — in the creative side, content and creation.

Grzesiek: What would you advise people who want to become product managers?

Krzysiek: As you can see from my story — it was pure chance that brought me here. My path is atypical, irreproducible, you can’t plan something like that.

I think the best entry point for someone coming from outside is UX or business analysis. As a business analyst, you learn many of the competencies needed to recognize the validity of requirements — how they’re created, gathered, and refined. You learn to work in a development team, you see how others work, what the dependencies are between different technical and business roles. Then you can more easily move up a level, take on a bit more responsibility — no longer just being the person who polishes requirements, but also synthesizing them into a whole and creating a product.

Another great option is being a specialist in a given domain — having what we call domain knowledge. It’s not uncommon for someone to be a specialist in a particular area and then move to a team building products for that area. Despite gaps in product management tools, thanks to their unique expertise, they’re able to accomplish the core task of a product manager — determining what’s truly valuable for users of that product. And product knowledge, tools, and techniques — those can always be picked up later.

Grzesiek: What’s your take on people coming from outside the industry into new domains?

Good ideas and inspiration can come from many industries and cross-industry. I try to observe different industries because we work in broadly defined new technologies, which touch many fields and products in our lives. Even though I’m interested in retail, I look at what’s emerging in other industries because maybe it could be adapted for our needs.

You have to keep your finger on the pulse, not get stuck in your favorite industry, but have broader horizons. You need to look at completely different markets, check out what’s happening in the US and Asia. Many things are totally different there, and some technologies are at completely different stages. A great example is payments and the level of advancement in a given market.

The way apps are built in Asia is completely different from ours. For example, Żabka as a group has several apps, but in Asia they’d probably have one app covering all user needs, like Gojek in Indonesia.

It’s worth drawing inspiration from other markets and industries — it’s not about copying, it’s about learning from others’ mistakes and successes.

My favorite example is voice technology. If I were working in that industry, I’d definitely look to the United States, which is much more advanced in that area. By looking at them, you already know what works, what doesn’t, and why.

I really encourage people to look around, because inspiration can come from really many, sometimes surprising, places.

Grzesiek: Is there anything you’d like to share that I haven’t asked you about yet?

Krzysiek: One of my more interesting experiences is definitely this unfortunate frequent job hopping. My last two years have been a lot of jumping between several companies. Each of those companies was awesome, they create great products. I didn’t leave any of them because it was toxic or anything — I just didn’t quite fit with the industry or type of product. But in the end, those two years of changes helped me discover exactly what I don’t want to do, and that’s practically just as important as knowing in product work what we don’t want to build ;). After Żappka, I knew I liked working with software houses and creating B2C mobile apps. I wanted to try something different, see if the grass was greener elsewhere. Test myself in different directions and various product types.

If someone is planning their career, they really need to try many things to see what suits them and what doesn’t — what excites them and what doesn’t.

Grzesiek: Thank you for the conversation!

Krzysiek: Thanks to you too, and see you on Product Art channels!

If you liked this interview, click the 💙 and leave a comment.

If you’re not yet part of the Product Art community, I invite you to subscribe.

🇵🇱 Wersja polska / Polish original

Krzysztof Heyda tworzy produkty cyfrowe już od 8 lat. Najbardziej lubi mobile, retail i produkty z dużym wolumenem klientów B2C. Był odpowiedzialny min. za aplikacje Sizeer App, Mój Tauron i żappka.

Grzesiek: Cześć, Krzysiek. Dzięki, że podzielisz się dzisiaj swoimi doświadczeniami z obszaru budowania produktów.

Krzysiek: Cześć Grzesiek. Serdecznie dziękuję za zaproszenie. Jestem Product Managerem od około ośmiu lat. Specjalizuję się (znalazłem sobie taką niszę) w technologiach mobilnych,a moja ulubiona branża to jest retail. Miałem okazję robić parę fajnych, dużych aplikacji – na przykład dla Sizeera, która była innowacyjna, zintegrowana z beaconami. Wtedy beacony były szałem na całym świecie, a my to wdrożyliśmy to rozwiązanie jako drudzy w Polsce.

Pracowałem również nad aplikacją dla Tauronu, czyli największej firmy energetycznej u nas w kraju. Aplikacja Mój Tauron – według mnie najładniejsza aplikacja w tej branży.

Byłem też Product Ownerem aplikacji żappka oraz produktów wokół niej – np. Żappka Pay i Żappka Post.

Przez pewien czas byłem Head of Product w uPacjenta – to jest startup z obszaru medtech, a teraz pracuję zarówno ze startupami, którym pomagam wystartować z produktami, jak i z dużymi firmami min. z obszaru retail.

Grzesiek: Mógłbyś opowiedzieć trochę więcej o każdym z tych produktów?

Krzysiek: Jeszcze dziewięć lat temu widziałem się w marketingu internetowym i takiej pracy szukałem. Tak trafiłem do Marketing Investmen Group – to jest firma, która jest właścicielem sieci Sizeer, Timberland, Umbro, Lotto i jeszcze paru innych marek. To jest polska firma z siedzibą w Krakowie, która ma paręset sklepów w Polsce i w Europie Centralnej. Tam trafiłem do działu marketingu, ale jak już zauważyli moje zamiłowanie do nowych technologii (jestem gadżeciarzem 😊) to mój ówczesny szef postanowił zaryzykować i powierzyć mi zrobienie aplikacji mobilnej. Wtedy nie znałem takiego terminu jak „product management”. To w ogóle była jakaś abstrakcja. Wiedzieliśmy, że chcemy robić aplikację mobilną do programu lojalnościowego.

Była ona robiona wbrew każdej zdroworozsądkowej praktyce, jaką teraz próbujemy szerzyć, żeby robić tego typu produkty-no ale koniec końców – wyszła. Aplikacja była tworzona przez bardzo mały zespół po stronie Software House. Warto dodać, że wtedy jeszcze robiliśmy aplikację na trzy systemy, bo był jeszcze Windows Phone.

Aplikacja była na tamten moment innowacyjna – to była druga w Polsce aplikacja, która była zintegrowana z beaconami, które serwowały content w zależności od tego, w jakim miejscu osoba znajdowało się w sklepie. W każdym salonie mieliśmy po trzy beacony - strefy męskie, damskie i marki.

To było moje pierwsze wejście w product management – mimo, że jeszcze wtedy nie znałem tych słów 😊

Grzesiek: W którym to było roku?

Krzysiek: To było około ośmiu lat temu, czyli w 2015. W Marketing Investment Group zrobiliśmy jeszcze tzw. Wirtualną Półkę – był to produkt robiony wspólnie z Nike. Była to sieć 40” ekranów dotykowych, a pod każdym podłączony był skaner kodów. Kiedy nikt z ekranu nie korzystał wyświetlały się na nim materiały marketingowe, natomiast klienci, po zeskanowaniu kodu z buta czy koszulki, mogli sprawdzić na ekranie dostępne w danym salonie rozmiary, inne kolory czy sugerowane stylizacje. Dodatkowo tworzyliśmy też na ekrany kontent interaktywny - np. edytor zdjęć, który był podstawą jednego z konkursów w naszej sieci. Co ciekawe, ekrany również były zintegrowane z beaconami, ale takimi z żyroskopem, czyli czułymi na ruch. W momencie jak Klient podniósł jakiegoś buta, to na ekranie wyświetlały się materiały z nim związane.

Po pracy w Marketing Invested Group odkryłem, że jestem dobry w te „klocki technologiczne”, co pozwoliło mi przejść do Taurona, gdzie rekrutowałem się na specjalistę od smart home. Oni mieli akurat w planie robić aplikację mobilną więc zachęcili mnie bym dołączył do tego zespołu. . W Tauronie po raz pierwszy usłyszałem o terminach tak jak Product Owner - przeszedłem różne szkolenia, które pozwoliły mi zdobyć wiedzę na temat dobrych praktyk, głównie z nakierowaniem na Scrum..

Już wcześniej dobrze pracowało mi się z zewnętrznym software house i tutaj było tak samo. W Tauronie mieliśmy dużo większy zespół, złożony z 10-12 osób. Mieliśmy bardzo dobrych developerów, mimo że byli młodzi. Scurm master był bardzo wymagający i pilnował, aby wszystko robione było zgodnie ze Scrum Guidem. Mogę teraz śmiało powiedzieć, że pracowałem w zespole, który potrafił się idealnie samoorganizować. Obecnie nazwalibyśmy go empowered team. Stworzyliśmy (wg mnie) najlepszą, a na pewno najładniejszą, aplikację z obszaru energetyki w Polsce. Wtedy już wiedziałem, że chcę iść rozwijać swoją karierę w kierunku budowania cyfrowych produktów – najlepiej mobile. Tak wylądowałem w Żabce.

Grzesiek: Czy uważasz, że dobre środowisko i odpowiednie nastawienie developerów przekonało Cię do wybrania właśnie tej drogi?

Krzysiek: Zdecydowanie, bo tworzenie produktów dawało mi po prostu niesamowitą frajdę. Oczywiście czasami były różne spiny, były problemy, były rzeczy, przez które człowiek był zestresowany i bał się w ogóle otworzyć kompa, żeby nie dostać po ryju, ale generalnie super bawiłem się tworząc aplikacje mobilne. Do dzisiaj mam z większością tych ludzi jakiś kontakt, także na stopie prywatnej.

Grzesiek: To przejdźmy dalej, bo chyba zaczynamy etap Twojej kariery z którego jesteś najbardziej dumny. Zgadza się?

Krzysiek: Tak, dokładnie, wchodzimy do Żabki. Teraz chyba już ponad 10 milionów użytkowników korzysta z aplikacji żappka (wg. jednego z artykułów, które czytałem). Adaptacja tego produktu jest niesamowita.

W Żabce pierwszy raz spotkałem się z podejściem, że zespół biznesowy był dedykowany pod daną aplikację. Jako product owner byłem odpowiedzialny za część frontową aplikacji oraz warstwę tzw. płytkiego backendu aplikacyjnego. Był też drugi product owner odpowiedzialny za backend. Nad nami był mój przełożony, który spinał naszą pracę w całość.

W ramach tego naszego zespołu była dziewczyna od UX-u, która zajmowała się szeroko rozumianym doświadczeniem użytkownika w naszej aplikacji - sprawdzała jak wygląda cała podróż użytkownika od momenty gdy ktoś podchodzi z telefonem do kasy i zaczyna mieć styczność z naszą aplikacją. Mieliśmy też do dyspozycji designera.

W naszym zespole była też dedykowana osoba od marketingu (tylko naszej aplikacji), która kontaktowała się z marketingiem odpowiedzialnym za komunikację całej firmy, tak aby spinać wszystkie cele marketingowe.

Mieliśmy jeszcze osobę od tworzenia contentu i analityków, którzy robili analizę danych. Reasumując, mieliśmy bardzo komplementarny zespół, który pozwalał na pracę end to end z produktem.

Grzesiek: Super. Nie jest to powszechne podejście, że masz osobę od marketingu przypisaną do swojego produktu. Przeważnie jest tak, że jest to osobny interesariusz z którym musisz „dealować” i dostosowywać wspólne cele.

Krzysiek: Tak, na pewno pomagało mi to, że ich cele były zbieżne z moimi. Dedykowana osoba od marketingu wspierała nas w pozyskiwaniu nowych użtkowników i kreaowaniu kampani, które dotyczyły naszej aplikacji.

Jak już ta aplikacja trochę urosła to musiałem sięgać po ludzi spoza naszego zespołu. Jak robiliśmy Żappkę Post, czyli usługę, która pozwalała na odbierania paczek za pomocą aplikacji w sklepach Żabka, to mieliśmy interesariusza, który osadzony był w tego typu strukturach w Żabce. Gdy trzeba było zrobić jakieś zmiany związane z oprogramowaniem na kasie to znowu był inny dział i zupełnie inne osoby.

Kolejnym graczem była firma, która nam zaprojektowała look and feel naszego produktu. To była firma, która tworzyła UI dla Slacka, Ubera – czyli aplikację z najwyższej półki. Mówię, że była, bo rok temu kupił ich Twitter.

Leave a comment

Grzesiek: Zanim przejdziemy dalej możesz mi powiedzieć jak wyglądała współpraca z nimi?

Krzysiek: Na przykład chodzili po sklepach i oglądali jak wszystko działa w każdym detalu – pomagali w wymyślaniu całego modelu „żappsowego”. Ich rola to nie było tylko zaprojektowanie interfejsów, ale też szeroko pojęty obszar discovery – robili wywiady z klientami i pracownikami Żabki, aby zmapować cały proces.

Współpracowaliśmy z nimi w takich trzy-czteromiesięcznych interwałach. Gdy wiedzieliśmy, co chcemy robić w najbliższym kwartale, spotykaliśmy się z nimi (później już tylko online) na takie dwu-trzy tygodniowe design sprinty, gdzie projektowaliśmy odpowiednie funkcjonalności.

Grzesiek: Na jakim poziomie współpracowałeś w Żabce? Bo brzmi, jakbyś miał bardzo duży ownership. Kto odpowiadał za wizję, za strategię, za roadmapę za backlog?

Krzysiek: W tej strukturze, która tam była to właściwie za taką wizję odpowiadał dyrektor obszaru digital. Wszystkie te osoby, które wymieniłem wcześniej raportowały w jakimś stopniu do niego, pośrednio albo bezpośrednio. To on był właśnie taką osobą, która znała wizję i nadawała główny kierunek. Product Ownerzy byli właścicielami poszczególnych backlogów oraz współtowrzyli roadmapę.

Grzesiek: Chcesz jeszcze coś dodać w tym temacie żappki?

Krzysiek: Jeszcze mam dwie rzeczy, które mogę opowiedzieć. Po pierwsze to mieliśmy inhousewe laboratorium, które pozwalało nam zbadać wszystko co chcieliśmy pod względem UX-a oraz zwalidować czy nasza hipoteza jest prawidłowa (choćby na poziomie mockupów).

Po drugie to zespół developerski był zewnętrzny, więc po raz kolejny ten setup bardzo dobrze działał, a ja czułem się bardzo komfortowo pracując z zewnętrznym Software Housem.

Grzesiek: Jak współpracuje się z Software House z perspektywy klienta?

Krzysiek: W przypadku Żabki, była to współpraca oparta o model „Time and Material”. Współpracowaliśmy w dwutygodniowych sprintach w Scrumie, zachowując wszystkie ceremonie. Review pozwalało pokazać wewnętrznym interesariuszom nad czym my w ogóle pracujemy 😊

Bardzo lubię współpracować w modelu w którym mam zewnętrzny Software House, mimo, że wiele osób pewnie się z tym nie zgodzi. Myślę, że po prostu miałem szczęście i wybraliśmy naprawdę dobrego partnera do tej współpracy., W takim modelu współpracy kompletnie odpadają Ci wszystkie kwestie HR-owe, wszystkie rzeczy managerskie, bo zawsze mieliśmy po drugiej stronie Project Managera, który się o to martwił.

Ważne we współpracy z SH jest to, żeby posiadać zaangażowany zespół, który jest zainteresowany tym co robi. W pewnym momencie (w Żabce) zaczęliśmy mocniej angażować developerów w samo tworzenie wymagań, aby nie byli tylko partnerem od delivery. Takie podejście pozwalało na współpracę w obu kierunkach – zespół sam przychodził z pomysłami na rozwiązanie problemów, a nie tylko czekał na gotowe taski.

Mieliśmy też analityka biznesowego po stronie SH, którego zadaniem było już rozbicie tego problemu na mniejsze części. Ja nie ukrywam, że jestem o wiele bardziej biznesowy niż technologiczny. Rozumiem technologię, ale nigdy nie kodowałem, a taki analityk był o krok bliżej technologii, więc potrafił znaleźć jakieś ewentualne luki w wymaganiach.

Grzesiek: A co wydarzyło się po etapie Żabki?

Krzysiek: Odszedłem z Żabki dwa lata temu i ostatnie dwa lata są niestety trochę skakaniem po różnych firmach i stanowiskach. Przez ten czas poszukiwałem trochę swojej drogi.

W pewnym momencie otrzymałem propozycję roli Head of Product od startupu uPacjenta. Firma posiada produkt, który pozwala zamówić badanie krwi do domu - głównie pobranie tej krwi w domu. Taka próbka jest później zabierana do laboratorium i po dniu można te wyniki zobaczyć w internecie oraz skonsultować online z lekarzem.

Było to stanowisko HoP połączone z rolą Product Managera, bo byłem jedyną produktową osobą w firmie. Zarządzałem zespołem około 15 osób (stricte) technicznych. Były tam osoby głównie od backendu, frontendu, testerzy oraz designerzy.

Na “ekosystem” uPacjenta posiada kilka różnych produktów. Głównym jest oczywiście cały proces zamawiania badań. czyli cała ścieżka zakupowa, Jest też również produkt dla personelu medycznego, który pomaga im zarządzać praca w ciągu dnia oraz informuje o szczegółach co, komu i gdzie należy pobrać. Poza tym trzeba było też zaopiekować rzeczy jak API dla partnerów czy całe panele administracyjne.

W pewnym momencie naszym głównym celem była optymalizacja ścieżki zamówienia przez klienta, czyli zwiększenie konwersji w liczbie zamawianych badań. W momencie, jak przychodziłem, to startowała (już wcześniej przygotowana) nowa ścieżka zamówienia. Ona nie do końca spełniła nasze oczekiwania, więc zaczęliśmy eksperymentować - krok po kroku analizując, w którym miejscu ludzie odpadają w tym lejku. Szukaliśmy miejsc, które można poprawić.

Grzesiek: Możesz opowiedzieć coś o tych eksperymentach? Jak one wyglądały?

Krzysiek: Najwięcej eksperymentowaliśmy z obszarem zamówień.

Były to głównie testy AB lub czasami nawet ABC, gdzie mieliśmy przygotowane parę wersji, które chcieliśmy sprawdzić. Sprawdzaliśmy stopniowo lejek, aby dowiedzieć się jak ludzie korzystają z naszego produkt krok po kroku.

Kierowaliśmy odpowiedni procent ruchu na odpowiednie segmenty użytkowników i patrzyliśmy jak konwertują. Patrzyliśmy gdzie ludzie odpadają, a gdzie konwertują lepiej.

Eksperyment trwał około 2 tygodnie - trzeba było chwilę poczekać, aby zobaczyć jakieś konkretne trendy.

Korzystaliśmy z narzędzia, które pozwalało nam dużo edytować bez konieczności angażowania developerów.

W pewnym momencie stworzyliśmy zespół, który był tylko odpowiedzialny za optymalizację konwersji - to był taki biznesowo-technologiczny zespół, który day-to-day walczył o jej zwiększenie. .

Share

Grzesiek: Co było po uPacjenta?

Krzysiek: Trafiłem do firmy Future Mind, czyli firmy, która robiła ze mną żappkę 😊 Pracuje w niej jako konsultant od cyfrowych produktów. Future Mind jest software-housem w którym robimy wiele dużych aplikacji np. dla LPP e-obuwie, Super-Pharm, Hebe czy Żabka.

Future Mind ma dużo fajnych projektów, skupiających się wokół retail (ale nie tylko). Do tego realizuje zadania nie tylko w obszarze delivery, ale potrafi stworzyć produkt od koncepcji, poprzez jego definiowanie, na dostarczeniu i rozwoju kończąc.

Grzesiek: Ok, może zmieńmy odrobinę temat. Jakie kompetencje według Ciebie są kluczowe u Product Managera?

Krzysiek: Na pewno asertywność, bo zwykle ludzie mają dużo potrzeb, a jeszcze więcej pomysłów. Co gorsza, nawet nie tyle co potrzeb, ale więcej gotowych rozwiązań, które przynoszą do Ciebie. Sztuka odmawiania i odpowiedniego argumentowania swoich decyzji jest kluczowa.

Kolejnym ważnym aspektem jest wiedza dziedzinowa bo to niesamowicie pomaga. Oczywiście wiele osób po raz kolejny się ze mną nie zgodzi, ale ja widzę różnicę w moim performance i sposobie pracy, w momencie kiedy robię rzeczy z obszaru na którym się po prostu znam.

Według mnie bardzo istotne jest również to, żeby nie patrzeć na produkt jak na takiego potworka, który musi posiadać wiele funkcjonalności i co chwilę budować coś nowego - tylko zobaczyć to co mamy już zaimplementowane i wykorzystać gotowe rzeczy, aby inaczej rozwiązać dany problem.

Grzesiek: Gdyby nie Product Manager to kto?

Krzysiek: Na pewno byłoby to coś kreatywnego - dla mnie to bardzo istotne. Najbardziej lubię w pracy product managera, że coś co tworzę (wiadomo, że nie sam), wprowadzam w życie – mam na to jakiś realny wpływ. Fajne jest to, że jak idę do Żabki to widzę, jak ktoś tę aplikację skanuje przy kasie, czy jak odbierają paczki. Czuje, że rozwiązuje jakiś realny problem, który pojawił się u klientów.

Gdyby nie Product Management to pewnie wylądowałbym w marketingu - w kreatywnej części, takiej contentowo-twórczej.

Grzesiek: A co byś poradził osobom, które chciałyby zostać product managerem?

Krzysiek: Tak jak było widać po mojej historii – to tylko przypadek spowodował, że jestem tu gdzie jestem. Moja ścieżka jest nietypowa, jest nie do powtórzenia, tego się nie da zaplanować.

Chyba najlepszym progiem wejścia dla kogoś kompletnie z zewnątrz jest UX lub analiza biznesowa. Jako analityk biznesowy uczysz się wielu kompetencji potrzebnych do tego, żeby rozpoznać zasadność wymagań-jak one są tworzone, zbierane i doprecyzowywane.. Uczysz się pracy w zespole wytwórczym, widzisz jak pracują pozostali, jakie są zależności pomiędzy poszczególnymi rolami technologicznymi i biznesowymi. Wtedy można jakoś łatwiej przejść stopień wyżej, wziąć trochę więcej odpowiedzialności, już nie tylko być osobą, która dopieszcza te wymagania, ale też je scala w całość i tworzy jakiś produkt.

Na pewno fajną możliwością jest bycie specjalistą w danej dziedzinie, czyli posiadając tak zwaną wiedzę domenową. Jest to nie rzadka sytuacja, gdy gdy ktoś jest specjalistą w danym obszarze po czym przechodzi do zespołu tworzącego produkty dla tego obszaru. Mimo braków w warsztacie produktowym, dzięki swojej unikatowej wiedzy, jest w stanie zrealizować najważniejsze zadanie Product Managera - czyli określić co jest naprawdę wartościowe dla użytkowników danego produktu. A wiedza produktowa, narzędzia i techniki - to zawsze da się nadrobić.

Grzesiek: A co myślisz o osobach, które przychodzą spoza branży do nowych obszarów?

Dobre pomysły i inspiracje można czerpać z wielu branż i między branżowo. Ja staram się obserwować różne branże bo pracujemy w szeroko pojętych nowych technologiach, które dotykają wielu dziedzin, a przez to produktów, w naszym życiu. Nawet jeśli interesuje mnie retail, to patrzę na to co nowego powstaje w innych branżach, bo być może da się to zaadoptować na nasze potrzeby.

Trzeba trzymać rękę na pulsie, nie być zamkniętym w tej swojej ulubionej branży, ale mieć trochę szersze horyzonty. Trzeba patrzeć na zupełnie inne rynki, popatrzeć na USA i na Azję. Tam wiele rzeczy jest zupełnie innych, część technologii jest tam na zupełnie innym etapie. Bardzo fajnym przykładem są płatności oraz poziom zaawansowania, na jakim jest dany rynek.

Zupełnie inaczej się tworzy te aplikacje w Azji niż u nas. Na przykład Żabka jako grupa ma kilka aplikacji, w Azji pewnie miałaby jedną aplikację, która by ogarniała wszystkie potrzeby użytkowników, jak np. Gojek w Indonezji.

Warto inspirować się innymi rynkami i branżami – to nie chodzi o zrzynanie, tylko o uczenie się na czyiś błędach i sukcesach.

Moim ulubionym przykładem są technologie głosowe. Gdybym robił coś w tej branży, to na pewno zwróciłbym uwagę na Stany Zjednoczone, które są dużo bardziej rozwinięte w tym obszarze. Patrząc na nich wiadomo już, co działa, co nie działa i dlaczego tak jest. .

Bardzo zachęcam ludzi, żeby rozglądali się dookoła, bo inspiracje można złapać naprawdę z wielu, czasami zaskakujących, miejsc.

Grzesiek: Czy chciałbyś o czymś opowiedzieć o co cię nie zapytałem dzisiaj jeszcze?

Krzysiek: Na pewno jedną z ciekawszych moich doświadczeń to jest ta nieszczęsna częsta zmiana zatrudnienia. Moje ostatnie dwa lata to jest dużo skakania po kilku firmach. Każda z tych firma była zajebista, tworzą tam superprodukty. Z żadnej firmy nie odszedłem z tego powodu, że to była np. firma toksyczna, po prostu nie do końca się odnajdywałem w danej branży czy rodzaju produktu.. ale koniec końców, te dwa lata zmian pozwoliły mi odkryć dokładnie czego nie chcę robić, a to praktycznie tak samo ważna rzecz jak podczas pracy produktowej wiedzieć, czego nie chcemy budować ;) . Po Żappce wiedziałem, że lubię współpracę z software house oraz tworzyć aplikacje mobilne B2C. Chciałem spróbować czegoś innego, zobaczyć czy trawa gdzieś indziej nie jest bardziej zielona. Sprawdzić się w trochę innych kierunkach i różnych typach produktu.

Jeśli ktoś planuje swoją karierę to musi jednak spróbować wielu rzeczy, aby zobaczyć co mu bardziej leży, a co nie – co go jara, a co nie.

Grzesiek: Dziękuję za rozmowę!

Krzysiek: Również dzięki i do usłyszenia na kanałach Product Art!

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.

Pola Białoskórska has been creating digital products since 2016. She’s a Product Manager and mentor who has had the opportunity to work on web/mobile/desktop applications, hardware, and embedded systems across many different industries—e-commerce, smart homes, automotive, Industry 4.0, logistics, healthcare, entertainment, services—from startups to corporations. Currently a PM at Novakid Inc.

Grzesiek: Hi, Pola. Thank you so much for wanting to share your experiences in the Product Art newsletter.

Pola: Hi, Grzegorz. Thank you very much for the invitation. First, I’m greeting you from sunny Croatia. I work as a product manager at Novakid, an EdTech company. It’s a company that mainly offers one-on-one online lessons with teachers from around the world for children ages 4-12. We also create games, stories, and other interactive materials for learning English. This product is interesting in that theoretically our customer is children, but we also have personas for teachers and parents.

Grzesiek: Great. Could you walk me through your career? How did you get into Product Management? Where did that passion come from?

Pola: To tell you about my career, I need to go back to my studies. I studied management in English at Gdańsk University of Technology, but I was also on an Erasmus exchange in Denmark for a year in a “Double diploma” program, where I had the opportunity to study Global Business Engineering—a program combining IT and business. That’s where I learned programming among other things. That’s also when I learned about Scrum and really liked it because it bridged the IT and management worlds.

I knew I wanted to work in that direction. When I came back from Denmark, I started working as a sales representative at a software house. After a short time, the company owner noticed that I was good at gathering requirements, client communication, estimating, and conveying those requirements to the development team. Back then, my role was called “Project Manager,” and it was new to me. I learned practices on my own or from developers, and theory from the internet. There were no designers, researchers, or salespeople at that company, but because of that, I got to try each of these areas.

At that time, I didn’t have a clearly defined career path, and I wondered whether to go the Scrum Master route, but in the end, an owner at another company noticed that I had business knowledge and got along really well with clients, so naturally, I became a product manager once again.

I worked mainly at software houses because I thought it was more exciting—the product constantly changes, you collaborate with different clients from various industries and countries. Later, I realized you could work on one product and still have as much fun and excitement as working on many different products 😊

Grzesiek: Can you say why you were torn between a product role and being a Scrum Master?

Pola: At that time, I was just getting familiar with different frameworks, and Scrum seemed very interesting to me. I thought that through that role, I could collaborate more closely with people and the team.

I’m an empathetic person, so I thought it was an ideal role for me. What I really missed about being a Scrum Master was that direct impact on the product.

However, developing features and thinking about product strategy is much more interesting to me, and empathy is still very important.

Grzesiek: Tell me more about your previous roles as Product Owner at LPP and Head of Product at Venture Devs.

Pola: After working at software houses, I decided to start working at LPP. I wanted to try working at a more stable company, in a larger team, and I was really keen on finding a mentor—someone more experienced who could guide me in the world of product management.

At LPP, I worked as a Product Owner and mainly handled the payments area. It was a relatively small slice and in some ways treated like a stepchild. Fortunately, I managed to change that perception and worked with stakeholders to leverage the potential of payments at every step of the purchase funnel. My team had only backend developers, which was an interesting challenge.

However, in that role, I really missed diversity and greater responsibility—unfortunately, there was no opportunity to switch to another product or work on additional areas, so I left and went back to software houses. I started working at Venture Devs.

At Venture Devs, I really liked that the company already had well-established processes and there was very high transparency. When I joined the company, my Product Lead told the entire team that she was leaving and they were looking for a replacement.

I was offered the Head of Product position because I had been hired as a Senior Product Manager, and naturally, it seemed like I was the best candidate for the role. I agreed because I wanted to develop my leadership skills. My main initial task was supposed to be supporting the team of Product Owners and Scrum Masters in collaborating with clients, but as it turned out, I had to help them finish projects and manage change. At that time, the company was changing a lot because it wanted to have its own products based on blockchain technology. I didn’t feel competent in that domain and decided to change jobs.

Grzesiek: What are the biggest differences you see between working at a software house versus working on one product at a product company?

Pola: The first thing is definitely stakeholder collaboration. At a software house, stakeholders are clients, and they have a completely different approach to collaboration and the product. They’re very concerned about their budget and cautious about what they decide on.

At a company with its own product, it’s better in that there’s more room for experimentation and bolder moves.

Stakeholders are more specific, they know what they want—they share information about their problems more openly. Work based on data is also very important. From my experience, at a software house, there’s very little work with data. You have to be creative to get it, and often client companies don’t want to share that data or don’t see the value in collecting it. They’re not willing to pay for such services—they don’t understand why it’s so important in the product-building process.

At product companies, there’s greater awareness and willingness to collaborate closely with users.

Grzesiek: How do discovery and delivery look in both cases?

Pola: At Venture Devs, discovery was super well-planned, and that was one of the reasons I wanted to work there. I have to mention two great leaders here—Magda Szeniak and Justyna Aptowicz-Aydin—who, along with the team of Product Managers and Scrum Masters, prepared a playbook that was know-how and a set of tools for conducting proper discovery with clients. I hadn’t seen anything like it at any other company.

At other software houses, it was often the case that a client came in and already had a vision for the product—they knew exactly what they wanted—they just wanted us to build what they told us.

Of course, many times I and other PMs tried to conduct discovery with them, but not always is there room for that at software houses. Because it’s a sensitive topic—the client comes with a vision and why would the company change that, why not theoretically make money from creating what they want.

At serious and well-respected software houses, you collaborate with the client to understand their business idea. We want to validate it with them and with the market where the problem is being addressed. Check with clients whether there really is such a need, or whether that need should be slightly modified to really create that product.

When it comes to discovery at product companies, I unfortunately have the experience that many companies still don’t understand what it is and that it’s worth doing.

At Novakid, we absolutely see the value in it, and before each quarter, we meet to establish our KPIs. This way, we know what we expect from the product and what our business needs are.

We discuss what problems could prevent us from achieving our KPIs. Once we know what the problems are, we look for solutions to them. We have some ideas, but they’re hypotheses, so at the beginning of the quarter, we test these hypotheses—if something turns out to be a good solution that helps us improve our metrics or KPIs, we simply keep developing it.

We’re constantly doing A/B tests, validating other ideas, collecting user feedback—qualitative feedback from interviews, testing features before production release. After releasing to production, we check the changes in our metrics and continue collecting feedback.

Grzesiek: Can you describe the structure at Novakid and what you’re responsible for?

Pola: At Novakid, our KPIs are structured around Pirate Metrics—we’re mainly focused on Acquisition, Activation, and Retention.

Our teams are divided that way too. Let me explain. We have an Acquisition team that handles the landing page and the funnel from lead to “sale,” which means booking a trial lesson—that’s where our sales funnel starts.

We also have a team and Product Manager that handles the Activation stage, from a successful trial lesson to a sale. After the sale, we have the retention phase.

For retention, we have assigned teams for parent experience, student experience, and my mobile app team.

On top of all this, we have back office and teacher experience teams.

Why does it look like this? We want each team to be able to focus on one KPI and work to improve it.

I was hired as a Product Owner, but now a new VP of Product has joined us and the structure is changing a bit. We were pulled out of development teams and are no longer strictly product owners—we’re product managers working on various initiatives, and each product manager can assign tasks or “product visions” to a given team.

Grzesiek: So if I understand correctly, you work on a problem that the team needs to solve?

Pola: Exactly. That’s exactly how it works. This is really nice because a lot of responsibilities—somewhat unnecessary ones in my opinion—are shifting away from the product manager to tech leads and development teams.

I know it’s not generally easy to do in every company because it requires a lot of maturity from developers and knowledge of the business. It works really well with us because developers know the product well and we all understand each other perfectly—we know our goals and what we want to achieve.

Currently, I’m responsible for the mobile app, so I need to tie together all those teams and areas I mentioned, because acquisition looks a bit different on mobile than on, say, a landing page. It’s also important to remember that users aren’t just in the web app or just in the mobile app—they overlap. They’re on different platforms at different stages. It’s a big task to coordinate that and think about how it impacts our metrics.

Grzesiek: Can you describe how you work on the mobile product?

Pola: The first thing is close collaboration with all the product managers and stakeholders. I’ve scheduled this so that I have weekly meetings with each product manager, and we think about whether things they want to introduce affect the mobile app and whether we should do it differently, the same way, or if we need to change something. If an initiative concerns the mobile app, I participate in stakeholder meetings and workshops.

It’s not easy also because the mobile app at Novakid was built fairly recently, but before I worked at this company, it wasn’t entirely clear whether we were building it for parents or for children. It wasn’t fully thought through. Now I’m trying to understand why we need the mobile app and why such a large percentage of our users use it. Based on that, I’m discovering how to further develop it—I’m thinking about what all those stages should look like: Acquisition, Activation, and Retention.

In every company, this will be different, but we discovered that the mobile app is mainly needed for user retention. That’s because very few users...

Grzesiek: ...start their journey from the mobile app.

Pola: Exactly. Most of our users start using Novakid from the web app—by registering through the landing page. They download the mobile app once they have a subscription, which we know positively impacts retention.

When it comes to Acquisition, the difference is that the path is a bit different on mobile—you can advertise downloading the app differently than registering on the website. You have to make much more effort to convince a user to download the app and then register within it.

Grzesiek: On what basis do you map all these dependencies between teams?

Pola: Before each quarter, we meet to conduct workshops and establish the KPIs I mentioned. We think about how we can move the metrics in those areas.

When we plan what we can do, we think about whether we’ll do it only in the web app, only in the mobile app, or in both at once.

A big support here is the development team leaders because they play an important role in planning work from the perspective of dependencies. I think that’s one of the reasons it’s so crucial to involve development representatives from the early stages of initiatives.

Grzesiek: Can you tell me which setup you prefer to work in? In the product manager role or earlier as product owner?

Pola: The first thing is that in every company, the understanding of these two roles differs.

From my experience, in the Product Owner role, it’s mainly about working closely with the development team—breaking down tasks, prioritizing them, participating in sprint planning, being in daily standups, monitoring the team’s progress, and sometimes planning releases.

The role of a product manager is more responsible and high-level, meaning I’m currently working on initiatives that truly impact every department in our company.

What I enjoy most about this role is that I can focus on tasks related to strategic planning, gathering data about new features, or user problems. I don’t need to spend as much time collaborating with developers, but of course I’m available for them whenever they need me.

Leave a comment

Grzesiek: So how do you go about finding the right problems to solve?

Pola: We have two teams that handle UX research. One focuses more on market validation and what’s happening in the industry. The other team, which is more design-oriented, works with users and conducts interviews with them.

We get so much user feedback that we already know where our customers are experiencing pain points or what they’re missing.

The second thing is quantitative data. When we see in our quantitative data that something isn’t working, we can take a closer look at the problem. For example, recently we discovered that users who had a trial lesson on mobile devices were less likely to purchase a subscription.

We usually start with small steps—for example, by informing the customer that they’d be more comfortable having a trial lesson on a different device rather than a mobile device, and we check if the user switches devices. We don’t always know for sure that they have another device available, so we want to verify this.

We also check if this will impact conversion. The mobile app is a delighter for users, so quantitative data will tell us something, but it won’t answer all our questions—we know we need to conduct user interviews.

These interviews are typically structured so that we examine the current user experience and try to understand why users do or don’t use a given feature. Of course, we also talk about their needs while we’re at it.

Sometimes more than one interview is needed. For example, first we gather requirements (users’ problems and pain points), and then in the next interview, when we have some hypotheses based on what they told us, we show them our prototypes and check if this is something we should be pursuing.

Grzesiek: Who conducts these interviews?

Pola: UX researchers and product managers (if they want to) participate in interviews. I try to participate, though of course these interviews take a long time and there are quite a lot of them, so I can’t always make it. But when I have the opportunity, I definitely participate. By “participate” I mean I sometimes ask additional questions if I think a topic is worth exploring further.

Grzesiek: You mentioned earlier that you have access to a lot of data and based on that you’re able to determine if something is working or not. Who provides you with this information?

Pola: Currently, our structure is set up so that we have an analytics team, and each analyst is assigned to a particular team or a particular PM. I happen to have the pleasure of working with an analyst who is very helpful. The analyst provides us with data to validate our hypothesis.

My analyst also informs me when they notice any inconsistency in the data or an unusual situation. That’s another point from which I can draw inspiration and learn what we could improve in our app.

Grzesiek: Okay, so we’ve talked about collaboration with UX researchers and data analysts. Who else do you work with?

Pola: I collaborate a lot with lead developers—if I want to implement a change in the mobile app, their knowledge about how something was implemented is very useful. These people can propose a better or faster solution to implement, which also solves user problems.

There’s the sales and marketing department—we have a very strong sales team in the sense that they’re in intensive contact with customers and also sell over the phone.

My experience collaborating with such departments is that they most often don’t come to us with problems, but unfortunately with solutions. Our job is to shift that approach and discover what the actual problem really is.

Grzesiek: Do you get a lot of feature requests from the sales department?

Pola: Yes, definitely. Sometimes they say customers will leave if we don’t build this or that. In those situations, I always try first to understand what the problem is (what’s actually happening), and second, I always try to think about how many users this affects and how much we could lose or gain from implementing the proposed feature.

Sometimes it’s hard to estimate the impact, so I always try to back things up with data. Often what happens is that salespeople think they know the solution, when the actual problem is somewhere completely different. It’s always worth checking.

Share PRODUCT HUB

Grzesiek: It seems to me that communication and negotiation are some of the key skills of a product manager—so you can work comfortably. If we can’t say “no” to someone, we have a problem because we’re digging ourselves into a hole. How do you handle that?

Pola: The sales department also has its own analyst, so they can check all the data needed to estimate the scale of the problem before they come to me.

Showing what our priority is at any given moment is very important, but it doesn’t always work in every company, because sometimes individual departments have different goals. In some companies, different departments don’t have a shared goal, which often leads to unhealthy competition.

At Novakid, we all know what we’re aiming for, which metrics we need to move, what our goal is. It’s much easier for us to discuss what’s worth doing at any given moment and what isn’t. When it comes to prioritization, we use things like RICE and we teach other teams to understand our prioritization methods so they know why the product team makes the decisions it does.

Grzesiek: So let’s move on to some softer questions now. How do you take care of your productivity as a product manager?

Pola: Recently I noticed I have quite a lot of meetings, so I started tagging them in Google Calendar to know how much time I’m spending on different initiatives.

As I mentioned, I’m responsible for the mobile app and I need to coordinate everything that’s happening, so I meet with product managers from different areas. I meet with UX designers, researchers, the analyst, I participate in customer interviews, I work with developers—that’s roughly what my work looks like.

These are the main meetings, but still I find time for focused work without meetings, because I think that’s super important. Sometimes I need to sit alone and look at the competition or what’s happening in the industry. When you’re constantly in meetings, it’s just impossible.

Grzesiek: I agree with you on that focused work. I’ve been in a few organizations where there was so-called “meeting culture”—a lot of talking and coordinating rather than actual work.

Pola: At Novakid, whenever we have a larger initiative, we always assign someone from the business side who is responsible and has the final say together with the product manager. This helps us a lot because there’s someone who can say: “okay, we’re making a decision and moving forward.”

The second thing that’s important is to have someone around you who is an expert in a given area.

For example, when we make a decision about marketing, the final word should come from someone in that department, not from a developer. If feedback comes from the CTO, they need to look at it from a technical perspective, not a sales perspective. Otherwise, we end up with a situation where we have many pseudo-experts and it’s hard for us to make a decision.

Grzesiek: Could you also tell me what remote work looks like for you?

Pola: I work remotely and additionally I work mainly with people who don’t live in Poland and don’t speak Polish. I think that’s an extra challenge, because one thing is remote work and another is the language barrier. We all communicate in English, but of course that conversation will never be at the same level as in our native languages. As for remote work: (this is just my opinion and it depends on the individual) I think that despite remote work, it’s worth meeting in person with the people you work with at least once—it really helped me.

In June we had the opportunity to meet in person in Istanbul, and since then I’ve been collaborating better with those people. However, remote work leaves a lot of room for speculation, for imagining what someone is like or what their intentions are. When we meet in person, nothing can be hidden, and that’s why the remote work barrier doesn’t exist.

During remote work, we use Slack very intensively, but of course when a conversation gets too long, it doesn’t make sense to continue it—you just jump on a quick call.

As for workshops, we often do it this way: we start with a meeting and then continue offline—we don’t all sit on a call writing down ideas on sticky notes. Instead, we split up and everyone has to write their ideas on, for example, a board in Miro. After that, still offline, we familiarize ourselves with what everyone has prepared, we meet again, and we discuss it to reach a result.

Grzesiek: What is your biggest challenge as a product manager?

Pola: Currently my biggest challenge is that I’m responsible for a mobile app that was once created based on previously established assumptions, and now I need to decide what to do with it.

Do we remove it completely, or do we split the mobile app into an app for kids and an app for parents? Do we keep the app as it is and build both the kids’ and parents’ sections within it? Or maybe we don’t actually need one of these sections at all.

This is a challenge for me because I think it also impacts the broader strategy of the company.

Grzesiek: That really does sound like a major challenge that will lead to great experience. Thank you for your time today.

Pola: Thank you as well!

If you enjoyed this interview, click the 💙 and leave a comment.

If you’re not yet part of the Product Art community, I invite you to subscribe.

🇵🇱 Wersja polska / Polish original

Pola Białoskórska tworzy produkty cyfrowe od 2016 roku. Jest Product Managerką i mentorką, która miała okazję pracować przy aplikacjach web/mobile/desktop, hardware i systemach wbudowanych z wielu różnych branż - e-commerce, smart homes, automotive, przemysł 4.0, logistyka, medycyna, rozrywka, usługi, od startupów po korporacje. Obecnie PM w firmie Novakid Inc.

Grzesiek: Cześć, Pola. Dziękuje bardzo, że chciałaś się podzielić swoimi doświadczeniami na łamach newslettera Product Art.

Pola: Cześć, Grzegorz. Bardzo dziękuję za zaproszenie. Na wstępie pozdrawiam Cię ze słonecznej Chorwacji. Pracuję jako product manager w firmie Novakid z branży EdTech. Jest to firma, która głównie oferuje lekcje online, one-on-one z nauczycielami z całego świata dla dzieci w wieku 4-12 lat. Tworzymy też gry, bajki i inne interaktywne materiały do nauki języka angielskiego. Ten produkt jest ciekawy pod takim kątem, że teoretycznie naszym klientem są dzieci, ale są też persony nauczycieli oraz rodziców.

Grzesiek: Super. Mogłabyś mnie przeprowadzić przez swoją karierę? Jak trafiłaś do Product Managementu. Skąd taka zajawka?

Pola: Żeby opowiedzieć o mojej karierze, muszę cofnąć się aż do studiów. Studiowałam zarządzanie po angielsku na Politechnice Gdańskiej, ale byłam też na Erasmusie w Danii przez rok, na takim programie „Double diploma”, gdzie miałam okazję studiować Global Business Engineering, które było kierunkiem łączącym IT i biznes. Tam uczyłam się między innymi programowania. Wtedy też dowiedziałam się o Scrumie i bardzo mi się to spodobało, bo łączyło to świat IT i zarządzanie.

Wiedziałam, że chciałabym robić coś w tym kierunku. Jak wróciłam z Danii to zaczęłam pracę jako przedstawiciel sprzedażowy w jednym z Software Housów. Po krótkim czasie właściciel firmy zauważał, że dobrze idzie mi zbieranie wymagań, kontakt z klientem, estymowanie oraz przekazywanie tych wymagań zespołowi developerskiemu. W tamtym czasie moją rolę nazwano “Project Manager” i było to dla mnie coś nowego. Praktyki uczyłam się sama lub od developerów, a teorii z internetu. W tej firmie nie było designerów, researcherów czy sprzedawców, ale dzięki temu mogłam spróbować każdego z tych obszarów.

Wtedy jeszcze nie miałam mocno sprecyzowanej ścieżki kariery i zastanawiałam się czy nie pójść w kierunku roli Scrum Mastera, ale koniec końców znowu właściciel jednej z firm zauważył, że mam wiedzę biznesową i bardzo dobrze dogaduję się z klientami, więc naturalnie stałam się po raz kolejny product managerem.

Pracowałam głównie w software housach, ponieważ myślałam, że jest to bardziej ekscytujące, przez to, że ciągle zmienia się produkt, współpracuje się z różnymi klientami (z różnych branż i krajów). Później okazało się, że można pracować przy jednym produkcie i nadal mieć z tego tyle funu i ekscytacji ile wcześniej przy wielu różnych produktach 😊

Grzesiek: A możesz powiedzieć, dlaczego wahałaś się między stanowiskiem produktowym a scrum masterem?

Pola: W tamtym czasie dopiero zaczynałam się zaznajamiać z różnymi frameworkami i scrum wydawał mi się bardzo ciekawy. Myślałam, że dzięki tej roli, będę mogła współpracować bliżej z ludźmi oraz zespołem.

Jestem empatyczną osobą, więc myślałam, że jest to idealna rola dla mnie. To czego mi bardzo brakowało w byciu scrum masterem to właśnie taki bezpośredni wpływ na produkt.

Jednak rozwijanie funkcjonalności i myślenie o strategii produktu jest dla mnie o wiele ciekawsze, a empatia nadal jest bardzo istotna.

Grzesiek: Opowiedz coś więcej o swoich poprzednich rolach Product Ownera w LPP oraz Head of Product w Venture Devs?

Pola: Po pracy w software housach postanowiłam zacząć pracę w LPP. Chciałam spróbować pracy w bardziej stabilnej firmie, w większym zespole i bardzo zależało mi na znalezieniu mentora - kogoś bardziej doświadczonego, kto poprowadzi mnie w świecie product managementu.

W LPP pracowałam jako Product Owner i zajmowałam się głównie obszarem płatności. Był to stosunkowo mały wycinek i w pewnym sensie traktowany po macoszemu. Na szczęście udało mi się to odczarować i razem ze stakeholderami wykorzystać potencjał płatności na każdym kroku lejka zakupowego. W moim zespole byli tylko backend developerzy, co było ciekawym wyzwaniem.

Jednak w tej roli bardzo brakowało mi różnorodności, większej odpowiedzialności – niestety nie było możliwości zmiany na inny produkt czy pracy nad dodatkowymi obszarami, więc zrezygnowałam i wróciłam do software housów - zaczęłam pracę w Venture Devs.

W Venture Devs bardzo podobało mi się że firma posiadała już wiele ułożonych procesów i była bardzo duża transparentność. Kiedy dołączyłam do firmy moja Product Lead poinformowała cały zespół, że odchodzi i poszukiwali kogoś na jej zastępstwo.

Zaproponowano mi pracę na stanowisku Head of Product, bo zostałam zatrudniona jako Senior Product Manager i naturalnie wydawało się, że ja jestem najlepszą kandydatką do wykonywania tej roli. Zgodziłam się, bo chciałam rozwijać swoje umiejętności liderskie. Moim głównym, pierwotnym zadaniem miało być wspieranie zespołu Product Ownerów i Scrum Masterów we współpracy z klientami, ale jak się później okazało, musiałam pomagać im kończyć projekty i zarządzać zmianą. W tamtym czasie firma mocno się zmieniała, bo chciała mieć swoje własne produkty oparte o technologię blockchain. Nie czułam się kompetentna w tej domenie i postanowiłam zmienić pracę.

Grzesiek: Jakie widzisz największe różnice pomiędzy pracą w software housie, a pracą nad jednym produktem w firmie produktowej?

Pola: Pierwsza rzecz, to na pewno współpraca ze stakeholderami. W software housie są nimi klienci i mają zupełnie inne podejście do samej współpracy oraz do produktu. Bardzo zastanawiają się nad swoim budżetem i ostrożnie podchodzą do tego, na co się decydują.

W firmie, która ma własny produkt jest o tyle lepiej, że jest większa przestrzeń na eksperymentowanie i odważniejsze kroki.

Stakeholderzy są bardziej sprecyzowani, wiedzą czego chcą - bardziej otwarcie dzielą się informacjami dotyczących ich problemów. Bardzo ważna jest też praca na danych. Z mojego doświadczenia, w software housie – bardzo mało pracuje się na danych, trzeba bardzo kombinować, żeby je zdobyć i też często firmy-klienci nie chcą dzielić się tymi danymi lub nie widzą wartości w zdobywaniu tych danych. Nie są skłonni płacić za takie usługi – nie rozumieją dlaczego to tak ważne w procesie budowania produktów.

W firmach produktowych jest większa świadomość i chęć bliskiej współpracy z użytkownikami.

Grzesiek: A jak wygląda części delivery i discovery w obu przypadkach?

Pola: W Venture Devs discovery było super zaplanowane i to był jeden z powodów dla których chciałam tam pracować. Muszę tutaj wspomnieć o dwóch świetnych liderkach - Magdzie Szeniak i Justynie Aptowicz-Aydin, które razem z zespołem Product Managerów i Scrum Masterów, przygotowały playbook, który był know how i zbiorem narzędzi do przeprowadzenia porządnego discovery z klientami. Nie widziałam czegoś takiego w żadnej innej firmie.

W innych software housach często było tak, że przychodził klient i on już miał wizję na produkt - wiedział dokładnie, czego chce - chciał tylko żeby stworzyć to, co on nam powie.

Oczywiście wiele razy ja czy inni PMowie próbowaliśmy przeprowadzać z nimi discovery, ale nie zawsze w software housach jest na to przestrzeń. Ze względu na to, że jest to delikatny temat, klient przychodzi z wizją i dlaczego firma miałaby to zmieniać, dlaczego nie mamy „na tym teoretycznie zarobić”, żeby stworzyć to, czego on chce.

W poważnych i liczących się na rynku software housach. jest tak, że współpracuje się z klientem, żeby zrozumieć, jaki ma pomysł na biznes. Chcemy zwalidować to z nim oraz rynkiem na którym adresowany jest dany problem. Sprawdzić z klientami, czy rzeczywiście jest taka potrzeba, czy ta potrzeba powinna być chociaż lekko zmieniona, żeby rzeczywiście stworzyć dany produkt.

Jeżeli chodzi o discovery w firmach produktowych to też niestety mam takie doświadczenie, że wiele firm jeszcze nie rozumie co to jest i że warto to robić.

W Novakid jak najbardziej widzimy tę wartość i przed każdym kwartałem spotykamy się, aby ustalić nasze KPI. Dzięki temu wiemy czego oczekujemy od produktu i jakie są nasze potrzeby biznesu.

Omawiamy jakie problemy mogą nam przeszkodzić w tym, żeby zrealizować nasze KPI. Kiedy już wiemy jakie są problemy to szukamy do nich rozwiązań. Mamy jakieś pomysły, ale to są nasze hipotezy, więc na początku kwartału testujemy te hipotezy – jeśli coś okaże się dobrym rozwiązaniem, które nam pomaga w podwyższeniu naszych metryk czy KPI –ów, to po prostu to dalej rozwijamy.

Cały czas robimy AB testy, walidujemy inne pomysły, zbieramy feedback od użytkowników - jakościowy na wywiadach, testując funkcje jeszcze przed wdrożeniem na produkcję. Po wypuszczeniu na produkcję sprawdzamy zmiany w naszych metrykach i dalej zbieramy feedback.

Grzesiek: Możesz powiedzieć jak wygląda struktura w Novakid oraz za co jesteś odpowiedzialna?

Pola: Jeśli chodzi o firmę Novakid nasze KPI są ułożone pod Pirate Metrics - głównie skupiamy się obecnie na Acquisition, Activation i Retention.

Nasze zespoły są też w taki sposób podzielone. Już tłumaczę o co chodzi. Mamy zespół od Acquisition, który zajmuje się landing pagem i lejkiem od leada do “sprzedaży” czyli do zarezerwowania lekcji próbnej – tak zaczyna się nasz lejek sprzedażowy.

Mamy też zespół i Product Managera, który zajmuje się etapem Activation, czyli od udanej lekcji próbnej do sprzedaży. Po sprzedaży mamy fazę retencji.

Dla retencji mamy przypisane zespoły parent experience, student experience i mój zespół aplikacji mobilnej.

Do tego wszystkiego dochodzą zespoły back office i teacher experience.

Dlaczego tak to wygląda? Chcemy, żeby każdy z zespołów mógł skupić się nad jednym z KPI i dążył do jego poprawy.

Byłam zatrudniona jako Product Owner, ale teraz doszedł do nas nowy VP of Product i trochę zmienia się ta struktura. Zostaliśmy wyciągnięci z zespołów developerskich i już nie jesteśmy stricte product ownerami tylko product managerami, którzy pracują nad różnymi inicjatywami, a każdy z product managerów może przekazać jakieś zadania, „wizje produktów” do danego zespołu.

Grzesiek: Czyli rozumiem, że pracujecie nad problemem, który zespół ma rozwiązać?

Pola: Tak, dokładnie tak to wygląda. To jest bardzo fajne, dlatego, że duża część obowiązków takich trochę niepotrzebnych (moim zdaniem) odchodzi od product managera – jest przekazywana tech leadom i zespołom developerskim.

Wiem, że nie jest to ogólnie łatwe do zrobienia w każdej firmie, bo wymaga dużej dojrzałości od developerów oraz znajomości biznesu. U nas to działa bardzo dobrze bo developerzy dobrze znają produkt i wszyscy znakomicie się rozumiemy – znamy nasze cele i to co chcemy osiągnąć.

Obecnie jestem odpowiedzialna za aplikację mobilną czyli muszę spiąć te wszystkie zespoły i te obszary, które wymieniłam, bo w aplikacji mobilnej trochę inaczej wygląda acquisition niż np. na landing page. Warto też pamiętać, że użytkownicy nie są tylko w aplikacji webowej lub tylko w aplikacji mobilnej tylko się przenikają, czyli na różnych etapach są na różnych platformach. To jest duże zadanie, żeby to skoordynować i zastanowić się jak to wpływa na nasze metryki.

Grzesiek: Możesz powiedzieć zatem jak wygląda Twoja praca nad produktem mobilnym?

Pola: Pierwsza rzecz to ścisła współpraca z wszystkimi product managerami i stakeholderami. Zaplanowałam sobie to tak, że mam weekly spotkania z każdym z product managerów i zastanawiamy się, czy rzeczy, które oni chcą wprowadzić, jakoś wpływają na aplikację mobilną i czy np. powinniśmy to zrobić inaczej, tak samo, czy coś musimy zmienić. Jeśli jakaś inicjatywa dotyczy aplikacji mobilnej to uczestniczę w spotkaniach i warsztatach ze stakeholderami.

Nie jest to łatwe też ze względu na to, że aplikacja mobilna w NovaKid była zrobiona dość niedawno, ale jak jeszcze nie pracowałam w tej firmie i nie do końca było jasne, czy robimy ją dla rodziców czy dla dzieci. Nie było to do końca przemyślane. Teraz staram się zrozumieć po co jest nam potrzebna aplikacja mobilna i dlaczego tak duży procent naszych użytkowników z niej korzysta. Też na podstawie tego, odkrywam jak ją jeszcze rozwinąć – zastanawiam się jak powinny wyglądać te wszystkie etapy, czyli Acquisition, Activation i Retention.

W każdej firmie na pewno będzie się to różnić, ale u nas odkryliśmy, że aplikacja mobilna jest głównie potrzebna nam pod kątem retencji użytkowników. Dlatego, że bardzo mało użytkowników...

Grzesiek: ...zaczyna swoją podróż od aplikacji mobilnej.

Pola: Dokładnie tak. Nasi użytkownicy zaczynają korzystać z Novakid w większości od aplikacji webowej – rejestrując się przez landing page. Ściągają aplikację mobilną, jak już mają subskrypcję, co wiemy, że pozytywnie wpływa na retencję.

Jeżeli chodzi o Acquisition, różnicą jest to, że to trochę inna ścieżka na mobile - inaczej można zareklamować ściągnięcie aplikacji niż zarejestrowanie się na stronie webowej. Trzeba wykonać dużo większy wysiłek, żeby przekonać użytkownika do ściągnięcia aplikacji i dopiero zarejestrowania się w niej.

Grzesiek: Na jakiej zasadzie mapujecie te wszystkie zależności pomiędzy zespołami?

Pola: Przed każdym kwartałem spotykamy się, aby przeprowadzić warsztaty i ustalić KPI, o których wspominałam. Zastanawiamy się, jak możemy ruszyć metryki w tych obszarach.

Kiedy już zaplanujemy, co możemy zrobić, to zastanawiamy się, czy będziemy to robić tylko w aplikacji webowej, czy tylko w aplikacji mobilnej czy w obu na raz.

Dużym wsparciem są tu liderzy zespołów developerskich, bo odgrywają ważną rolę w planowaniu prac pod kątem zależności. Uważam, że to jeden z powodów dla których tak kluczowe jest zaangażowanie przedstawicieli developmentu od pierwszych zalążków inicjatyw.

Grzesiek: Możesz mi powiedzieć, w którym setupie lepiej Ci się pracuje? W roli product manager czy wcześniej jako product owner?

Pola: Pierwsza rzecz to taka, że w każdej firmie rozumienie tych obu ról się różni.

Z mojego doświadczenia w roli Product Ownera głównie chodzi o to, by ściśle współpracować z zespołem developerskim - rozpisywać zadania, priorytetyzować je, uczestniczyć w planowaniu sprintu, być na daily, sprawdzać jak wygląda progres zespołu, czasem planować release’y.

Rola product managera jest bardziej odpowiedzialna i wysokopoziomowa, czyli pracuję obecnie nad inicjatywami, które dotykają tak naprawdę każdego działu naszej firmy.

W tej roli bardziej podoba mi się to, że skupiam się na tych zadaniach dotyczących planowania strategii, zbierania danych na temat nowej funkcjonalności, czy problemów użytkowników. Nie muszę tak wiele czasu poświęcać na współpracę z developerami, ale oczywiście jestem dla nich dostępna, kiedy mnie potrzebują.

Leave a comment

Grzesiek: A jak wygląda poszukiwanie odpowiednich problemów, które chcecie rozwiązać?

Pola: Mamy dwa zespoły, które zajmują się UX researchem. Jeden z nich skupia się bardziej na sprawdzeniu rynku i tego co się dzieje w branży. A drugi zespół, który jest bardziej ze strefy designu – zajmuje się użytkownikami i wywiadami z nimi.

Mamy tak dużo feedbacku od użytkowników, że już wiemy, gdzie klienci mają jakieś swoje bolączki lub czego im brakuje.

Druga rzecz, to dane ilościowe. Kiedy widzimy w danych ilościowych, że coś nie działa to możemy się bliżej przyjrzeć temu problemowi. Na przykład ostatnio odkryliśmy, że użytkownicy, którzy mieli lekcję próbną na urządzeniach mobilnych rzadziej decydują się na zakup subskrypcji.

Zaczynamy przeważnie od małych kroczków, czyli np. od poinformowania klienta, że wygodniej mu będzie mieć lekcję próbną na innym urządzeniu, niż urządzenie mobilne i sprawdzamy, czy użytkownik zmienia urządzenie, bo nie zawsze mamy pewność, że je ma (chcemy to sprawdzić).

Sprawdzamy też, czy to wpłynie na konwersję. Aplikacja mobilna to jest taki delighter dla użytkownika, więc tutaj dane ilościowe coś nam powiedzą, ale nie odpowiedzą na wszystkie wątpliwości - wiemy, że musimy przeprowadzić wywiad z użytkownikami.

One najczęściej są zaplanowane w ten sposób, że sprawdzamy obecny user experience i staramy się dowiedzieć dlaczego korzystają bądź nie z danej funkcji. Oczywiście przy okazji rozmawiamy o ich potrzebach.

Czasami potrzeba więcej niż jednego wywiadu, bo np. najpierw zbieramy wymagania (problemy tych użytkowników, ich bolączki), a dopiero na kolejnym wywiadzie, kiedy mamy jakieś hipotezy na podstawie tego co powiedzieli, to pokazujemy im nasze prototypy i sprawdzamy czy to jest coś do czego powinniśmy dążyć.

Grzesiek: Kto przeprowadza te wywiady?

Pola: W wywiadach uczestniczą UX researcherzy i product menedżerowie (jeśli chcą). Ja staram się uczestniczyć, chociaż wiadomo, że te wywiady trwają długo i jest ich dość dużo, więc nie zawsze mogę, ale kiedy mam taką możliwość to jak najbardziej w tym uczestniczę. Mówiąc „uczestniczę” mam na myśli, że zadaję czasem jakieś dodatkowe pytanie, jeśli wydaje mi się, że jakiś temat jest warty pogłębienia.

Grzesiek: Powiedziałaś wcześniej coś takiego, że macie dostęp do dużej ilości danych i na podstawie tego jesteście w stanie stwierdzić, czy coś jest ok, czy też nie. Kto dostarcza ci te informacje?

Pola: Obecnie struktura wygląda tak, że mamy zespół analityczny i każdy z analityków jest oddelegowany do jakiegoś zespołu, czy do jakiegoś PM-a. Ja akurat mam przyjemność współpracować z analitykiem, który jest bardzo pomocny. Analityk dostarcza nam dane, aby zwalidować naszą hipotezę.

Mój analityk informuje mnie również gdy zauważa jakąś niezgodność w danych lub dziwną sytuację. To jest kolejny punkt, z którego mogę czerpać inspirację i dowiaduje się co moglibyśmy poprawić w naszej aplikacji.

Grzesiek: Okej, to powiedzieliśmy sobie o współpracy z UX resercherami oraz z analitykami danych. Z kim jeszcze współpracujesz?

Pola: Bardzo dużo współpracuję z lead developerami - jeśli chcę wdrożyć jakąś zmianę w aplikacji mobilnej, to bardzo przydaje mi się ich wiedza na temat tego jak coś zostało zaimplementowane. Takie osoby mogą zaproponować lepsze lub szybsze w implementacji rozwiązanie, które też rozwiązuje problemy użytkowników.

Jest dział sprzedaży i marketingu – mamy bardzo silny zespół sprzedażowy, w takim sensie, że on bardzo intensywnie rozmawia z klientami - jest z nimi w kontakcie i też sprzedaje przez telefon.

Moje doświadczenie współpracy z takimi działami jest takie, że najczęściej oni nie przychodzą do nas z problemami, ale niestety z rozwiązaniami. Naszym zadaniem jest zmiana tego podejścia i odkrycie, co tak naprawdę jest problemem.

Grzesiek: Macie dużo „wrzutek” od działu sprzedaży?

Pola: Tak, tak, mam takie sytuacje. Czasami mówią, że klienci odejdą jeśli nie zrobimy tego czy tametgo. Ja zawsze w takich sytuacjach próbuję po pierwsze zrozumieć jaki jest problem (co się dzieje), a druga rzecz: zawsze staram się zastanowić, jak dużą ilość użytkowników to dotyka i ile możemy stracić lub zyskać na wdrożeniu proponowanej funkcjonalności.

Czasem ciężko oszacować wpływ więc zawsze staram się wspierać danymi. Najczęściej jest tak, że handlowcom wydaje się, że znają rozwiązanie, a problem tkwi zupełnie gdzieś indziej. Zawsze warto to sprawdzić.

Share PRODUCT HUB

Grzesiek: Wydaje mi się, że komunikacja i negocjacje to są jedne z kluczowych umiejętności product managera - po to żeby komfortowo móc pracować. Jeśli nie umiemy dobrze powiedzieć osobie „nie” to mamy problem bo sami sobie kopiemy trochę dołek. Jak sobie z tym radzisz?

Pola: Dział sprzedaży również ma swojego analityka, więc mogą sprawdzić wszystkie dane potrzebne do tego żeby oszacować skalę problemu, zanim do mnie przyjdą.

Pokazanie co jest naszym priorytetem w danym momencie jak najbardziej jest ważne, tylko nie w każdej firmie to się sprawdza, bo czasem cele pojedynczych działów są różne. W niektórych firmach, różne działy nie mają wspólnego celu, co powoduje, że najczęściej istnieje niezdrowa rywalizacja.

W Novakid wszyscy wiemy do czego dążymy, jakie metryki musimy ruszyć, co jest naszym celem. Jest nam dużo łatwiej dyskutować o tym, co w danym momencie warto robić, a czego nie. Jeśli chodzi o priorytetyzację to używamy np. RICE i uczymy inne zespoły zrozumienia naszych metod priorytetyzacji, aby wiedziały dlaczego zespół produktowy podejmuje takie, a nie inne decyzje.

Grzesiek: To może przejdźmy sobie teraz do takich miękkich pytań. Jak dbasz o swoją produktywność jako product manager?

Pola: W ostatnim czasie zauważyłam, że mam dość dużo spotkań i zaczęłam sobie je tagować w kalendarzu Google, żeby wiedzieć ile czasu poświęcam na różne inicjatywy.

Tak jak wspomniałam, jestem odpowiedzialna za aplikację mobilną i muszę spinać to wszystko co się dzieje, więc spotykam się z product managerami z różnych obszarów. Spotykam się z UX designerami, z researcherami, analitykiem, biorę udział w wywiadach z klientami, pracuje z developerami - tak mniej więcej wygląda moja praca.

Są to główne spotkania, jednak mimo wszystko znajduję czas na skupienie i pracę bez spotkań, bo uważam, że to jest superważne. Potrzebuję czasem sama spojrzeć na konkurencję lub na to co się dzieje w branży. Po prostu usiąść i zastanowić się co dalej, a będąc ciągle na spotkaniach jest to po prostu niemożliwe.

Grzesiek: Zgadzam się z Tobą, jeśli chodzi o tę pracę fokusową. Byłem w kilku organizacjach, gdzie była tak zwana „spotkanioza” czyli dużo rozmów i uzgadniania, aniżeli realnej pracy.

Pola: W Novakid, jeżeli mamy jakąś większą inicjatywę to zawsze wyznaczamy osobę z biznesu, która jest odpowiedzialna i ma ostatnie słowo razem z product managerem. To nam bardzo pomaga bo jest ktoś, kto może powiedzieć: „okej, podejmujemy decyzję i idziemy dalej”.

Druga rzecz, która jest ważna to żeby mieć koło siebie osobę, która jest ekspertem w danym obszarze.

Na przykład, gdy podejmujemy decyzję na temat marketingu to niech ostateczne słowo ma osoba z tego działu, a nie np. developer. Jeżeli feedback daje CTO, to on musi patrzeć na to od strony technicznej, a nie sprzedażowej. W przeciwnym razie mamy do czynienia z sytuacją, że mamy wielu pseudo ekspertów i ciężko nam jest podjąć decyzję.

Grzesiek: A mogłabyś mi jeszcze powiedzieć jak wygląda u Ciebie praca zdalna?

Pola: Pracuję zdalnie i jeszcze dodatkowo pracuję głównie z osobami, które nie mieszkają w Polsce, i nie mówią po polsku. Uważam, że to jest dodatkowe utrudnienie, bo jedno to praca zdalna, a drugie to bariera językowa. Rozmawiamy wszyscy po angielsku, ale wiadomo, że ta rozmowa nigdy nie będzie na takim poziomie jak w naszych ojczystych językach. Jeżeli chodzi o pracę zdalną: (to jest tylko moje zdanie i zależy to od osób indywidualnie) uważam, że mimo pracy zdalnej warto chociaż raz zobaczyć się z ludźmi, z którymi się pracuje – mi to bardzo pomogło.

W czerwcu mieliśmy okazję spotkać się na żywo w Stambule i od tego czasu lepiej współpracuje mi się z tymi osobami. Jednak praca zdalna zostawia dużo pola do domysłów, jakiegoś wyobrażania sobie, kto jaki jest, albo kto jakie ma intencje. Kiedy widzimy się na żywo to nic nie da się ukryć i dlatego nie ma tej bariery pracy zdalnej.

Podczas pracy zdalnej bardzo intensywnie korzystamy ze Slack-a, ale wiadomo, że kiedy rozmowa jest zbyt długa, to nie ma sensu jej kontynuować, tylko wskoczyć na szybkiego calla.

Jeśli chodzi o warsztaty to często robimy tak, że zaczynamy od spotkania, a później kontynuujemy offline – nie siedzimy razem na callu i nie zapisujemy na karteczkach jakichś pomysłów, tylko rozchodzimy się i każdy musi zapisać swoje pomysły np. na tablicy w Miro. Po tym, nadal offline, zapoznajemy się z tym, co każdy przygotował spotykamy się ponownie i o tym dyskutujemy, żeby dojść do rezultatu.

Grzesiek: A co jest twoim największym wyzwaniem w pracy product managera?

Pola: Obecnie moim największym wyzwaniem jest to, że jestem odpowiedzialna za aplikację mobilną, która była kiedyś stworzona na podstawie wcześniej ustalonych założeń, a ja muszę teraz zadecydować co z nią robimy.

Czy zupełnie ją usuwamy, czy rozdzielamy aplikację mobilną na aplikację dla dzieci i aplikację dla rodziców. Czy zostajemy przy aplikacji, która jest i w niej robimy część dla dziecka i dla rodzica. Czy może w ogóle nie potrzebujemy którejś z tych części.

To jest dla mnie wyzwanie, bo uważam, że dotyczy to też zaplanowania większej strategii firmy.

Grzesiek: Faktycznie brzmi jak mega wyzwanie, które zaowocuje super doświadczeniem. Dziękuje za Twój czas dzisiaj.

Pola: Również dziękuję!

Jeśli podobał Ci się ten wywiad to kliknij w 💙 oraz zostaw komentarz.

Jeśli jeszcze nie jesteś w naszej społeczności Product Art to zapraszam do subskrypcji.