Andrey Osipenko


Kanal geosi va tili: Ukraina, Ukraincha


Канал про менеджмент проектів, роботу з людьми, маркетинг та розвиток технологічних продуктів простою мовою
PM zksync.io вдень, а вночі навчаю проектних менеджерів – redcamp.pro
Для зв'язку: @andreyosipenko
ex. COO TestFort, ex. CPO ItomychStudio

Связанные каналы

Kanal geosi va tili
Ukraina, Ukraincha
Statistika
Postlar filtri


🎙️Новий випуск подкасту «кнопкодави» вже на каналі

У цьому випуску ми з Каріною поговорили про:

💢Що бісить в ІТ після 10 років🔥😤
- Перфекціонізм у поєднанні з маленьким бюджетом.
- Забобони по якості.
- “Ефект Оракла” - оверреакція на людей із сертифікатами та іншими “плашками”.
- Лібертаріанство / Овер демократія – розмазування відповідальності по команді, або навпаки “давайте врахуємо думку всіх”.
- Дурнувата економія
- Не потрібні мітинги
- Порушення процесів керівництвом
- Ту мач полайт спілкування - скажіть вже прямо

🎧Подкаст також доступний на Spotify та Apple Podcasts

🗯️Чекаємо на ваш фідбек та відмітки в сторіз!


Чому продакти можуть навчитися у науковців?

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

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

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


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

🔵Починаєте робити контент для себе, а не для користувачів

🔵Думаєте що знаєте що хоче ринок, навіть не поспілкувавшись з ЦА й не зробивши аналіз ринку.

Щоб бути успішним менеджером, вам потрібно якомога більше забирати своє его від роботи.

Якщо ви довго щось робите, а результатів немає, зупиніться та подивіться правді в очі.
Ви працюєте зі світом та аудиторією, чи з вашим очікуванням про світ та аудиторію?


Забирайте свою особистість від своїх суджень. Ви зробили експеримент, він не вдався, ок, беремо наступну гіпотезу. Щоб щось вдалося, ви повинні робити експерименти та тестувати гіпотези.

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

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

🌐 Правда у всесвіті, щоб її звідти забрати вам ТРЕБА багато ітерувати й доставати її звідти.

Будь-який науковець не думає що в нього вийде знайти відповідь на якесь запитання за секунди -> йому потрібен час й багато спроб. Як й шахтер, знає, що йому потрібно докопатися до руди.

Дайте собі час, зробити достатню кількість спроб, щоб зробити ідеально!

Став 🔥 якщо сподобався цей пост!


🤖Як розробляти круті продукти?

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

Знання добуваються виключно експериментами та взаємодією з ринком та аудиторією.


Ваша задача як продакта, фасилітувати процес здобування знань та реалізовувати їх у щось корисне для користувачів та вашого продукту.

Один з головних ваших інструментів, це розробка та аналіз продуктових гіпотез.

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

Чекліст якості гіпотези
- Ви вірите що це може бути правдою (❗), але вам треба зрозуміти наскільки ваші думки співпадають з реальністю.
- Може бути перевірена різними способами.
- Прикладна для ідеальних користувачів вашого продукту.
- Бінарна: або вона має вплив, або ні.
- Її можна виміряти та ідентифікувати її вплив на проєкт / продукт.

✍️ Структура ідеальної гіпотези
- Idea: Основна ідея, припущення або спостереження
- Potential Impact: Потенційний ефект який буде мати ця ідея
- The audience of impact: Яку когорту користувачів вашого продукту зачепить ця гіпотеза.
- Impact Volume: Який очікуваний результат та природа його походження,
- Time Period: Який проміжок часу ми беремо щоб зрозуміти, чи має ця гіпотеза афект на цю метрику, чи ні.

🧠 Думайте подібним чином:
Я бачу що користувачі роблять А, тому що Б. Я думаю що якщо я зроблю В, вони почнуть робити більше А тому що ….


В цьому прикладі, ваше судження привʼязано до фактів та спостережень, а не до відчуття людини. Т.я. наші почуття можуть помилятися.

Pro Tip: робить логування ваших гіпотез та їх тестів. Це сильно допоможе як вам, так і вашим колегам робити більш data-driven рішення у наступному. Й навчатися з кожної помилки ( яких буде багато ❗ )

