The post has been translated automatically. Original language: Russian
In many technical projects, it's not the product that appears first, but the internal tool. It is created to solve its own problem, gradually becomes more useful, overgrown with opportunities, and at some point the question arises: is it worth turning it into an independent product?
With SJV, we came to something like this situation. Initially, it was needed as part of a broader development — to check states and transitions in Memora8 and other system components. But if the tool begins to solve a separate understandable task, the following question naturally arises: is it necessary only for us or can it be useful to other developers?
The answer to this question cannot be obtained solely from the technical architecture. Here you already need to look at the actual usage.
An internal tool and a product are not the same thing.
An internal tool can be very useful and at the same time completely unsuitable for external users. It is created by people who know the project well, understand all the conventions and are willing to put up with inconveniences.
This is not enough for a single product.
It should be clear to an external user why the tool is needed, what problem it solves, and how to start using it. He should not need to know the entire history of the project or the internal structure of Memora8.
If SJV is useful only together with a set of our own conventions, it is rather part of an internal system. If the developer can take it separately, connect it to his project and get an understandable benefit, the situation is already different.
The first sign is an independent problem.
A technology has a chance to become a separate product when it solves a problem that exists independently of the project in which it appeared.
For example, Memora8 needs to check states, transitions, and memory access rules. But there are similar tasks in other projects: digital devices, controllers, processors, control systems.
If developers of such systems face the same problem, then SJV potentially solves a broader problem.
It is the presence of an independent problem that is important. It is not enough to say: "our tool knows how to formally check the system." You need to understand at what point the developer feels the need for it.
For example, a team may regularly encounter errors in state transitions that are difficult to reproduce with tests. This is a specific problem around which you can build a separate product.
The second feature is that the tool can be separated from the original project.
A good test is to imagine that Memora8 will disappear tomorrow. Will SJV remain useful?
If the tool makes no sense without Memora8, then it's still part of a larger development. If it can be applied to an independent project on SystemVerilog and get a result, this is already a sign of independence.
To do this, you have to separate the general parts from the specific ones.
Internal names, assumptions about the structure of the project, special rules of Memora8 and other details should not be mandatory for SJV work. The user must describe their module, their properties, and get the verification result.
The less a tool depends on a specific project, the easier it is to consider it as a separate product.
The third sign is that an external user appears
The strongest signal is not our reasoning, but the actual use by someone else.
While SJV is used only by ourselves, we can only assume how understandable and useful it is to others. The first external user will almost certainly find problems that cannot be seen inside the team.
It may turn out that the installation is too complicated, the language is unclear, the error messages are not informative enough, or the verification model itself does not correspond to the usual work process.
This is useful information.
If several independent developers are willing to spend time on a tool and come back to it again, this proves its value much more strongly than any internal list of features.
The fourth sign is that there is an understandable reason to switch to a new tool.
A new product is always competing with what a person is doing today.
The developer is already writing tests, using an existing formal verification tool, checking the code manually, or simply accepting a certain level of risk. In order for him to start using SJV, there must be a good enough reason to change the usual process.
This may be due to a simpler description of properties, convenient verification of states, saving verification results, or the ability to apply the same approach to multiple components.
But this reason must be confirmed by the users.
If a person says, "this is interesting," but continues to do everything as before, the product has not yet become valuable enough. If he replaces part of the existing process with a new tool, this is a much more important signal.
Not every useful technology should become a product.
Sometimes it's better to keep a good internal tool internal.
A single product requires documentation, installation, backward compatibility, error handling, user support, and many other things that are almost unrelated to the main technical idea.
If a tool is needed only by a small group of developers within a single project, turning it into a product may simply be a waste of resources.
Therefore, the question should not be: "can we sell SJVS?" Technically, almost any tool can be packed and put outside.
A more useful question is, "Are there enough people for whom the problem is so important that they are willing to regularly use a separate tool to solve it?"
If there is no answer yet, there is no need to rush.
A single product must have its own value.
There is another simple test. Is it possible to explain SJV without mentioning Memora8 or Sekura JS at all?
For example: SJV allows you to separately describe the acceptable states and transitions of the system and verify that the implementation on SystemVerilog does not violate these rules.
If such a description is clear and useful in itself, the technology has its own value.
If you have to tell the whole story of our projects for a long time so that a person understands why a tool is needed, then the boundaries of the product are not yet clearly defined.
This applies not only to the description on the website. The product itself should also have its own completed work cycle: connect the project, set properties, perform verification, and get a clear result.
Narrow product first
If SJV becomes a separate product, I would not start by trying to make a universal tool for all languages and all types of programs.
It is much more practical to choose a narrow task. For example, checking states and transitions in projects on SystemVerilog.
This makes it easier to understand the user, the product requirements, and the actual limitations. You can see which properties people really want to check and what prevents them from using existing tools.
If this scenario works, the product can be expanded gradually.
If you immediately try to cover Verilog, SystemVerilog, C, C++, Rust and other languages, development will quickly become too big, and the main question is whether a new tool is needed at all — and will remain unanswered.
A free tool can also be a product.
An independent product does not necessarily immediately mean a paid service.
For a technical audience, the first step may be an open source tool, a local program, or a free version with a limited set of features. The goal of this stage is not to maximize revenue, but to make real use of it.
We need to see if the developers can install SJV on their own, apply it to their project and get the result without our constant participation.
This is especially important for the developer's tool. If each user needs a personal explanation of the architecture and help with the first launch, it will be difficult to scale such a product.
Therefore, independence of use is one of the important signs of maturity.
When can I think about a commercial model?
Talking about price makes sense after the appearance of a repeatable value.
If teams regularly use SJV, save the test results and include it in their development process, you can see exactly what they are willing to pay for.
For some, the value may be working with large projects. For another, it's team collaboration, verification history, support for multiple languages, or use within a closed infrastructure.
It is not necessary to guess the ideal payment model in advance. It is much more important to first understand which part of the product is really becoming necessary in work.
The price should appear around the proven value, not around the number of features implemented.
What does this mean for SJV now
At the current stage, SJV can already be considered as a separate technical system. It has its own language for describing properties, a verification mechanism, and a stored result.
But this is still not enough to claim that there is a separate market.
The next important step is to apply it to other people's projects. We need to understand whether developers who are not related to Memora8 can use the same approach for their modules and gain significant benefits.
If this happens, it will become much clearer which parts of SJV should be developed as an independent product, and which remain features of our internal development.
If it turns out that the tool is particularly useful only within a larger system, this is also a normal result. Not every technology has to turn into a separate company or a separate service.
The product does not start with the packaging
A technology doesn't become a product when it has a website, a name, and pricing plans. This happens when it has its own task, its own user, and its own value.
Therefore, the main question for SJV is not whether it is technically advanced enough. It is more important to understand whether there is a person outside of our projects who is facing this problem, sees SJV as a more convenient way to solve it and is ready to use it regularly.
If such users appear, the boundaries of the product will gradually become more obvious.
Until then, it's more useful to continue testing the technology on real-world tasks and not confuse technical completeness with market availability.
Во многих технических проектах сначала появляется не продукт, а внутренний инструмент. Он создаётся для решения собственной задачи, постепенно становится полезнее, обрастает возможностями и в какой-то момент возникает вопрос: стоит ли превращать его в самостоятельный продукт?
С SJV мы пришли примерно к такой ситуации. Изначально он нужен был как часть более широкой разработки — для проверки состояний и переходов в Memora8 и других компонентах системы. Но если инструмент начинает решать отдельную понятную задачу, естественно возникает следующий вопрос: нужен ли он только нам или может быть полезен другим разработчикам?
Ответ на него нельзя получить только из технической архитектуры. Здесь уже нужно смотреть на реальное использование.
Внутренний инструмент и продукт — не одно и то же
Внутренний инструмент может быть очень полезным и при этом совершенно не подходить для внешних пользователей. Его создают люди, которые хорошо знают проект, понимают все условности и готовы мириться с неудобствами.
Для отдельного продукта этого недостаточно.
Внешнему пользователю должно быть понятно, зачем инструмент нужен, какую проблему он решает и как начать им пользоваться. Ему не должны требоваться знания всей истории проекта или внутреннего устройства Memora8.
Если SJV полезен только вместе с набором наших собственных соглашений, это скорее часть внутренней системы. Если же разработчик может взять его отдельно, подключить к своему проекту и получить понятную пользу, ситуация уже другая.
Первый признак — самостоятельная проблема
Технология имеет шанс стать отдельным продуктом, когда она решает проблему, существующую независимо от проекта, в котором появилась.
Например, Memora8 нуждается в проверке состояний, переходов и правил доступа к памяти. Но похожие задачи есть и в других проектах: цифровых устройствах, контроллерах, процессорах, системах управления.
Если разработчики таких систем сталкиваются с той же проблемой, значит SJV потенциально решает более широкую задачу.
Важно именно наличие самостоятельной проблемы. Недостаточно сказать: «наш инструмент умеет формально проверять систему». Нужно понимать, в какой момент разработчик чувствует необходимость в нём.
Например, команда может регулярно сталкиваться с ошибками в переходах состояний, которые трудно воспроизвести тестами. Это уже конкретная проблема, вокруг которой можно строить отдельный продукт.
Второй признак — инструмент можно отделить от исходного проекта
Хорошая проверка — представить, что Memora8 завтра исчезнет. Останется ли SJV полезным?
Если без Memora8 инструмент теряет смысл, значит пока это часть более крупной разработки. Если же его можно применить к независимому проекту на SystemVerilog и получить результат, это уже признак самостоятельности.
Для этого приходится отделять общие части от специфических.
Внутренние названия, предположения о структуре проекта, особые правила Memora8 и другие детали не должны быть обязательными для работы SJV. Пользователь должен описать свой модуль, свои свойства и получить результат проверки.
Чем меньше инструмент зависит от конкретного проекта, тем легче рассматривать его как отдельный продукт.
Третий признак — появляется внешний пользователь
Самый сильный сигнал — не наши рассуждения, а реальное использование кем-то ещё.
Пока SJV применяем только мы сами, можно лишь предполагать, насколько он понятен и полезен другим. Первый внешний пользователь почти наверняка обнаружит проблемы, которые невозможно увидеть внутри команды.
Может оказаться, что установка слишком сложная, язык непонятен, сообщения об ошибках недостаточно информативны или сама модель проверки не соответствует привычному процессу работы.
Это полезная информация.
Если несколько независимых разработчиков готовы потратить время на инструмент и возвращаются к нему повторно, это намного сильнее подтверждает его ценность, чем любой внутренний список возможностей.
Четвёртый признак — есть понятная причина перейти на новый инструмент
Новый продукт всегда конкурирует с тем, что человек делает сегодня.
Разработчик уже пишет тесты, использует существующее средство формальной проверки, проверяет код вручную или просто принимает определённый уровень риска. Чтобы он начал использовать SJV, должна быть достаточно веская причина изменить привычный процесс.
Такой причиной может быть более простое описание свойств, удобная проверка состояний, сохранение результатов проверки или возможность применять один подход к нескольким компонентам.
Но эту причину должны подтвердить пользователи.
Если человек говорит: «это интересно», но продолжает делать всё как раньше, продукт пока не стал достаточно ценным. Если же он заменяет часть существующего процесса новым инструментом, это намного более важный сигнал.
Не всякая полезная технология должна становиться продуктом
Иногда хороший внутренний инструмент лучше оставить внутренним.
Отдельный продукт требует документации, установки, обратной совместимости, обработки ошибок, поддержки пользователей и множества других вещей, которые почти не связаны с основной технической идеей.
Если инструмент нужен только небольшой группе разработчиков внутри одного проекта, превращение его в продукт может просто отвлекать ресурсы.
Поэтому вопрос должен звучать не так: «можем ли мы продавать SJV?» Технически почти любой инструмент можно упаковать и выставить наружу.
Более полезный вопрос: «есть ли достаточно людей, для которых проблема настолько важна, что они готовы регулярно использовать отдельный инструмент для её решения?»
Если ответа пока нет, нет необходимости спешить.
Отдельный продукт должен иметь собственную ценность
Есть ещё один простой тест. Можно ли объяснить SJV, вообще не упоминая Memora8 или Sekura JS?
Например: SJV позволяет отдельно описывать допустимые состояния и переходы системы и проверять, что реализация на SystemVerilog не нарушает эти правила.
Если такое описание понятно и полезно само по себе, у технологии есть собственная ценность.
Если же приходится долго рассказывать всю историю наших проектов, чтобы человек понял, зачем нужен инструмент, значит границы продукта пока определены недостаточно ясно.
Это касается не только описания на сайте. Сам продукт тоже должен иметь собственный законченный цикл работы: подключить проект, задать свойства, выполнить проверку, получить понятный результат.
Сначала узкий продукт
Если SJV станет отдельным продуктом, я бы не начинал с попытки сделать универсальное средство для всех языков и всех видов программ.
Гораздо практичнее выбрать узкую задачу. Например, проверка состояний и переходов в проектах на SystemVerilog.
Так проще понять пользователя, требования к продукту и реальные ограничения. Можно увидеть, какие свойства люди действительно хотят проверять и что мешает им пользоваться существующими средствами.
Если этот сценарий работает, продукт можно постепенно расширять.
Если же сразу пытаться охватить Verilog, SystemVerilog, C, C++, Rust и другие языки, разработка быстро станет слишком большой, а главный вопрос — нужен ли вообще новый инструмент — так и останется без ответа.
Бесплатный инструмент тоже может быть продуктом
Самостоятельный продукт не обязательно сразу означает платный сервис.
Для технической аудитории первым этапом может быть открытый инструмент, локальная программа или бесплатная версия с ограниченным набором возможностей. Цель такого этапа — не максимальная выручка, а реальное использование.
Нужно увидеть, смогут ли разработчики самостоятельно установить SJV, применить его к своему проекту и получить результат без нашего постоянного участия.
Это особенно важно для инструмента разработчика. Если каждому пользователю требуется личное объяснение архитектуры и помощь с первым запуском, масштабировать такой продукт будет трудно.
Поэтому самостоятельность использования — один из важных признаков зрелости.
Когда можно думать о коммерческой модели
Разговор о цене имеет смысл после появления повторяемой ценности.
Если команды регулярно используют SJV, сохраняют результаты проверки и включают его в свой процесс разработки, можно смотреть, за что именно они готовы платить.
Для кого-то ценностью может быть работа с большими проектами. Для другого — совместная работа команды, история проверок, поддержка нескольких языков или использование внутри закрытой инфраструктуры.
Необязательно заранее угадывать идеальную модель оплаты. Гораздо важнее сначала понять, какая часть продукта действительно становится необходимой в работе.
Цена должна появляться вокруг подтверждённой ценности, а не вокруг количества реализованных функций.
Что это означает для SJV сейчас
На текущем этапе SJV уже можно рассматривать как отдельную техническую систему. У него есть собственный язык описания свойств, механизм проверки и сохраняемый результат.
Но этого ещё недостаточно, чтобы утверждать, что существует отдельный рынок.
Следующий важный этап — применение к чужим проектам. Нужно понять, смогут ли разработчики, не связанные с Memora8, использовать тот же подход для своих модулей и получить заметную пользу.
Если это произойдёт, станет намного понятнее, какие части SJV должны развиваться как самостоятельный продукт, а какие остаются особенностями нашей внутренней разработки.
Если же окажется, что инструмент особенно полезен только внутри более крупной системы, это тоже нормальный результат. Не каждая технология обязана превращаться в отдельную компанию или отдельный сервис.
Продукт начинается не с упаковки
Технология становится продуктом не тогда, когда у неё появился сайт, название и тарифы. Это происходит тогда, когда у неё появляется собственная задача, собственный пользователь и самостоятельная ценность.
Для SJV главный вопрос поэтому не в том, достаточно ли он технически развит. Важнее понять, существует ли человек за пределами наших проектов, который сталкивается с этой проблемой, видит в SJV более удобный способ её решения и готов использовать его регулярно.
Если такие пользователи появятся, границы продукта постепенно станут очевиднее.
А до этого полезнее продолжать проверять технологию на реальных задачах и не путать техническую завершённость с наличием рынка.
Share
