Продуктове мислення

Простої універсальної формули для спільноти не існує. Вона вимагає часу, експериментів та ітерацій, щоб знайти правильний підхід, — і навіть «правильна» відповідь змінюватиметься з часом. Саме тому Membership Puzzle Project каже: базова одиниця практики спільноти — «спроба». Зробіть обґрунтоване припущення про те, що спрацює з учасниками. Скоригуйте за потреби або відмовтеся, якщо не працює. Головне — не інвестувати надто багато в жодну окрему спробу, поки не з'ясуєте, що вона працює.

Саме тому продуктове мислення — критична навичка для редакцій зі спільнотою. Продуктове мислення — це підхід, який ставить рішення на основі даних вище за інтуїцію і цінує перевірювані інсайти вище за закриті процеси. Він базується на управлінні цифровим продуктом — дисципліні, поширеній у розробці програмного забезпечення. Продуктове мислення допомагає редакції налагодити співпрацю між командами й розкрити потенціал міждисциплінарних партнерств.

А оскільки спільнота пронизує редакційну, технічну, фінансову роботу й роботу зі спільнотою одночасно, вона вимагає продуктового менеджменту — міжфункціональної дисципліни, зосередженої на стратегічній розробці, запуску, вдосконаленні й підтримці продуктів організації. Навіть невеликий організаційний досвід тестування й навчання на потенційних учасниках суттєво допоможе вашим першим спробам побудувати спільноту.

Продуктом може бути будь-що, що медіа створює для розв'язання проблеми чи задоволення потреби. Ефективний продукт служить чітко визначеній аудиторії й часто прив'язаний до конкретного способу заробітку. Продукт може бути цифровим (застосунок чи функція сайту) або фізичним (серія подій). Він може служити зовнішній аудиторії (розсилка) або команді всередині (наприклад, CMS вашої редакції — теж внутрішній продукт).

Думайте про свою спільноту як про продукт — а з ускладненням, можливо, як про серію продуктів. Продуктове мислення для спільноти обертається довкола базового циклу: поставити конкретні цілі, згенерувати креативні ідеї, поставити в центр потреби учасників, провести швидкі тести, оцінити результати й ітерувати.

Як і будь-який продукт, стратегія спільноти процвітає, коли вся організація — від редакції до відділу доходу — розуміє й підтримує її мету. Підхід до спільноти як до продукту дозволяє підтримати потреби вашого бізнесу й дати наявній команді змогу робити ще більше. Це включає й уміння відзначати й вчитися на власних невдачах: якщо ставитися до невдачі як до можливості навчитися, ви вже на шляху до продуктового мислення.

У цьому розділі ми розглянемо ключові інструменти й робочі процеси продуктового мислення, застосовні незалежно від розміру чи віку вашого медіа. Наприкінці розділу поговоримо про те, чи потрібна вам формальна продуктова команда, і про типові перешкоди на шляху до продуктового мислення в редакціях.

Постановка цілей

Для будь-якого продукту, який ваша організація створює чи підтримує, варто мати реалістичні, амбітні й вимірювані цілі — і жоден процес розробки продукту не має починатися, поки цих цілей немає.

Цілі дають продукту напрямок. Завдання — це те, що потрібно зробити, щоб досягти цілі. Чи запускаєте ви спільноту, чи ітеруєте наявну, чи впроваджуєте більше спільнотних рутин — почавши без чітких цілей, ви, найімовірніше, будете блукати.

Важливо, щоб цілі були водночас реалістичними й амбітними: занадто легкі — і ви постійно їх досягатимете, майже нічого не роблячи для процвітання організації; занадто амбітні — і ви ніколи їх не досягнете, що вдарить по мотивації команди. А без вимірюваності ви ніколи не зрозумієте, чи досягли їх.

Ще кілька порад щодо постановки цілей:

Визначте, хто може допомогти. Формуючи цілі, подумайте, кого залучити до цього процесу. Корисно проаналізувати історичні дані чи порадитися з аналітичною командою (якщо вона є). Корисно поговорити з керівництвом, щоб зрозуміти фінансові показники, потрібні для стійкості. А якщо цілі вимагають редакційних зусиль, варто поговорити з журналістами, щоб переконатися, що цілі резонують і з ними.

Оберіть стандартний формат для цілей. Використання єдиної рамки — це планування наперед: ви зможете застосовувати той самий формат знову і знову, заощаджуючи час і легко порівнюючи всі свої продукти між собою.

