Content marketing dla software house'u: jak tworzyć treści, które odróżniają firmę od konkurencji

Samo pisanie o technologii przestało być wyróżnikiem

Artykuły techniczne nadal mają sens. Mogą generować ruch z wyszukiwarki, wspierać rekrutację, pomagać developerom rozwiązywać konkretne problemy i budować rozpoznawalność ekspertów. Trudno jednak oczekiwać, że sam fakt publikowania treści o technologii będzie dzisiaj dużą przewagą konkurencyjną.

Dostęp do wiedzy technicznej jest ogromny. Dokumentacja, GitHub, Stack Overflow, blogi producentów technologii, materiały video i narzędzia AI sprawiają, że podstawowe informacje można znaleźć w kilka minut. Sam tekst tłumaczący różnice pomiędzy dwoma popularnymi frameworkami nie mówi więc jeszcze zbyt wiele o jakości firmy, która go opublikowała.

Klient kupujący usługę developmentu nie kupuje zresztą znajomości konkretnej technologii. Kupuje zdolność zespołu do podejmowania dobrych decyzji w określonych warunkach biznesowych. Dwa software house'y mogą pracować na podobnym stacku, zatrudniać developerów o zbliżonym doświadczeniu i mieć porównywalne portfolio. Różnica zaczyna być widoczna dopiero wtedy, kiedy zobaczymy, jak podchodzą do ryzyka, jak prowadzą discovery, w jaki sposób oceniają istniejący system klienta i kiedy potrafią powiedzieć, że rozwiązanie, o które klient prosi, wcale nie jest najlepszym kierunkiem.

To właśnie takie rzeczy warto pokazywać w treściach. Zamiast kolejnego materiału „Node.js czy Python?” znacznie ciekawszy może być artykuł pokazujący, dlaczego w konkretnym typie projektu zespół zdecydował się na jedno z tych rozwiązań, jakie ograniczenia brał pod uwagę i jak ta decyzja wpłynęła na utrzymanie systemu dwa lata później. Technologia nadal jest ważna, ale pojawia się w realnym kontekście.

Dobra komunikacja zaczyna się od decyzji, dla kogo właściwie powstaje

Jednym ze źródeł generycznego contentu jest bardzo szerokie pozycjonowanie samej firmy. Jeżeli software house określa się jako dostawca „dedykowanych rozwiązań cyfrowych dla biznesu”, można pod tę definicję podpiąć niemal wszystko: aplikacje mobilne, AI, chmurę, UX, e-commerce, automatyzację, integracje, cybersecurity czy systemy wewnętrzne.

W efekcie również komunikacja staje się szeroka. Firma pisze trochę o wszystkim, ale trudno po kilku materiałach powiedzieć, z czym powinna być kojarzona. Nie oznacza to, że software house musi nagle ograniczyć działalność do jednej branży. Warto jednak określić, jakie typy projektów są dla firmy najbardziej interesujące, gdzie ma największe doświadczenie i z jakimi problemami klientów spotyka się najczęściej.

Firma pracująca głównie z fintechami może rozwijać treści o bezpieczeństwie, regulacjach, integracjach z systemami finansowymi, wysokiej dostępności czy skalowaniu systemów transakcyjnych. Software house mający doświadczenie w przemyśle może mówić o połączeniach z ERP i MES, danych z maszyn, wdrażaniu systemów w działającej fabryce czy ograniczeniach wynikających z wieloletniej infrastruktury. Zespół specjalizujący się w e-commerce może budować swoją komunikację wokół migracji platform, wydajności, integracji z logistyką, checkoutu i obsługi dużych pików ruchu.

Każdy z tych tematów pozostaje techniczny, ale jednocześnie jasno pokazuje, dla jakiego rodzaju problemów dana firma jest dobrym partnerem.

Problemy klientów są lepszym punktem wyjścia niż lista technologii

Software house patrzy na projekty przez pryzmat technologii, bo właśnie tym zajmuje się na co dzień. Klient zwykle dochodzi do technologii dopiero później. Nie budzi się rano z myślą, że potrzebuje Kubernetesa. Zaczyna raczej od tego, że obecny system nie radzi sobie z ruchem, wdrażanie zmian trwa za długo, dane są rozproszone pomiędzy kilkoma narzędziami albo utrzymanie starej aplikacji zaczyna kosztować coraz więcej.

