Читая книгу «The Silicon Valley Way» by Elton Sherwin. Наткнулся на интересный тест, который уверен поможет стартапщикам искать слабые места и белые пятна в своих будущих продуктах.

За каждый вопрос ставьте следующие балы:

• Нет и не планирую — 0
• Нет, но планирую — 4
• Верно на пятьдесят процентов — 5
• Верно на восемьдесят процентов — 8
• Да, совершенно верно — 10

Стив Бланк — гуру в области стартапов, основоположник концепции клиентоориентированной разработки, автор культовых книг — The Four Steps to the Epiphany и The Startup Owner's Manual -, фаундер восьми стартапов. Данная статья раскрывает причины, по которым стоит отказаться от традиционных подходов к построению стартапа.

После 20 лет работы в стартапах, я решил остановиться и посмотреть на модель разработки продукта (Product Development Model), которой следовал: понять, почему она была неуспешной в том, что касается нашей работы «вне офиса» — продаж, маркетинга и развития бизнеса.

У каждого стартапа есть какая-нибудь методология по разработке продукта, его запуску и управлению жизненным циклом. В идеальном случае, эти процессы содержат детальные планы, чек-пойнты и майлстоны для каждого этапа вывода продукта на рынок: определение размера рынка, оценка продаж, разработка маркетингово плана, приоритезация фич продукта. Но в конце концов, не смотря на все эти инструменты, 9 из 10 продуктов терпят неудачу.

Управление стартапом подразумевает большой круг обязанностей. Маркетинг и продажи, любительский HR и бухгалтерский учет, разработка и проджект менеджмент, одним словом, вы должны быть мастером на все руки. Мы все понимаем важность подхода Бережливого стартапа (Lean Startup) и методов развития клиентов (Customer Development), однако, их трудно реализовать на практике. Кстати, если вы еще не наткнулись на CustDev.com, бегите туда прямо сейчас и хватайте книгу Brant’а и Patrick’а The Entrepreneur’s Guide to Customer Development (или русский перевод книги — Стартап вокруг клиента).

Как только вы пообещали себе «выбраться из офиса», чтобы поговорить со своими клиентами и по-настоящему исследовать вопрос о востребованности предлагаемого продукта на рынке (Profit-Market Fit), очень важно выжать максимум из этого мероприятия. Для новичков в методологии развития клиента одной из наиболее сложных вещей является составление опросов, поэтому я бы хотел поделиться тем, как я структурирую опросы для достижения максимальной отдачи от них.

В этом блоге мы много пишем про разработку и продвижение приложений. Настало время для взгляда с другой стороны. В середине ноября наши друзья из Sports.ru запустили курс по продакт-менеджменту мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Весь декабрь студент курса kirillkobelev будет рассказывать, как проходит обучение и что же нужно знать юному продакт-менеджеру, чтобы создать лучшее мобильное приложение. Передаем слово автору:

В середине ноября наши друзья из Sports.ru запустили курс для тех, кто хочет стать продакт-менеджером мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Весь декабрь студент курса kirillkobelev рассказывает, как проходит обучение. Сегодня – инсайды с лекции об этапах разработки приложения.

В середине ноября наши друзья из Sports.ru запустили курс для тех, кто хочет стать продакт-менеджером мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Весь декабрь студент курса kirillkobelev рассказывает, как проходит обучение. Ниже репортаж с лекций 4 и 5, которые были посвящены болезненным вопросам для начинающего продакт-менеджера – монетизации и управлению командой. В этот раз, для разнообразия, – в жанре производственной драмы.

В середине ноября наши друзья из Sports.ru запустили курс для тех, кто хочет стать продакт-менеджером мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Студент курса kirillkobelev рассказывает нам, как проходило обучение. Сегодня – заметки о том, на какие аспекты аналитики должен прежде всего обращать внимание начинающий продакт-менеджер (по мотивам лекции Олега Новикова из Uber) и как продвигать свое приложение в сторах без бюджета (со слов Сергея Шарова из ASO Desk).

Сегодня мы выкладываем последнюю статью с тезисами из курса по продакт-менеджменту Product.Degree. В ней студент курса kirillkobelev рассказывает о бизнес-моделях приложений (бегло), фичеринге (подробно) и своем собственном опыте управления продуктом (чуть-чуть).

