I don't really know much about GTM, and I usually just hear people talk about it occasionally.
We often talk about physical intelligence, focusing more on models, data, hardware and algorithms, and rarely looking at the industry from a GTM perspective. The article provides a slightly different starting point: what are the issues that a technology is moving from a lab to a real business in the middle? How do customers understand the value of technology and how should the team build trust?
Of course, the article presents more of the ideal side of the job. The connection between technology, products, customers and business sounds attractive, but the actual work is far from as simple. Especially in the early teams, many tasks do not have clear boundaries, both to understand technology and to understand customers and to be responsible for business outcomes.
Therefore, the recommendation of this article is not to discuss whether GTM is a worthwhile direction to take, but rather that it is necessary for tech classmates who are physically intelligent to change their perspective on the world outside of technology from time to time.
Here is the correct spelling.
Working in the field of Physical AI has helped me to understand how to find clients, build trust in technology, and bring robotics to market.
Over the past few months, more and more people have begun to ask me the same question: How exactly should the robotics industry do GTM?
Sometimes the questioners are working in sales, growth or business collaboration, hoping to move into the robotics and physical AI industries; sometimes they're looking for entrepreneurs who have their first customers, who have done impressive technological achievements, but don't know how to turn them into business opportunities; and sometimes they're just wondering how a robotics company moves from a surprising demo on X to a product that's actually used by their customers and willing to pay for it.
For a while, it was hard for me to give a simple answer. The longer I worked in the robotics industry, the more I realized why: the industry doesn't actually have a mature, unified GTM methodology yet.
Technology is evolving at an astonishing rate. New market categories are emerging around Robot Learning, Simulation, Teleoperation, Data, Evaluation, Foundation Models, Developer Infrastructure, World Models and Deployment Tooling.
At the same time, robotics companies are faced with challenges that software companies do not have to face completely: the physical world. Hardware must work in a truly reliable way, models must be able to run outside of controlled environments, and systems must be integrated with existing business processes.
From engineering breakthroughs to real deployments, someone in the middle always needs to solve a problem: how to turn these technological capabilities into a business?
After working on Simulation, Robot Data, Developer Ecosystems, Robotics Platforms, Hardware, Partnerships, Outbound, Content and Early Customer Search, I began to understand the GTM of the robotics industry in a different way - far more than just sales, marketing, cold emails, or posting some amazing robot videos online.
In my opinion, the core of GTM in the robotics industry is the transformation of technical uncertainty into business trust.
Customers initially ask a series of questions: Is this technology really effective? Is it suitable for our robots and tasks? Is it integrated into existing workflows? Is it worth investing in engineering resources and funds?
A good GTM should answer these questions one by one so that customers can gradually move from being interested in a particular technology to being confident in adopting it.
This is exactly what I want to explore in this article and some of the insights I have gained from working in this industry.
GTM is much more than just selling
GTM is usually defined as the strategy by which a company pushes its product to its customers. This definition is not wrong, but it is not complete for an early robot company.
In real work, GTM in the robotics industry may mean communicating with robotics researchers to confirm whether or not the problem you think exists actually exists; it may also mean researching a company's technical background to determine whether it is likely to become a customer; or working with an engineer to determine what kind of technical evidence potential customers need to see.
It may also involve finding the first design partners who can provide valuable feedback, designing pilots, producing technology demos, writing outbound information, exploring customer needs, and connecting with researchers and entrepreneurs.
In addition, there is a need to translate engineering results into content so that more people understand why this technology is important.
Depending on the stage of the company's development, you may need to take on several of these tasks simultaneously. Sometimes you're doing sales, sometimes you're doing research or content creation, and sometimes you need to help the team adjust the product itself based on market feedback.
This is also where I think the robotics industry is very interesting. Especially in early startups where products and markets are still evolving together, the boundaries between engineering, products, sales, business collaboration, content and customer success can be very blurred.
This also means that GTM strategies in different robotic segments may be completely different.
There is no unified GTM model for the robotics industry
One of the first things I realized was that it makes little sense to simply sell products to a robot company because the industry includes businesses that have completely different customers, products and commercial challenges.
Selling autonomous robots to warehouses is a completely different business model than selling the Robot Foundation Model. Simulation Platform's purchasers and technical requirements are not the same as Teleoperation Data.
Humanoid Robotics startups, Manipulation Companies, Observability Platforms, and robotic developer ecosystems are all part of the broader robotics industry, but they may have different users, budgets, sales cycles, and product adoption motivations.
Physical AI is expanding to include Foundation Models, Autonomy, Simulation, Robot Learning, Data Infrastructure, Observability, Hardware and Deployment Tooling.
Understanding a company's position in the entire technology landscape is crucial because it determines who really faces the problem it is trying to solve, who might pay for the solution, and what evidence customers need to see before making a decision.
So I'm no longer asking the question of what kind of robot companies we should be selling products to, but I'm starting to ask a more valuable question:
What is the bottleneck we are really solving?
This seems like a very small difference, but it will change almost everything that happens afterwards, including how to define the Ideal Customer Profile (ICP), how to write outbound information, and how to communicate with customers.
Selling bottles, not the concept of selling
Most customers don't wake up every morning thinking they need more Physical AI Infrastructure. They are faced with a specific problem that is slowing progress or hindering them from achieving an important goal.
For one team, collecting enough effective robot data can be expensive and time-consuming. Another team may have accumulated large amounts of Teleoperation Data without knowing how to organize it into data for training or evaluation.
Some teams also found that under changing deployment conditions, assessing robotic strategies requires investing too many engineering resources; or that robots perform well in a given environment, but performance drops significantly once the scenario changes.
Other companies may be facing problems such as system integration difficulties, failure to reproduce, high deployment costs, or the inability to economically justify automation in a specific application scenario.
These are different issues that require different GTM approaches.
Describing a company as a Physical AI Infrastructure Platform may explain which market category you belong to, but it may not necessarily explain why customers should care about you.
This is particularly important in the robotics industry, as technology itself is often so exciting that it's easy to focus on what the system can do rather than what value it can bring.
A company's technology can be very good, but customers are usually only concerned with one more practical issue:
What can this technology do for me that I can't do now?
The shift from describing technology to understanding the real value that technology can bring is one of the biggest thinking shifts I've made when I'm working on robot GTM. Once you understand the bottlenecks that customers face, it's much easier to find the right customers.
ICP should be based on signals, not corporate logos.
Building an impressive list of potential customers is quite easy, but that doesn't mean you're actually building a valuable ICP.
You can find a large robotics company, a well-funded Humanoid startup, a well-known Autonomy team, or a well-known research lab.
Suddenly, you seem to have found a good group of potential customers.
But a well-known company doesn't mean it's the right customer.
I am now more concerned with the signals that can indicate that an organization is indeed facing a targeted problem.
For example, a company may be deploying robots in a new environment, hiring a Simulation Engineer, expanding its Robot Learning team, collecting Teleoperation Data, or starting to experiment with new Manipulation tasks.
Other signals may come from technical papers, engineering blogs, recruitment information, product announcements, or public discussions about Evaluation, Generalization and Deployment.
Sometimes the infrastructure that a company is building internally may overlap with the problems your product solves. This can also be a very valuable starting point for further research into the company.
Of course, none of these signals can directly prove that a company really needs your product.
Instead of judging a company as a good customer just because it's in the robotics industry, it's better to look for evidence to determine whether a specific team is facing a problem that your technology can solve.
This will be much more effective because when you enter a conversation, you are asking a question that is based on research, rather than a general product marketing.
This also makes Outbound more than just a tool for booking customer meetings.
Outbound can also be a market research.
Outbound is often viewed as a market-driven activity. Searching for potential customers, writing information, booking meetings, introducing products, and repeating it over and over again.
In a mature market where the needs of both buyers and customers are already quite clear in one product category, this approach may make perfect sense.
But in the emerging technology market, I think Outbound has another important role to play:
It can be used as a market research tool.
Every customer exchange is an opportunity to learn.
Gradually, you'll find out which issues trigger customer responses, which expressions are more likely to cause resonance, which product capabilities are overlooked, and which technical issues are repeatedly raised.
You'll also find out which positions are able to immediately understand the problem, which organizations really have the urgency to adopt a product, and which companies find the technology interesting but don't think it's important enough to be used.
You'll also find out which teams have already developed similar schemes internally, which alternatives they're considering, and which assumptions you're making when you're studying potential customers are actually completely wrong.
As the number of exchanges increases, these conversations will gradually reveal certain rules.
GTM campaigns begin to help you understand the market itself, and this information can be used to adjust product positioning, customer imagery, communication patterns, and even product roadmaps.
Therefore, I don't think that GTM, an early robot company, should always behave like it's actively selling products.
Sometimes the most important question you should ask customers is not whether they want to see our products.
So how do you deal with this issue now?
These answers may be more valuable than the conference itself, especially when you're not sure which market your technology is right for.
Of course, as long as you are willing to communicate with your customers with curiosity, rather than assuming that you fully understand their problems.
Don't create pain points for customers
This is one of my strongest principles when it comes to reaching technical customers.
Personalized communication is important, preliminary research is important, and assumptions are important.
But it's easy to lose trust if you just browse the other person's website or LinkedIn homepage and pretend to know what's going on inside them.
For example, there is a clear distinction between the following two expressions:
One: Oh, I know Simulation is slowing down your deployment.
Second, considering the environment you're deploying, I'm curious if testing across different conditions has become a challenge for the team.
The first expression anticipates a problem that you may not have verified at all.
The second expression indicates that you have done some research and are able to ask relevant questions while also leaving room for others to explain their real situation.
The robot industry's audience usually has a strong technical background. Many of the people you connect with may have a much better understanding of their systems than you do.
If you exaggerate product capabilities, misunderstand workflows, or create problems that don't exist, you will soon lose your technical credibility.
Instead of a message that sounds highly personal but is actually based on false assumptions, I'd rather send a less subtle but completely accurate message.
The same principle applies to the description of the product itself, especially when the technology is still in the development stage.
In the robotics industry, evidence surpasses product positioning
This is one of the most important lessons I have learned since working in this industry.
You can describe companies as accelerating the development of physical intelligence, releasing the potential for scalable Physical AI, or building a layer of intelligent robotics infrastructure.
These expressions may sound attractive, but they do not answer the most important questions of a technical customer:
Can it really work?
The physical world has unusually high requirements for technical verification.
A well-designed product landing page does not prove that robots can run reliably in warehouses. An excellent publicity slogan does not prove that a strategy can adapt to different environmental conditions. A well-designed presentation does not prove that simulations can accurately reproduce real-world factors that are really important in specific tasks.
In the end, you have to show technology in a way that customers can understand and evaluate.
If you're selling Simulation, show the simulation system and explain what it can do.
If you are selling Robot Data Infrastructure, show how the data is represented and how it is actually used.
If you're selling Evaluation Tooling, show the evaluation process and what it measures.
If you're selling Teleoperation Infrastructure, you're showing real workflows.
If you're selling robots, show that robots are doing meaningful work under conditions that are clearly described.
If you have a Benchmark, explain what it measures and what it does not measure.
If a capability is still in the experimental stage, make it clear. If a capability is validated only in a specific environment, explain the scope of the validation, rather than imply that it can work in all environments.
The reliability of technology will accumulate over time, but the damage caused by overcommitment will also accumulate.
In an industry where a client is usually an engineer and a researcher, being precise about what you have proven can be much more valuable than describing a product that is actually mature.
To be frank about limitations is to enhance GTM.
This may be somewhat contrary to traditional marketing practices, as traditional marketing usually seeks to present the most perfect side of the product.
But for emerging technologies, the robotics industry has rarely been able to provide a seamless story.
A system may be able to complete three tasks but not ten. A simulation system may be able to replicate certain dynamics well but perform poorly in other respects. A strategy may have good generalization capabilities under a set of conditions, but will fail when the environment changes.
Robots may be able to complete tasks successfully most of the time, but there are still failures that need to be understood and addressed.
People's instinctive response may be to hide these limitations, but I think it might be a mistake for a tech-savvy customer.
Engineers, researchers, CTOs and Autonomy leaders know how difficult robotics can be. They don't expect a perfect system.
What they really want to judge is whether they can trust this technology, the team that developed it, and the technical evidence that each other provides.
In addition, technical customers typically spend a significant amount of time independently researching products before communicating with suppliers.
They want to see demos, technical documentation, benchmarks, architectural details, and explanations from people who really understand technology.
Sometimes the most compelling message you can convey is:
Well, that's part of what we've already verified and that's part of what hasn't been verified.
This may not sound as impressive as a lavish marketing campaign, but it gives customers a clearer understanding of exactly what they're evaluating.
At the same time, it also creates opportunities to transform real engineering progress into valuable content.
Content is part of the GTM system
One of the things that interests me most about the robotics industry is the very close link between technical content and business activity.
A good Demo can answer the question in advance before a potential customer asks.
A technical article can establish a company's technical credibility before salespeople send outbound information.
A founder's explanation of an engineering problem may appeal to those who are facing the same problem; while a Benchmark, deploying video or case analysis of failures, can also be a very useful material for future customer interactions.
So I don't think that in early robotic companies, Content and Sales should run as two completely independent systems.
Technical customers are increasingly inclined to do their own product research before interacting with sales teams. Videos, technical demos, documentation, and engineering interpretations affect how they evaluate a foreign technology.
The robotics industry has a natural advantage in terms of visual content, as many of the jobs themselves are very suitable for video presentation.
People want to see how robots move, how they interact with objects, how they work in real environments, and how the system responds when the environment changes. They also want to see what happens when a mission fails and whether the system can recover from failure.
Sometimes a short video can convey a message that requires several words to explain clearly.
But there's an important difference: content that looks surprising is not the same thing as content that really helps people understand technology.
The best robot technology content should not only show that a robot has completed an operation, but should also explain why the action makes sense, what problems it solves, and what the experimental results actually prove.
This distinction is even more important when content is used to build the trust of potential customers.
Demo and technical evidence are not the same thing.
A robot that successfully completes a task can be a very attractive demo, but that doesn't mean it provides enough information to allow others to evaluate the technology behind it.
A valuable technical verification material should be able to answer a specific technical question.
For example, it can show:
- How can a task be done steadily and repeatedly?
- When an object or environment changes, what does the system do?
- How is success defined and measured?
- What inputs did the system receive?
- Are humans involved in the execution process?
It can also record failures, recovery behaviours, and the conditions under which experimental results are achieved.
What specific information needs to be provided depends on the product itself and what the customer needs to evaluate.
It is to this specific extent that technological progress can truly be transformed into commercial evidence.
This also brings an interesting responsibility to the GTM team.
If multiple prospective customers independently raise the same technical issue, it doesn't have to be just a sales pitch, but it can also mean that the engineering team should create a demo, benchmark, experiment or technical explanation that specifically answers that question.
When this exchange of information is returned to the engineering team, GTM can help identify which technical verification materials the market needs the most.
The engineering team then provides verified results, while the GTM team is responsible for delivering the results to people who really need to know about them.
This feedback loop is especially valuable when companies start working with Design Partners and early customers.
Design Partner, POC and Pilot solved different problems
Design Partnership, Proof of Concept (POC) and Pilot are often seen as interchangeable concepts, but I think it's necessary to distinguish them because the three have different tasks.
Design Partner helps you understand customer issues and adapt your products around practical application scenarios.
POCs typically focus on addressing specific technical uncertainties.
Pilot tests a product that is already mature in a relevant customer environment or workflow, and ideally there should be a path to business decision making.
For early robotic startups, the high-quality feedback and learning opportunities provided by Design Partner may be more important than the immediate revenue it can generate.
The best early partners aren't necessarily the largest companies, and Logo isn't necessarily the best known.
It may be a smaller organization, but it does face the problems you're trying to solve, has a strong enough willingness to collaborate, a willingness to invest time in technical leaders, and its application scenario is close enough to the market you ultimately want to serve.
Pilot requires more rigorous planning, as it can consume large amounts of engineering resources.
Before launching, it must be clear:
- What is the specific evaluation?
- What responsibilities do the two sides each have?
- How long did the collaboration last?
- How to measure success?
- If Pilot succeeds, what happens next?
Without these expectations, an early robotics company could easily spend months developing customized engineering, but could never build a replicable business model.
A Pilot with no clear follow-up path could eventually turn into a consulting project with a GTM outfit.
Therefore, customer screening and success criteria are just as important as the technical work itself.
Users of products are not necessarily buyers
Another challenge for robot GTM is that product users, technology evaluators, internal drivers and economic decision-makers may be completely different people.
Let's say you're selling infrastructure products to a Robot Learning organization.
The real user of the product may be the Machine Learning Engineer, while the Head of Robot Learning may be the person driving the procurement within the organization.
The budget may be controlled by the VP of Engineering, the CTO may influence the final decision, and it may ultimately involve the procurement sector.
Everyone is evaluating the same technology from different perspectives.
Engineers want to know if the product can improve their workflow and integrate with existing systems.
Technical managers want to know if a product can help the team solve important problems or improve efficiency.
Senior managers may be more concerned with strategic value, resource allocation, cost, and whether the investment is appropriate for the organization as a whole.
Good GTM must understand these different perspectives while not distorting the underlying technology itself in conveying product value.
This is a completely different ability than repeating the same set of sales phrases to everyone.
This is why technical skills are so important for those who want to get into the robotics industry.
You don't have to have a PhD in robotics to work in GTM.
This is something I want more people to understand, especially those with a sales, growth, marketing or business background who want to get into the robotics industry.
You don't have to be a robotic researcher to work in the robotics industry.
I'm not a robot researcher myself. I don't design executives, I don't train Foundation Models, and I don't write game planning algorithms.
But if you want to do commercial work in this industry, you can't stay in a state of lack of technical understanding.
You need to understand industry terms and have enough knowledge of the whole technical spectrum to keep up with the discussions of engineers and researchers.
This means that you need to understand this step by step:
- Why do we need Simulation?
- How is Teleoperation used?
- Why is data quality so important?
- What should evaluation measure?
- Why is Generalization still such a difficult problem in robotics?
You also need to understand why a technology can work in a simulation, but that doesn't mean it has to work in real robots.
Why replacing an object, an environment, a robot, or a task could present a whole new challenge.
You don't have to understand every mathematical formula in a research paper, but you should be willing to read the paper and try to understand the parts you can understand.
You don't need to know how to implement every model you hear, but you should try to understand what it's trying to solve and why someone would care about it.
Critically viewing demos, reading technical documentation, keeping up with research progress, and asking engineers questions are all effective ways to build this understanding.
A very useful habit I've developed is to openly admit that I don't understand something and proactively ask others to explain it.
Pretending to understand a technical concept is more likely to cause harm than asking a thoughtful question, especially when you are faced with someone who has accumulated years of professional experience in a particular field.
A new robot GTM career is emerging
One of the reasons I wanted to write this article is that I keep seeing people who are interested in robots and Physical AI who think that the only way to get into this industry is to work in engineering or research.
I don't think that's true.
As robotics companies move from research to commercial deployment, they need people who can collaborate between engineering, customers, products, businesses, content, communities, and deployments.
Professional portraits of such people may be quite different from those of traditional software vendors or marketers.
They may be particularly good at researching, understanding technical content, and being able to communicate well with engineers.
They can create content themselves, engage in customer exploration, connect with researchers and entrepreneurs, manage Outbound, understand the developer community, or help companies design early Pilots.
They may also visit the lab regularly, attend robotics conferences, interact with entrepreneurs, observe actual deployments, or learn how different teams solve the same technical problems.
What really connects these activities is the ability to transition between technology and markets.
I believe that as Physical AI companies mature, the combination of technological curiosity, communication, research, relationship building and business thinking will become increasingly valuable.
It's also an inspiring opportunity for those who want to get into robot GTM today, as many of the skills that don't require a traditional background in robotics can be gradually developed.
If I could get into robot GTM from scratch today,
If I were to start from scratch, I wouldn't recite the various sales frameworks first, and I wouldn't try to become an expert in all areas of robotics at once.
I will first learn how the whole industry works and then gradually explore the direction of my interest.
I look at the founders, engineers, and researchers of robotics companies, watch technology demos, read company blogs, and spend time researching papers, even if at first I can only understand a portion of them.
I will also try to understand the connections between different levels of robotics, from Hardware, Perception, to Robot Learning, Simulation, Data, Evaluation and Deployment.
On this basis, I will choose a number of directions for in-depth exploration.
These include Manipulation, Humanoids, Autonomy, Teleoperation, Industrial Robotics, Robot Data, Simulation or Developer Infrastructure.
Once I have a certain understanding of basic technologies and related companies, I start thinking about these areas from a business perspective.
I would ask:
Who really faces the problems these companies are trying to solve?
How do they deal with these issues now?
How serious is the problem?
What factors will motivate them to consider adopting new solutions?
I also try to understand what evidence customers need to see to truly trust a product; who is in charge of the budget; and what internal processes an organization needs to complete before adopting new technology.
These are all GTM issues.
Even if no one has officially given you a GTM position, you can start developing this way of thinking ahead of time.
Over time, a combination of technical understanding and business curiosity will become an important foundation for your collaboration with early robotics companies.
I've been thinking about the GTM framework.
After working in different areas of the robotics industry, I gradually discovered that even when products and customers are completely different, GTM processes usually follow a similar learning cycle.
The framework that I think about repeatedly is:
Signal → Hypothesis → Conversation → Proof → Pilot → Evidence → Distribution → Expansion
The whole process begins with a Signal, a signal that indicates that a specific organization may indeed be facing a target problem.
This signal may come from recruitment information, technical papers, product announcements, deployment progress, or information obtained from previous customer interactions.
You then form a hypothesis based on these signals to determine which aspects your technology might help you in, and then verify that this hypothesis is correct through Conversation.
The goal here is not to force customers to accept the product language you've already prepared, but to really understand their problems and judge whether there are any meaningful business opportunities in them.
If the problem does exist and your technology is relevant, the next step is to build the Proof that customers really need.
Depending on the maturity of the product, this may be further developed into a range-specific POC, Pilot, or other form of technical assessment.
When these activities produce meaningful results, evidence is formed that can be used to build credibility.
The evidence can be translated into technical content, case studies, demos, documentation, or other material that helps potential customers understand the value of a product.
As credibility increases, companies have the opportunity to expand to more users, tasks, environments, teams, or customers, namely Expansion.
The interesting thing about this framework is that it doesn't actually end up in the Expansion phase.
Because each stage generates new information and brings it back to the beginning of the process.
A Pilot may reveal a new technical issue; a customer interaction may expose different application scenarios; a technical article may attract customers from segments of the market that have never been considered before; and an engineering team may learn something from actual deployments that will change product positioning.
Over time, ICPs will become more accurate, communication methods will be clearer, technical evidence will be more complete, and the products themselves can be improved.
Not all companies will go through these stages in exactly the same order. Early design partnerships or technical evaluations may also occur before a product reaches the maturity required for a traditional Pilot.
However, the overall principle still applies.
I increasingly prefer to understand robot GTM as a continuous learning system rather than a traditional linear sales funnel.
Commercialization should not only help companies understand the market, but it should also help the market understand the products.
For tech starters, GTM can start earlier than they thought.
When tech entrepreneurs hear the word Go-to-Market, they sometimes think of building a sales team, setting up marketing campaigns, attending industry conferences, building CRM, and pursuing revenue goals.
These things may be important in the future, but early GTM could be much simpler.
It might just start with talking to 20 people who might have a problem that you solve and learning how they're currently dealing with it.
You can find out what they've tried, what programs aren't working, and whether it's worth their time or money.
Through these exchanges, you may find a few people who really care about the issue and are willing to work with you.
They can be early design partners to help clarify technical needs, or tell you what kind of technical evidence makes a product really useful to their team.
You may also find that customers really care about something entirely different from what you initially anticipated, or that the products you're developing actually overlap with the systems they've built in-house.
These are very valuable discoveries and can be obtained whilst the product is still in the development stage.
In many cases, I think this is exactly what should happen at this stage.
The real risk is not that you start selling too early, but that you spend too much time behind closed doors developing something that the market really cares about, which is completely different from what you initially imagined.
The physical world makes trust expensive
There are many barriers to the adoption of software products themselves, but the robot adds a layer of challenge because it operates in a real physical environment where mistakes can lead to actual operational consequences.
Robots interact with people, equipment, goods and infrastructure.
They may cause damage to objects, disrupt production, encounter accidents, or require professional maintenance and deployment.
Hardware can fail, system integration can become very expensive, and systems that run well in controlled environments can perform completely differently in the face of real-world change.
For companies considering adopting robotics, technological performance is only part of the decision-making process.
They also need to consider the return on investment, the investment recycling cycle, overall cost, reliability, and integration requirements, as well as the impact of introducing the technology on existing operations.
That's why just showing amazing demos is often not enough to convince customers to adopt a product.
Customers need to figure out:
Is the system really working? Is it applicable to its specific scenario? Is it integrated with the existing environment? Is the return it brings enough to justify the investment?
For robotics infrastructure companies, the same principle applies at another level.
The team evaluating a Simulation, Data Infrastructure or Robot Learning tool needs to be convinced that the product can improve an important link in its technical workflow, and that this improvement is worth investing the appropriate resources.
Every stage of GTM should help customers reduce the level of uncertainty.
Customers will gradually move from understanding the technical capabilities to evaluating the relevance of the technology to their own needs, testing the actual performance, evaluating system integration, and ultimately deciding whether it is worth adopting or expanding the scale of use.
This is why I have always believed that the essence of robot GTM is to build trust through understanding and evidence.
We are still in the early stages.
One of the reasons I'm so attracted to robots and Physical AI is that the industry is still changing so fast.
Foundation Models are continuously evolving, Robot Data is becoming an independent infrastructure category, and Simulation is continuously evolving.
New approaches to World Models and Robot Learning are providing different technical pathways for training, evaluating and deploying robotic systems.
Hardware companies are also developing new robotic platforms, while developing a whole new workflow around data collection, evaluation, deployment and monitoring.
Even the jobs needed to commercialize these technologies have yet to form standardized job titles or mature career paths.
We don't have a set of sales methodologies that have been around for twenty years that can be used directly to sell many of today's robot products because many of those products didn't exist at all twenty years ago.
Some products didn't even exist five years ago.
This has led to uncertainty, but it has also created an unusual opportunity for those entering the industry today.
Founders are still learning how to find the right market for their technology.
Engineers are still learning how to convert research progress into products that can be used by other organizations.
GTM practitioners are learning how to convey technical value, build relationships with professional buyers, and build commercialization processes around products that are still evolving.
Today's participants have the opportunity to work together to define the next generation of robots and how GTM works for Physical AI companies.
I think people who are really good at this job will understand one fundamental thing:
You're not just selling a robot, a model, or a set of robot software.
What you really need to do is build enough understanding, evidence and trust to get another person or organization willing to invest in a technology that has to really work in the physical world.
This requires curiosity, technical skills, careful research, good communication skills, and the ability to ask the right questions.
It also requires you to be honest about what works and what doesn't, to spend time with engineers and customers, and to be willing to adjust your assumptions as cognition changes.
I'm still learning myself, and that's where I find it interesting.
The GTM methodology for the robotics industry is still being written, and now we all have the opportunity to participate in it.