Поширена стратегія — цілі SMARTIE. The Management Center, некомерційна тренінгова організація, створила корисний робочий аркуш для формулювання цілей за такою рамкою:

• Стратегічна (Strategic): ціль відображає важливий вимір того, чого прагне досягти ваша організація.
• Вимірювана (Measurable): розумні люди можуть узгодити кілька стандартів, за якими визначити, чи досягнуто мети.
• Амбітна (Ambitious): достатньо складна, щоб її досягнення означало значний прогрес — «виклик на межі можливостей» для організації.
• Реалістична (Realistic): не настільки складна, щоб шанс успіху був майже нульовим (наприклад, якщо ви невелике локальне медіа, що обслуговує регіон із 3 млн населення, мета залучити мільйон цифрових передплатників за один рік навряд чи реалістична).
• Обмежена в часі (Time-bound): має чіткий дедлайн.
• Інклюзивна (Inclusive): залучає традиційно маргіналізованих людей — особливо тих, кого це найбільше стосується, — до процесів і рішень так, щоб ділитися владою. Так само, як і для інших вимірів цілі, варто мати стандарти для оцінки того, чи справді ваша ініціатива інклюзивна.
• Справедлива (Equitable): включає елемент справедливості, спрямований на подолання системної несправедливості, нерівності чи гноблення.

Нехай цілі визначають метрики, на яких ви фокусуєтеся. Обравши ціль, яку хочете досягти, можна вирішити, які метрики використовувати. Наприклад, якщо головна організаційна мета — зміцнити лояльність і підвищити утримання учасників на 5%, визначте ключові метрики, пов'язані з лояльністю й утриманням, і ретельно відстежуйте їх з часом. Це можуть бути: повторні донати, повторні відвідування сайту, індекс лояльності клієнтів (NPS), час, який відвідувачі проводять з вашими матеріалами, чи кількість прочитаних матеріалів.

Фокусуйтеся на результатах, а не на діях. Ваші цілі мають ґрунтуватися на результатах (чого ви сподіваєтеся досягти), а не на діях (що ви плануєте робити). Ось приклад від Дугласа К. Сміта, Квентіна Хоупа й Тіма Ґріґґса з Knight-Lenfest Newsroom Initiative (Table Stakes): ціль, засновану на діях, сформулювали б так — «до 15 грудня ми навчимо всіх журналістів, як використовувати заголовки для залучення трафіку»; ціль, засновану на результатах — «до 15 грудня всі журналісти застосують уміння працювати з заголовками, щоб підвищити загальний трафік щонайменше на 10%».

«Ми навчимо всіх журналістів» — це дія, а не результат. Формулюючи цілі мовою дій, ви потрапляєте в пастку самозбувного пророцтва: уявіть розмову 16 грудня — «Як справи з ціллю?» — «Чудово! Ми навчили всіх журналістів працювати з заголовками». Але ніхто не знає, чи справді навчання щось змінило.

Коли Chalkbeat готувався запускати спільноту, у команди було чітке розуміння того, які результати покажуть, що спільнота «працює» для них.

Дві інші поширені рамки постановки цілей — ключові показники ефективності (KPI) та цілі й ключові результати (OKR). Вони складніші за SMARTIE, і MPP радить почати саме з SMARTIE, якщо ви новачки в постановці організаційних цілей.

KPI — це точкові, орієнтовані на результат метрики, якими вимірюють успіх організації, команди чи окремої людини. Зниження щомісячного відтоку — приклад KPI для редакції, що поставила за мету зміцнити утримання учасників.

OKR визначають конкретні цілі та метрики для відстеження прогресу. Вони мають бути амбітними. Ціль команди може звучати як «краще пояснити цінність нашої спільноти», а ключовим результатом — зниження відтоку. (Різницю між KPI та OKR буває складно вловити.)

Команда спільноти південноафриканського Daily Maverick використовує OKR для постановки маркетингових цілей. Одна ціль — наростити кількість активних учасників, залучаючи нових і утримуючи наявних. Три ключові результати: досягти 20 000 учасників до кінця 2020 року, тримати щомісячний відтік нижче 5% і досягти NPS 8/10 для спільноти.

Детальніше про визначення цілей для своєї стратегії спільноти — в розділі «Метрики спільноти».

Генерація ідей