Dopiero wtedy pojawia się pytanie, co z tym zrobić. Warto zachować tę samą kolejność również w content marketingu. Zamiast zaczynać od mikroserwisów, można opowiedzieć o momencie, w którym monolit rzeczywiście zaczyna ograniczać rozwój produktu. Zamiast kolejnego artykułu o migracji do chmury można przeanalizować sytuacje, w których taka migracja wcale nie przynosi spodziewanych oszczędności. Zamiast ogólnego materiału o AI lepiej pokazać kilka przypadków, w których wykorzystanie modeli językowych rzeczywiście ma sens biznesowy, i kilka takich, w których komplikuje prosty proces bez wyraźnej korzyści.

Tego typu treści są wartościowe także dla technicznych odbiorców, bo pokazują coś więcej niż znajomość narzędzi. Pokazują sposób rozumowania zespołu.

Inaczej trzeba rozmawiać z CTO, inaczej z osobą odpowiedzialną za biznes

Sprzedaż usług technologicznych rzadko dotyczy tylko jednej osoby. Pierwszy kontakt może rozpocząć CTO, ale później w proces wchodzi product manager, CEO, dyrektor operacyjny, procurement albo finanse. Każda z tych osób ocenia projekt z trochę innej perspektywy.

CTO chce wiedzieć, czy zespół podejmie dobre decyzje techniczne, jak wygląda jakość pracy i czy dostawca będzie partnerem dla jego ludzi. Product manager patrzy na tempo developmentu, możliwość reagowania na zmiany i przewidywalność projektu. Zarząd częściej skupia się na ryzyku, kosztach, czasie wdrożenia oraz tym, co stanie się, jeśli zakres projektu zmieni się w trakcie pracy.

Dlatego treści software house'u nie powinny być kierowane wyłącznie do developerów.

Case study powinno pokazywać sposób pracy, nie tylko rezultat

Wiele case studies software house'ów kończy się na krótkiej historii: klient miał problem, zespół zbudował rozwiązanie w określonym stacku, projekt zakończył się sukcesem. Formalnie wszystko się zgadza, ale niewiele wynika z tego dla kolejnego potencjalnego klienta.

Znacznie ciekawsze jest to, co wydarzyło się pomiędzy początkiem projektu a efektem końcowym. Jak wyglądało stare rozwiązanie? Dlaczego klient zdecydował się na zmianę właśnie wtedy? Jakie ograniczenia trzeba było uwzględnić? Czy pierwsza koncepcja została zrealizowana bez zmian, czy w trakcie projektu pojawiły się informacje, które wymusiły korektę kierunku? Co było największym ryzykiem i jak zespół sobie z nim poradził?

Właśnie takie szczegóły pokazują doświadczenie. Dobre case study nie musi przedstawiać projektu jako idealnej historii, w której wszystko od początku przebiegało zgodnie z planem. Wręcz przeciwnie. Dla doświadczonego klienta znacznie bardziej wiarygodna jest opowieść o decyzjach, trudnościach i zmianach, które trzeba było wprowadzić po drodze.

Analiza architektury może powiedzieć o zespole więcej niż rozbudowane portfolio

Software house może również regularnie pokazywać fragmenty konkretnych rozwiązań i tłumaczyć decyzje, które za nimi stoją. Nie chodzi o ujawnianie poufnych danych klienta ani publikowanie pełnej dokumentacji systemu. Często wystarczy jeden wybrany problem.

Dlaczego zastosowano określoną architekturę? Jak wyglądał przepływ danych? Dlaczego zespół zrezygnował z rozwiązania, które na początku wydawało się najbardziej oczywiste? Jakie ograniczenia pojawiły się przy integracji ze starszym systemem? W którym miejscu skalowanie mogło stać się problemem?

Taki materiał może mieć formę artykułu, rozmowy z CTO, nagrania przy tablicy albo dłuższego filmu na YouTube. Nie musi zdobywać dużych zasięgów. Jeżeli obejrzy go kilkuset CTO, founderów i product managerów z firm, które rzeczywiście pasują do profilu klienta, może mieć znacznie większą wartość niż popularny materiał o ogólnych trendach technologicznych.

Doświadczenia z nieidealnych projektów są bardzo dobrym materiałem

W firmach technologicznych znajduje się ogromna liczba historii, które nigdy nie wychodzą poza zespół. Migracja danych, którą źle oszacowano. Integracja z API, która na papierze wyglądała prosto, a w praktyce generowała kolejne problemy. Funkcja rozwijana przez kilka tygodni, której użytkownicy później prawie nie używali. Decyzja architektoniczna, która była sensowna przy pierwszej wersji produktu, ale po dwóch latach zaczęła ograniczać jego rozwój.

