Как не строить продукт для affiliate-команды, которая на самом деле не ваш клиент

Как не строить продукт для affiliate-команды, которая на самом деле не ваш клиент

Частая ошибка в product management для арб-инструментов: брать за "пользователя" всех подряд — байера, тимлида, owner'а, аналитика. У них разные задачи, критерии успеха и даже язык описания боли.

Если вы валидируете идею только через общие интервью, получите вежливое "интересно" вместо решения. Лучше заранее выбрать один сегмент и один сценарий: например, "тимлид, который вручную собирает отчёты по связкам" или "owner, который теряет деньги на медленной сверке".

Что проверять на discovery:
— где человек теряет время прямо сейчас;
— какие обходные решения уже используют;
— что должно измениться, чтобы он перешёл на новый tool;
— кто ещё влияет на решение о покупке.

В affiliate-нише это особенно заметно: один и тот же продукт могут хвалить за разные вещи. Байер хочет скорость, owner — контроль, операционка — меньше ручного хаоса. Если не разводить эти роли, MVP превращается в набор чужих хотелок.

Сначала формулируйте не фичу, а конкретный workflow и одного покупателя. Тогда интервью, прототип и пилот проверяют реальную боль, а не абстрактный "нужен ли вам этот продукт".