+25 do ekwipunku warsztatowca, czyli lista 25 narzędzi do prowadzenia warsztatów zdalnie

Zamów e-booka

Szymon Paluch – Jak wygląda branża startupowa w Polsce? Project: People Podcast 16

Podcast

Jak wygląda branża startupowa w Polsce?

Joanna Ostafin rozmawia z Szymonem Paluchem CTO uPacjenta i Co-Founderem agencji RIOT, na temat tego, jak kształtuje się branża startupowa w Polsce. Ewangeliści tezy: „trzeba być zakochanym w problemie, a nie w rozwiązaniu” rozmawiają o tym, czy startupy w Polsce w ogóle się rozwijają, czy programy akceleracyjne przynoszą jakiekolwiek korzyści oraz o tym, czym jest ukryty waterfall pod płaszczykiem zwinnej metody.

Słuchając tego odcinka dowiesz się:

  • że dużym problemem naszego rynku jest przewaga firm usługowych, nad produktowymi i dlaczego tak jest;
  • czym jest MVP i jakie ma pełnić zadanie;
  • jakie są 3 największe problemy i potencjalne kroki, które founderzy lub twórcy produktów powinni zrealizować, aby umocnić produktowość;
  • czym różnią się rolę Scrum Mastera, Product Ownera i Project Managera, a jak zazwyczaj są odbierane w branży startupowej w Polsce;
  • czym wg Szymona jest startup.

Wymieniona w podcaście książka:

  • Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group) – Marty Cagan.

Chcesz mieć dostęp do rozbudowanej bazy autorskich narzędzi i dodatkowych materiałów?

