Николай

Посмотрите практику Lean Startup, в интернете много статей на эту тему, хотя подход не является прям универсальным.

Вкратце, до запуска продукта и вообще до кода, сделайте страницу "по-быстрому" на каком-нибудь генераторе Landing Page. Даже, если вы крутой Front-end девелопер, вам это будет дешевле. Распишите планируемую идею, напишите "Скоро будет", добавьте блок "Подписаться" или "Сообщите мне, когда продукт появится". Распространите сайт среди целевой аудитории и оцените "как зайдет", сколько потенциальных первых заказчиков вы получите. Самые активные пользователи отправят вам еще и фидбеки, и пожелания. Можно понять, будет ли вообще все это дело рентабельно и стоит ли свеч.
Классический маркетинг вроде анализа конкурентов, ниши, бизнес-планирования тоже никто не отменял.

Если овчина выделки стоит, то делайте MVP (один или командой зависит от масштабов). Распространяйте его среди целевой аудитории и уже собранной базы подписчиков. Это вам и первые клиенты и фидбеки для дальнейшего роста (или остановки проекта).

А еще бытует мнение (и я склонен с ним согласиться), что если за MVP, то есть первую версию продукта, по прошествию времени не стыдно, то что-то пошло не так.

Если вы хотите больше советов, то:
- Найдите мотивированного напарника. Если вы технарь, то пусть это будет маркетолог/продавец и наоборот.
- Большую команду не стоит привлекать, если вы ее не потянете по деньгам. При этом, найти людей которые работают не только за зарплату, а еще и потому, что ваш продукт им нравится - большая удача, но к этому надо стремиться на первом этапе.
- Оформляйтесь официально, когда стало понятно, что MVP идет удачно. Много есть разговоров на эту тему на самом деле, но если с партнерами не сойдетесь, потом будет еще больнее расходиться. Хотя, если риск неудачи продукта слишком большой, ввязываться в бюрократию/бумажки/юридические вопросы слишком рано тоже не круто и отнимет кучу времени.
- Не привлекайте инвестиции слишком рано, если можете протянуть сами хоть какое-то время. Потом вы будете стоить дороже, а процентом делиться меньшим.
- Не бойтесь меняться на ходу, MVP для того и есть, чтобы нащупать свою бизнес-модель. Есть много примеров, когда выстреливала не основная идея, а побочное ответвление продукта.
- И кстати сразу думайте, как будете отстраиваться от конкурентов.

Вообщем боюсь, вы все равно не послушаете часть советов. Если это ваш первый проект, все равно набьете шишек, чтобы к следующему проекту понять что "MVP за 5 дней" не такая уж и плохая идея :) Проходили, знаем.

UPD. И еще, ваши инструменты на первом этапе:
- Конструктор Landing Page
- Excel
- Mailchimp
- Перейдете к разработке, сразу ставьте что-то для управления тикетами. На первом этапе может быть что-то легковесное типа Trello.

P.S. если не секрет, в какой области идея?

Redmine - неплохая условно-бесплатная система управления проектами со своими недостатками. Активно пользовались ей на первом этапе, до выхода нашего приложения в лайв. В Redmine сильная база, но как kn0ckn0ck правильно сказал - она, к сожалению, уже давно практически не развивается. Многие фичи приходится допиливать под компанию, покупать платные плагины. Хотя для стандартных кейсов, при небольшом количестве сотрудников, вполне сойдет.

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

Речь же идет о сайте, верно? Хотя не так принципиально. Начните с контента: с того, какую информацию вы хотите разместить на своем сайте/проекте. От этого уже пойдет составление технического задания, оно же "ТЗ":
1) Структура страниц: что, где, на какой странице должно располагаться
2) Как будут выглядеть отдельные страницы блоки
3) Какой дополнительный функционал будет подключаться. Например, виджеты обратных звонков.
ну и т.д

Дальше в хорошей студии большую часть всего этого доработают за вас. Сначала вы заполните бриф, ответите на вопросы что и как хотите сделать. После этого менеджер по продукту со стороны студии задаст нужные вопросы по ТЗ и отдаст в работу.

Идеальный вариант, если вы сможете сами составить грубые недетализованные макеты того, как хотели бы видеть страницы своего проекта. Для этого есть довольно простые инструменты для прототипирования. Если даже сами макеты делать не будете, перед началом полномасштабной работы пусть дизайнер студии сделает это за вас. Когда ТЗ превращается в визуальную форму могут вылезти косяки самого ТЗ. Что-то не учли, забыли или вообще получается не очень.

Если бы я выбирал только из этих двух, то наверное взял бы Redmine, он мне всегда был ближе.

Плюсы:
- Open-source. Хотя это плюс, который одновременно и минус, но зато позволяет производить доработки.
- Относительно гибкий в настройках
- Достаточно понятный, хотя и устаревший интерфейс
- Расширение функционала плагинами

Минусы:
- Нужно разворачивать и сопровождать свой сервак. Для кого-то это проблема, так как нет специалистов. Мало того, это значительно нивелирует условную "бесплатность".
- На больших объемах данных, пользователей или количестве подключенных плагинов начинает существенно падать производительность.
- Как опенсорс, медленно разрабатывается, какие-то баги проще самим исправить, чем дождаться обновления.
- Scrum/Kanban борды, если это актуально, придется решать плагинами, а они далеко не все огонь.

Другие решения даже не рассматриваете?

Лучшего решения нет и волшебной таблетки не существует. Это я вам как разработчик решения для управления проектами и бизнес-процессами говорю.

Поэтому пробуйте разные программы и пытайтесь адаптировать под то, как вы видите работу команды. Найти сервисы можно например на Startpack.ru. Там есть из чего выбирать.

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