Что такое MVP?

MVP (minimum viable product — минимально жизнеспособный продукт) – это продукт, который разрабатывается с максимальной экономией денег и ресурсов, как правило, с единственной целью – проверки гипотезы. Гипотеза, как правило, заключается в необходимости и/или полезности этого продукта.

MVP ни в коем случае не означает “черновой вариант”, сделанный в спешке, который после завершения выбросят и будут писать с нуля.

Если вы убеждены в обратном, то вам точно стоит остановиться, пересмотреть приоритеты разработки и прочитать эту статью. Стоит уменьшать функционал продукта, но ни в коем случае не пытаться сделать все и сразу, в безумной спешке, упуская важные части функционала и оставляя за собой вереницу багов. Нужно точно определить, какой функционал является основным, а какой не используется в большей части случаев.

Хэллоуин — время поговорить о страхах. Я работаю продакт-менеджером в IT-компании, поэтому речь пойдёт про кошмары разработчиков. Но не обычные, а те, что появляются во времена перемен.



Когда компания развивается — меняет подход к разработке, создаёт новые продукты и расширяет возможности текущих, десятками принимает сотрудников, тем, кто работал по-старому, бывает тяжело перестроиться. Мы радуемся изменениям, но иногда, чего скрывать, боимся их. Я работаю продакт-менеджером уже год и за это время столкнулась с пятью крупными страхами своей команды. Сегодня расскажу об этих страхах и о том, как нам удалось их преодолеть.

Это перевод первой части цикла из четырех статей о разработке и производстве физических продуктов. Автор, источник: Ben Einstein.

Зачастую разница между компанией, приносящей миллиарды, и компанией-банкротом – в умении создать продукт, который полюбят клиенты. Но с учётом стоимостных и временных затрат в промышленном секторе, у стартапов по большому счету есть только один шанс вывести товар на рынок. У них нет возможности заниматься итеративной разработкой или позволить себе выпустить недоработанный продукт, в отличие от стартапов, разрабатывающих программное обеспечение.

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

Эта серия статей расскажет о том, какими могут быть качественные процессы разработки физических продуктов.

Это третья из четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, или Часть 2: Дизайн, стоит их прочитать. Вскоре вы сможете перейти к Части 4: Валидация. Автор: Ben Einstein. Оригинал Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.

Часть 3: Конструирование

Каждый шаг на стадии конструирования (разработка технических требований, создание функционирующего прототипа, программирование прошивки/софта) нужен чтобы убедиться в том, что продукт надёжно функционирует и его производственная себестоимость оптимальна. Результат процесса инженерной разработки — прототип, который корректно функционирует, но пока не имеет хороших пользовательских характеристик (UX) и визуально не слишком благороден. Конструирование и дизайн продукта почти всегда идут одновременно.


Рисунок 3.1 Этапы конструирования продуктов

Технические требования (Engineering Specification)

Один из лучших показателей хорошо спроектированного продукта — детальность технической документации.

Dealing with priorities is a constant necessity in product management and development processes. In order to improve professional skills, product managers should find time to explore and try using simple and complex methods and frameworks to determine priorities.

The Lean Prioritization approach is one of the simplest and most accessible methods that help product managers with managing task backlog, especially when it needs to be done quickly and efficiently. This post is about the power of Lean Prioritization.

В 1985 году Дэвид Дойч первым описал квантовую машину Тьюринга. Позже он соединил идеи Поппера, Докинза, Эверетта и того же Тьюринга в теорию разумных объяснений. А недавно я обнаружил, что улучшаю процессы разработки банковских продуктов на основе его подхода к методологии науки.

Привет. Меня зовут Дима Мурзин.

По профессии я бизнес аналитик в сфере финансов, работаю с бизнес-стейкхолдерами и с командой разработки, в которой исполняю роль Product Owner. Третий год живу с семьёй в Нью-Йорке.

