Sprawa wygląda następująco: zespoły zajmujące się danymi potrzebują ról/umiejętności menedżerów produktu, aby odnieść sukces. (TL;DR)

Słyszymy jednak, że Airbnb zlikwidowało stanowiska PM, a inne startupy nie planują zatrudniać żadnych PM.

Zacznijmy od podstaw: Czym zajmują się kierownicy projektów? Odpowiedź w dużej mierze zależy od organizacji. Nie można oczekiwać takiego samego zakresu obowiązków od Google Cloud Product Managera, jak od 20-osobowego PM startupu. Nie twierdzę, że jest to łatwiejsze lub bardziej złożone: jest inaczej. Jednak oczekiwanie posiadania i kierowania produktem jest wspólne dla obu ról, niezależnie od wielkości firmy. Wiąże się to z ustalaniem priorytetów zadań, komunikacją i utrzymywaniem interesariuszy w pętli, identyfikowaniem potencjalnych możliwości strategicznych i wprowadzaniem rzeczy w życie.

W przypadku Airbnb ich CEO po raz pierwszy ogłosił, że połączy funkcje PM z funkcjami Product Designerów, co ma dla nich duży sens. Ogromna część ich produktu to UX/UI. W tym przypadku konsolidacja funkcji PM w ramach roli, która jest właścicielem wizualnych i behawioralnych aspektów produktu, jest genialną decyzją. Było to możliwe dzięki dojrzałości produktu i pracującego z nim zespołu. Później ogłosili, że rola PM została połączona z Product Marketing Managerem. Stało się tak, że obowiązki PM zostały rozdzielone między projektanta produktu i menedżera ds. marketingu produktu. Moje przekonanie, że było to możliwe, opiera się na wyraźnym dopasowaniu produktu do rynku, długiej historii udanych iteracji i eksperymentów produktowych, długoletnim personelu, jasnych obowiązkach między zespołami oraz kulturze zespołu, w której członkowie byli zachęcani do przejęcia odpowiedzialności i przywództwa w inicjatywach. Najważniejsza jest dojrzałość kultury, ludzi, procesów i produktów.

Mówiąc o identyfikacji produktów danych, kwantu danych i domen w organizacji, aby rozpocząć tworzenie siatki danych, oczekuje się, że ktoś z zespołu danych zacznie to robić. Moim zdaniem zespoły ds. danych były zbyt długo pomijane i niedoceniane. Wychodzenie na zewnątrz i proaktywne rozmowy z zespołami biznesowymi, identyfikowanie potencjalnych produktów danych i zadawanie pytań są dziś postrzegane jako dodatkowe. Nie mówię, że tak się nie dzieje, po prostu nie dzieje się tak w 9 na 10 przypadków.

Jednym ze sposobów rozwiązania tego problemu jest utworzenie stanowiska menedżera produktu ds. danych. Osoba ta ostatecznie przejmie odpowiedzialność i przywództwo w zakresie dostarczania produktów danych i utrzyma szerszy obraz. Szkoliłaby również zespół ds. danych w zakresie umiejętności myślenia o produkcie, motywując ich do bardziej znaczącej współpracy z użytkownikami biznesowymi.

Inicjatywy dotyczące siatki danych wymagają roli menedżera produktu danych, ponieważ większość firm jest na wczesnym etapie wdrażania siatki danych. Musimy wyciągnąć wnioski dotyczące organizacji, dojrzałości kulturowej i gotowych procesów, zanim będziemy mogli przekazać tę odpowiedzialność członkom zespołu zajmującego się produktami danych.

Poniżej wyjaśniam, dlaczego myślenie produktowe jest kluczem do sukcesu z produktami danych i siatką danych.

Czym są produkty danych?

Zacznijmy od podstaw. Produkty danych są jedną z kluczowych koncepcji Data Mesh, która podkreśla, że dane mogą być produktem wewnętrznym lub zewnętrznym w stosunku do organizacji. Data Mesh to paradygmat budowania platform danych w sposób zdecentralizowany, aby wspierać i służyć strukturze i projektowaniu organizacji.