Сподобався пост? Став 🔥


⚙️ 5 речей які потрібно знати кожному менеджеру про інжиніринг

На початку моєї кар'єри, було дуже мало ресурсів, які могли пояснити простою мовою про складні технічні концепти.

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


1️⃣Технічні основи

Ви повинні розуміти, як працює інтернет. Що трапляється коли ви натискаєте на ту, чи іншу кнопку. В якому форматі дані летять на сервер. Що сервер з ними робить. І як вони зберігаються.

Ключові слова: API, JSON, Endpoint, SQL, Client / Server relations, HTTP.

Ви не можете управляти тим, чого не розумієте.

2️⃣Tech Stack вашої компанії

Чому важливо?

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

Старі та не популярні технології впливають на пошук нових інженерів, вам складніше їх шукати, ви більше їм платите.

3️⃣Сенсетів точки вашого кодбейзу

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

Уявіть що зміна тексту на якійсь сторінці вашої документації займає 2 дні, тому що ви обрали Gatsby, який потребує повний редеплой рішення, при будь-якій зміні контенту.

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

Як дізнатися?
Запитайте вашу команду, де найбільша кількість технічного боргу. І які частини вашого продукту найбільш складні для правок.

4️⃣Як вносити правки у продукт
Не усі правки потребують уваги програміста. Деякі маленькі речі ви можете робити самостійно, й це пришвидшить ваш робочий процес.

Наприклад, вам потрібно зробити нову сторінку для публічної документації вашого продукту, чи новий блог пост. А ваш продукт працює зі статичним генератором сайтів. Ви може зробити її зробивши один pull-request з Markdown файлом ( до речі цей пост я пишу саме у цьому форматі ).

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

5️⃣Процес вашого білда й деплойменту вашого продукту
Написати код, це тільки половина діла — інша задача його доставити до ваших користувачів.

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

Деякі ченжи десктопних додатків будуть потребувати у користувача реінсталяції додатку взагалі.

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

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

Як дізнатися?
Запитати вашого тех. ліда чи архітектора. Подивитися на логи pull request’ів.

Став 🔥 щоб бачити більше такого контенту!




💭 Я рідко ділюся відгуками, але отримую їх кожного дня по кожному з продуктів.

Цей інтенсив пройшло вже більше 40 людей, і у кожного відбулись якійсь зміни:
1. Хтось зміг отримати першу роботу в айті
2. Хтось отримав офер x2 від зарплатні на початку курсу

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

🔗Передзапис

🌐 Сайт інтенсиву


🔥 Відкрито передзапис на інтенсив Технічні Навчики для Нетехнічних Менеджерів 3.0

📈Трохи статистики:

- 80% вакансій на менеджера на DOU та Djinni потребують технічних навичок.
- Технічні менеджери заробляють на 40% більше ніж їх коллеги без технічних навичок ( дані indeed )

3️⃣ За 3 інтенсивних тижні, я навчу вас:

- З повного нуля розбиратися в складних технічних системах
- Розмовляти з программістами однією мовою.
- Розробляти технічну документацію, діаграми архітектури інфраструктури та баз данних.

🏅Ви отримаєте:

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

Кількість місці на тариф зі зворотнім зв'язком, перевіркою ДЗ та щотижневими зустрічами обмежена. Та закінчується за довго до відкриття продажів у блозі.

🎁 Як бонус, при оплаті у наступні 3 дні, ви можете забронювати за собою знижку 15% на кожен із тарифів. Та тестове інтервью зі мною в кінці курсу. Просто забронюйте місце :)

📆 Старт навчання: 4 березня

🛡️ Бронювання місця: 2,000 грн ( входить у ціну курсу )

Деталі курсу та посилання на передзапис тут ⬇

https://tech.redcamp.pro/

🔗 Передзапис


Привіт! Новий випуск подкасту «кнопкодави» вже каналі 🎙

У цьому випуску ми з Каріною поговорили про:

- Як ініціювати проєкт з повного нуля
- Як налагодити стосунки з клієнтом
- Як сформувати команду
- Що потрібно знати про тімбілдінги
- Налаштування PM Tools
- Впровадження типових процесів (робота з вимогами, звіти, ченжі)
- Як обрати методологію розробки ПО
- Типові помилки при старті проєкту
- Back-office (інвойси, ресурси, маржинальність)
- Різниця старту проєкту в аутсорсі та продукті
- Бонус випуску - відповідаємо на питання підписниці

Чекаємо на ваш фідбек та відмітки в сторіз!


2️⃣ поради які принесуть вам x2 у зарплатні

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

Хочете більше заробляти -> спілкуйтесь зі стейкхолдерами

Хочете більш спокійний робочий процес -> спілкуйтесь зі стейкхолдерами

Не хочете благати про підвищення ЗП -> спілкуйтесь зі стейкхолдерами

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

Ці поради допомогли мені свого часу зробити квантовий стрибок у ЗП, а тепер можуть змінити й ваш вектор роботи.


📆 Зробіть щотижневий 1-1 мітинг з вашим менеджером
Говоріть не тільки про себе, запитуйте як справи у вашого менеджера, з якими проблемами він зараз стикається, і з чим у ваших силах йому допомогти.

Кожному менеджеру, хочеться відчувати, що поруч є партнери, на яких можна спертися якщо це необхідно.

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

Ці зустрічі будуть допомагати йому періодично проактивно думати про ваші відносини і про його очікування від вас.

✉️ Check Up Email кожен цикл / тиждень
Зробіть собі звичкою, періодично робити пост до вашого менеджера з наступними пунктами:
- Що я зробив у попередній цикл.
- Що я збираюсь зробити у наступний.
- Штуки в яких я на цей момент відчуваю труднощі, і в яких ви б хотіли почути перспективу вашого менедж

Менеджеру навіть не обовʼязково на них відповідати, він може просто ставити емодзі під ними, як знак що він ознайомився з ними.

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

А вам не прийдеться “продавати” свою роботу, бо ваш менеджер вже буде знати, що ви зробили за останні місяці. А у крайньому кейсі, у вас завжди будуть ці пруфи 🙂

🎁 А бонусом, раз на рік ви можете зробити саммарі цих постів, й показати менеджменту, або команді ваш рік й чим ви займалися

Якщо було цікаво, не забувай ставити ❤️




🏦 Сьогодні хочу трохи розказати вам про Product Management Debt.

Вже багато людей знають про Technical Debt. Пару років тому навіть писав про Management Debt.

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

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

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

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

❓Задавайте собі періодично наступні питання
- Що можна видалити з продукту?
- Чим користувачі вже не користуються?
- Чи який вже наявний функціонал треба переробити, бо він не зручний?
- На який функціонал ми витрачаємо найбільше часу на його підтримку?

Як продакт менеджер ви повинні, не тільки додавати більше велью до продукту, але й видаляти все інше, що відволікає користувача або команду.


📈 Як запобігти появленню боргу?

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

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

- Стратегічне планування. Процес довгострокового планування, не до деталей, але хоча б до напрямку.


🎙️Новий випуск подкасту «Кнопкодави» вже каналі

У цьому випуску ми з Каріною поговорили про:

- Що таке проєкт, та з чого він складається?
- Артефакти та церемонії
- Як спілкуватися зі стейкхолдерами та розуміти їх пріорітети?
- Як працювати з дедлайнами та скоупом робіт
- Як працювати зі змінами
- Стартер-пак процесів при старті проєкту в IT
- Типові помилки на початку проєкту

✨Чекаємо на ваш фідбек та відмітки в сторіз!


🗣 Хочеш бути корисним — спитай 

Друзі, як у проєкті, так і у житті я намагаюсь не рухатись «наосліп». Я зустрічав так багато бізнесів, які робили продукт навіть не розібравшись ХТО буде ним користуватись. Як наслідок - провал. 

Зараз формую контент-план для каналу, і не хочу допускати тих самих помилок. Хочу, щоб мій контент був для вас релевантним. Тому ви мені потрібні.

- Можете описати проблеми з якими ви зараз стикаєтесь на роботі, і від котрих у вас припікає?

- Або інформацію яку ви зараз шукаєте в професійному плані, але не можете знайти, а хотіли б мати.

Такий бонус за вашу активність від мене — 1️⃣ першому, хто залишить коментар з описом проблеми я зроблю розбір у коментарях. А другого оберу серед інших рандомно і також зроблю розбір. 

