Managing Expectations in Robotics Projects

"The first step in building a robot isn’t about technology—it’s about understanding the mission" As the team lead of the Kerala Police Cyberdome Robotics Wing, I was tasked with designing a robot for policing applications. Our initial discussions revolved around traffic control, perimeter security, and automation, but we quickly realized something—we were thinking too much like engineers and not enough like the end users. So, we took a step back and asked the police officials directly about their biggest challenges. The answer? Their bomb diffusion robot was incredibly expensive yet lacked many critical features including precise arm control - critical flaws in high-risk operations. This is the first step in any real innovation: - Understand the user’s pain points before jumping into assumptions. - Ask the right questions. (Not “What’s wrong with your robot?” but “What’s the most frustrating part of using it?”) - Refine the requirements. Strip away unnecessary features and prioritize impact over complexity. Before designing anything, always start with the right questions: - What is the biggest challenge you face while using the current system? - What features do you wish existed but don’t? - What slows you down the most in critical situations? - If you could change one thing about it, what would it be? Next, we turned these insights into a well-defined requirement sheet—the foundation for designing an optimized robot. How do you approach requirement gathering for your projects? Share your thoughts in the comments! 🔜 Next up: From concept to design—how do you translate an idea into a real, functional robot? In the next post, I’ll share how we sketched out the frame, chassis, and robotic arm, choosing the right materials and design philosophy to meet the mission’s demands. Stay tuned!

𝗢𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝘀𝗵𝗶𝗳𝘁𝘀 𝗜’𝘃𝗲 𝗺𝗮𝗱𝗲 𝗮𝘀 𝗮𝗻 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗼𝗿 is... Focus less on the robot and more on the problem. Don't get me wrong, we invest an immense amount of time and resources on training to be the most technically competent robot company we can be.  But I've learned to spend less time talking about the technology, robot or the company. 😆 In the early days, I focused on technical readiness—cycle time, fixturing, reach studies, simulation.  I felt like we had all the boxes checked technically, but for some reason the project died before it got approved. And those things still matter .... 𝘼𝙇𝙊𝙏 But they don’t matter if the project dies in approval. I’ve seen solid systems get sidelined because the people expected to run them never got a say in how they were built or why.  Technically it 𝘾𝙊𝙐𝙇𝘿 have worked, but it didn't go forward because the team wasn't ready enough to sell the project internally. No One has a Robot Problem!  The Robot is a tool to solve a problem.  Not the solution itself. Now, we approach projects differently. We ask WHY you think you need a robot. We ask HOW parts are run today. We ask WHO is responsible for what. We ask WHEN  you need it. We ask WHAT success looks like from multiple angles: 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘦𝘰𝘱𝘭𝘦 𝘥𝘰𝘪𝘯𝘨 𝘵𝘩𝘦 𝘸𝘰𝘳𝘬, to management, to ownership, to the board, to other stakeholders. And sometimes the best solution is to pause the project until there’s alignment. It might feel slower in the beginning, but it saves months of headaches down the road. The robot is just the last piece of the puzzle. If the people around it aren’t part of the process, it won’t deliver. What are you seeing out there? Curious how others approach this on their shop floor. #automation  #manufacturing #leadership #roboticintegration #changemanagement #peoplefirst

I’ve seen student projects stall for months simply because no one was tracking dependencies. The same happens in startups. Most robotics startups race into prototyping and they think once there is a prototype (call it duct-tape prototype), they are ready to manufacture. They hire brilliant engineers, buy parts, start building. What’s missing? A dedicated hardware product manager who connects the technical roadmap to business reality. The mistake is also more common with first time founders Here’s why it matters: 1. Requirement clarity What works: A product manager translates fuzzy founder visions into measurable requirements. Instead of “we need a robot arm that is safe,” it becomes “payload: 5kg, repeatability: ±0.05mm, safety compliance: ISO 10218-1.” What doesn’t work: Leaving engineers to interpret business needs. You end up with redesigns, wasted time, and parts that don’t fit regulatory pathways. 2. Cross-functional alignment Robotics isn’t just software. It’s sensors, hardware, mechanics, supply chain, and integration. Without someone connecting those dots, things fall apart fast. A PM anticipates these conflicts before they become delays. 3) Market fit validation Hardware PMs test early prototypes with customers. They catch that a warehouse wants a 1-hour recharge, not just 6-hour battery life. What doesn’t work: Building the “perfect” robot in the lab that fails the first customer pilot. The result? Without hardware PMs, early-stage robotics teams burn months and millions fixing avoidable mistakes. With them, the product evolves with customer input and scales faster. The underrated benefit? They give engineers breathing room to focus on solving technical challenges instead of juggling project logistics. I think early-stage teams that invest in this role early end up moving faster, not slower and saving more money. A Technical/Hardware PM isn’t a luxury. They’re the difference between an over-engineered prototype and a product that survives in the market. I’m curious, how early does your team bring product managers into hardware development? #robotics #productmanagement #projectmanagement #marketfitvalidation

Unclear expectations are a project killer When I first started managing projects, I thought everyone would be on the same page. Alignment on roles, responsibilities, timelines, & deliverables Spoiler alert - they weren't. Fast forward 6 months: → A task was delayed because no one owned it → A stakeholder expected something we never agreed to → The team was frustrated by murky priorities It all came back to unclear expectations. Now, every time I kick off a project, I focus on 3 key things: ☝ Define roles & responsibilities Who owns what? Don't assume people know. Spell it out. RACI charts work wonders. ✌ Clarify deliverables & deadlines What are we delivering and when? Be specific. Confirm alignment with your team/stakeholders. 🤟 Overcommunicate early Repeat key details. Document agreements/decisions. Follow-up to ensure understanding. Clarity by setting expectations prevents future problems. It also establishes trust, teamwork, and successful delivery. When everyone knows what's expected, they can execute instead of guess. PS: what's your go-to strategy for setting clear expectations? 🤙

Managing client expectations is an under-appreciated art. Here are a few ways I do it successfully: (Starting with some context about my line of work) C-level executives have huge expectations for AI (which I love). They're excited to integrate AI automation into as many protocols and processes as possible. The trouble is, many don't know what’s *actually* possible with today’s AI tech. It's no fault of their own. After all, AI is still an abstract concept to many business leaders. The challenge is: You can’t launch a successful AI project on unrealistic expectations. Part of my job = bridging the gap between vision and reality. It's about level-setting expectations. This process starts by answering 4 key questions with every new client: 1. Agreeable: Do we agree that AI is the right solution? 2. Feasible: Can we do this, technically? 3. Clear: Do we both understand WHY it will / won't work? 4. Achievable: Do you have the budget and resources? No project moves forward until we’re aligned. Because in my experience, managing expectations (through education, coaching, and listening) is the difference between AI projects that fail and those that succeed.