Mówiąc prościej, “produkty danych” w kontekście Data Mesh to fragmenty danych, które są pakowane, posiadane i utrzymywane w sposób podobny do tego, w jaki traktowane są produkty oprogramowania. Przykłady produktów danych mogą obejmować pulpit nawigacyjny dla CMO lub CFO, zestaw danych z danymi klientów lub model ML używany przez zespół ds. sukcesu klienta lub pojedynczą tabelę danych z obliczonymi wskaźnikami dla zespołu sprzedaży. Innymi słowy, zależy to od struktury firmy – domen danych i JTBD (Job to Be Done) z produktami danych. Kluczowym pytaniem jest, jak zaprojektować tę architekturę i strukturę danych, aby były one wielokrotnego użytku, łatwo dostępne i godne zaufania dla wszystkich zespołów zainteresowanych określonymi produktami danych.

Produkty danych: Cykl i atrybuty

Produkty danych mają swój cykl życia, tak jak każdy produkt w oprogramowaniu, marketingu lub jakiejkolwiek innej dziedzinie.

Oprócz cyklu życia, produkty danych muszą posiadać pewne atrybuty, aby odnieść sukces: posiadanie jasno zdefiniowanego właściciela, jasno zdefiniowanego konsumenta (konsumentów), przynależność do określonej domeny oraz posiadanie zdefiniowanego kwantu produktu danych, który może się różnić w zależności od produktu danych.

Źródło: Masthead Data

Produkty danych są wynikami infrastruktury IT i danych, które mają na celu tworzenie wyników biznesowych, podczas gdy siatka danych kieruje i wspiera architekturę danych, która spełnia wymagania biznesowe i umożliwia firmom szybsze wydobywanie wartości z danych.

Charakterystyka produktów danych

Dzięki Data Mesh dane są postrzegane jako produkt. Ostatecznym celem jest wykorzystanie danych w działaniu i wygenerowanie wymiernej wartości dla firm. W związku z tym generowanie wyników biznesowych jest podstawową cechą, która definiuje istnienie produktów danych. Wartość ta różni się w zależności od biznesu, domeny, przypadku użycia i wielu innych czynników. Sposób mierzenia i określania wartości produktów danych zależy od konkretnego zespołu, który posiada odpowiedni kontekst biznesowy. Na przykład zespół sprzedaży jest właścicielem określonej tabeli danych i jest odpowiedzialny za zapewnienie jej aktualizacji na czas, utrzymanie wiarygodności danych i skuteczne zarządzanie produktem danych w celu zapewnienia jak najlepszych wyników biznesowych.

Inną cechą charakterystyczną produktów danych jest to, że można je znaleźć. Choć może się to wydawać proste, biorąc pod uwagę stale rosnącą ilość danych, potoków i modeli, zapewnienie łatwego dostępu do produktów danych ma kluczowe znaczenie. Konsumenci danych potrzebują możliwości skutecznego dostępu do tych produktów w celu ich praktycznego wykorzystania.

Co więcej, wszystkie produkty danych w organizacji powinny być ustandaryzowane, zapewniając, że nawet jeśli są zdecentralizowane i należą do różnych zespołów, istnieją spójne standardy dostępu do danych, ich zabezpieczenia i wykorzystania w celu zapewnienia spójności i niezawodności.

Bardzo dobrą i prostą analogią dla siatki danych i produktów danych jest sposób, w jaki książki są zorganizowane w bibliotece. Książki, podobnie jak produkty danych, są zazwyczaj przechowywane w różnych sekcjach lub domenach biblioteki, takich jak beletrystyka, powieści, edukacja itp. Każda książka jest przechowywana w określonej domenie i zazwyczaj jest łatwa do wyszukania, ponieważ jest pogrupowana według roku lub nazwiska autora. Co więcej, wyznaczone osoby są zwykle odpowiedzialne za utrzymanie porządku w tych domenach (alejki z książkami).

Koncepcja ta może wydawać się teoretyczna, ale staje się praktyczna, gdy praktycy danych i firmy zaczynają wdrażać siatki danych i definiować produkty danych.

Jak zidentyfikować “produkty danych”?

Łaskawie idę naprzód, zakładając, że mamy poparcie na poziomie C dla projektu Data Mesh ze wszystkimi niezbędnymi zatwierdzonymi budżetami, przydzielonymi mocami i zasobami oraz ogromną wiarą w przyjęcie Data Mesh w całej firmie.

Warto zauważyć, że Data Mesh ma na celu zminimalizowanie ilości danych w pamięci masowej poprzez skupienie się na eliminacji niepotrzebnych elementów i zachowaniu tylko tego, co jest niezbędne dla biznesu. Podejście to kontrastuje z powszechną praktyką biznesową stosowaną w ciągu ostatnich 15 lat, polegającą na gromadzeniu wszystkich możliwych zdarzeń i punktów danych, zgodnie z zasadą: “Kto wie, może będziemy tego potrzebować jutro?”. Nie spotkałem się jednak z organizacją, w której ktoś byłby skłonny usunąć dane, aby celowo zwolnić miejsce na dysku.