Когда я жил в Петербурге, мне посчастливилось поработать в команде, в которой был очень хорошо поставлен SCRUM процесс. Во многом, это произошло благодаря тому, что продакт менеджер со стороны заказчика очень глубоко понимал принципы Agile, а также знал, как должен быть устроен SCRUM с точки зрения всех практик и церемоний. В Одном Большом Европейском Банке (на который я работал) это было большой редкостью. Также, я должен отметить мой непосредственный менеджмент со стороны компании подрядчика. Они наняли хорошего коуча, который посвятил нас в процесс и следил за нами еще несколько недель, дали нам полную свободу дуйствий и ответственность за продукт, а после этого вмешивались лишь если возникали серьезные проблемы, что случалось редко. Кроме того, они занимались хайрингом и подбирали людей, которым подходила работа в условиях постоянных изменений.

Мы уже писали в статье Локализация как «красная таблетка»: рецепт и инструкция по применению, что в локализации продукта много подводных камней, и с двумя из них разработчики сталкиваются уже ПОСЛЕ локализации. Это — перевод обновлений продукта и поддержка пользователей локализованных версий. В этой статье мы расскажем, как решить эти проблемы за несколько кликов.

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

И тогда у нашего СЕО Александра Муравского назрела идея сервиса, куда можно было закинуть текст для перевода безо всяких переписок с менеджером и получить свой перевод в течение дня. Когда появилась тестовая версия сервиса, желающие его попробовать нашлись мгновенно, хотя мы даже не успели добавить кнопку для оплаты.

Написано в Alconost

Дедлайны есть во всех без исключения проектах и практически во всех продуктовых процессах разработки. В проектном управлении дедлайны легко напрямую связать с выручкой, но для продуктов всё несколько сложнее. Какую роль играют дедлайны при развитии продукта? Можно ли без них обойтись?

In the previous article, we discussed the most important languages for app localization. Soon afterward we received several requests to share our perspective on the key languages for game localization. That’s why we came up with this new post.

We’ve analyzed localization languages from the perspective of return on investment.

There are numerous case studies, research projects, and forecasts regarding the most promising countries and languages for game localization. In this article, we’re going to examine the game language issue from the perspective of the most efficient allocation of your localization budget.

What are the highest- and lowest-priority objectives when it comes to game localization?

We suggest raising this question first before selecting localization languages. Why? Because, depending on the type of game you’re localizing, your business objectives, and your audience’s expectations, there are several levels of localization.

You can do the minimum required and stop at the first level, or you can go further with a step-by-step localization and maximize outreach.

The first thing to start with is the localization of keywords and game description for app stores. This alone might work perfectly well if your game has little to no text or voice and its interface design is fully compatible with the standards of the country you are targeting.

Next, if your game contains text-based instructions, you have no choice but to translate them. In addition, other design choices will also need adjustments in terms of colors, numbers, and other local standards.

Finally, voice-over, if present in the game, must be translated as well, or at least subtitled. Or you can fully complete the localization process by rerecording voice-over in your target languages, thereby providing the perfect user experience.

Written by Alconost

Localizing your product can involve many pitfalls, and there are two of them that developers face AFTER the content has been localized: translating the product updates, and offering support for international users of the localized versions.

In this article, we will demonstrate how these issues can be solved with just a few clicks.

Written by Alconost

5 options to choose from

I used to work as a translator. As I speak several foreign languages, friends, colleagues and “friend-of-a-friends” — heck, even total strangers — would often approach me asking to translate “just a few sentences”.

I have translated for clients, for friends and for my own needs. And I can tell you: there are several ways to get your text translated.

How do you choose the best one? Well, it boils down to the famous “time — cost — quality” triangle. And normally we get only two of these three at a time…

Let’s weigh up the pros and cons of each method. I hope to save you a headache next time you’re translating something into another language :)

Written by Alconost

RetouchMe — популярное приложение, в котором профессиональные дизайнеры отредактируют ваше фото за 10-15 минут.

В США занимает 100-150 позиции в топ-чарте приложений App Store (категория «Фото и Видео»).

• 17 млн установок в 150 странах мира
• Локализация на 35 языков
• 10-15 минут — среднее время редактирования фото
• Армия дизайнеров и модераторов в разных странах
• Помимо App Store и Google Play, доступно в Amazon AppStore и Samsung Galaxy Store

RetouchMe заказывают локализацию в Alconost и переводят обновления в нашем онлайн-сервисе Nitro.

Команда RetouchMe поделилась с Nitro, как локализация помогла им выйти в топ во многих странах, оправдала ли себя локализация на 35 языков и как за сутки-другие выпускать новые фичи без релиза.