Takie doświadczenia są często ciekawsze niż kolejna lista „dobrych praktyk”. Oczywiście trzeba uważać na poufność i relacje z klientami. Część historii będzie wymagała anonimizacji, a część po prostu nie powinna być publikowana. Nadal zostaje jednak sporo wiedzy, którą można wykorzystać bez zdradzania szczegółów konkretnego projektu.

Materiał w rodzaju „co zrobilibyśmy inaczej, gdybyśmy drugi raz budowali ten system” pokazuje coś bardzo ważnego: firma nie tylko wykonuje projekty, ale również wyciąga z nich wnioski. Przy usługach opartych na wiedzy jest to jeden z najmocniejszych sposobów budowania wiarygodności.

Specjalizacja może dotyczyć problemu, niekoniecznie branży

Wiele software house'ów unika wyraźnego pozycjonowania, bo nie chce zamknąć sobie drogi do projektów spoza jednej branży. To zrozumiałe, ale specjalizacja w komunikacji nie musi oznaczać deklaracji „pracujemy wyłącznie z fintechami”. Można budować pozycję wokół konkretnego rodzaju problemu.

Jedna firma może być szczególnie dobra w modernizacji systemów legacy. Inna w budowaniu marketplace'ów. Kolejna w integracji złożonych systemów albo produktach wymagających wysokiego poziomu bezpieczeństwa. Jeszcze inna może specjalizować się w przeprowadzaniu produktów od MVP do etapu, na którym trzeba uporządkować architekturę i przygotować system do skali.

Taki kierunek daje większą elastyczność, a jednocześnie pozwala konsekwentnie budować skojarzenie z określonym rodzajem kompetencji. Software house może dzięki temu realizować projekty w kilku branżach, ale nadal komunikować się w sposób znacznie bardziej spójny niż firma, która co tydzień publikuje o czymś zupełnie innym.

Ekspert nie musi sam zostać twórcą contentu

W wielu firmach najlepsza wiedza znajduje się u osób, które mają najmniej czasu na publikowanie. CTO nie chce pisać artykułów wieczorami. Architekt systemowy niekoniecznie ma ochotę planować posty na LinkedIn. Senior developerowi trudno oczekiwać, że oprócz pracy projektowej będzie regularnie przygotowywał scenariusze i nagrywał materiały.

Nie ma zresztą takiej potrzeby. Znacznie lepiej działa model, w którym ekspert jest źródłem wiedzy, a nie osobą odpowiedzialną za cały proces produkcji. Raz w miesiącu można przeprowadzić z nim dobrze przygotowaną rozmowę. Ktoś wcześniej robi research, zbiera pytania i prowadzi spotkanie tak, żeby wyciągnąć konkretne przykłady, doświadczenia oraz opinie.

Z jednej rozmowy mogą później powstać artykuł, dłuższy film, kilka krótszych fragmentów i materiały do social mediów. Ekspert nie musi uczyć się copywritingu ani montażu. Jego zadaniem jest dostarczenie tego, czego marketing sam nie stworzy: wiedzy wynikającej z realnej pracy przy projektach.

Podobny model dobrze sprawdza się przy budowaniu widoczności firmy wokół wiedzy założyciela, z tą różnicą, że w software housie warto korzystać z kilku ekspertów reprezentujących różne obszary.

Obecność CTO lub foundera przed kamerą nie musi oznaczać „robienia marki osobistej”

Nie każda osoba techniczna chce zostać twórcą internetowym i nie ma powodu, żeby ją do tego zmuszać. Warto też oddzielić ekspercką komunikację od popularnego modelu personal brandingu opartego na codziennych postach, prywatnych historiach i ciągłej obecności w social mediach.

CTO może raz na kilka tygodni nagrać konkretną analizę problemu technicznego. Founder opowiedzieć o decyzjach charakterystycznych dla branży klientów. Product expert pokazać, jak firma prowadzi discovery albo przygotowuje produkt do skalowania. Nie trzeba przy tym budować całej komunikacji wokół życia prywatnego konkretnej osoby.

W takiej formie twarz eksperta jest po prostu nośnikiem wiedzy firmy. Video pozwala dodatkowo zobaczyć, jak dana osoba tłumaczy problem, jak myśli i jak podchodzi do trudniejszych pytań. Przy usługach, w których klient będzie później przez wiele miesięcy pracował z ludźmi dostawcy, to ma znaczenie.

Jeden dobry temat można sensownie wykorzystać w kilku kanałach

Częstym problemem jest prowadzenie każdego kanału jak osobnego projektu. LinkedIn ma własną listę tematów, SEO własną, a YouTube jeszcze inną. Przy każdym materiale trzeba ponownie znaleźć eksperta, zebrać wiedzę i od początku przygotować treść.