Хороші ідеї можуть прийти звідки завгодно, і продуктове мислення дозволяє редакції збирати, підтримувати й утілювати ідеї від ключових зацікавлених сторін — і всередині команди, і поза нею, у спільноті учасників. Ось як MPP радить генерувати ідеї для нових продуктів спільноти — чи ви проєктуєте її з нуля, чи покращуєте наявну.

Думайте про «роботу, яку потрібно виконати» для учасників. Продуктове мислення — це не лише збір даних, а й розуміння даних, які вже є. Частина фокусу на голосі учасника — розуміння того, хто вони і як виглядає їхній щоденний розпорядок. Переглядаючи дані, шукайте незадоволені потреби чи часті больові точки. Покійний професор Гарвардської школи бізнесу Клейтон Крістенсен, піонер теорії підривних інновацій, називав цей підхід «роботою, яку потрібно виконати».

Застосувавши цей підхід до власних даних про учасників, ви, ймовірно, зрозумієте: ваша організація конкурує не лише з іншими медіа, а й за час і увагу — із соцмережами, завантаженим розкладом і навіть телефонними дзвінками.

Наприклад, німецький Krautreporter пишається орієнтованим на залученість підходом до журналістики з акцентом на контекст, а не оперативні новини. Але опитавши учасників наприкінці 2019 року й проаналізувавши метрики, команда зрозуміла: учасники часто скасовували участь, бо не мали достатньо часу взаємодіяти з контентом. Krautreporter описав це як «дорого коштує часу».

У відповідь Krautreporter спростив учасникам вписати сайт у своє життя: переробив ранкову розсилку, додавши огляд головних новин поряд із власними глибокими матеріалами, планує й далі розвивати щоденну розсилку, а також розробляє функції сайту, що показуватимуть, скільки часу займе прочитання матеріалу.

Проводьте мозкові штурми з учасниками. Продуктове мислення фокусується на голосі аудиторії — критичному компоненті успіху спільноти. Хоча багато організацій проводять мозкові штурми лише всередині команди, MPP радить час від часу залучати й учасників спільноти — потужний спосіб стати справді орієнтованим на них. Такі сесії запрошують групу учасників (наявних чи потенційних) попрацювати разом над розв'язанням спільних проблем.

Такі сесії найкорисніші, коли організовані навколо конкретних питань чи відгуку, який ви шукаєте. Membership Puzzle Project створив набір інструментів «мозковий штурм у коробці» з понад 30 запитаннями формату «як ми могли б», на які можна відповісти разом з учасниками.

На таких сесіях ваша роль — лише фасилітатор. Переконайтеся, що не говорите більшість часу самі. Створіть розслаблену, відкриту атмосферу. Дайте людям сидіти невеликими групами й говорити вільно.

Ось кілька вправ для спільного мозкового штурму про вашу спільноту: попросіть учасників заповнити анкети, а потім обговорити відповіді разом (це дає можливість подумати наодинці перед тим, як ділитися з групою, — добре запобігає групному мисленню й підходить тим, хто любить зібратися з думками перед виступом); попросіть учасників у малих групах обговорити, у яких ще спільнотах вони перебувають і що з цього отримують, а потім представника кожної групи — поділитися підсумком (одне з одним люди можуть бути відвертішими, ніж з вами); попросіть учасників «намалювати» те, що вони найбільше хотіли б бачити у спільноті (звучить лякаюче, але може розкрити несподівану креативність). Попросіть дозволу записати результати, щоб повернутися до них пізніше.

Робота з учасниками не закінчується одним мозковим штурмом. Варто знайти спосіб тримати хоча б частину учасників постійно залученими до процесу. У Британії Black Ballad створив закриту Slack-спільноту лише для учасниць — простір, де вони можуть спілкуватися одна з одною, і водночас спосіб регулярно отримувати відгук.

Проводьте мозкові штурми з командою. Люди, що працюють з вами, можуть мати чудові ідеї щодо того, над чим варто працювати організації, — треба лише знайти правильний спосіб їх запитати. Хороший підхід — структурований процес прийому ідей: створіть дошку Trello, таблицю Google чи Google-форму, відкриту для всієї організації, і запросіть людей подавати ідеї через анкету-пітч із питаннями на кшталт «хто це робитиме?». Повідомте, що переглядатимете дошку ідей регулярно, — і дотримуйтеся обіцянки.

