1. Риск ценности. Продукт должен решать какую-то задачу и не быть бесполезным. (пример - провальная копия "фейсбука для своих") (в нашем кейсе - маски точно не нужны).
2. Риск юзабилити. Стоит делать некоторый определенный набор минимальных функций. Сделать полностью жизнеспособный продукт - скорее всего мы не успеем. Но при этом нужно сделать чтобы было понятно как использовать этот продукт. Для чего на какую кнопку нажать.
3. Технический риск. Мы ограничены во времени. Не стоит включать очень сложные технологии. Мы должны уложиться в период времени, который нам выделен.
4. Риск бизнес-модели. Если что-то разрабатываем - нужно разбираться в этой сфере. Например, чтобы не засудили. Работа с персональными данными. Другой риск здесь - финансовая составляющая. Сервис должен быть окупаемым.

Не говорите о своем продукте в том плане что - "вы хотите эту фичу?" В ответ скажут - "О, круто". Вы воспринимаете как похвалу и потратите кучу времени на что-то бесполезное.

Не давите на собеседника. И опрашивайте тех кому это интересно.

Решит ли мой продукт проблему?

"Полюбите плохие новости". Когда клиент критикует - это хорошо, потому что вы еще в процессе разработки, а не закончили продукт. Клиент почувствует своё участие.

Фича полезная - забронировать видеозвонок. Возможность отложенного вызова. Указание времени для видеозвонка. "Мне удобно показать товар - с 19:00 до 23:00"

Продукт нужно выпускать не на всю клиентскую базу сразу.

Оценка фич. Два варианта. 
1. Простой график (по осям простая-сложная и ценная-не ценная). Оценивать следует командой от 1 до 5.
2. Через экселевский файл.

variables:
  ALIAS: 'minio'

deploy-develop:
  image:
    name: minio/mc
    entrypoint: ['']
  stage: deploy
  before_script:
    - mc alias set $ALIAS $MINIO_HOST $MINIO_ACCESS_KEY $MINIO_SECRET_KEY --path on
  script:
    - cd ./public
    - mc cp ./ minio/$BUCKET_DEV/ --recursive
  tags:
    - docker
  except:
    - master