Daj znać, pod jakim adresem możemy się z Tobą kontaktować!



    Zgadzam się na przetwarzanie moich danych osobowych przez Project: People Sp. z o.o. w celu komunikacji marketingowej, a tym samym wysyłania mi newslettera, informacji o usługach, promocjach lub nowościach zgodnie z Polityką prywatności.

     

    Odcinek prowadzi:

    Joanna Ostafin

    Gość odcinka:

    Szymon Paluch

     

    Słuchaj też na:

     

    Transkrypcja:

    Cześć, słuchasz Project: People Podcast, czyli audycji, w której omawiamy problemy biznesowe i ich rozwiązania na konkretnych przykładach.

    Jako agencja strategiczna, zajmujemy się tworzeniem strategii biznesowych i marketingowych, digital marketingiem oraz UX i UI.

    Mamy już ponad 4 – letnie doświadczenie w pracy z polskimi i zagranicznymi firmami. A ten podcast stworzyliśmy z potrzeby – nieodpartej potrzeby dzielenia się wiedzą. Cześć, z tej strony Asia Ostafin i mam okazję gościć w naszym podcaście Szymona. Szymon Paluch CTO uPacjenta i Co-Founder agencji RIOT. Cześć Szymon.

    Szymon: Cześć.

    Asia: Zacznijmy od tego, żeby zrobić tło naszym słuchaczom, skąd nasza dzisiejsza rozmowa. W zeszłym tygodniu, z Szymonem, mieliśmy spontaniczne spotkanie przy kawie online, gdzie zaczęliśmy rozmawiać o tym, jaka jest kondycja branży startupowej i branży usługowej w Polsce.

    Rozmowa w zasadzie ciągnęła się i na tyle była interesująca, że przerwaliśmy ją stwierdzając, że nadaje się na podcast. Stąd jesteśmy tutaj dzisiaj dzisiaj z wami. Chcielibyśmy porozmawiać o tym, o czym wtedy zaczęliśmy z Szymonem. Czyli jak wygląda branża startupowa w Polsce i trochę o tym, jak wygląda poszukiwanie tego unicorna, tego startupu, tego produktu, który odnosi sukces.

    Ale też z drugiej strony, jak wygląda poszukiwanie unicorna pod kątem osoby. Takiej osoby, o której my rozmawialiśmy, która ma takie holistyczne podejście i umie działać na styku wielu branż. Myślę, że to będzie nasz główny motyw, ale też poruszymy kilka innych tematów.

    Szymon: Tak dokładnie. Ja napisałem do Asi, czy nie miałaby ochoty porozmawiać, gdyż stwierdziłem, że chciałbym właśnie znaleźć kogoś, kto ma takie holistyczne spojrzenie, a wiem, że w Project: People jest dużo takich osób. I chciałem porozmawiać o obserwacjach, które miałem przeglądając grupy na Facebooku, rozmawiając ze znajomymi, czy rozmawiając z ludźmi z branży.

    Zauważyłem, że jest bardzo dużo osób, które idą mocno domenowo, które mają specjalizacje techniczne, biznesowe, designerskie, a często brakuje im takiego myślenia na styku. Czegoś, co będzie przechodziło pomiędzy tymi dziedzinami i sprawiało, że można tworzyć produkty, które naprawdę fajnie rosną.

    Asia: To było też wstępem do naszej rozmowy o spostrzeżeniach na temat naszego podwórka startupowego. Jak wygląda proporcja między firmami produktowymi vs firmami usługowymi. 

    Szymon: A pamiętasz to pierwsze pytanie, które Ci zadałem wtedy? Czy macie dużo klientów, którzy są firmami produktowymi, czy raczej to są firmy usługowe? Tutaj w waszym przypadku, z tego co powiedziałaś, to były produkty. Natomiast po tym, jak zaczęliśmy analizować, to stwierdziliśmy, że nasz polski rynek w głównej mierze skupia się na firmach usługowych, a nie na firmach produktowych.

    Dzisiaj jak to analizowałem, to stwierdziłem, że pewnie gdybyśmy przeszli sobie tutaj ulicą pod budynkiem, znaleźlibyśmy pewnie pięć software house’ów i żadnej firmy produktowej. 

    Asia:  Tak, ja się z tym zgodzę. Tych produktów jest faktycznie mało. My mamy okazję pracować z branżą usługową i z branżą produktową. Natomiast wydaje mi się, że siłą rzeczy z produktami więcej, bo my dużo pracujemy ze startupami. Z takimi startupami na samym początku drogi, więc tutaj mamy ogrom różnych pomysłów, idei, które raz wypalają raz nie wypalają. Pracujemy trochę ze startupami, które są już po jakichś rundach finansowania, są trochę bardziej dojrzałe i tam już kompetencje wyglądają zupełnie inaczej. 

    Szymon: Dużo tych firm wypala?

    Asia: Chociaż się mówi, że ta statystyka, że osiem na dziesięć firm startupowych upada, jest już nieprawdziwa, to ja bym powiedziała, że jednak mimo wszystko, jesteśmy dalej blisko tej statystyki.

    Nie prowadzimy u nas takich liczb, nie sprawdzamy sobie tego. Natomiast tak bardziej z mojego czucia, bo ja mentoruje pewnie około pięćdziesięciu startupów rocznie, w ramach różnych Startup Weekendów, różnych programów akceleracyjnych, w ramach pracy z naszymi klientami, tak naprawdę to po dwóch, trzech latach, dalej słyszę tylko o 10% z nich. 

    Szymon: No właśnie, tutaj mamy ten problem, że startupy produktowe mogą bardzo fajnie wystrzelić, zostać tym unicornem, ale też bardzo często upadają. Natomiast software house’y, agencje, firmy usługowe, nie powiem, że nie upadają, ale ich żywot jest taki spokojniejszy, nie skalują się tak dobrze i nie upadają tak szybko, przez co łatwiej jest utrzymać taką firmę, pewnie łatwiej jest wejść, a to jest naprawdę ciężki kawałek chleba, utrzymanie takiej firmy.

    Natomiast jeżeli chodzi o jej żywotność, to chyba łatwiej ją utrzymać przy życiu, niż taką firmę produktową. To może być jeden z powodów, dla których nie ma aż tak wielu, przynajmniej moim zdaniem, startupów produktowych. Na tyle, na ile się mówi o całym środowisku, o całej branży startupowej w Polsce, już parę lat temu zaczął się bardzo duży hype na robienie własnych produktów, własnych firm, to jednak tak na dobrą sprawę te firmy, które osiągnęły wielki sukces, to można policzyć na palcach dwóch rąk.

    Potem na kolejnych palcach u rąk możemy policzyć te, które gdzieś może nam się obiły o uszy. Istnieją, ale ten sukces nie jest tak duży, jakby wszyscy myśleli. A potem cisza, dużo tych małych, o których nikt nie słyszał, dużo tych którzy byli i nagle ich nie ma. Natomiast jeżeli mówimy o software house’ach, to jest ich naprawdę na pęczki, bardzo dużo świadczy usługi.

    No i tutaj zaczyna się ten problem, który zacząłem obserwować już jakiś czas temu, że w Polsce, moim zdaniem, jest dość słabej jakości kultura produktowa, a mocna kultura usługowa. Co widać potem w tym, jak my te produkty robimy, jakie mamy podejście do tworzenia startupów, do tworzenia produktów cyfrowych, czy nawet do codziennej pracy.

    Asia: Zgodzę się z tym, co powiedziałeś pod kątem tego, jak dużo mamy firm usługowych vs produktowych, jak dużo software house’ów. Czyli co, wygodniej jest stworzyć software house, czy firmę usługową?

    Szymon: Czy wygodniej to nie wiem, tak na dłuższą metę. Natomiast próg wejścia na pewno jest niższy. Wystarczy znać pierwszego klienta, który będzie chciał zapłacić za nasze usługi i możesz zacząć działać.

    Tworząc produkt nie jest tak prosto, bo nie mając środków, załóżmy taki scenariusz, bo są też osoby, które mają środki na początku, ale jeżeli nie mamy środków, musimy w jakiś sposób ten produkt stworzyć, zacząć go sprzedawać. A to naprawdę bardzo długa droga do pierwszych pieniędzy, do pierwszego klienta i do osiągnięcia tego break even point, gdzie zaczynamy zarabiać na naszym produkcie.

    Asia: No i właśnie mamy taką sytuację, że na samym początku wydaje się nam, że: ooo, otworzę sobie firmę usługową, bo właśnie to co powiedziałeś, jest dużo, dużo prościej i mamy masę software house’ów, małych zespołów designerskich.  Takich, które są w stanie wspierać twórców produktów, bo jest prosto to zrobić.

    Wystarczy mieć jednego klienta, dwóch klientów i jakoś to będzie. Masz doświadczenie w branży usługowej również, więc wiesz, że utrzymanie później takiego większego zespołu, to wbrew pozorom w firmie usługowej jest ciężka orka często. Jest to ogrom pracy.

    Szymon: Jeżeli mamy produkt, który zaczyna nam przynosić zyski, to jest to produkt, najlepiej na rynku B2C, przy którym mamy dostęp do dużej ilości klientów. Jego skalowalność będzie stosunkowo duża, więc przychody, które zaczynamy w końcu osiągać, czy inwestycje, które zaczynamy zdobywać, są tak bardzo rosnące, że jesteśmy w stanie faktycznie nasz zespół szybko i mocno poszerzać.

    W przypadku usług zwrot jest dość mocno liniowy. Tutaj mamy więcej projektów, potrzebujemy więcej pracowników. Takie przełamania mamy, w momencie, w którym wychodzimy z rynku polskiego na zagranicę. Skalują nam się ceny, ale to dalej nie jest wzrost wykładniczy, tylko skok na kolejną linię pod wyższym kątem nachylenia.

    Asia: No i dochodzi do takiej sytuacji, którą ja też obserwuję, czyli masa właścicieli software house’ów, czy mniejszych, większych zespołów deweloperskich/designerskich, którzy chcą mieć własny produkt. Co stoi na przeszkodzie, żeby mieli swój produkt? 

    Szymon: No tak. Też zacząłem to obserwować, szczególnie jeżeli udało im zbudować jakąś poduszkę finansową, tak, żeby pozwolić sobie na stworzenie własnego produktu. Często też jest sytuacja, gdzie zespoły tworzą produkt na potrzeby własne, jakieś narzędzie wewnętrzne, zaczęła go sprzedawać.

    Natomiast usługi charakteryzują się bardzo często tym, że są domenowe. Czyli mamy tutaj software house’y, które zajmują się technologią. Mamy agencje kreatywne, które bardziej idą w stronę designu. Mamy firmy, które skupiają się na tym, co robią najlepiej, a tworząc produkt, nie możemy się skupiać na jednej rzeczy.

    Jeżeli mamy software house, który ma super programistów, on zatrudniając najlepszych programistów, może być najlepszym software housem, ale zatrudniając tylko programistów, nie stworzy najlepszego na świecie produktu. Brakuje mu domen w innych częściach, w których nie jest wyspecjalizowany.

    Asia: Dochodzimy właśnie do tego, o czym rozmawialiśmy. Czyli mamy sytuację, taką bardzo klasyczną w naszej branży. Mamy osoby, które chcą stworzyć własne produkty. Na początku łatwo jest odpalić software house, bo jest usługowy. Później, do pewnego momentu się skalujemy, dochodzimy do tego momentu o którym wspomniałeś. Zaczynamy dostrzegać, że nasze skalowanie polega na tym, że zatrudniamy kolejne osoby i ewentualnie wychodzimy na nowe rynki, a wtedy lekko się skaluje ceny.

    Natomiast jakby jest dość liniowo. W pewnym momencie wszystkie te software house’y chcą właśnie mieć swój produkt. Część zaczyna faktycznie tworzyć swój produkt, bo my też się z nimi spotykamy. Ja to też widzę, czyli zaczynają tworzyć swój produkt, bo znają się na tym, jak go zrobić dobrze technicznie, zależy czy mają designera na pokładzie, czy nie, to on jeszcze czasem jakoś wygląda, lub wygląda trochę mniej przyjaźnie dla użytkownika.

    Natomiast później dochodzimy do tego momentu marketowania. To co powinny zrobić w tej chwili software house’y według Ciebie, jeśli już mają swój produkt?

    Szymon: No tutaj na pewno musimy podejść do tego bardzo zwinnie. Nie możemy znaleźć jednej recepty, tylko to jest kwestia prób i błędów. Różne software house’y będą sobie lepiej, bądź gorzej radzić w sprzedaży swojego produktu, w rozwoju tego produktu.

    Tak, jak powiedziałem wcześniej. Technologia – super, mamy najlepszego programistę. Brakuje nam, przykładowo, designu, a wiemy, że musi być produkt, który jest łatwy. Możemy zatrudnić najlepszego designera. Musimy zrozumieć rynek na którym chcemy sprzedawać, poznać biznes, mieć te fundamenty biznesu, zmienić swój marketing, bo inaczej się sprzedaje usługi, inaczej się sprzedają produkty. Uczenie się wszystkiego. Bo to nie jest tak, że zrobimy sobie software house i te same mechanizmy sprzedaży, te same mechaniki marketingowe, możemy zastosować do produktu.

    Sprzedajemy to w zupełnie inny sposób. Jeżeli wiemy, że nie możemy stosować tych samych technik, to zaczynamy korzystać z tych, które są przeznaczone dla produktów, więc musimy się nauczyć, musimy próbować, co działa w naszym przypadku. Czyli wchodzimy w taki fajny agile, gdzie musimy testować.

    A tutaj jest takie ryzyko, że my, jako już doświadczeni przedsiębiorcy stwierdzimy, że już wiemy jak się sprzedaje, jak się robi marketing, więc wszystko będzie po staremu. No nie będzie. Tutaj pewne inne prawa wchodzą w grę i trzeba być świadomym i zacząć sprawdzać, i próbować, co działa.

    Natomiast wracając do tego clue. OK, mamy technologię, a nie mamy designu. To zatrudniamy najlepszego designera jakiego znajdujemy na rynku. Mamy dużą poduszkę powietrzną, klienci ze Stanów zapewnili naprawdę fajne finansowanie na software house’ie, mam dużo pieniędzy, żeby zbudować dział designu.

    Mamy już dział designu, zaczynamy budować w ogóle pozycje, których do tej pory nie mieliśmy, bo musimy zacząć budować marketing, który pewnie był albo mniejszy, jednoosobowy, a nagle przy produkcie, on zaczyna mieć większą rolę. 

    Musimy zacząć mieć analityków biznesowych, zaczynają też wchodzić testerzy na większą skalę. Więc zaczynamy budować dział, którego do tej pory nie było. Możemy znowu bardzo dużo środków pieniężnych przeznaczyć na to, żeby te działy zacząć budować.

    Ale czy to da nam sukces? Niekoniecznie. Bo znowu, jeżeli będziemy mieli osobno, najlepszego designera, najlepszego programistę, to oni nie stworzą najlepszego produktu, jeżeli będą działać razem i nie znajdą wspólnego języka komunikacji.

    Dopiero współdziałanie pomiędzy tymi różnymi dziedzinami daje nam efekty. Takie jest moje zdanie, oparte o własne obserwacje. Największymi problemami są te problemy komunikacyjne. Nie jest problemem napisać kawałek kodu, a potem go poprawić, nie jest problemem zrobić projekt, zwalidować i potem go poprawić. Ale problem jest przy tworzeniu takiego zespołu, który ramię w ramię będzie działał po to, żeby stworzyć produkt i będzie on zespołem cross-domenowym.

    Asia: Czyli brakuje nam, w zasadzie, umiejętności nie na poziomie specjalistycznym, wykonawczym, ale później, na poziomie liderskim, menedżerskim. Jedna rzecz, którą Ty powiedziałeś i złapała moją uwagę.

    Powiedziałeś, że trzeba wiedzieć, że potrzebuję np. zatrudnić designera albo wiedzieć, że potrzebuję zatrudnić jakiegoś dewelopera itd. Ja bym powiedziała, że ten problem, który jest, to jest właśnie to, że dużo osób nie wie. Nie wie czego potrzebuje, tylko jej się wydaje: stworzę produkt i jakoś to będzie.

    Szymon: Musimy wiedzieć, że trzeba kogoś zatrudnić. A jak go zatrudnimy, to musimy wiedzieć, jak pokierować tymi ludźmi tak, żeby oni działali razem. Tutaj też musimy nastawić pracowników na to, że teraz pracują inaczej, że tworzymy produkt. Nie tworzymy projektu dla klienta. Z tym też często się spotykam.

    Programiści, przychodząc do firmy, mają w głowie deadline, że sprint musi być zamknięty ze wszystkimi taskami. Nie do końca tak wygląda praca nad produktem. Nam nie zależy tak bardzo na czasie. Oczywiście wiadomo, im szybciej wyjdziemy na rynek, tym lepiej, ale po to robimy sobie małej itercje.

    Natomiast nam zależy na dostarczaniu wartości dla klienta. Na stworzeniu jak najlepszego produktu rozwiązującego problem naszych klientów. Na walidacji pewnych założeń, na całej fazie discovery, której w praktyce, w software house’ach, nie ma. Przychodzi klient, daje nam wytyczne, daje nam deadline, musimy to dowieźć.

    Czyli tak naprawdę delivery jest dla nas najważniejsze, dowiezienie produktu. W przypadku tworzenia produktów delivery nie jest najważniejsze, nie dostarczenie tego na czas, tylko dostarczenie odpowiedniej wartości. Tak naprawdę wartość wchodzi w grę, a nie czas.

    Asia: To jest zupełna zmiana perspektywy. Tutaj już nie skupia się na tym, że musisz dowieźć cokolwiek.

    Szymon: Dany zespół musi to wiedzieć, zespół to musi czuć. To nie tak tylko, że menadżer powie im: słuchajcie, nie mamy deadline’ów. Jeżeli oni są przyzwyczajeni do pracy takiej, że robimy task za taskiem, to tak będą robić. Natomiast tutaj pojawia się pytanie: dlaczego?

    Ja staram się zawsze swojemu zespołowi powiedzieć: jak robicie zadanie, to powinniście wiedzieć, dlaczego je robicie. Nie chodzi o to, żeby być maszynką, która siądzie do komputera i “nakodzi”. Tu chodzi o to, żebyśmy mieli świadomość, dla kogo to robimy, po co to robimy, jaką wartość wnosimy dla użytkownika. Jaki impact mamy na firmę.

    Żebyśmy nie robili głupich zadań, bo możemy mieć pełen backlog hell. Mamy super dużo User Stories i sobie ściągamy, ściągamy, ściągamy, a koniec końców, nie dowozimy żadnej wartości. Możemy zrobić mniej, a większą wartość i w przypadku produktów, to ma znaczenie.

    W przypadku software house’ów najczęściej po prostu ściągnięcie wszystkich features z oczekiwań klienta sprawia, że mamy sukces. Natomiast tutaj też jest właśnie ta różnica, że w software house’ach, zadowalamy najczęściej naszego klienta, którym jest jakaś firma, jakiś przedsiębiorca, który zamówił u nas produkt.

    W przypadku tworzenia produktów, musimy zadowolić końcowych użytkowników i to jest ta różnica. Tworząc nawet firmy, które mają doświadczenie w tworzeniu produktów cyfrowych dla klientów, dla startupów, one nie tworzą tego dla klientów końcowych, tylko dla swoich klientów, którzy płacą, a nie dla tych, którzy używają.

    Asia: Zawsze mamy klasyczny problem ze sprzedażą np. badań, czy testów itd., bo zależy nam, żeby sprzedać cokolwiek, a my nie musimy dowieźć wartości gdzieś tam na końcu. Często się pojawia takie coś w branży usługowej. 

    Szymon: Też wchodzi kwestia badania. W produkcie mamy dwie fazy: discovery i delivery. Czyli moment, w którym musimy odkryć produkt, zdefiniować go. Moment, w którym musimy ten produkt wypuścić. W przypadku agencji mamy przeważnie delivery, czasem jest jakieś małe discovery, ale to bardziej technologiczne, sprawdzenie wymagań klienta.

    Natomiast discovery, w prawdziwej firmie produktowej, polega na tym, że my musimy poznać wszystkie zagrożenia. A zagrożenia, to mam na myśli, nie tylko, czy będą jakieś problemy technologiczne. To jest akurat najmniejszy problem. My musimy zbadać użyteczność, czy w ogóle to, co dopuścimy, będzie w jakikolwiek sposób używane.

    Bo co z tego, że klienci chcą z tego korzystać, co z tego, że technologia nam pozwoliła to zrobić, skoro klient w połowie się nie połapie i zrezygnuje. Ale to też nie jest największy problem. Największym problemem jest to, czy w ogóle to, co wypuszczamy, sprawi, że ktokolwiek będzie chciał z tego skorzystać. Czyli sprawdzenie wartości biznesowej. Tak naprawdę możemy stworzyć najlepiej działający technologicznie produkt, super użyteczny, z którego nikt nie chce korzystać.

    Asia: To spróbujmy podsumować te problemy. Bo zaadresowaliśmy kilka różnych problemów. W zasadzie też i kilka rozwiązań poszerzyliśmy. Ale czas, żeby to spiąć wszystko.

    Największe problemy na naszym rynku, to te, o których już powiedzieliśmy. Generalnie mamy więcej firm usługowych, mamy kulturę usługową, a nie produktową. Zgadza się? Z drugiej strony, brakuje nam na poziomie menedżerskim świadomości i wiedzy, na temat tego, jakich kompetencji potrzebujemy, żeby budować produkty.

    Ja do tego worka bym dorzuciła, że brakuje nam też wśród takich founderów, założycieli firm, którzy jeszcze nie mieli żadnego startupu, żadnego produktu, żadnej firmy, biznesu, to brakuje nam też takiej wiedzy, że założenie własnego startupu, to nie jest tylko fajny design, dobry kod, ewentualnie jakaś wiedza taka biznesowa, ale to też jest zarządzanie w ogóle firmą, to też jest myślenie o finansach, HR-ach.

    Szymon: Kiedy budujemy firmę, budujemy biznes to to, że mamy produkt i jest on corem naszej działalności, nie zmienia faktu, że zaraz zaczniemy zatrudniać ludzi. Trzeba umieć rekrutować, rozmawiać z ludźmi. Zaczniemy płacić podatki, trzeba umieć się rozliczyć.

    Więc faktycznie budujemy biznes, budujemy firmę, a nie tylko i wyłącznie sam produkt. Natomiast tak w przypadku budowania firmy, tu mamy dużo pomocy z zewnątrz. Jeżeli chodzi o kwestie finansowe, to jest bardzo dużo firm księgowych i pewnie dopóki nie będziemy mieli kilkuset osób na pokładzie, będziemy korzystać z zewnętrznej firmy księgowej.

    W przypadku HR-ów, to też jest bardzo duże wyzwanie, natomiast mając jakieś fundusze możemy korzystać z agencji rekrutujących. Na początek trzeba będzie samemu to wszystko robić, ale potem znajdziemy jakąś osobę do HR-u. Na początek to wystarczy.

    Natomiast tworzenie produktów, to jest taka niezbadana ziemia. Często widzę gdzieś tam po grupach na Facebooku, że przychodzą ci młodzi ludzie, którzy mają w głowie jakiś pomysł, ale w ogóle nie mają pojęcia, jak zwalidować pomysł, użyteczność, by się te wszystkie rzeczy zgadzały, żeby się dowiedzieć, czy nasz pomysł jest dobry.

    Często są zakochani w swoim produkcie i to jest problem. Są zakochani w produkcie, mają wizje, więc to już jest super, bo są gdzieś tam przed 80% społeczeństwa, które w ogóle nie mają wizji. Posiadanie wizji to nie wszystko. Bo możemy mieć wizję, ale tę wizję trzeba umieć zwalidować.

    Zakochanie w produkcie może nam utrudnić życie, bo tak naprawdę mamy wizję, mamy ten produkt, ale się okazuje, że nie do końca wszystko jest tak, jak sobie to wymarzyliśmy. Tutaj nasza wizja najczęściej jest rozwiązaniem problemów. Po to robimy produkty, po to robimy biznes, żeby rozwiązywać problemy naszych użytkowników, naszych klientów.

    Jeżeli zdefiniujemy dobrze ten problem, to clue jest po to, żeby być zakochanym w tym problemie. Żeby wiedzieć, jak go rozwiązywać, jak optymalizować, a nie w samym produkcie. Bo produkt się będzie zmieniał. To też jest taki główny problem founderów.

    Oni mają jedną wizję i trzymają się jej kurczowo, nieważne co się dzieje. Idą potem na spotkanie z inwestorami i przedstawiają liczby. Widziałem wiele takich arkuszy, gdzie te liczby były naprawdę naciągane, ale ci ludzie wierzyli. Ci ludzie wierzyli, że te liczby tak będą za rok wyglądać, a zgadnij, ile razy tak to wyglądało.

     Asia: 1/10, oby tyle. Powiedziałeś takie zdanie, a ja jestem mocną ambasadorką, czy ewangelistką tego zdania, że trzeba być zakochanym w problemie, a nie w rozwiązaniu.

    Mam to w swoich prezentacjach. Pewnie, jeśli ktoś przejrzałby nasze prezentacje na firmowym slideshare’rze, to tam od czterech, pięciu lat o tym wspominam. I teraz się tak zastanawiam. Powiedziałeś: wchodzę na te grupy startupowe na Facebooku i czytam cały czas te same pytania, czyli jak zwalidować pomysł na nowy startup, na nowy produkt.

    Ja myślę, że też mówię o tym już od kilku lat, Ty o tym mówisz, masa osób o tym mówi. To jak to się dzieje, że w dalszym ciągu pytamy o te same rzeczy? Czy nasza branża się nie rozwija?

    Szymon: Wydaje mi się, że to jest trochę w naturze ludzkiej. Nie myślimy problemami, myślimy rozwiązaniami. Nasz umysł, jak widzi jakiś problem, to od razu stara się nam podpowiedzieć jakieś rozwiązanie, bo chce nas pozbawić problemu. Wpada nam rozwiązanie do głowy i my się go kurczowo trzymamy.

    To często widać w firmach, w których nie ma takiej kultury produktowej, gdzie nie ma fazy discovery, gdzie nie ma badań, gdzie wszystko jest troszkę w rękach działów biznesowych, gdzie po prostu jest zespół, który ma to wytworzyć. Przychodzi biznes i mówi: zróbcie mi takie rozwiązanie.

    Problem jest, jeżeli ono dostarczone zgodnie ze specyfikacją, dalej nie będzie rozwiązywać problemu. Może się tak okazać. Jest mało myślenia co powoduje ten problem, jest mało myślenia, jakie są alternatywy. Czyli można powiedzieć, że jest takie leczenie objawów, a nie leczenie realnego powodu tego problemu.

    Asia: Też się z tym zgodzę. To co możemy teraz zrobić? Bo ja i ty mamy takie mocne nastawienie na wsparcie, na edukację i rozwój naszej społeczności. Co możemy zrobić żeby trochę poprawić to myślenie?

    Szymon: Tutaj trzeba wrócić do tej kultury. Wypadałoby zrobić miejsce, w którym ludzie będą w stanie obcować z tą kulturą produktową, wymieniać się wiedzą. Tak jak wspomnieliśmy. Ktoś zaczyna z poziomu technologii, to pewnie ma dość małe pojęcie na temat designu, wiedzy o tym, czemu pewne rzeczy tak powinny być zaprojektowane albo inaczej, jak walidować użyteczność.

    Ktoś idzie z poziomu biznesu, nie zawsze wie, jaką technologię ma dobrać. Ktoś zaczyna z poziomu designu, też ma problem z technologią, czasem może mieć problem z biznesem. Teraz każda z tych dziedzin ma problem z wiedzą cross domenową.

    Moim zdaniem brakuje miejsca, gdzie ta wymiana wiedzy byłaby odpowiednia. Brakuje materiałów, żeby faktycznie dało się tę wiedzę zdobyć, a może nawet brakuje trochę mentoringu. Pewnie większość osób, która zaczyna swój startup, czytała książkę „Lean Startup”. Tam bardzo fajnie zdefiniowane jest MVP.

    A ile osób wie co to jest MVP? Tak po czasie doszedłem, że pewnie mało. Mając nawet w czasach agencyjnych klientów, to 90 procent moich klientów przychodziła i mówiła, że chce MVP, a tak naprawdę z tych wszystkich klientów, może jeden chciał MVP. MVP jest traktowane jako produkt, który powinien trafić na rynek i zacząć zarabiać, ale kosztować tyle, co około 20 procent swojej wartości.

    Tak naprawdę MVP powinno być testem. MVP powinno być produktem, który nam odpowie, czy nasze założenia biznesowe są słuszne, czy może po prostu nie powinniśmy przepalać więcej pieniędzy i powinniśmy zrezygnować. Możemy mieć MVP, które potem pójdzie do kosza, bo będzie pozytywnie zwalidowane i trzeba zrobić coś od nowa.

    Ale coś, co będzie się skalować. A MVP nie musi się skalować. Takich podstaw brakuje ludziom. Nie wiedzą, jak realizować swoje pomysły. Nie wiedzą, jak zrobić pierwsze kroki. Nie wiedzą, jakie technologie dobrać, jeżeli nie są technologiczni. A jeżeli są technologiczni, to nie wiedzą, jak odpowiednio to zaprezentować, żeby ludzie chcieli z tego korzystać.

    I tutaj wydaje mi się, że to wymiana wiedzy jest takim fundamentem do tego, żeby ci młodzi founderzy, mając swoją domenę jedną, ale też mając jakieś wsparcie wiedzowe w innych domenach, byli w stanie robić lepsze produkty. Często widzimy, że founderzy są cross domenowi.

    Jak mamy dwóch, trzech founderów, to jeden jest techniczny, drugi bardziej biznesowy. Często te projekty mają o wiele łatwiej na początku, bo każdy bierze na siebie odpowiedzialność, a kiedy mamy pojedynczych founderów, jest znacznie trudniej. 

    Asia: Co myślisz o roli programów akceleracyjnych, czy pre-akceleracyjnych, czy inkubatorów? Bo teoretycznie, to one powinny dawać taką wiedzę, jak rozwijać produkty.

    Szymon: To jest dokładnie to, co mówisz. Tutaj powinna to być ich taka rola. Natomiast, jak to się w praktyce sprawdza, ja mam takie troszkę mieszane zdanie. Sam brałem udział w akceleratorach i powiem szczerze, dały mi dużo wiedzy. Ja byłem osobą technologiczną i tutaj dla mnie wiedza biznesowa, którą tam dostałem, to było naprawdę coś dużego.

    Ja siedziałem i wychodziłem z każdych 100 spotkań ze szczęką na podłodze. Jak sprzedawać? Jak robić marketing? Kwestie księgowe. Dla mnie to była mega wiedza, która mi dużo dała. Natomiast byli koledzy z Uniwersytetu Ekonomicznego na tych zajęciach. No i oni nie dostali tej części technologicznej, której potrzebowali.

    A na tych zajęciach, na których ja zbierałem szczękę z podłogi, oni ziewali i potem wychodzili, mówiąc, że nic więcej niż na studiach. Znowu mamy tak, że zależy kto prowadzi akcelerator. Jeżeli mamy domenę akceleratorów technologiczną, to pewnie będzie troszkę nacisk na technologię. Jeżeli mamy domenę biznesową, będziemy mieć nacisk na kwestie ekonomiczne. Ja nie spotkałem, nie mówię, że nie ma, takiego fajnego cross domenowego środowiska.

    Asia: Ja widzę podobny problem, patrząc na startupy, które do nas przychodzą. Często opowiadają, jak są po różnych akceleratorach. Czyli w zależności od tego, jaka jest edycja, taka jest specyfika akceleratorów, że skupiają się mocniej na marketingu, na sprzedaży, to na technologii, na designie, na prawie, na księgowości.

    Natomiast w dalszym ciągu mamy mało tych produktowych. Patrząc na to, że są osoby, które odpowiadają generalnie za produkt w firmach, Project Managerowie, czy Project Ownerowie produktu. To są osoby, które teoretycznie wiedzą, jak zarządzać produktem. Może zacznijmy od tego, jaka jest różnica w ogóle.

    Szymon: Tak, mamy kilka stanowisk. Niektóre z nich są zdefiniowane, niektóre nie są zdefiniowane. To, co ja widzę, to że w Polsce jest bardzo mało pozycji Product Managera, jest ona bardzo słabo zdefiniowana. Natomiast Project Managerów jest dużo, Scrum Masterów mamy dużo. Product ownerów też trochę jest. Jak klasycznie się na to spojrzy, to najczęstszą z tych wymienionych przeze mnie pozycji, jest Project Manager, chyba jest ich najwięcej.

    Ma to odzwierciedlenie właśnie w tej kulturze usługowej. Project Manager to klasyka w software house’ie. Mamy osobę, która ma dopilnować tego, żeby właśnie terminy się zgadzały, żeby gdzieś tam zasoby pomiędzy zespołami były dobrze rozlokowane.

    Projekt musi się skończyć. Projekt zakończony sukcesem, to jest taki, który klient podpisze, akceptuje odbiór i projekt jest zakończony. Czy produkt tam był dobrze zrobiony, to jest jakby nieistotne. Ważne, żeby był podpis klienta na zakończonym projekcie.

    Scrum Master nie ma aż tak chyba roli, jeżeli chodzi o projekty i produkty, bardziej chyba też im chodzi o wsparcie zespołu. Ktoś, kto harmonizuje pracę zespołu, usuwa przeszkody, więc jest to bardzo wewnętrzna rola.

    Następnie mamy Product Ownera i tutaj się zaczynają schody. Jak to wygląda w przypadku Product Ownerów w Polsce? Spotkałem się z różnymi definicjami i z różnymi wizjami product Ownera z software house’ów, które mają swojego Ownera, nie bardzo wiem po co. Bo taka klasyczna definicja Product Ownera, to jest ktoś, kto powinien harmonizować backlog, po to, żeby stories, które dostarczamy, dawały jak największą wartość w ramach sprintu, w ramach potem całego jakiegoś milestona.

    Także odpowiada za to, jaki jest priorytet, jaka kolejność w realizowanych pracach. Po to, żeby maksymalizować wartość produktu. Teraz w przypadku takiej klasycznej współpracy software house’u z klientem, Product Owner, w mojej opinii, powinien być po stronie klienta, bo on odpowiada za to, co chce osiągnąć.

    W przypadku firm produktowych, też dobrze mieć taką rolę, bo jest to osoba, która finalnie będzie mówiła o priorytetach, o tym co nam da największą wartość. Ona nie działa tak bardzo z zespołem. Oczywiście rozmawia z nimi, jest na spotkaniach, nie harmonizuje pracy zespołu, od tego są Project Managerowie, Scrum Masterzy, oni pomagają, natomiast ten Product Owner odpowiadam za kontakt z biznesem, za to, co robią i w jakiej kolejności. Teraz mając Product Ownera, trochę nie mamy potrzeby posiadania Product Managera i tutaj się nam to zaczyna trochę wykluczać.

    Bo Project Manager, tak naprawdę, jeżeli sobie poczytamy książkę „Inspired” Cagana, to osoba, która odpowiada za kształt produktu. I jaka jest różnica? Można powiedzieć: OK, ale przez to, że Product Owner mówi, co mamy robić, to też odpowiada za kształt produktu. I tak tutaj się to wyklucza.

    W ten sposób natomiast, w takim klasycznym podejściu tworzenia produktów, to Biznes definiował produkty. Biznes mówił: chcemy mieć takie features, chcemy osiągnąć to. I przychodził Product Owner i rozmawiał z Biznesem, on ustalał z nimi priorytety, harmonizował sobie to, patrząc jak zespół pracuje, jak szybko dostarcza. Pod to ustawiał backlog, po to, żeby cele biznesowe były realizowane.

    Czyli on był takim punktem stykowym pomiędzy. Bo powinna być jedna osoba odpowiedzialna za to, żeby dowieźć jak największą wartość. I jest to punkt stykowy pomiędzy zespołem, a Biznesem.

    Natomiast w przypadku, kiedy wprowadzamy Product Managera, w ogóle pozbywamy się jednej osoby łącznikowej. Wtedy tak naprawdę powinniśmy mówić o Produktowym Trio. Czyli designer, developer i Product Manager, czyli trzy osoby, których celem jest tworzenie jak najlepszego produktu.

    To oni rozmawiają z Biznesem, jeżeli robimy coś dla biznesu. Ale jeżeli robimy coś dla klientów, to on już nie rozmawiają z Biznesem. Rozmawiają z klientami. Na nich jest odpowiedzialność, żeby dowieźć jak najlepszy produkt, pracując wspólnie.

    I tutaj mamy wizjonera, który powinien zaprojektować, powinien testować użyteczność.

    Mamy dewelopera, który powinien zbadać zagrożenia technologiczne, a potem w komunikacji z resztą zespołu developerów, dowieźć ten produkt.

    No i mamy Project Managera, który tak naprawdę spina to wszystko, poprzez sprawdzenie, czy założenia biznesowe się sprawdzają, czy mam odpowiednią wartość biznesową. Żebyśmy nie mylili, raczej Produkt Designer będzie sprawdzał użyteczność, ale nie będzie sprawdzał, czy dany produkt ma wartość biznesową dla użytkownika końcowego.

    To jest odpowiedzialność managera, to on powinien wiedzieć, czy to, co robimy ma sens, czy robimy to tylko po to, żeby sobie to zrobić. Ja bym powiedział, że to jest jego odpowiedzialność główna w tym zespole. On powinien być najbardziej cross domenowy, powinien łączyć te wszystkie światy. Mieć podstawową wiedzę z technologii, przynajmniej podstawową.

    Tak samo z designu. Wiedzieć, jaki jest rynek, w jakim biznesie działa. Znać swoich użytkowników, wiedzieć, jakie mają potrzeby i jak można realizować te potrzeby. Jak można rozwiązywać problemy finalnych użytkowników.

    Asia: Brzmi, jakby Product Manager był takim rozwiązaniem na te problemy, o których rozmawiamy.

     Szymon: A ilu znasz Product Managerów?

    Asia: No właśnie się miałam też zapytać teraz, ilu znasz Product Managerów, którzy zrobili własny produkt i czemu nie ma ich tak dużo? To jest właśnie to rozwiązanie, o którym rozmawiamy.

    Szymon: To nie jest rozwiązanie. To jest jeden ze sposobów. Ja nie krytykuję tutaj podejścia z Product Ownerem, który jest w zespole. Po prostu on sprawdza się w troszkę innych warunkach, kiedy mamy faktycznie mocny wpływ Biznesu na produkt.

    Może być tak. Natomiast w przypadku większości projektów B2C, jesteśmy w przypadku, w którym to, jak powinien wyglądać nasz produkt, definiują nasi użytkownicy. I tutaj przydaje się rola Product Managera.

    Asia: Tak, zdecydowanie się z tym zgodzę. Mi kiedyś było bliżej podejścia, dalej jestem zwolenniczką, że generalnie dobry Product Designer powinien jednak trochę stać na styku.

    Z racji tego, że ja też czułam, że brakuje nam takich Product Managerów, że generalnie u nas w zespołach, w tej chwili, jak rozmawiam z różnymi designerami, to uważam, że oni powinni zwracać uwagę z jednej strony na perspektywę użytkowników, ale z drugiej strony powinni zmienić perspektywę Biznesu właśnie przez to, że brakuje nam najczęściej kompetencji Product Managera.

    Szymon: Tak jest, jak mówisz. Natomiast ja jestem wielkim fanem angażowania na jak wcześniejszym etapie, czy to dewelopera, czy nawet jakiegoś testera. Ponieważ oni mają takie podejście często ścisłe, widzą pewne rzeczy, których inni nie widzą, z powodu sposobu swojej pracy.

    Dopiero zaangażowanie każdej z tych osób, kogoś, kto ma ogólnie szeroki pogląd, wie, o co chodzi w produkcie, wie o co chodzi w użytkownikach, w biznesie, kogoś, kto wie, jak projektować, kogoś kto wie, jak działają systemy. Zaangażowanie tych trzech osób potrafi dać najlepsze rezultaty. Collaborative Thinking, gdzie trzy osoby razem, z różnym doświadczeniem, potrafią stworzyć coś lepiej, niż jedna osoba, która myśli, że wszystko wie.

    Asia: Nie musisz mnie przekonywać. Ja jestem fanką Lean UX-owego podejścia. Gdzie z góry założenie jest takie, że zespół powinien holistycznie pokrywać procesy z wielu różnych kompetencji. Jestem ogromną fanką tego podejścia. Bardzo lubię angażować marketing od samego początku, czy osoby które odpowiadają za kontakt i obsługę klienta.

    Zdarzyło mi się przy takich sprintach, jak my pracujemy, angażować nawet osoby, które odpowiadały za księgowość, czy prawników. Więc to już w ogóle jest super, jeżeli możemy na tyle holistycznie podejść. Ja się jak najbardziej z tym zgadzam.

    Dobra, to tak, żeby zacząć zacząć powoli spinać pewne tematy, bo pewnie nasi słuchacze, widzą, że otworzyliśmy tutaj wiele wątków. Moglibyśmy gadać o tym pewnie jeszcze spokojnie drugie tyle, a może jeszcze nam się kiedyś uda. Rozmawialiśmy z Szymonem o tym, że może zrobimy jakiś webinar, może jakąś społeczność.

    Szymon: Myślę, że też chętnie byśmy z wami porozmawiali. Mam taką nadzieję, że część z was chętnie by uczestniczyła w takich rozmowach i swoje przemyślenia, swoje doświadczenia, włożyła do tej dyskusji. 

    Asia: My byśmy byli bardzo chętni. Więc jeżeli ktoś nas słucha i chciałby z nami również pogadać, to może łapać mnie albo Szymona, bo pewnie chętnie byśmy się zaangażowali w dyskusję, co możemy zrobić, żeby więcej produktów powstawało u nas nad Wisłą.

    Żebyśmy byli w stanie wytworzyć naprawdę fajną wartość jako społeczność. No dobra, ale tak wracając do naszego podsumowania. Szymon, jakbyś wymienił trzy największe problemy i trzy potencjalne kroki, które ty widzisz, jakieś sposoby. Co powinniśmy zrobić, jako potencjalni founderzy, czy twórcy produktów, jako uczestnicy tej społeczności, żeby rozwiązać ten problem, żebyśmy byli mniej usługowy i mocniej produktowi.

    Szymon: No tak, to jest moim zdaniem pierwszy problem. Czyli brak dobrze zbudowanej kultury produktowej. Duże piętno odciska w każdym z nas kultura usługowa. Drugi, jest z nim związany, to kwestia wymiany wiedzy. Nie posiadamy często, jako młodzi founderzy, wiedzy, spoza swej domeny, jesteśmy skupieni tylko na swojej domenie. Tutaj trzeci problem, który widzę, to z komunikacją. Nawet jeżeli my nie posiadamy wiedzy, a ktoś inny ją posiada, to mamy problem, żeby dojść do porozumienia, żeby zacząć mówić jednym językiem z ludźmi, którzy posiadają wiedzę w miejscach, w których my mamy braki.

    Asia: Ja dorzucę, że mam problem, żeby rozpocząć tę komunikację w ogóle. Ja się spotykam często z takim pytaniem o to, z kim warto byłoby porozmawiać, a nawet jak już wiemy, z kim warto by było rozmawiać, to mimo wszystko dalej mamy taki opór, żeby po prostu zapytać się tych osób.

    Przynajmniej z mojego doświadczenia, osoby, które mają duże startupy, duże biznesy, osiągnęły fajny sukces, też chętnie dzielą się swoją wiedzą. Tylko po prostu często ludzie nawet nie pytają.

    Szymon: Teraz rozwiązania, tak? Co poleciłbym takim founderom? Dużo czytać. Szczególnie rzeczy spoza swojej domeny, właśnie po to, żeby tę wiedzę zdobyć. Czyli jeżeli jesteśmy techniczni, wiemy, jak projektować systemy, ale sprawdźmy, jak je walidować, jak je testować. Sprawdźmy, jaki mamy rynek, w jaki biznes wchodzimy.

    Czyli nauczmy się troszkę tego, co jest poza naszą strefą komfortu. To pierwszy taki pomysł. Drugi. Rozmawiamy z ludźmi doświadczonymi i to nie tylko ze swojej wiedzy. Z ludźmi, którzy osiągnęli dużo w tych innych dziedzinach. Zobaczmy, jak oni działali, co robili. Może porozmawiajmy. Tutaj się przydają różnego rodzaju meetupy, różnego rodzaju konferencje.

    Trzecia taka rzecz. Spróbujmy wyjść z tej swojej strefy komfortu. Jeżeli jesteśmy programistą, spróbujmy coś zaprojektować. Zobaczmy, jak inne rzeczy są zaprojektowane. Nie tylko czytajmy, nie tylko rozmawiajmy z innymi ludźmi, ale spróbujmy zrobić coś, czego nie robimy na co dzień. Wtedy możemy zobaczyć jak całościowo tworzy się produkty, jak całościowo tworzy się startupy. Ta zdobyta przez to wiedza i zdobyte doświadczenie, na pewno przyda nam się przy tworzeniu takich produktów. 

    Asia: Dla mnie zwłaszcza ta ostatnia rada, o której powiedziałeś, jest mocno bliska. Ja też, jak pracuję z różnymi zespołami, to często sugeruję im, żeby jak najwięcej osób brało udział w tych warsztatach. Tam, gdzie planujemy sobie jakieś produkty, przygotowujemy sobie jakieś koncepty, zachęcam właśnie, żeby na przykład deweloperzy zaczęli coś rysować.

    Tutaj często pojawia się opór. A później się okazuje, że mają świetne pomysły. Albo po stronie designerów, żeby zaczęli myśleć o technologiach, a pojawia się opór, że się na tym nie znają, takie padają argumenty, czy po stronie Biznesu, bo nie musi się znać ani na tym, ani na tym, a ja właśnie zachęcam, że fajnie jest brać udział w takich warsztatach wspólnie. Bo wtedy wytwarzamy to, co powiedziałeś wcześniej, wtedy wytwarzamy prawdziwą wartość.

    Szymon: Ja też tak mam, że jak rozmawiam ze swoim programistami, to często ich zachęcam do brania udział w dyskusji z biznesem. Do zrozumienia tego, co robimy. Ale ta komunikacja musi być dwustronna. Biznes powinien zrozumieć technologię.

    Wszyscy nawzajem muszą się zrozumieć. Designer musi zrozumieć technologie i biznes. Mamy tercet, a tak naprawdę wchodzi jeszcze więcej innych domen. Przykładowo ja, rozmawiając ostatnio, rekrutując Project Managera, pytałem, czy potrafi programować. To nie było dla mnie kluczowe, ale był to dla mnie bardzo duży plus. Jak rozmawiam z designerami, to też wiem, który z nich choćby linijkę kodu napisał w życiu i naprawdę się to potem przydaje.

    Asia: Też się zgodzę. No dobra, to podsumowując. Na samym początku rozmawialiśmy o unicornie, jeżeli chodzi o startupy i o osobę. To teraz, jakbyśmy mieli zdefiniować, czyli idealny startup, z czego powinien się składać? Z jakich kompetencji? I tak samo pod kątem, osoby, która będzie tworzyła idealne produkty, jaka ona będzie?

    Szymon: Wiesz, tutaj tak naprawdę, jedno z drugim się pokrywa. Bo osoba tworząca produkty, powinna być cross domenowa. Pewnie będzie miała jedną domenę mocniejszą, ale inne powinny być w jakimś tam stopniu uzupełnione.

    Najlepiej, jeżeli też będzie miała wsparcie wśród founderów, albo wśród innych osób, pracujących dla niej, którzy wypełnią te luki. Będą potrafili się między sobą komunikować. I teraz właśnie taki startup, który ma zostać unikornem, moim zdaniem, musi pokrywać te wszystkie domeny.

    Musi być dobry w technologii, musi być dobry w designie, musi rozumieć swój biznes. A co najważniejsze, musi mieć odpowiednią komunikację pomiędzy designem, a technologią i biznesem, bo ta komunikacja będzie kluczem do sukcesu.

    Asia: Super. Cieszę się, że Cię tak mocno wypytałam. To teraz w drugą stronę. Czy ty masz jakieś pytania do mnie jeszcze?

    Szymon: Czy te problemy o których rozmawialiśmy, to są problemy z którymi przychodzą do was klienci, czy są jakieś inne, coś, czego nie udało nam się poruszyć?

    Asia: Podzieliłabym pewnie te problemy na kilka kategorii. Jeżeli rozmawiamy z takimi technicznymi klientami, to są software house’y, ale to też są founderzy, którzy mają po prostu jakiś technologiczny, techniczny background, po różnych technicznych uczelniach.

    Dalej, to są te osoby, którym najczęściej brakuje, wbrew pozorom, wiedzy biznesowej. Mają świadomość, że trzeba zrobić jakiś research. Nie znają się na researchu, na designie itd. Natomiast już często mają świadomość, bo w kolejności projektowania, w takim standardowym procesie, no to jest ten kolejny etap w waterfallu. Więc wiedzą, że to się musi zadziać. To jest super.

    Natomiast, tutaj brakuje wiedzy biznesowej. Z drugiej strony spotykamy się z takimi founderami, którzy też mają świetne pomysły, mają jakąś tam wiedzę biznesową i często jakąś taką marketingową, takie czucie marketingowe, natomiast brakuje tej wiedzy technologicznej.

    I to jest tak, że przychodzą, bo traktują nas jako firmę usługową. Potrzebują dostać gotowy produkt. Brakuje też często takiej wiedzy, że traktują te firmy zewnętrzne, jako osoby, które zrobią im ten produkt, ale zapominają o discovery. Czyli oni przychodzą z gotowym pomysłem. Są zakochani w tym swoim pomyśle.

    Kolejna grupa, najmniejsza. O tym rozmawialiśmy wcześniej. To są designerzy, albo osoby wywodzące się z produktów, które mają jakiś tam koncept. I tutaj w sumie z mojego doświadczenia, to jest tak, że tym osobom często brakuje wiedzy na temat takiego Business Development. One wiedzą, jak zrobić fajny produkt.

    Mam takie osoby, z którymi nawet ja współpracuję, czyli wiedzą jak zrobić fajne Discovery, znają się trochę na technologii i wiedzą, jak zaprojektować fajny pomysł itd. Wiedzą, jak zrobić ten produkt dobry, ale jak zrobić, żeby ten produkt lubili użytkownicy.

    Nie mają pojęcia, jak go zmonetyzować. Nie mają pojęcia, jak zrobić model biznesowy. Jakie są w ogóle opcje, jakie są źródła przychodu, które ja tutaj mogę wygenerować. Więc tutaj brakuje nam takiej wiedzy na temat budowania samego biznesu i rozwijania tego biznesu.

    Asia: Ja bym powiedziała, że w zależności od tego, kto do nas przychodzi i jaki ma swój background, jakie ma doświadczenie, to z takim problemem przychodzi.

    Szymon: Dwa szybkie pytania. Bo tak jak powiedziałaś, że programiści często wiedzą, że wcześniej powinien być design i to jest rzecz, którą ja zacząłem obserwować. Że pomimo, iż mówimy, że jesteśmy Agile, Lean, czy czasami korzystamy ze Scruma, to tak naprawdę duża część tych firm, która kreuje się na firmy Agile, to tak naprawdę są firmami waterfallowymi.

    Czyli pierwsze robimy design, a potem robimy development. Czy zgodzisz się z tym? Bo dla mnie to jest taki procesowy problem w próbie wytwarzania produktu zwinnego, ale procesem waterfallowym. 

    Asia: Tak, ja się z tym mocno zgodzę. Jesteśmy firmą, która mocno komunikuje to, że działamy w Leanie. Przychodzą do nas klienci, którzy mówią, że chcą też działać w Leanie i tak dalej, bo podejście się im podoba. I próbujemy ukryć waterfallowy proces pod tą nazwą. Takie są oczekiwania z drugiej strony. Że podzielimy sobie to, że ten development odłożymy na później, a tak naprawdę ten Lean nam się kojarzy, żeby to było trochę taniej. Więc też to mocno dostrzegam.

    Szymon: No i ostatnie pytanie, które fajnie wyszło, jak rozmawialiśmy wcześniej. Czym jest dla Ciebie startup?

    Asia: Faktycznie, chyba powinniśmy od tego zacząć. Ja się zawsze śmieję jak zaczynam, że zaczynam od podsumowania. Dla mnie startup to jest stan umysłu. Definicja Erica Riesa jest dla Ciebie bliska, dla mnie również. Dla mnie to jest organizacja, która jest powołana w celu poszukiwania pewnej odpowiedzi i działa, co ważne, w skrajnej niepewności.

    Ty podałeś fajny przykład z piekarnią czy z salonem fryzjerski,. W momencie, kiedy my otwieramy kolejny salon fryzjerski, czy kolejną piekarnię, to niekoniecznie to jest startup. Chyba, że otwieramy go w jakimś nietypowym miejscu. Na przykład Arktyka.

    Nie wiemy, jak to robić i otwieramy tam salon fryzjerski itd. Wtedy zmieniają się pewne parametry. Natomiast generalnie to nie jest startup, bo ten biznes jest powtarzalny. Natomiast startup to jest organizacja, która jest powołana w celu poszukiwania też pewnego modelu. 

    Szymon: Organizacja… a ja lubię używać słowa “Inicjatywa Ludzka”. Możemy mieć startup w ramach, nawet, urzędu skarbowego. Można w Urzędzie Skarbowym zrobić startup. W definicji jest to niedopuszczalne.

    Asia: Zgadzam się z tym. W sumie nawet bym to rozszerzyła. Bo dla wielu osób startup jest od razu związany z poszukiwaniem skalowalnego modelu biznesowego. Czyli stricte związne z zarabianiem.

    Często lubię mówić, że jednak to pewien stan umysłu, bo można też robić w podejściu startupowym organizacje non-profit, która nie jest nastawiona stricte na zysk, na zarabianie, ale na realizację jakiejś misji, wizji.

    Wiadomo, musi się z czegoś utrzymywać, ale ma inne źródło przychodu, niż zarabianie na potencjalnie swoich odbiorcach, czy swoich klientach. Więc ja lubię mówić o tym, że to jest pewien stan umysłu.

    Szymon: Z klientami to różnie bywa. Słynny żart związany ze startupami, gdzie kiedyś ktoś na grupie Facebookowej zapytał, że zbadał już wszystkie możliwe źródła przychodów, fundusze unijne, dotacje państwowe, akceleratory. Jakie są jeszcze źródła, które mógłby uwzględnić w ramach swojego startupu? No i pierwsza odpowiedź: klienci.

    Asia: Niestety, najmniej oczywista, ale temat jakby finansowania, którego tutaj nie poruszyliśmy, to jest temat na inny odcinek. Tak, no to ja Ci bardzo dziękuję, Szymon, za rozmowę. Mam nadzieję, że nasi słuchacze wyciągną trochę z tego, jakie możemy znaleźć różne sposoby rozwiązania, jakie są bolączki naszego podwórka startupowego, podwórka produktowego, tutaj w Polsce. A na zakończenie, mamy dla Was jeszcze małe zaproszenie od Szymona.

    Szymon: Zapraszam was na mojego Instagrama, Szymon Paluch, na co dzień dzielę się tym, jak budujemy produkt uPacjenta, jak działam w środowisku startupów. Dzielę się swoimi przemyśleniami na temat tego, jak wprowadzić produkty cyfrowe. I tutaj chciałbym was zaprosić do konkursu, który będzie ogłoszony na Instagramie. Myślę, że będzie trwał przez około tydzień i będzie bardzo fajna nagroda. Ale to już musicie wejść do mnie i zobaczyć o co chodzi i co fajnego może was czekać.

    Asia: A ja bardzo polecam. Mogę też polecić śledzenie Szymona na Linkedinie, bo wrzuca bardzo bardzo wartościowe posty z różnymi przemyśleniami. Podkreślam, że Szymon jest CTO, ma doświadczenie technologiczne, pracował w firmie usługowej, produktowej. Wrzuca świetne posty z takimi przemyśleniami na poziomie biznesowym, menedżerskim, więc warto jest czytać.

    Szymon: Dużo osób zarzuca mi ostatnio, że za mało technologii umieszczam w swoich wpisach.

    Asia: Jestem wielką fanką Twoich wpisów, więc zdecydowanie polecam. A jeśli kogoś interesują tematy związane z rozwojem produktu, jak testować swoje pomysły, swoje hipotezy, to my też staramy się tworzyć dużo materiałów na ten temat i edukować.

    Więc możecie zobaczyć sporo wpisów na naszym blogu, na naszej stronie internetowej www.projectpeople.pl, zerknąć na naszego LinkedIn, również osobistego, bo każdy z nas dzieli się wiedzą na styku marketingu, biznesu, designu, researchu, bo to jest nasz kierunek rozwoju.

    A jeżeli ktoś szuka konkretnych narzędzi, to wejdźcie na naszego Slideshare’a, gdzie wrzucamy prezentacje z różnych warsztatów, a tam krok po kroku jest rozpisane, jak korzystać z różnych narzędzi, które mogą się przydać w rozwoju biznesowym. Dzięki za dzisiejszą rozmowę.

     

    Szymon: Również dziękuję.

     

     

    Artykuły to za mało?

    Chcesz poznać cały proces i dowiedzieć się, jak mógłby wyglądać w Twojej organizacji?

    Umów się na bezpłatną konsultację
    Joanna Ostafin
    Współzałożycielka Project: People, współtwórczyni Krakowskiej Inicjatywy Designerskiej (KID), organizatorka DesignWays Conf.

    Jako Lean UX Strategist na co dzień zajmuje się... niezgadzaniem się ze swoimi klientami - wspiera ich w zakresie weryfikowania pomysłów na nowe produkty, usługi czy biznesy. Pomaga przejść od “innowacyjnego pomysłu” do “realnego produktu”, walidując założenia w oparciu o swoje kompetencje biznesowe, strategiczne, UX, UI, Service Design oraz Lean.

    Szczerze zakochana w podejściu Lean (Lean Startup & Lean UX & Lean UX Research). Wierzy w warsztaty i kolektywne budowanie projektów, rozwiązywanie problemów czy generowanie pomysłów.

    Uwielbiamy ciasteczka!

    Nie wierzysz? Odwiedź nas w naszym biurze i sprawdź! Ciasteczka serwujemy z pyszną kawą. Dowiedz się więcej

    Zgoda