Przy ograniczonej dostępności zespołu taki model szybko przestaje być wydajny. Lepszym punktem wyjścia jest jeden wartościowy temat. Załóżmy, że CTO opowiada o przejęciu starego systemu po innym dostawcy. Na podstawie rozmowy może powstać dłuższy film na YouTube, szczegółowy artykuł pod wyszukiwarkę, kilka krótszych fragmentów na LinkedIn i seria wypowiedzi eksperckich.

Nie chodzi o mechaniczne wrzucanie tego samego materiału wszędzie. Każdy kanał wymaga własnej formy, ale research i wiedza źródłowa powstają tylko raz. Podobny model opisywałem przy video marketingu dla SaaS. W software housie ma on szczególne znaczenie, ponieważ największym ograniczeniem często nie jest produkcja treści, ale dostęp do ekspertów.

Jeżeli na godzinę rozmowy z CTO trzeba czekać dwa tygodnie, warto tę godzinę dobrze wykorzystać.

Najlepsze tematy zwykle pojawiają się podczas sprzedaży i pracy projektowej

Software house nie musi organizować kolejnej burzy mózgów, żeby znaleźć pomysły na content. Wystarczy zebrać pytania, które klienci zadawali podczas ostatnich kilku miesięcy.

Każde z tych pytań może stać się dobrym artykułem albo filmem. Najważniejsze jest to, że nie powstały w głowie marketera zastanawiającego się, co opublikować w przyszłym tygodniu. Zostały zadane przez ludzi, którzy naprawdę rozważali zakup.

To bardzo dobra wskazówka dotycząca tego, jaki content może być dla rynku rzeczywiście użyteczny. Więcej podobnych kierunków można znaleźć również w zestawieniu przykładów contentu B2B wspierającego sprzedaż.

Prosty sposób na zaplanowanie kilku miesięcy komunikacji

Tematy można uporządkować, łącząc trzy elementy: osobę, problem i format.

Po dodaniu tematów wynikających ze specjalizacji firmy oraz doświadczeń zespołu okazuje się, że nie ma większego problemu z przygotowaniem planu na cały kwartał. Problemem zwykle nie jest brak tematów. Bardziej chodzi o to, że wiedza znajduje się w wielu miejscach i nikt jej wcześniej nie zebrał.

Content powinien przygotowywać klienta do rozmowy sprzedażowej

Dobry materiał nie musi kończyć się formularzem kontaktowym, żeby mieć wpływ na sprzedaż. Potencjalny klient może najpierw trafić na artykuł dotyczący problemu, kilka dni później obejrzeć materiał CTO, następnie przeczytać case study podobnej firmy i dopiero później wejść w kontakt ze sprzedażą.

Kiedy dochodzi do pierwszej rozmowy, część pracy została już wykonana. Klient zna podejście firmy, rozumie jej specjalizację i ma przynajmniej częściowe wyobrażenie o sposobie pracy zespołu.

Przy droższych usługach B2B jest to znacznie bardziej realistyczny scenariusz niż oczekiwanie, że pojedynczy artykuł wygeneruje lead bezpośrednio po publikacji. Dlatego warto patrzeć na treści szerzej niż tylko przez liczbę formularzy i łączyć je z całym procesem video lead generation w B2B.

Content może skrócić etap edukacji, poprawić jakość zapytań i sprawić, że część potencjalnych klientów sama odrzuci firmę, jeśli zobaczy, że jej sposób pracy im nie odpowiada. To również jest wartościowe.

Najtrudniej skopiować sposób myślenia zespołu

Stack technologiczny można powtórzyć. Układ strony internetowej również. Nawet case studies konkurencji z czasem zaczynają wyglądać podobnie. Znacznie trudniej skopiować doświadczenie konkretnych ludzi: sytuacje, które widzieli wcześniej, błędy, które popełnili, wnioski z trudnych wdrożeń i podejście do problemów regularnie pojawiających się u klientów.

Dlatego content marketing software house'u ma największy sens wtedy, kiedy marketing nie próbuje produkować eksperckości samodzielnie, ale potrafi ją wydobyć z organizacji i dobrze opakować.

Zanim firma zacznie zwiększać liczbę artykułów albo uruchamiać kolejny kanał, warto sprawdzić, ile jej prawdziwej wiedzy jest dziś widoczne z zewnątrz. Jeżeli najciekawsze rozmowy nadal odbywają się wyłącznie na Slacku, podczas spotkań projektowych i calli sprzedażowych, to właśnie tam znajduje się materiał, który może najbardziej odróżnić ją od konkurencji.