Пігнали 👇🏻


Метрики у проєктному менеджменті

Нещодавно була консультація, і основною темою дискусії були метрики на проєкті, захотів поділитися основними поінтами з вами! 

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

😵 Які зараз задачі ви ставите перед собою? Метрики повинні допомагати вам трекати ваш прогрес до цих цілей. Трекати заради трекінгу суто витрата часу. 

💭Задайте собі й менеджменту питання, яких цілей ми хочемо досягти за допомогою метрик?

Приклади цілей:
- Прозорість продуктивності кожного циклу.
- Відчуваємо що можемо брати більше роботи у кожен цикл роботи
- Хочемо зрозуміти де саме вузьке горнятко процесу.

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


Метрик повинно бути не більш ніж 3-5 максимум. Інакше ви суто на збір будете витрачати часу більше ніж на аналіз даних.

Питання які треба ставити собі по кожній цифрі яку ми будемо заміряти:
- Що будемо заміряти?
- Як будемо заміряти?
- Кордоні значення метрики, т.е. що таке добре, а що таке погано.
- Які наші дії при виході метрики з кордонних значень?
- Які наші гіпотези й зміни в менеджменті можуть впливати на ці метрики?
- Коли ми робимо замір? Робити замір кожен день не продуктивно, раз на цикл, раз на білд/реліз.

✍️Формати
Спочатку робіть мануально в excel чи навіть у повідомленнях. Коли ви бачите що це працює, починайте думати над автоматизацією.

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


Записатися на персональну консультацію


🎙️ Проектний Менеджер в IT: обов'язки, ключові навички, оцінка роботи, проблеми та кар'єра Новий випуск подкасту «кнопкодави» вже каналі

У цьому випуску ми з Каріною поговорили про:
- 🗒️ Обов'язки ПМа в різних компаніях і їх різниця в залежності від компанії та проєкту.
- 💼 Відповідальність. Накосячила команда, а відповідаю я - чому?
- ⚙️Ключові навички проєктного менеджера в IT
- 🛠Найрозповсюдженіші проблеми з якими стикається менеджер проєктів.
- 📈 Метрики успішності проєктного менеджера в IT: як виміряти результати та вдосконалювати роботу.
- 👨‍💻Перспективи карʼєри в IT: Наче все ок, але я не розумію що далі.

🗯️ Чекаємо на ваш фідбек та відмітки в сторіз!

Подкаст доступний у відео форматі на YouTube: https://linktw.in/coqrni
Або на Spotify та Apple Podcasts: https://podcasters.spotify.com/pod/show/knopkodavi


🧑‍💻 Хто такі DevRel? І нащо вони потрібні у сучасних компаніях?

Сьогодні до вас з новою цікавою темою. Чи знаєте ви хто такі DevRel? Скоріш за все ні, таку роль в Українських компаніях я ще не бачив. Ці люди відповідають за співпрацю з розробниками. З відси і назва Developer Relationships.

Якщо ваш продукт так чи інакше використовують розробники, то вам знадобляться подібні люди. Наприклад, якщо ви розробляєте якусь бібліотеку, фреймворк чи API. 

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

- Допомагати вашому коммьюніті розробників у розв'язанні проблем з вашим продуктом на рівні коду.

- Робити туторіали та приклади використання вашого продукту.

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

- Збирати фідбек з розробників які користуються вашим продуктом, заповнювати

- Доповнювати публічну документацію


👥️️️️️️Загалом, DevRel відповідають за побудову позитивних стосунків і співпрацю з розробниками, щоб сприяти успіху продуктів або послуг компанії в технічній спільноті.

У таких доменах як Crypto чи Developers Tooling ця роль дуже важлива, бо розробники це ваші основні клієнти у таких компаніях.


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

Став 🔥 якщо було цікаво, і поділись, чи був у тебе досвід співпраці з DevRel спеціалістами?

4k 0 11 3 64

⚙️Чи потрібні технічні навички проектному менеджеру в IT?

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

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

Так народилася ідея для подкасту 🎙«Кнопкодави» і першою темою нашої розмови стала дискусія на тему «Технічні навички для проектного менеджера в IT», де ми поспілкувалися про:

- 👩‍💼 Чи має РМ бути технічно обізнаним?
- 🧠 Які переваги надає технічна обізнаність РМу?
- 🧑‍💻 Що кажуть розробники? Що їм потрібно від РМ?
- 👾 Чому зараз на ринку так багато запиту на технічні навички ?
- 🫂 Що важливіше технічні навички чи people менеджмент?

Подкаст доступний у відео форматі на YouTube: https://linktw.in/aEBbij

Або на Spotify та Apple Podcasts: https://podcasters.spotify.com/pod/show/knopkodavi

🔥 Буду радий вашому фідбеку по нашому пілотному випуску, реакціям та лайкам

P.s. Якщо вам зайде такий формат будемо періодично робити подібні випуски 🙂


⚛️ Синдром самозванця: як позбутися та чому він важливий?

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

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

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

Тому що на цьому шляху може бути багато нездорових установок:
Та я менеджером тільки тут був, це все команда. Або, та це воно само так вийшло. Мені пощастило, і т.д.


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

🛠 Як з цим впоратися?

1️⃣ Проведіть ревізію, всіх проблем з котрими ви стикнулися за останні 2 роки. Включно з проєктами, котрі ви завершили. Це вже дасть вам буст у впевненості в собі, і якийсь ґрунт на якому ви можете стояти.

2️⃣Почитайте The Courage To Be Dislike, The Happiness Hypothesis.

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

Також ось дуже гарна стаття

------

Час від часу і я його відчуваю. Іноді цілими тижнями. Але не забувайте, що той поінт де ви зараз є, це вже ваша заслуга. Усі наші попередні рішення привели нас туди, де ми зараз є.

А якщо вам здається що це все удача і так сталося, тоді раджу вам почати грати у карти, з такою удачею вам точно підфартить 🙂


🤖 No-code інструменти для продакт менеджера

Продакт менеджеру дуже важливо швидко ітерувати і перевіряти гіпотези. Команда розробників це лише один з інструментів який може вам в цьому допомогти. 

No-Code інструменти дозволяють вам збирати сайти, і цілі аплікації без інженерів. Звісно у цього підходу купа лімітів та обмежень. Але для перших прототипів і тестування гіпотез цього буде достатньо.

💻 Уявіть, що у лічені години ви можете зробити повністю робочий вебсайт з CMS системою за допомогою Notion’a і Super.so. А якщо хочеться трохи більше свободи, то Framer. Наприклад, сайт мого останнього продукту, повністью зроблений за допомогою Framer’a, без строчки коду, дивиться - NotionForCreators

🔗 Потрібна якась інтеграція? Подумайте про Zapier. Він вміє коннектити й автоматизувати цілу купу сервісів між собою, наприклад коли хтось приймає інвайт на івент у Google Cal, я можу додавати цю людину у Google Spreadsheet.

🎛 Потрібна адмінпанель для вашого нового стартапу? Використовуйте Retool, він може сам під'єднуватися до вашого бекенду і візуалізувати чи взаємодіяти з будь-якими даними без інженерів. Його можна розгорнути навіть на ваших серверах, що достатньо безпечно навіть для банків. Навіть мобільні додатки зможете зібрати для вашого бек-офісу.

🛠 За допомогою Bubble ви зможете збирати цілі бекенди для ваших додатків, і навіть щось готове для мас-маркету може вийти.

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

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

Відпишіть чи використовуєте ви no-code інструменти у своїх проєктах, і для яких задач?


Всім привіт!

Сьогодні хочу поділитися з вами своєю варіацією на План розвитку проєктного менеджеру від 0 до $5,000 в аутсорсі або продуктових компаніях.

Поговоримо про:
1️⃣Хард, софт і технічні скілли які потрібні на кожному рівні
2️⃣Як ці навички прокачувати?
3️⃣Також можете оцінити на якому рівні ви зараз знаходитесь
4️⃣Додаткові навички які будуть корисні на усіх рівнях розвитку

Буду радий вашим підпискам, лайкам, шерам і коментарям 🙂
Посилання на відео: https://youtu.be/Ib0e4R-jfC8

5.5k 0 83 2 105
20 ta oxirgi post ko‘rsatilgan.