Якщо організація невелика, формальний процес подачі може відлякувати. Проведіть натомість розмову, зосереджену на генерації ідей, — це дає можливість ставити уточнювальні питання й давати відгук у реальному часі. Такі розмовні сесії можна проводити як разовий мозковий штурм або регулярну нараду.

Пріоритизація

Найімовірніше, у вашої редакції ідей і цілей більше, ніж реально втілити. Визначення пріоритетів — над чим працювати першим, а що відкласти — критичний компонент продуктового мислення.

Коли продуктові менеджери говорять про пріоритети, вони говорять і про компроміси: часу й ресурсів не безмежно, тож робота над однією річчю часто означає відмову від іншої.

Часто журналісти вирішують, над чим працювати, за інтуїцією, історичними уподобаннями чи організаційною ієрархією. Продуктові менеджери намагаються ухвалювати ці рішення на основі дослідження аудиторії, аналітики й бізнес-впливу.

Ось дві можливі рамки для визначення пріоритетів.

Матриця вплив/зусилля. Мета цього підходу — ранжувати завдання за впливом, який вони створять, проти зусиль, потрібних на виконання. Складіть список того, над чим хочете попрацювати найближчим часом, і для кожного пункту оцініть: який вплив ця ідея матиме на бізнес (спираючись на дані — конкуренти, що зробили подібні зміни, минулий досвід подібних змін) і скільки зусиль потрібно для реалізації (скільки часу від наявної команди, чи потрібні нові інструменти чи зовнішня допомога). Оцінюйте числами або простими категоріями «високо/середньо/низько».

На основі цих двох вимірів ідеї розподіляються на чотири категорії: швидкі перемоги (мало зусиль, великий вплив); масштабні проєкти, варті інвестицій (багато зусиль, великий вплив); допоміжні завдання, корисні колись, але не пріоритетні (мало зусиль, малий вплив); невдячні завдання, що не варті вашого часу (багато зусиль, малий вплив).

Отримавши ці оцінки, легше порівняти ідеї між собою. Пам'ятайте: оцінки не мусять бути точними. Якщо виявите, що помилилися, — скоригуйте, де можете, і врахуйте цей досвід у наступному раунді пріоритизації.

Цей підхід особливо ефективний для малих команд, для яких «швидкі перемоги» можуть мати непропорційно великий вплив — і звільнити час і ресурси для масштабніших проєктів пізніше.

Матриця терміново/важливо. Цей підхід, також відомий як матриця Ейзенхауера, особливо ефективний для пріоритизації списку справ і визначення (та усунення) активностей, які тримають вас зайнятими, але майже не сприяють довгостроковому успіху організації.

Легко відволіктися від важливих, але не термінових завдань (наприклад, планування спринту дослідження аудиторії для ітерації спільноти) на термінові, але не важливі (наприклад, відповіді на листи). Нанесення завдань на цю матрицю допоможе зрозуміти, на що варто знайти час, а від чого варто відмовитися чи що делегувати. Це також допомагає братися за важливі завдання ще до того, як вони стануть терміновими.

Дорожня карта і спринти

Визначивши цілі й ідеї, на яких хочете зосередитися, потрібно нанести їх на те, що продуктові мислителі називають «дорожньою картою» — довгостроковим плановим документом, який дає конкретний план перетворення ідей на реальність. Якщо ваша організація вирішила запустити спільноту, вам знадобиться дорожня карта, що веде до запуску.

Ось основні орієнтири для побудови дорожньої карти: використовуйте таймлайн (за тижнями, місяцями, кварталами чи роками — головне, щоб він узгоджувався з розкладом спринтів вашої команди); визначте категорії (за командою, комітетом, продуктом, типом завдання — важливо обрати просту систему й дотримуватися її); створюйте паралельні треки (дорожня карта дозволяє бачити плани кількох проєктів одночасно, що допомагає розставляти пріоритети і для близьких, і для довгострокових цілей).

