Cześć MailingR, tu Jarek 👋
Kilka wydań temu rozmawialiśmy sobie o mikrocontencie.
Przypomnę tylko - mikrokontent to krótkie formy treści cyfrowej, które można szybko konsumować podczas przeglądania mediów społecznościowych.
Tweety, rolki z napisami itd.
Wykorzystałem porady jednego z topowych twórców LinkedIn Justina Welsha, żeby usystematyzować swoje tworzenie mikrocontentu.
W skrócie - od blogposta/newslettera do kilku-kilkunastu tweetów.
O, ale fajną rzecz zrobiłem! Może innym też się to przyda?
Ustawiłem fajny system z AI dla siebie. Jako automatyzację w Make. Wrzucam COŚ do tej automatyzacji i w moim Notion pojawiają się nowe drafty wpisów.
I to już jest coś użytecznego. Rozwiązuje pewien problem klienta (ja tu jestem klientem).
Teraz „to coś” można przedstawić jako: - Usługę - Produkt
Wrzuciłem na Instagram i na jedną grupkę dla przediębiorców opis tej automatyzacji (link). Pojawiły się osoby zainteresowane tym rozwiązaniem. Zrobiłem 3 wdrożenia tego systemu u klientów.
Odkryłem kilka rzeczy. 1. Każdemu trzeba ustawić to nieco inaczej (jeden klient miał Make, inny Zapiera, inny nic nie miał) 2. Każda osoba w inny spsób planowała content (odpowiednio Buffer, Meta Business Suitę i ponownie Buffer) 3. Spędziłem dużo więcej czasu na badaniu przed wdrożeniem niż na samym wdrożeniu 4. Wyceniłem tę usługę za nisko biorąc pod uwagę ile mojej energii to pochłonęło.
No i jest to coś, co mnie kręci (tworzenie treści) i jest w tym fajny pieniądz (każda firma potrzebuje tworzyć content)
Taką usługę można skalować na kilka sposobów: - zdobycie większej ilość klientów - sprawienie, że klient zostawi więcej pieniędzy (droższa usługa i usługi komplementarne)
W momencie gdy mamy dużo klientów za fajne stawki ORAZ mamy sposób na pozyskiwanie nowych klientów, to kolejnym etapem jest zatrudnienie nowych osób, które będą taką usługę świadczyć.
To co, zabiegać o klientów i szukać kogoś ogarniętego do zespołu?
Mam przed tym obawy. Nie jestem w tym momencie do końca świadomy jakie. Po prostu mi to nie leży w tym momencie.
Trust your gut.
No ale wait, przecież potrafię programować :D
Decyzja. Zrobię to w trudny sposób.
Zrobię aplikację. Software as a service.
Ta sama usługa może być teraz świadczona automatycznie, bez mojego ciągłego zaangażowania.
Marzenie. Coś, co można skalować w nieskończoność.
Pierwszy prototyp
Nie ma co komplikować sobie życia. Wykorzystajmy no-code.
Mam już automatyzację w Make.
Teraz potrzebny jest interfejs użytkownika.
Co ma KAŻDY?
Przeglądarkę i skrzynkę pocztową.
Prototyp aplikacji działał w następujący sposób: - do formularza Tally wrzucasz swój content i zaznaczasz kilka opcjonalnych pól - Automatyzacja mieli swoje rzeczy i wysyła użytkownikowi maila z gotowym contentem - Jedyną warstwą zabezpieczenia jest sprawdzenie, czy mail który ktoś podał znajduje się w tabeli „Approved users”
Wspaniałe. 10 testerów w ten sposób sprawdziło pierwszą wersję i dało mi feedback.
No i ten feedback był pozytywny. Nie miałem pewności czy był pozytywny dlatego, że ktoś mnie
lubi, czy dlatego, że rozwiązanie faktycznie jest fajne (o syndromie oszusta porozmawiamy innym razem).
Niemniej, uznałem że warto pocisnąć to dalej.
Zacząłem przygotowywać „prawdziwą” aplikację.
Wybór padł na NextJS (bo kiedyś coś liznąłem Reacta) i Firebase (bo jako Androidowiec i Google Developer Expert już sporo w ekosystemie Google działam)
Stworzyłem mnóstwo długu technologicznego. Świadomie.
Przykład: generowanie contentu powinno odbywać się w asynchronicznej kolejce, bo mamy rate limitng na API OpenAI, żeby w tej kolejce potencjalnie przechwytywać abuse i prompt injection...
Ale wiesz co? Te rzeczy są mało istotne w tym momencie.
To co jest istotne, to stworzenie kozackiego User Experience.
Tworzymy produkt, a nie apkę w NextJS
Steve Jobs podobno kiedyś powiedział:
„Start with user experience and work backwards to the technology”
Pamiętam z jakiegoś hackatonu prezentacje jednego zespołu. Zaczęła się od „nasz startup to aplikacja w PHP” - zapamiętałem to sformułowanie. Jako przestrogę, żeby tak nie myśleć.
Zmiana mindsetu - od inżyniera do... produktowca.
Przy budowie kursów i infoproduktow mogłem myśleć jak inżynier. Bo te produkty były skierowane do inżynierów, czy tez szeroko pojętej branży IT.
Teraz muszę nauczyć się mówić do nieco innych odbiorców - twórców treści, niekoniecznie związanych z IT.
Pytania: - jaki konkretny
problem aplikacja rozwiązuje? - kim jest idealny klient? - w jakim modelu aplikacja ma zarabiać?
Odpowiedzi już mi się kształtują. Te odpowiedzi nie muszą być ostateczne.
Czeka mnie sporo rozmów z ludźmi spoza mojej bańki.
To trochę straszne i trochę ekscytujące.
Stay tuned.
|