The post has been translated automatically. Original language: Russian
When you create a new technical system, it's easy to fall into the trap of developing the technology for several months or years first, and only then starting to look for those who need it. For complex engineering projects, this path is especially natural, because most of the attention is spent on architecture, code, testing, and bug fixing.
The problem is that technical complexity alone does not create a market. You can solve a really difficult task, but you can't find enough people or companies for whom this task is important enough.
Therefore, it is better to start searching for a market not after the development is completed, but in parallel with it.
Don't ask, "Do you need such a product?"
The easiest way to test an idea is to describe the product to a potential user and ask if they need it. In practice, such a question rarely provides a useful answer.
A person can say that an idea is interesting because they really find it interesting. But this does not mean that he will use the product, change his usual work process, or pay for a new solution.
For a new technology, it is more useful to start not with a product, but with an existing problem. It is necessary to understand how a person solves a problem today, what tools he uses, what does not suit him in this process, and how serious the consequences of mistakes are.
For example, in the case of SJV, the question "do you need a new formal verification language?" leads the conversation too early to our decision. It is much more useful to ask how the team checks complex hardware conditions today and what errors remain after routine testing.
This is how the conversation starts with the actual user experience, not with the assumptions of the product developer.
We are not looking for interest, but for existing behavior.
A strong sign of a problem is not a person's words that it is important, but the actions they are already taking to solve it.
If a team supports hundreds of tests, manually checks architectural constraints, uses several separate verification tools, and spends a lot of time searching for rare errors, then the problem already has a cost.
If a person says that a new technology looks useful, but today it does not solve this problem in any way and almost does not face its consequences, the probability of real demand is much lower.
Therefore, it is useful to look for workarounds. They are often better than any surveys at showing where there really is a need.
Sometimes the most interesting future user is the one who has already built his own inconvenient tool to solve the same problem.
It is important to understand the cost of a mistake
Not all technical issues are equally important. A developer may encounter an inconvenience on a regular basis, but if it takes five minutes per month, a separate product to fix it is unlikely to be particularly valuable.
A completely different situation occurs when an error leads to weeks of debugging, reassembly of hardware, delayed product release, or problems after implementation.
Therefore, when searching for a market, it is important to find out not only the frequency of the problem, but also its cost. How much time does the team lose? How many specialists are involved in the search for the cause? What happens if an error is detected too late?
This is especially important for formal verification. The very fact of the existence of errors is obvious, but the market appears where the cost of a certain class of errors is high enough for the team to be ready to change the development process.
It's better to start with a narrow task.
New technology often seems universal to its creator. SJV can theoretically be applied to different languages and different systems. Memora8 affects processor architecture, memory, hardware implementation, verification tools, and artificial intelligence.
But it's easier for the market to understand a solution that answers one specific question first.
For example, instead of the idea of a "universal system for formal verification of programs and hardware," we can explore a narrower task: checking state transitions and memory access rules in SystemVerilog projects.
If a persistent problem is found in such a segment, the direction can be expanded. If not, this is also a useful result: it is better to find out about it sooner than after creating a large universal system.
At the first stage, a narrow market is needed not because the technology must remain narrow forever. It allows you to more accurately verify its value.
Who to talk to
For technical development, it is especially important to choose the right first interlocutors. The user must know the problem well enough to talk about it using specific examples.
In the case of hardware verification tools, these may be digital circuit designers, verification specialists, processor architects, and heads of small engineering teams. Different people may have the same problem in different companies.
It is useful to talk with those who are already using existing formal verification tools, and with those who have deliberately abandoned them. The former can tell you about the shortcomings of current solutions, the latter — about the reasons why existing tools are not included in their development process.
Both types of conversation are important. Sometimes rejecting a competitor's product says as much about the market as using it.
A competitor is not necessarily a similar product.
When searching for a market, it is easy to limit yourself to comparing with other programs of the same class. But the user's actual alternatives are usually broader.
For SJV, the competitor may be the existing formal verification system. But it can also be a large set of tests, internal team rules, manual code analysis, or a decision not to check anything at all.
It is with these options that the new product should be better in the eyes of the user.
If the existing method takes a little time and gives an acceptable result, it doesn't make much sense for a person to master another tool. Even if the new product looks much more interesting technically.
So the question is, "What are our competitors?" it is useful to replace the question "what does the user do if our product does not exist?"
The answer often greatly changes the perception of the market.
The market can be searched through small experiments.
To test demand, it is not necessary to create a ready-made commercial product right away. This is especially important for complex technical systems, the development of which can take considerable time.
You can take a small real module and try to test it in a new way. You can ask the engineer to describe several important properties of an existing project. You can compare how much effort it takes to find the same error with regular tests and a new tool.
Such experiments provide significantly more information than demonstrating a long list of future possibilities.
The main thing is to understand in advance what exactly is being checked. For example, whether the error search time is shortened, whether it becomes easier to describe architectural limitations, or whether it is possible to detect a class of problems that has not been practically tested before.
Then each experiment gradually clarifies the possible market.
Publications also help to find a market.
Technical articles can be part of such a search. Good material shows a specific problem and solution, after which you can observe who reacts to it and what questions are asked.
If an article about memory ownership rules is of interest only to architecture researchers, this is one signal. If developers of industrial automation or microchips begin to respond to the material about checking states, this is another possible market.
Publications are not a substitute for direct communication with users, but they allow you to expand the circle of people who learn about your work. Sometimes it is through such material that the first person with a real similar task is found.
In addition, the preparation of the article forces the developer himself to explain the problem without the internal terms of the project. This is a useful test of the clarity of an idea.
What we are trying to understand for SJV
In the case of SJV, we still have no reason to consider the market found in advance. The technical ability to check complex states by itself does not mean that there is a strong enough need for a new tool.
Therefore, several questions are important now. What properties do hardware developers consider the most difficult to verify? What tools are they already using? What is inconvenient about these tools? In what situations are errors discovered too late?
Separately, you need to understand whether it is enough to start with SystemVerilog or whether users really need support for other languages. It is also better to find out through real projects, rather than adding features in advance.
The answers to such questions can be changed by SJV itself. Market search is not only a search for buyers for an already created technology, but also a way to understand which one it should be. become this technology.
And what to do with Memora8
Memora8 has a slightly different situation. It is not necessary to look for a market directly for a new processor here yet.
The project can help to discover more narrow technologies that have independent value. This may be a way to test hardware modules, a new model of working with memory, development tools, or an approach to collaboration between an engineer and artificial intelligence.
Therefore, Memora8 can be considered not only as a future product, but also as a source of testable technical hypotheses.
Sometimes the market is not where the creator of the project originally expected.
Technology and the market are developing together
In a technical project, the developer wants to find the right engineering solution first. But the correctness of the technology and its relevance are different issues.
One part can be verified by modeling, tests, formal methods, and hardware prototypes. The other is only through interaction with real people and existing development processes.
Therefore, the search for a market should not be perceived as a separate stage that begins after the completion of the technology. This is another type of research.
First, a hypothesis about a technical solution appears. Then a hypothesis about who it is especially useful for. After that, real projects and conversations either confirm the assumption or force a change of direction.
Such a result is normal for a new technology. It is much more dangerous to spend several years on the perfect solution to a problem that in the real world does not bother anyone enough to change their usual way of working for it.
Когда создаёшь новую техническую систему, легко попасть в ловушку: сначала несколько месяцев или лет развивать технологию, а уже потом начинать искать тех, кому она нужна. Для сложных инженерных проектов такой путь особенно естественен, потому что большая часть внимания уходит на архитектуру, код, испытания и исправление ошибок.
Проблема в том, что техническая сложность сама по себе не создаёт рынок. Можно решить действительно трудную задачу, но при этом не найти достаточного количества людей или компаний, для которых эта задача достаточно важна.
Поэтому поиск рынка лучше начинать не после завершения разработки, а параллельно с ней.
Не спрашивать: «Нужен ли вам такой продукт?»
Самый простой способ проверить идею — описать продукт потенциальному пользователю и спросить, нужен ли он. На практике такой вопрос редко даёт полезный ответ.
Человек может сказать, что идея интересная, потому что действительно считает её интересной. Но это ещё не означает, что он станет использовать продукт, менять привычный процесс работы или платить за новое решение.
Для новой технологии полезнее начинать не с продукта, а с существующей проблемы. Нужно понять, как человек решает задачу сегодня, какие инструменты использует, что в этом процессе его не устраивает и насколько серьёзны последствия ошибок.
Например, в случае SJV вопрос «нужен ли вам новый язык формальной проверки?» слишком рано переводит разговор к нашему решению. Гораздо полезнее спросить, как команда сегодня проверяет сложные состояния аппаратуры и какие ошибки остаются после обычного тестирования.
Так разговор начинается с реальной работы пользователя, а не с предположений разработчика продукта.
Ищем не интерес, а существующее поведение
Сильный признак проблемы — не слова человека о том, что она важна, а действия, которые он уже предпринимает для её решения.
Если команда поддерживает сотни тестов, вручную проверяет архитектурные ограничения, использует несколько отдельных средств проверки и тратит много времени на поиск редких ошибок, значит проблема уже имеет стоимость.
Если же человек говорит, что новая технология выглядит полезной, но сегодня никак не решает эту задачу и почти не сталкивается с её последствиями, вероятность реального спроса значительно ниже.
Поэтому полезно искать обходные решения. Они часто лучше любых опросов показывают, где действительно существует потребность.
Иногда самый интересный будущий пользователь — тот, кто уже построил собственный неудобный инструмент для решения той же проблемы.
Важно понимать цену ошибки
Не все технические проблемы одинаково важны. Разработчик может регулярно сталкиваться с неудобством, но если оно занимает пять минут в месяц, отдельный продукт для его устранения вряд ли будет особенно ценным.
Совсем другая ситуация возникает, когда ошибка приводит к неделям отладки, повторной сборке аппаратуры, задержке выпуска продукта или проблемам уже после внедрения.
Поэтому при поиске рынка важно выяснять не только частоту проблемы, но и её стоимость. Сколько времени команда теряет? Сколько специалистов участвует в поиске причины? Что происходит, если ошибку обнаруживают слишком поздно?
Для формальной проверки это особенно важно. Сам факт существования ошибок очевиден, но рынок появляется там, где стоимость определённого класса ошибок достаточно высока, чтобы команда была готова изменить процесс разработки.
Начинать лучше с узкой задачи
Новая технология часто кажется универсальной своему создателю. SJV теоретически можно применять к разным языкам и разным системам. Memora8 затрагивает архитектуру процессоров, память, аппаратную реализацию, средства проверки и работу искусственного интеллекта.
Но рынку проще понять решение, которое сначала отвечает на один конкретный вопрос.
Например, вместо идеи «универсальная система формальной проверки программ и аппаратуры» можно исследовать более узкую задачу: проверка переходов состояний и правил доступа к памяти в проектах на SystemVerilog.
Если в таком сегменте обнаружится устойчивая проблема, направление можно расширять. Если нет, это тоже полезный результат: лучше узнать об этом раньше, чем после создания большой универсальной системы.
Узкий рынок на первом этапе нужен не потому, что технология обязана навсегда остаться узкой. Он позволяет точнее проверить её ценность.
С кем разговаривать
Для технической разработки особенно важно правильно выбрать первых собеседников. Пользователь должен достаточно хорошо знать проблему, чтобы рассказать о ней на конкретных примерах.
В случае средства проверки аппаратуры это могут быть разработчики цифровых схем, специалисты по проверке, архитекторы процессоров и руководители небольших инженерных команд. В разных компаниях одна и та же проблема может находиться у разных людей.
Полезно разговаривать и с теми, кто уже использует существующие средства формальной проверки, и с теми, кто сознательно от них отказался. Первые могут рассказать о недостатках текущих решений, вторые — о причинах, по которым существующие инструменты не вошли в их процесс разработки.
Оба типа разговора важны. Иногда отказ от продукта конкурента говорит о рынке не меньше, чем его использование.
Конкурент — это не обязательно похожий продукт
При поиске рынка легко ограничиться сравнением с другими программами того же класса. Но реальные альтернативы пользователя обычно шире.
Для SJV конкурентом может быть существующая система формальной проверки. Но им также может быть большой набор тестов, внутренние правила команды, ручной анализ кода или решение вообще ничего дополнительно не проверять.
Именно с этими вариантами новый продукт должен быть лучше в глазах пользователя.
Если существующий способ занимает немного времени и даёт приемлемый результат, человеку нет особого смысла осваивать ещё один инструмент. Даже если технически новый продукт выглядит значительно интереснее.
Поэтому вопрос «какие у нас конкуренты?» полезно заменять вопросом «что пользователь делает, если нашего продукта не существует?»
Ответ часто сильно меняет представление о рынке.
Рынок можно искать через небольшие эксперименты
Для проверки спроса необязательно сразу создавать готовый коммерческий продукт. Особенно это важно для сложных технических систем, разработка которых может занимать значительное время.
Можно взять небольшой реальный модуль и попробовать проверить его новым способом. Можно предложить инженеру описать несколько важных свойств существующего проекта. Можно сравнить, сколько усилий требуется для поиска одной и той же ошибки обычными тестами и новым инструментом.
Такие эксперименты дают значительно больше информации, чем демонстрация длинного списка будущих возможностей.
Главное — заранее понимать, что именно проверяется. Например, сокращается ли время поиска ошибки, становится ли проще описывать архитектурные ограничения или удаётся обнаружить класс проблем, который раньше практически не проверялся.
Тогда каждый эксперимент постепенно уточняет возможный рынок.
Публикации тоже помогают искать рынок
Технические статьи могут быть частью такого поиска. Хороший материал показывает конкретную проблему и решение, после чего можно наблюдать, кто на него реагирует и какие вопросы задаёт.
Если статья о правилах владения памятью вызывает интерес только у исследователей архитектур, это один сигнал. Если на материал о проверке состояний начинают откликаться разработчики промышленной автоматики или микросхем, это уже другой возможный рынок.
Публикации не заменяют прямого общения с пользователями, но позволяют расширить круг людей, которые узнают о работе. Иногда именно через такой материал находится первый человек с реальной похожей задачей.
Кроме того, подготовка статьи заставляет самого разработчика объяснить проблему без внутренних терминов проекта. Это полезная проверка ясности идеи.
Что мы пытаемся понять для SJV
В случае SJV у нас пока нет оснований заранее считать рынок найденным. Техническая возможность проверки сложных состояний сама по себе ещё не означает, что существует достаточно сильная потребность в новом инструменте.
Поэтому сейчас важны несколько вопросов. Какие свойства разработчики аппаратуры считают наиболее сложными для проверки? Какие средства они уже используют? Что в этих средствах неудобно? В каких ситуациях ошибки обнаруживаются слишком поздно?
Отдельно нужно понять, достаточно ли начать с SystemVerilog или пользователям действительно требуется поддержка других языков. Это тоже лучше выяснять через реальные проекты, а не добавлять возможности заранее.
Ответы на такие вопросы могут изменить и сам SJV. Поиск рынка — это не только поиск покупателей для уже созданной технологии, но и способ понять, какой именно должна стать эта технология.
А что делать с Memora8
У Memora8 ситуация немного другая. Здесь пока не обязательно искать рынок непосредственно для нового процессора.
Проект может помочь обнаружить более узкие технологии, которые имеют самостоятельную ценность. Это может быть способ проверки аппаратных модулей, новая модель работы с памятью, инструменты разработки или подход к совместной работе инженера и искусственного интеллекта.
Поэтому Memora8 можно рассматривать не только как будущий продукт, но и как источник проверяемых технических гипотез.
Иногда рынок находится не там, где первоначально ожидал создатель проекта.
Технология и рынок развиваются вместе
В техническом проекте разработчику хочется сначала найти правильное инженерное решение. Но правильность технологии и её востребованность — разные вопросы.
Одну часть можно проверять моделированием, тестами, формальными методами и аппаратными прототипами. Другую — только взаимодействием с реальными людьми и существующими процессами разработки.
Поэтому поиск рынка не стоит воспринимать как отдельный этап, который начинается после завершения технологии. Это ещё один вид исследования.
Сначала появляется гипотеза о техническом решении. Затем гипотеза о том, для кого оно особенно полезно. После этого реальные проекты и разговоры либо подтверждают предположение, либо заставляют изменить направление.
Для новой технологии такой результат нормален. Намного опаснее потратить несколько лет на идеальное решение проблемы, которая в реальном мире никого не беспокоит настолько, чтобы менять ради неё привычный способ работы.
Share