Ось приклад того, як команда французького Mediacités побудувала свою дорожню карту: спершу склали список того, що працює і що не працює; пункти зі списку «не працює» нанесли на матрицю терміново/важливо, щоб побачити, що потрібно вирішити негайно (наприклад: «немає KPI для вимірювання конверсії та утримання учасників», «інвестиційні матеріали запускаються без попередньої оцінки інформаційних потреб спільноти», «частину команди все ще потрібно переконати в перевагах спільноти», «бракує часу відповідати на всі внески читачів і керувати ними»); ті самі пункти нанесли на матрицю вплив/зусилля, щоб оцінити масштаб кожного завдання (на маленькій команді, як у Mediacités, складно братися одразу за два масштабні проєкти, навіть якщо обидва мають великий вплив); визначили два пріоритети на квартал — розв'язати брак KPI для конверсії й утримання (терміново, важливо, мало зусиль) і наростити дохід від учасників заради стійкості (терміново, важливо, багато зусиль); визначили короткострокові й довгострокові цілі для кожного з двох пріоритетів і призначили дедлайни; розбили цілі на конкретні завдання з власними дедлайнами.

Ваша дорожня карта має розкладати головні ідеї на завдання з оцінкою часу на виконання. Дорожні карти часто розраховані на багато місяців і вимагають більшого, ніж просто дата початку й кінця, — потрібні проміжні дедлайни, щоб триматися курсу й вчитися на ходу, адаптуючи технології й стратегію в міру того, як з'ясовуєте, що працює.

Багато продуктових команд виконують свої ідеї циклами по одному-чотири тижні, які називають «спринтами». Концепція спринтів популярна в гнучкій (agile) розробці програмного забезпечення, і сьогодні багато редакцій пріоритизують і виконують ідеї саме так. Спринти корисні тим, що розбивають великі проєкти на менші відрізки й ставлять усю команду на однаковий графік — це стандартизує проміжки, на яких ви вимірюєте результати й проводите тести, що критично важливо, коли редакція підтримує кілька редакційних продуктів одночасно кількома командами.

Завдання з дорожньої карти призначаються на конкретний спринт (чи кілька спринтів для особливо великих завдань). Кожна команда обирає тривалість спринту залежно від того, чого хоче досягти, і які ресурси має. Що б ви не обрали, тримайте ритм спринтів послідовним — оберіть темп, який працюватиме навіть із ускладненням ваших продуктів.

Для кожного спринту ви розробляєте й випускаєте змістовний шматок роботи, оцінюєте його ефективність і вирішуєте, чи задоволені результатом, чи хочете доопрацювати, чи переходити до наступного шматка роботи з дорожньої карти.

Хоча більшість редакцій організовують спринти за часовими інтервалами, це не єдиний спосіб визначити початок і кінець спринту. Scalawag, редакція з Північної Кароліни, що висвітлює американський Південь, має стратегію зростання спільноти, зосереджену на подіях. Вони планують і проводять події серіями, тож логічніше було вирівняти спринти саме за цим, а не за фіксованим проміжком часу.

MVP: чотири етапи

Ви не дізнаєтеся, чи працює ідея, поки не покажете її реальним учасникам. Немає заміни реальним даним. Але й не варто вкладати всі ресурси в щось, поки не зрозумієте, що рухаєтеся в правильному напрямку.

Найкраща стратегія запуску ефективних продуктів для спільноти — тестуй-і-вчись. Щоб застосувати цю стратегію, часто потрібно створити мінімально життєздатний продукт (MVP) — спосіб перевірити ідеї в реальному світі.

MVP не мусить бути ідеальним. Це найпростіший вияв вашої ідеї чи продукту. Розробляючи MVP, зосередьтеся на найважливіших функціях, тримайте список вузьким і сфокусованим — додаткові функції можна нашарувати пізніше, після перевірки концепції. Простий MVP також дозволяє легко простежити зв'язок між діями й ефектом.

Процес розробки MVP складається з чотирьох етапів: постановка чітких цілей, дизайн MVP, запуск і збір даних, оцінка й ітерація.

1. Поставте чіткі цілі. Перший крок запуску MVP — чіткі, орієнтовані на результат цілі. Чого має досягти ваш MVP і як ви зрозумієте, що досягли успіху? Інший спосіб думати про MVP — як про гіпотезу: яку інформацію потрібно зібрати, щоб підтвердити чи спростувати її? Наприклад, коли південноафриканський Daily Maverick запускав MVP своєї донатної моделі, мета була відповісти на питання: чи готові люди підтримувати Daily Maverick фінансово на постійній основі; де серед власних платформ знайти найзалученіших читачів; яке повідомлення про спільноту резонує найкраще; як розташування кнопок і кольорова схема впливають на реєстрації.

