From Robotics Ambition to Product Reality: Lessons from Failure
What my failed product-lab startup taught me about product management
During my Executive management studies at the Indian Institute of Management Bangalore, a group of classmates and I decided to learn product management by doing it.
We did not want to spend our time only discussing personas, value propositions, user journeys, minimum viable products, and go-to-market strategy. We wanted to create something real.
So we started a company.
Our idea was ambitious: build a low-cost autonomous farming machine for small landholding farmers. The machine would move through a field, use computer vision to identify weeds or diseased plants, and apply pesticides precisely where they were needed. It could eventually support other implements such as a weeder or seeder and generate useful crop data.
We named the company Halcyon Technologies. We converted a room in our apartment into a lab and office. We assembled a small team of engineers and testers, designed mechanical and electrical systems, developed the software, built prototypes, and worked toward an MVP.
From a technology perspective, the project was exciting.
From a product perspective, we got the most important thing wrong.
We built a machine for the farm we had imagined — not for the farms our customers actually operated.
The idea looked compelling on paper
The opportunity seemed obvious.
Weeding and pesticide application were expensive and time-sensitive. Farmers faced labour shortages, rising input costs, and the need to protect yield. Precision spraying could reduce chemical usage, lower operating costs, and leave less residue on crops.
The market numbers also looked attractive. India had a large agricultural land base, and even a modest reduction in weeding costs appeared to represent a significant market opportunity.
The value proposition sounded strong:
An affordable farm robot that could reduce operating costs by applying chemicals precisely, while giving small farmers access to robotics, computer vision, and AI.
We had the technology ambition, a prototype roadmap, and a team capable of building hardware and software together. We even explored service-based distribution through local agents and village-level entrepreneurs.
But we had not answered the questions that mattered most:
- Who exactly would pay for the product?
- Who would operate it?
- What did a real farmer consider an urgent problem?
- What field conditions would the machine have to survive?
- Would the economics work for a smallholder farmer?
- Would the customer buy the machine, rent it, or pay for the outcome?
We were answering these questions after becoming emotionally and financially committed to the solution.
That sequence was our first mistake.
The failure was not simply technical
It is tempting to explain a hardware startup failure through engineering complexity. Hardware is difficult. Robotics is difficult. Computer vision in uncontrolled environments is difficult.
All of that was true.
But our deepest problem came earlier.
We had not done enough structured discovery with farmers and the broader agricultural ecosystem before committing to the product architecture.
We visited farmland on the outskirts of Bengaluru and observed the problem space. But observation is not the same as customer discovery. We did not build a sufficiently detailed understanding of farmer personas, decision rights, purchasing behaviour, service economics, crop cycles, maintenance realities, or the physical diversity of Indian farms.
The critical insight came too late: Indian farms are not uniformly flat, open operating environments. Many are uneven, irregular, fragmented, and difficult to navigate. A machine designed around assumptions closer to large, flat farms in countries such as the United States or Australia would face a fundamentally different operating problem in India.
Terrain was not a minor feature request.
It was a load-bearing product assumption.
Once that assumption became visible, several other assumptions became questionable: autonomous navigation, operating speed, machine stability, implement design, field coverage, maintenance, serviceability, and the return on investment for the farmer.
The product was not merely missing a feature. The context in which it was supposed to create value was different from the context we had designed for.
Ten lessons from the failure
1. Start with the customer’s reality, not the technology’s possibility
We began with what we could build: robotics, computer vision, sensors, and precision spraying.
We should have begun with what farmers were already doing, what constrained them, and what they were willing to change.
Technology can make a problem more interesting to engineers without making it more valuable to customers. A technically impressive solution is not automatically a commercially meaningful one.
The first product question should have been:
What painful, frequent, expensive problem will a specific customer pay us to solve?
2. Field visits are not the same as customer discovery
We did visit farms, but our research was not systematic enough. We did not speak deeply and repeatedly with enough farmers, farm workers, equipment owners, agricultural service providers, or buyers.
We needed to understand:
- how decisions were made
- who controlled the budget
- when the problem occurred in the crop cycle
- how farmers currently solved it
- what alternatives cost
- what failure would mean in the field
- and what level of reliability was required before trust was earned.
A few visits can create confidence. Repeated conversations create evidence.
3. Never treat the operating environment as a detail
For a software product, a change in context may require a workflow adjustment. For a hardware product, the environment can determine whether the product is viable at all.
Get Shine Vijayan’s stories in your inbox
Join Medium for free to get updates from this writer.
Soil, slope, field size, crop geometry, weather, water, dust, power availability, transport, storage, repair access, and operator skill were not peripheral considerations. They were product requirements.
We should have translated the Indian farm environment into explicit engineering constraints before designing the machine.
4. Separate the user, buyer, operator, and beneficiary
We used “the farmer” as if it represented one person with one set of needs.
In reality, the farmer may be the beneficiary, but the buyer could be a larger landholder, a village-level entrepreneur, a farming-as-a-service company, a cooperative, or an equipment dealer. The operator might be someone else. The person who experiences the pain may not control the budget.
Without clarifying these roles, our customer segmentation and distribution strategy remained mostly theoretical.
5. Validate the riskiest assumption before building the riskiest system
We spent considerable energy proving that the robot could work. We should first have proved that the proposed business model could work.
Our assumption backlog should have ranked risks such as:
- whether customers truly wanted the outcome
- whether the machine could operate across representative Indian fields
- whether the unit economics created a credible payback
- whether customers would buy, rent, or request the service
- whether the machine could be maintained locally
- whether the sales and service channel was viable
The highest-risk assumptions deserved the cheapest possible tests. Instead, we allowed the prototype to become the centre of gravity.
6. An MVP is not a smaller version of the final product
We thought of the MVP primarily as a functional prototype.
But a product MVP must test the most important value and business assumptions — not merely demonstrate that the technology works.
For us, an earlier MVP could have been a human-assisted service using a simpler machine, a manually operated precision sprayer, or even a workflow that measured the economics and customer willingness to pay before full autonomy.
The question was not, “Can we build the robot?”
It was, “Can we reliably deliver a valuable outcome in a real field at a price that works?”
7. Cool products do not create demand by themselves
Robotics and AI made the idea compelling to us. That did not mean they made it compelling to the customer.
Customers do not buy computer vision, autonomy, or elegant engineering. They buy lower cost, higher yield, reduced risk, timely execution, reduced drudgery, or a better business outcome.
The product needed to earn trust through a clear and measurable improvement over the farmer’s current alternative.
8. Solve one problem deeply before creating a platform
Our vision expanded across spraying, weeding, seeding, crop analytics, disease detection, and multiple distribution models.
That created strategic breadth before we had achieved product depth.
Startups are resource-constrained. The discipline is to identify one customer, one crop or operating context, one painful job, and one measurable outcome. Solve that problem exceptionally well before describing the product as a platform.
9. Hardware economics must be validated early
We underestimated the work, time, and capital required to move from a working prototype to a market-ready hardware product.
The cost was not limited to components. It included mechanical redesign, manufacturing, tooling, quality, field validation, repair, logistics, software, training, distribution, inventory, and after-sales support. Hardware iteration cycles were also much longer than software iteration cycles.
Most importantly, our return-on-investment assumptions were not sufficiently grounded in the customer’s actual operating model.
If the payback period does not make sense to the buyer, technical elegance cannot rescue the product.
10. Engineers must resist the instinct to “just build”
We were engineers presented with an interesting problem. We did what engineers often do when excited: we started building.
Building produced visible progress. Customer discovery felt slower and less satisfying. A new prototype created energy; a difficult conversation with a customer created ambiguity.
But ambiguity is not a reason to skip discovery. It is the reason discovery is necessary.
The product manager’s job is not to protect the team from uncertainty. It is to make the uncertainty visible early enough that the team can make a better decision.
What I would do differently today
If I were restarting the venture, I would follow a different sequence:
- Choose one crop, one geography, and one customer segment.
- Conduct structured interviews across farmers, operators, service providers, and buyers.
- Spend time observing the complete job during the relevant crop cycle.
- Map the physical environment and convert it into engineering constraints.
- Quantify the current cost, timing, failure modes, and alternatives.
- Rank assumptions by risk and validate the most dangerous ones first.
- Test the service and economics with a human-assisted or semi-mechanical solution.
- Build autonomy only after proving that the customer will pay for the outcome.
- Define a narrow pilot with explicit success criteria.
- Make a stop, pivot, or continue decision using evidence rather than attachment.
This sequence would not guarantee success. It would, however, reduce the cost of learning.
The lesson I carry forward
The startup failed, but the experience changed how I think about products.
Product management is not the art of converting a clever idea into a feature roadmap. It is the discipline of reducing uncertainty about customers, context, value, feasibility, economics, and adoption — before the organisation spends too much time and money.
We believed that product management could be learned only by doing. We were right.
We learned that doing product management means more than building, testing, and launching. It means getting close enough to reality that the product can no longer hide behind a compelling pitch.
Our robot did not fail because the ambition was too large.It failed because our understanding of the customer and operating environment was too small.
That remains one of the most expensive — and most valuable — lessons of my product career.
Disclaimer: The views expressed here are strictly my own.
