Преодолевая инерцию: О решении ложных проблем

Во время поиска продуктовых решений часто всплывает, что мы пытаемся решать свои внутренние проблемы, а не проблемы пользователей. Вместо того, чтобы отталкиваться от «боли», мы отталкиваемся от своих же ограничений и забываем для чего мы делаем продукт. Мы можем принять за аксиому какие-то внутренние процессы и строить пользовательский сценарий вокруг куска своих внутренних проблем. Некоторые мастера могут обсуждать дизайн решения не имея представления о решаемой проблеме — какую и чью проблему они решают при этом? Говорят, что продукты отражают организационную структуру компании-создателя — это снова оно, но в большем масштабе.

Как не потерять фокус? Для начала, нужно убедиться, что фокус у нас вообще есть и он нацелен на проблему. Сформулирована ли проблема, можно ли её подтвердить на данных или живых пользователях? Сравните две формулировки: «пользователи не могут выразить своё отношение к записи в ленте» и «нет возможности поставить лайк сообщениям в ленте». И то и другое звучит как проблема, но в первом случае это действительно проблема, а во втором — замаскированное решение. Концентрируясь на проблеме, мы не закрываем для себя возможные пути решения и не затягиваем в проблему пользователя свои собственные проблемы. Кто знает, может наше решение с «лайками» изначально не удачное и его стоит пересмотреть, но возвращаясь на уже проторенную дорожку мы это не узнаем.

Решать проблемы сложно, это требует поиска неочевидных решений, может даже внутренней ломки. Куда проще «заниматься деланием» и это нормально, люди стремятся к минимизации энергозатрат и предсказуемости. Но важно помнить, какую «боль» мы пытаемся лечить, чью проблему решаем. И держать эту боль постоянно перед собой и постоянно задавать себе вопрос «то, что я делаю, имеет отношение к боли или я просто решаю какие-то другие проблемы?».

Подборка материалов за неделю

Know Your Customers’ “Jobs to Be Done”

Надеюсь, вы ещё не исчерпали лимит бесплатных статей на HBR:) Отличный материал по «Jobs to Be Done» от Clayton M. Christensen и соавторов. Как раз к вопросу об определении ценности для клиента, с помощью JtbD можно докопаться до глубинной потребности клиента, которую он так или иначе решает с помощью «найма» вашего продукта, продуктов конкурентов или собирает решение из различных заменителей. Если вы ещё не знакомы с этой концепцией и занимаетесь продуктовой разработкой, то читать нужно обязательно.

Why Experts Make Bad Teachers

Наглядная демонстрация того, почему некоторые учителя объясняют сложные вещи доходчиво и легко, а с некоторыми возникает комплекс неполноценности — вроде знающий человек объясняет, а ты не понимаешь . Эксперты склонны транслировать свою абстрактную модель предмета обучения, но эффективнее помочь ученику построить свою собственную модель. Провести ученика через самостоятельное понимание намного сложнее, но в этом и заключается искусство хорошего учителя. Всем, кто так или иначе обучает кого-то чему-то — читать обязательно.

What Is Agile?

Очередная статья про «взрослый» Agile на уровне мировоззрения организации. Статья хорошая, всё правильно написано, но хотелось бы отметить не это. Уже сейчас встаёт вопрос построения той самой Agile культуры — кто её будет строить, каким образом, что это за процесс такой вообще.

What is an API? In English, please

Продолжаем ликбезы по технологиям для не технических менеджеров. Сегодня небольшой, но ёмкий рассказ про API, одно из самых страдающих от упоминания всуе понятий разработки:)


Рассылка отборных материалов на тему менеджмента и еженедельное преодоление инерции — подписывайтесь!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.