2. Спроєктуйте MVP. Простий MVP чудовий тим, що дозволяє чітко провести зв'язок між ідеями та поведінкою аудиторії, і його можна спроєктувати й запустити відносно швидко. У своєму гайді з ухвалення рішень про спільноту на основі даних коуч MPP Федеріка Керубіні радить: «Важливо пам'ятати про введення лише однієї змінної за раз, щоб зрозуміти, яка стратегія працює, а яку потрібно скоригувати. Наприклад, тестуючи, яка платформа краще конвертує, переконайтеся, що формулювання заклику до дії однакове чи майже однакове на всіх (тон має лишатися послідовним, навіть якщо слова трохи різняться). Перевіривши платформу, можна тестувати, яке повідомлення працює найкраще, пробуючи різні формулювання на одній платформі».

3. Запустіть MVP. Визначивши, як тестувати MVP, — запускайте його. Ось короткий, далеко не вичерпний список способів показати MVP аудиторії: інструменти на кшталт Google Optimize підключаються до Google Analytics і дозволяють проводити легкі тести на сайті — корисно, наприклад, для тестування MVP нового заклику до дії; більшість провайдерів email-розсилок дозволяють проводити A/B-тести теми листа, імені відправника й часу надсилання прямо у своїй системі; платформи керування соцмережами дозволяють тестувати текст поста, прев'ю-зображення й інше; інструменти на кшталт TestFlight та InVision дозволяють показати ранні версії застосунків і цифрового досвіду потенційним тестувальникам.

The Narwhal провів A/B-тест, щоб з'ясувати, чи краще потенційні учасники відгукуються на запрошення «Стати учасником» чи «Стати Нарвалом», — усунувши здогадки з вибору формулювання, яке резонує з аудиторією.

Одна з ключових речей, яку варто пам'ятати під час тестування, — потрібно достатньо часу і правильних тестувальників для значущого результату. Переконайтеся, що люди, які бачать ваш MVP, відповідають типу аудиторії, яку ви сподіваєтеся залучити. Якщо ваша цільова аудиторія — студенти, не тестуйте MVP виключно на працюючих професіоналах. Якщо ви спеціально проєктуєте щось для недопредставленої аудиторії, переконайтеся, що представники цієї аудиторії включені у ваше тестування.

4. Оцініть результати й ітеруйте. Залежно від характеру тесту, варто дати йому пропрацювати щонайменше один спринт, а можливо, і довше. Важливо не піддаватися імпульсу перервати тест раніше, якщо кілька людей відреагували негативно, — порівнюйте негативний відгук із загальною кількістю учасників тесту. Бувають ситуації — наприклад, якщо тест стабільно негативно впливає на пошукову позицію чи рекламний дохід, — коли вплив на бізнес змушує перервати тест достроково. Але загалом найкращі результати дає тест, якому дали пройти повний цикл.

Провівши перший тест, оцініть результати й покращте MVP. Поверніться до цілей, які поставили на старті. Чи досягли їх? Де відстали? Що вас здивувало? Визначте кілька невеликих змін, які, на вашу думку, допоможуть досягти чи покращити цілі, впровадьте їх і виміряйте результат. Цикл починається знову.

Коли румунський DoR почав проводити спливаючі редакції поза Бухарестом, вони створили серію MVP, що зростали в масштабі протягом місяця: MVP 1 — серія розмов після роботи у своїй редакції; MVP 2 — повний день на сцені фестивалю поза Бухарестом; MVP 3 — тиждень у місті Тиргу-Муреш; бета-версія — серія поїздок у регіон Васлуй протягом кількох місяців.

Ваша пропозиція спільноти, найімовірніше, змінюватиметься з часом навіть у межах успішної програми, бо потреби й очікування учасників змінюються. Впроваджуючи цикл «тестуй-і-вчись», ваш продукт для спільноти зможе рости разом з учасниками.

Ретроспектива

Навіть команді з однієї людини критично важливо закладати час на рефлексію. Один з найкорисніших інструментів продуктового мислення — ретроспектива, або просто «ретро». Ретро дає команді простір обміркувати робочий процес і результати, щоб зафіксувати найкращі практики для майбутніх проєктів. Це на диво потужний інструмент, особливо якщо використовувати його регулярно.

Ретроспективу можна проводити будь-коли, головне — наприкінці змістовного відрізка роботи: після MVP, після спринту чи після довгострокового проєкту. Як орієнтована на спільноту редакція, ви можете проводити ретро після запуску спільноти, після масштабного проєкту залученості аудиторії чи після тестування змін у розсилці для учасників.