Ponieważ produkty danych są faktycznym wynikiem Data Mesh, pojawia się pytanie: jak je zdefiniować? Podejście, które zyskało największą popularność i przyniosło korzyści firmom, polega na tym, że zespoły danych zaczynają rozmawiać z konsumentami danych, próbując zdefiniować zadania do wykonania (JTBD) z danymi, zanim zostaną one zidentyfikowane jako produkty danych. Wyjątkowi inżynierowie danych podjęli proaktywne kroki, wychodząc na zewnątrz i zadając ludziom biznesu proste pytania:

• Jaki problem próbują rozwiązać konsumenci danych?
• Co obecnie robią, aby go rozwiązać?
• Co się stanie, jeśli nie będą już dysponować danymi, z których obecnie korzystają?
• Jakich danych brakuje?
• Jaka jest szacowana wartość dodana wynikająca z dysponowania tymi danymi?

Te proste pytania pomagają obu zaangażowanym stronom uzasadnić przekształcenie tego, co mają, w produkt danych o wszystkich niezbędnych cechach. Jednak właśnie ta rozmowa stawia inżyniera danych w zupełnie nowej perspektywie, w której przyjmuje on rolę menedżera produktu.

Dlaczego przyjęcie sposobu myślenia menedżera produktu ma tak duże znaczenie dla sukcesu w Data Mesh?

Wczesne badanie i określanie zakresu problemu rozwiązywanego za pomocą danych ma kluczowe znaczenie. Pomaga to zdefiniować architekturę przyszłej platformy danych, określić alokację zasobów do jej budowy i utrzymania oraz zidentyfikować niezbędne narzędzia do obsługi infrastruktury. Otwarta rozmowa i środowisko do współpracy dla zespołów zajmujących się danymi i użytkowników biznesowych ma zasadnicze znaczenie dla przyszłych decyzji dotyczących aktualizacji, iteracji lub wycofania produktów danych, a ostatecznie platform danych.

Wiele organizacji decyduje się na zatrudnienie do tej roli menedżera produktu danych. Rola ta przejmuje własność produktów danych, określa ich zakres i ustala priorytety zadań niezbędnych do osiągnięcia sukcesu biznesowego. Rola ta nie jest jednak bezwzględnie konieczna, jeśli członek zespołu ds. danych jest wystarczająco proaktywny, aby przejąć dodatkowe obowiązki. Niemniej jednak nie należy przyjmować jej za pewnik, ponieważ ta rola w zarządzaniu produktami danych oznacza dużo pracy nad planowaniem, synchronizacją, ustalaniem priorytetów i utrzymywaniem wszystkich interesariuszy w pętli, aby zapewnić, że produkty danych są dostarczane i zapewniają oczekiwaną wartość dla biznesu.

Konieczność posiadania na pokładzie menedżera produktu danych w dużej mierze zależy od dojrzałości zespołu danych i organizacji, a także cyklu życia produktów danych organizacji.

Przemyślenia końcowe

Koncentrując się na JTBD odróżnia się od tego, czego chcą i potrzebują konsumenci danych, co ostatecznie generuje wartość biznesową. Odbywa się to również ręcznie, ze ścisłą priorytetyzacją. Zrozumienie wszystkich potencjalnych użytkowników w innych domenach i sposobu ich standaryzacji. Podczas opracowywania jakichkolwiek projektów dotyczących danych, zespoły ds. danych muszą koncentrować się na zadaniu do wykonania, a następnie na technologii. Aby to osiągnąć, zespół ds. danych może potrzebować dedykowanej roli menedżera produktu danych, który będzie miał szerszy obraz i wykona wszystkie niezbędne prace związane z gromadzeniem wymagań, ustalaniem priorytetów i utrzymywaniem wszystkich interesariuszy na bieżąco i zaangażowanych. Mając to na uwadze, nie powinniśmy oczekiwać tego od inżynierów danych, chociaż skupienie się na wartości i wynikach dla użytkowników powinno być najwyższym priorytetem dla inżynierów danych, gdzie menedżerowie produktu danych mogą pomóc im rozwinąć niezbędny sposób myślenia o tworzeniu produktów danych, które są używane, a nie zestawów danych, które znajdują się gdzieś w pamięci.