Biznes i kod w jednym mieszkali domu

Jakiś czas temu pisałem o relacji tzw. „biz guy” versus „tech guy” w tekście Mam pomysł, potrzebuję tylko programisty. Ostatnio trafiłem na dość dobry tekst, który pokrótce podsumowuje to, co starałem się przekazać. Jako że nie ma sensu wszystkiego przepisywać, to podam tylko to, co uważam za esencję. Jest to też niejako skondensowana myśl przewodnia mojego wyżej wspomnianego tekstu. No i na dodatek świetne zobrazowanie graficzne tejże teorii. Jestem zagorzałym zwolennikiem przejrzystego przedstawiania treści w formie graficznej.

„(…) the product entrepreneurs have an increasingly marginal role as a startup evolves and becomes more successful. In fact, I’d argue that they are in a rude awakening – they either need to evolve into business entrepreneurs (as Gates and Jobs did, for example – both shrewd business guys) or hire people to play that role (a la Eric Schmidt at Google). Building an asset is the first (and most important) challenge. But finding the customer for that asset and maximizing the revenue/profit is also a challenge (and one that many builders are ill-suited to handle).” 

Dobre podsumowanie tego, co również uważam za prawdziwe. W artykule jest trochę więcej na ten temat i rozwinięcie powyższego akapitu. Polecam zapoznanie się z całością.

Na początku trzeba zbudować produkt i tylko to się liczy. „Tech guy” i jego wartość są zbliżone do maksimum. Kiedy jednak produkt jest już gotowy i działa, to na początku oczywiście trzeba robić jakieś poprawki i wprowadzać funkcje, które są naprawdę potrzebne i przydatne dla użytkowników. Poprawki jednak z biegiem czasu powinny (przynajmniej w teorii) się zmniejszać, a funkcji też nie ma sensu dodawać w nieskończoność. Przykład: czy ktoś, tak jak ja, tęskni za WinAmpem sprzed ładnych kilku lat, kiedy to był on małym i prostym programikiem idealnie spełniającym jedną funkcję: odtwarzanie muzyki? Teraz to ledwo dający się używać kombajn do wszystkiego i jeszcze trochę. Sens? Brak…

Na początku, kiedy produkt nie jest dostępny publicznie i dopiero jest budowany, wartość „biznesowego partnera” ogranicza się do generowania pomysłów na funkcje, a nie do generowania kodu, czyli samego mięsa produktu. Oczywiście w bardzo dużym uproszczeniu. Z biegiem czasu jednak, kiedy programista już tylko wprowadza poprawki i dodaje nowe funkcje, to wtedy zaczyna się prawdziwa praca partnera od biznesu. I to w przeważającej części od niego będzie zależało czy produkt (który równie dobrze może być rewolucyjny) odniesie jakikolwiek sukces. Czy dotrze tam, gdzie jest potrzebny. Czy przekona tych, których trzeba przekonać, żeby dali szansę temu produktowi.

Idealnie oczywiście kiedy jedna osoba (lub kilka) skupia w sobie cechy jak z jednego partnera, tak i z drugiego. Jednak daleko nie zawsze tak się dzieje.

Tak na marginesie, to jest artykuł napisany przez autora RescueTime, czyli najważniejszego konkurenta dla polskiego TimeCamp. I moim zdaniem chłopaki z RescueTime niestety wygrywają bezapelacyjnie. 
Kilka miesięcy temu (zdaje się na jakimś *campie) we Wrocławiu dyskutowałem o tym publicznie z autorem serwisu, ale od tamtego czasu nie widzę żadnych zmian. Chyba że pracuje nad backendem (oby tak było) i dlatego efektów nie widać gołym okiem. Z niedawnej dyskusji z autorem serwisu wynika, że skupiają się bardziej na niszy monitorowania pracowników, niż na modnym ostatnio i dość nasyconym już rynku personal productivity (nie znajduję naturalnie brzmiącego polskiego odpowiednika). Ukierunkowanie się na monitoring i odejście od programu stricte dla użytkownika publicznego jest moim zdaniem dobrym posunięciem. Chłopaki jednak nie mają polskiej wersji – od początku stawiają tylko na angielską. Polskiej nie ma nawet w najbliższych planach. Co najwyżej dalszych. Czy to słuszne posunięcie? Niekoniecznie.

Nie mając sensownego zaplecza sprzedażowego, dość trudno jest od razu uderzać z ofertą międzynarodową. Na dodatek skierowaną do firm, do których się jednak dociera inaczej, niż do użytkowników prywatnych.

Na miejscu ekipy z TimeCamp spróbowałbym więc najpierw spenetrować rynek polski, tu się trochę doszlifować i ewentualnie później wypływać na szersze wody. Po pierwsze – łatwiej dotrzeć do grupy docelowej, po drugie – mniejsze będą koszty alternatywne ewentualnych pomyłek. No i zdobyte doświadczenie na pewno nie zaszkodzi.

Podsumowując: zarówno TimeCamp’owi, jak i innym polskim firmom – jak najlepszej mieszanki kodu i biznesu życzę.

Liczba komentarzy: 3 ↓

#1 TimeCamp 12.03.08 o 11:53

Dzięki za te propozycje, co z nimi zrobimy, to się okaże po znalezieniu finansowania, bo to w dużej mierze będzie miało na to wpływ.

Z doszliwowaniem w Polsce może w ogóle nie wyjść. Polscy internauci są jednak dużo mniej wymagający i pewnie przyjmą TimeCamp takim jakim jest, w przeciwieństwie do USA…

#2 Kamil 12.17.11 o 16:38

Piszę jako współwłaściciel TimeCampa. Przewidziałeś dobrze że na początku musieliśmy zrobić polski rynek, w sumie nawet teraz chyba jeszcze nie jesteśmy gotowi na zagranicę :)

#3 Sabon 12.17.11 o 16:47

Kamil, mam nadzieję, że dobrze wam idzie. Chciałem sprawdzić jak wygląda serwis, ale teraz jest jakaś przerwa techniczna.
Powodzenia, chłopaki.

Zostaw swój komentarz