Ключові умови успішної ретроспективи — чесність і відчуття безпеки. Нейтральний фасилітатор часто працює краще, ніж хтось із самої команди; деякі команди проводять ретро без керівників у кімнаті, щоб люди могли говорити вільніше. Важливо нагадувати командам, що мета — покращити процеси, а не звинувачувати одне одного, навіть якщо результат роботи, яку ви обговорюєте, був невдалим.

До ретро варто запросити всіх, хто безпосередньо працював над проєктом; у менших організаціях — можливо, всю редакцію.

Запросивши людей, обравши фасилітатора й задавши тон, потрібно вирішити, що саме робити на самій ретроспективі. Поширений метод — відкрити цифрову дошку (по суті, цифровий варіант стікерів на стіні) і створити три колонки: «Продовжити», «Почати», «Припинити» (іноді використовують «Залишити», «Припинити», «Додати»). Кожен анонімно додає картки в кожну колонку.

Колонка «продовжити» — для того, що команда вже робить і вважає за потрібне продовжувати, бо це працює: це може бути внутрішня практика (щотижнева нарада про спільноту) або продукт чи функція (нещодавні зміни в розсилці лише для учасників, що підвищили відкриття). Колонка «почати» — для того, що команда хоче почати робити. У колонку «припинити» записують те, що команда хоче припинити.

Після цього кожен голосує за картки, з якими найбільше себе ідентифікує. Фасилітатор виносить картки з найбільшою кількістю голосів на обговорення. Команда може не погоджуватися щодо певних пунктів — і позначити їх для подальшого опрацювання.

Після ретро фасилітатор має занотувати, що команда почне, припинить і продовжить робити, включно з усіма завданнями. Уроки процесу варто записувати і, можливо, зберігати в одному файлі. Ретроспективи корисні, лише якщо ви починаєте їх зі згадки, де організація була на старті спринту, який оцінюєте, і фіксуєте уроки, щоб застосувати їх у майбутній роботі.

Чи потрібна продуктова команда

Коротка відповідь — ні. Нижче — три проміжні кроки, які дозволяють почати застосовувати продуктове мислення в редакції без найму продуктового менеджера.

