When a factory replies "yes we can do it, here is the price" to your detailed request for quote, miscommunication has already started compounding. Scope that nobody defined becomes the silent killer of timelines. I have spent years on the ground in China, sitting in rooms with factory engineers and brand teams on IoT, smart home, and wearable projects. The pattern repeats: these are not cultural quirks. They are structural cracks that show up in every project, every budget.
The Quote Request Black Hole
You write a detailed RFQ. Every project requirement clearly marked. You send it to a factory and get back a one-line reply: "Yes, we can do it. Here is the price." You follow up with questions. The sales rep does not understand what you are asking. You end up screenshotting your own RFQ and circling sections. Then you discover that half of the things you assumed were included in the price are actually "extra."
Factory sales reps do not have technical backgrounds. They understand production lines and unit pricing, not firmware or product specs. The engineers who could answer your questions are not in the room when the quote goes out.
The factory is in a brutally competitive market. Saying "yes" is not about confidence — it is about survival. Technical understanding comes later, if it comes at all.
Your RFQ is a starting point for conversation, not a binding specification document. Budget time for multiple rounds of clarification. The first price you receive is a starting position, not the final cost.
Finding the Right Supplier
One of the most common things I hear: "I'm struggling to find suppliers." China's manufacturing ecosystem is fragmented in ways that are hard to navigate from overseas. A factory that does PCBA does not do firmware. A factory that does assembly does not do cloud. Testing does not necessarily include certification. Small order quantities make this harder. Factories want predictable runs, and a custom order disrupts their workflow. The factories that do take these projects are often solution providers — smaller companies that bridge prototype and production. My advice: separate hardware from software in your head before you start looking. The factory handles the physical product. Firmware, cloud, and app development requires a separate partner.
The Handshake Deal Trap
A product manager once described a situation I think about often. His company made white label home appliances sourced from China. His CEO told a factory: "We have it all figured out. Our product manager will coordinate with you on the details."
The problem was, they did not have it figured out. Not the firmware, not the component selection, not the feature scope. The CEO had made promises and handed the hot potato to the PM, who was expected to fill in all the blanks retroactively — with a factory that had already been told the hard work was done.
The factory sat back and waited for inputs. The PM tried to push forward but had no authority to make decisions the CEO had not made. Every question from the factory looped back to the CEO. Every answer was vague. Delays started stacking up.
This is what happens when you skip the scope document: the person who has to execute the project is the last one to find out that nobody defined it.
During prototyping, the same factory presented a specific component as the only option. It was not. It was simply what they had on hand. Nobody had defined the real design intent upstream, so every downstream decision defaulted to whatever was cheapest for the factory.
No scope means no technical decisions made by the brand. The factory fills the vacuum with whatever works for them. By the time the PM realizes what happened, unwinding it costs more time than writing a spec would have.
The CEO was not careless. He followed a path that worked for simpler products in an earlier era. When you are buying commodity items, a handshake might be enough. The moment you are developing something new — custom firmware, specific components, performance requirements — you need specifications. The person downstream who has to make it real cannot do their job without them.
If you are the PM, the product lead, or the technical person on the brand side: push for a scope document before you need one. Even if your boss does not think it is necessary. Especially if your boss does not think it is necessary.
The Three-Party Problem — And How to Solve It
When a brand builds a smart connected product in China, there are typically three parties involved: the brand (overseas), the factory (hardware, in China), and the solution provider (firmware, cloud, app — also in China, usually a completely separate company, often in a different city).
Every specification crosses all three parties. Each party naturally optimizes for their own deliverable: the solution provider wants clean firmware architecture, the vendor wants manufacturability, the brand wants market timing. Nobody is optimizing for the whole product by default.
I have seen this go wrong in most cases. But I have also seen it go right, and that story is worth telling.
I worked on a smart IoT project with a listed UK company. Strong branding and established market channels, but not enough R&D or manufacturing capability for the new product they needed. The project involved coordinating their own factory, a solution provider, multiple vendors, and their internal UK team across two countries.
The timeline was aggressive: kickoff in January, integration done within ten months, product demoed at a UK exhibition in October, mass production by December. Ten months from nothing to production-ready.
Large companies in China face two problems that kill projects: language barriers, and role divisions that look precise on paper but create gaps. We solved the language problem by keeping information flowing across all teams in real time. Everyone saw the final delivery goal and timeline. From there, we broke it down into milestones. Chaos in a multi-party project is normal, as long as the main axis is clear. Teams follow the pace, and blockers surface on their own.
Every party understood their role and stuck to it. The brand defined clear requirements and made decisions fast. The solution provider focused on firmware without trying to redesign the hardware. The factory optimized for manufacturability. Someone made sure that when one party's output became another party's input, the handoff was clean.
There was no resource waste. No waiting for someone else to finish before starting. Scope was defined from day one, so there was no creep.
This is what good coordination looks like. Not one magical supplier who does everything, but clear responsibilities, constant communication, and someone who understands the whole picture.
Most projects fail because nobody takes ownership of coordination. The brand assumes the factory will figure it out. The factory assumes the brand has a plan. Everyone is busy. Nobody is aligned.
The UK project worked because it did not fall into that trap. It was not smooth all the way through — integration testing before mass production surfaced many issues. What matters at that stage is not another meeting. It is using the right tools (e.g. serial debuggers, circuit analysis, cloud logs) to expose and reproduce the problem. Once the issue is visible, pull in the right person and solve it. Chinese factories and solution providers share a trait: when they see a concrete problem, they fix it fast.
The Milestone Problem
Most brand customers skip over a step that quietly determines whether their product launches or stalls: turning a business launch date into engineering milestones.
A brand wants to launch by Q3. That is a business goal. But what does the engineering team need to deliver, in what order, to make that possible?
Most brands do not know how to decompose a launch into development milestones. They put business goals on top and neglect feasibility. They want every feature, every certification, every market — and they do not want to give up anything.
The factory, meanwhile, is too afraid to push back. They will nod along and accept requirements they cannot deliver on time, because saying "no" feels like losing the order.
In most projects, the real blockers are not the factory or the solution provider. They are the client's internal decisions and the information the client needs to provide: requirements, design specs, acceptance criteria. If this is not prepared in advance, suppliers hit a wall. That creates an information vacuum, and pushing forward means rework.
Sitting down early and building a roadmap that says what ships first and what ships later — what the MVP includes, what gets cut if timelines slip, which certifications are required now — this separates products that launch from products that stall.
Most teams avoid this conversation because it forces tradeoffs nobody wants. But it determines whether you ship or stall for another year.
I help brands build IoT products in China — from first prototype to mass production. Learn more at ChinaTechSource.