Продакт-мышление внутри рефералки — короткая история
Реферальная программа выглядит как чисто техническая штука: выдал код, применил скидку, готово. На деле почти каждое решение внутри неё — продуктовое, просто замаскированное под техническую деталь.
Дыры, которые продумал заранее — до того как их кто-то нашёл бы на практике. Первая: что мешает пригласить самого себя и получить скидку на пустом месте? Привязка «кто кого пригласил» происходит только в момент самого первого запуска бота новым человеком — если это не первый запуск, а уже существующий пользователь, привязка просто не срабатывает, откуда бы ссылка ни пришла.
Вторая: что если человек уже пользовался ботом какое-то время, а потом задним числом решил перейти по чьей-то ссылке — можно ли так задним числом получить скидку? Тоже нет — привязка возможна только в момент самого первого знакомства с ботом, не позже.
Третья, самая неочевидная: пригласивший получает свою скидку, когда приглашённый оплачивает подписку. А что если пригласил сразу пятерых, и все пять вдруг оплатили один за другим? Должна ли скидка начисляться пять раз подряд? Решил, что нет — награда устроена не как счётчик, а как разовый флаг «есть скидка / нет скидки»: несколько друзей, оплативших почти одновременно, не открывают пять скидок сразу, только одну.
Четвёртая: скидка действует только на самый доступный тариф, а не на любой — иначе программа превратилась бы в способ дёшево получить самый дорогой план, хотя задумывалась как способ привести новых людей через низкий порог входа.
Где здесь граница между техническим и продуктовым решением одной и той же задачи. Возьмём деньги: место в коде, где реально начисляется или списывается скидка, — ровно одно, и никакого дублирования логики в других частях кода, даже в тех, что технически могли бы это делать. На первый взгляд — просто чистоплотность в коде, вопрос архитектуры. На деле за этим стоит продуктовое требование: цифры по деньгам должны быть всегда однозначно достоверны, а не «примерно похожи» в зависимости от того, какой участок кода отработал. Техническое решение существует, чтобы обслуживать продуктовую гарантию, а не наоборот.
А решение сделать награду разовым флагом, а не счётчиком, — с виду мелкая техническая деталь (тип данных, да и только), но на самом деле это чисто продуктовое решение о том, насколько щедрой должна быть программа и какое поведение она поощряет: не «зови больше — получай больше», а «первое реальное приглашение засчитывается, дальше — по новому кругу». Когда работаешь один, эта граница вообще стирается: иногда правильный вопрос — не «как это закодить», а «что вообще должно быть разрешено происходить».