Знайдіть продуктових мислителів у наявній команді. Якщо немає ресурсу найняти окремого продуктового менеджера, але ви знаєте, що в організації є місце для постійної продуктової роботи, варто визначити наявних співробітників, які можуть узяти на себе продуктові ролі. Рішад Патель, співзасновник азійської медіаконсалтингової компанії Splice, пропонує шукати в журналістах такі ознаки продуктового потенціалу: журналісти, які ставлять читача на перше місце (продуктове мислення — це пріоритизація потреб користувача, і якщо журналіст уже розуміє, що робить журналістику для реальних людей і спільнот, він, найімовірніше, зрозуміє й орієнтовану на користувача природу продуктового мислення); журналісти, які вміло формулюють проблему (успішні продуктові мислителі вміють точно визначити проблему від імені своїх користувачів — «це головний Грааль», каже Патель); журналісти, які бачать бізнес-логіку (продуктові мислителі в редакції розуміють, як їхня робота пов'язана з бізнес-моделлю й джерелами доходу організації — «ставитися до своїх користувачів з повагою — це робить бізнес кращим», каже Патель).

Одна з редакцій, з якими працював Патель і Splice, — Frontier Myanmar, англомовний бізнес-журнал із Янгона. 2019 року Frontier Myanmar вирішив перейти до моделі спільноти. Журнал отримав фінансування від Google News Initiative (яка також підтримує цей посібник). Цифрова редакторка Клер Гаммонд опинилася в ролі відповідальної за дизайн і запуск спільноти.

Якщо ви опинилися в подібній ролі продуктового менеджера без досвіду, колишня директорка з продукту Chalkbeat Бекка Аронсон радить «затінити» роботу колег з інших команд, з якими ви мало знайомі, — краще розуміючи, як різні команди працюють день у день, легше знайти зв'язки й зруйнувати внутрішні бар'єри. Багато організацій підтримують редакційних співробітників у продуктових ролях — Open News, Online News Association, Women in Product.

Призначте міжфункціональну команду. Одна з головних речей, які роблять продуктові менеджери, — руйнують внутрішні бар'єри між командами. Іноді, особливо на невеликій команді, не потрібно наймати нову людину — потрібна нова нарада для координації. Детальніше — в розділі «Кадри для стратегії спільноти».

У Chalkbeat це реалізували через «AudSquad» — коаліцію лідерів редакції, маркетингу, продукту й залученості аудиторії, яка зустрічається раз на два тижні для координації міжфункціональної стратегії. Більшість продуктового мислення й виконання перейшло саме в цю команду.

Наймайте консультантів чи коучів. Консультанти можуть допомогти рекомендувати інструменти продуктового мислення для інвестування, планувати й проводити дослідження аудиторії, розробляти дорожню карту разом із наявною командою, навчати пріоритизації й способам її здійснення чи безпосередньо керувати циклом розробки програмного забезпечення. Обираючи консультанта, шукайте людей з досвідом роботи в медіа. Фокусуйтеся на проєктах, дотичних до того, що ваша організація вже робить, — так у консультанта одразу буде внутрішній партнер. News Catalyst (США), Sembra Media (Латинська Америка) і Splice Media (Азія) пропонують консультації й можуть порекомендувати коучів і тренерів. News Product Alliance, запущений у вересні 2020 року, пропонує підтримку саме для лідерів продукту в медіа.

Типові перешкоди

Впровадження продуктового мислення в організації — масштабна зміна культури, але без нього стратегія спільноти навряд чи вдасться. Ось найпоширеніші перешкоди, які ми бачили, і можливі способи реагувати.

Люди можуть опиратися продуктовому мисленню повністю чи окремим його аспектам. Команда, звикла ухвалювати рішення інтуїтивно, може сильно опиратися рішенням на основі даних. Стратегії подолання внутрішнього спротиву: де можливо, впроваджуйте ідеї по одній, а не всі одразу; пам'ятайте, що продуктове мислення — це ще й про співпрацю та задоволення від роботи: запрошуйте колег досліджувати разом із вами й наголошуйте, що продуктове мислення тут, щоб допомогти й підсилити вашу чудову роботу, а не витіснити когось; знайдіть ключових союзників — чи є в організації одна-дві людини, відкриті до нового способу мислення, готові допомогти спробувати кілька легких рішень чи змін; подбайте і про себе — якщо постійно відчуваєте, що штовхаєте камінь у гору наодинці, знайдіть час відновитися й переосмислити підхід.

Брак ресурсів. Навіть великі організації борються з амбіціями, що виходять за межі їхніх можливостей. Гнучкість продуктового мислення насправді допомагає організації ефективніше використовувати обмежені ресурси, щойно ви освоїте підхід. Де можливо, шукайте способи розбити навантаження: сформулюйте вимірювану ціль (що найважливіше продуктове мислення має дати вам і вашій організації, і як це виміряти); пріоритизуйте інструменти з цього набору (не потрібно робити все одразу й не потрібна одна людина, яка робить усе, — так само, як пріоритизуєте цілі, пріоритизуйте частини продуктового мислення, які здаються найкориснішими, і беріться за них першими); залучайте союзників (подумайте, у кого в наявній команді є простір чи бажання розширити навички, і кого можна залучити як союзника).

Команда постійно зриває дедлайни. Плануючи проєкти, потрібно вміти оцінювати, скільки часу займе робота і які ресурси знадобляться. Хоча зриви дедлайнів можуть особисто фруструвати, часто це результат системних проблем, які постійно підривають здатність команди вдосконалювати продукти. Можливо, план проєкту не врахував літні відпустки, або залишив замало часу на затвердження дизайну керівництвом. Забагато пропущених продуктових дедлайнів з часом може посилити внутрішній спротив продуктовому мисленню й ресурсам для нього.

Якщо ви часто зриваєте дедлайни, час поставити собі такі питання: де у вашому процесі неефективність чи вузькі місця? Який вплив має ця неефективність? Де саме ваші оцінки часу чи ресурсів виявляються заниженими? Де вам бракує ключових ресурсів (людей, інструментів, знань) чи чітких ліній відповідальності й повноважень?

Оцініть ці прогалини й підніміть питання, які потребують вирішення на вищому рівні. Якщо не вирішити системні проблеми, що заважають вкладатися у строки й бюджет, зриви дедлайнів можуть перетворитися на великий і повторюваний виклик. Але відокремивши систему, що підтримує створення продукту, від конкретних людей, які його створюють, ви зможете спокійно братися за прострочений дедлайн як за безособову проблему — і, сподіваємося, розв'язати її на майбутнє.