When developing a product, it is easy to fall into a familiar assumption:
If we want a better result, we should use a better material.
If we want a stronger structure, we upgrade the material.
If we want the electronics to be thinner, we choose a more advanced circuit solution.
If we want the product to feel more premium, we add more parts, more processes, and more cost.
But after working on enough real-world products, I have become increasingly convinced that this is not always the right way to think.
Sometimes, a very ordinary — even seemingly “low-end” — material can create an unexpectedly refined result when it is used in exactly the right place.
The important question is not how sophisticated the material is.
The important question is:
What problem do you actually need it to solve?
A Lighting Problem Inside a Flexible Structure
The solution should meet the real bending, lighting, weight, and cost requirements—nothing more.
In one project, we needed to add a lighting effect inside a soft, flexible textile structure.
From an electronics perspective, this did not seem particularly complicated.
If a structure needs to bend while carrying multiple LEDs, one of the most obvious solutions is:
Use a flexible printed circuit, or FPC.
That is exactly what FPC is designed for.
It is thin, flexible, suitable for mounting LEDs, and technically easy for an electronics engineer to justify.
On paper, it looks like the standard answer.
But product development is different from pure electronics engineering.
A technically correct solution is not always the best product solution.
So we went back and looked at the actual requirements again.
Did the structure really need a full flexible circuit?
Did it need to survive repeated, extreme folding?
Did it require high-density routing?
High-speed signals?
Very tight dimensional tolerances?
Not really.
The real requirements were much simpler:
It needed to carry LEDs.
It needed to conduct electricity.
It needed to tolerate a certain degree of bending with the textile structure.
It needed to stay lightweight.
It had to remain hidden inside the product.
And it had to be inexpensive.
Once the requirements were broken down this way, the problem changed.
We were no longer asking:
“What is the best flexible circuit solution?”
We were asking:
“What is the lowest-cost structure that can reliably meet these actual requirements?”
Those two questions sound similar.
But they can lead to very different answers.
A Solution That Did Not Look “Premium”
The final solution was not a conventional high-spec flexible circuit.
Instead, we used a very low-cost circuit structure built on a substrate that naturally offered a useful degree of flexibility.
By itself, the material was not impressive.
It was not something a marketing team would put on the front of the package.
The end user would probably never know it existed.
But inside the right product structure, it did exactly what we needed.
The LEDs could be distributed along the flexible section.
The overall assembly could still bend sufficiently.
The electronics could remain hidden inside the textile construction.
And the user could still clearly perceive the intended lighting effect.
What the customer experienced looked more sophisticated than what the internal cost structure might suggest.
That is one of the most interesting things about product development.
The user experiences the result, not the BOM.
“Cheap” Does Not Mean “Bad”
A lower-cost structure is valuable when it reliably delivers the performance the product genuinely needs.
There is an important distinction here.
Cost optimization is not simply about finding a cheaper component.
If you replace a two-dollar part with a one-dollar part but create more failures, more assembly difficulty, more rework, more compliance risk, or more after-sales problems, that is not real cost optimization.
Good cost engineering means:
Finding a lower-cost solution that still satisfies the performance the product genuinely requires.
In some cases, a simpler and cheaper structure may even be more suitable for mass production than a supposedly “better” solution.
That is why I do not find it particularly useful to divide materials into:
premium materials and low-end materials.
A better distinction is:
the right material and the wrong material.
Do Not Choose the Material First and Justify It Later
Engineers naturally tend to begin with the technologies they already know.
An electronics engineer sees a flexible structure and thinks of FPC.
A mechanical engineer sees a connection problem and thinks of screws, snap-fits, or reinforcement ribs.
A supplier sees an appearance issue and may immediately suggest painting, UV printing, IMD, or another added component.
None of these solutions are necessarily wrong.
The problem is that we sometimes move too quickly into how to build something before clearly defining what the product actually needs.
A useful habit in product development is to ask, before choosing the solution:
What conditions does this feature truly need to satisfy?
Then break those conditions down.
For example:
How much does it actually need to bend?
How many bending cycles does it need to survive?
Can the user touch this component?
What is the realistic product life requirement?
Is the feature carrying a functional load, or is it mainly creating a visual effect?
Is this level of performance genuinely required by the product, or was it added by the engineering team simply because it was possible?
A surprising amount of unnecessary cost enters a product before these questions have been properly answered.
Premium Products Do Not Always Come From Expensive Parts
The best material decision is the one that creates the intended experience without spending where the customer gains no value.
I increasingly enjoy studying products that are clever on the outside and surprisingly simple on the inside.
They create strong perceived value without relying on excessive material cost.
In many ways, that is harder than simply using expensive components.
Because good product engineering is not:
“I know an advanced technology, so I should put it into the product.”
It is:
“I know many possible technologies, but I will only use the one this product actually needs.”
That is why opening a well-designed mass-produced product can sometimes create a strange reaction:
“That is all there is to it?”
But this kind of simplicity is rarely accidental.
It is often what remains after many rounds of trade-offs, simplification, testing, and decision-making.
A ToyRD Product Development Principle
At ToyRD, these are exactly the kinds of engineering decisions I want to keep documenting.
Not simply:
Which material is the best?
Which chip is the most advanced?
Which manufacturing process is the most sophisticated?
But rather:
What is the most reasonable choice when cost, performance, reliability, manufacturability, and user experience all have to be balanced at the same time?
Great products are not always great because they use expensive things.
Often, they are great because someone understood precisely:
where the money should be spent — and where it should not.
Sometimes, a very ordinary material, used in exactly the right place, can create a surprisingly extraordinary result.
That may be one of the most interesting parts of product development.
*Some product details in this case have been generalized to protect project confidentiality.*
In toy development, material cost is easy to see.
Engineering cost is not.
A resin that saves a few cents per part can look like a good decision in a BOM review. But when that material is used inside a mechanism with gears, sliding parts, repeated movement, and tight dimensional relationships, the real cost may appear later—in noise, friction, inconsistent assembly, rework, tooling changes, and delayed production.
Recently, I ran into exactly this kind of problem on a toy project involving a small motorized mechanism.
The mechanism itself was not complicated. A motor drove a gear train, and the gear train moved a plastic component back and forth repeatedly. But the motion depended on several molded parts staying within the right dimensional range.
At an early stage, PP was selected for part of the mechanism as a cost-saving option.
On paper, that choice looked reasonable.
In practice, it became much more complicated.
PP Is Not a Bad Material
PP, or polypropylene, is one of the most widely used plastics in toys and consumer products.
It is lightweight, cost-effective, chemically resistant, and tough. It works very well in many applications such as housings, living hinges, containers, clips, and flexible parts.
The problem is not that PP is "cheap" or "low quality."
The problem is that material selection has to match the job the part is doing.
For a decorative cover, a small dimensional change may not matter much.
For a moving mechanism, it can matter a lot.
The Real Problem Was Dimensional Stability
Material shrinkage and dimensional stability must be evaluated as a mechanism-level issue.
One of the most important differences between PP and ABS is molding shrinkage.
The exact value depends on the resin grade, filler content, wall thickness, mold temperature, packing pressure, gate design, and many other processing conditions. So it is never correct to treat shrinkage as one universal number.
But the general engineering trend is clear:
PP typically has significantly higher molding shrinkage than ABS.
That becomes important when molded parts are part of a mechanical system.
A mechanism may rely on:
gear center distances,
shaft positions,
sliding clearances,
guide surfaces,
wall straightness,
bearing locations,
part-to-part gaps,
and cumulative tolerance across several components.
A small deviation in one part may be harmless.
Small deviations across several parts can become a system-level problem.
That is where symptoms such as these begin to appear:
intermittent friction,
unstable movement,
increased mechanical noise,
inconsistent assembly,
higher motor load,
parts rubbing where they should not,
and units that behave differently even though they use the same design.
This is a good reminder that a plastic part does not exist independently.
Inside a mechanism, every dimension interacts with another dimension.
A Cheaper Resin Can Create More Expensive Problems
When engineers or sourcing teams review a BOM, the conversation often focuses on the material price itself.
For example:
Can we save a little by changing this part from ABS to PP?
That is a valid question.
But it is incomplete.
The better question is:
What happens to the total engineering cost if this material changes?
That total can include:
tooling adjustment,
additional sampling,
longer debugging cycles,
extra assembly labor,
sorting and rework,
higher QC burden,
reduced yield,
mechanical noise complaints,
inconsistent function,
and production delays.
If a material saves $0.03 per unit but causes $0.08 per unit in additional manufacturing or quality cost, that is not cost reduction.
It is cost transfer.
And cost transfer is often harder to see because it appears across different departments.
"Why Not Just Switch the Existing Mold to ABS?"
Once a PP part starts creating dimensional problems, the obvious reaction is often:
Then let's just mold the same tool in ABS.
Sometimes that can work.
But it should not be treated as a drop-in material substitution.
Injection molds are designed around the expected behavior of the material, including shrinkage.
The tool cavity dimensions, part dimensions, clearances, draft, ejection strategy, and processing window were all developed under certain assumptions.
If a mold was designed around a higher-shrinkage PP grade and the material is suddenly changed to a lower-shrinkage ABS grade, the final dimensions can shift.
That may affect:
overall part size,
fit with mating parts,
gear alignment,
snap engagement,
interference,
sliding gaps,
and ejection behavior.
The correct conclusion is not:
"A PP mold can never run ABS."
That would be too absolute.
The correct conclusion is:
A material change after tooling must be treated as an engineering change, not a purchasing change.
The mold, part dimensions, tolerances, processing conditions, and mechanical performance all need to be re-evaluated.
Then Another Idea Came Up: Filled PP
During the discussion, another possibility came up:
Could we keep PP, but use a modified grade with talc, mineral filler, or glass fiber to improve stiffness and reduce shrinkage?
From a material-science perspective, this is a perfectly reasonable direction to investigate.
Filled PP compounds are widely used in industry precisely because fillers can improve properties such as:
stiffness,
dimensional stability,
heat resistance,
creep performance,
and molding shrinkage.
So the proposal is technically plausible.
But technically plausible is not the same as production-ready.
The existing mold was not originally developed around an arbitrary filled PP grade.
Changing filler type and percentage can also change:
melt flow,
viscosity,
warpage behavior,
surface appearance,
abrasion on tooling,
ejection behavior,
weld-line behavior,
and actual molded dimensions.
At the same time, the molding team raised practical concerns about whether a different compound could create new molding or release problems in the existing tool.
At that point, the most useful response was not to argue from theory.
It was to test.
This Is Where AI and Factory Experience Should Meet
Use trials and measurements to test material hypotheses against the real tool and mechanism.
This case also illustrates something increasingly common in product development.
AI can very quickly suggest technically reasonable directions:
use a filled PP grade,
reduce shrinkage,
increase stiffness,
change a material system,
adjust clearances,
review processing parameters.
That is useful.
But AI does not physically see the mold.
It does not automatically know:
the actual draft angle,
the tool surface condition,
the gate location,
the wall-thickness transitions,
the ejector layout,
the existing dimensional deviation,
the real machine settings,
or what happened during the previous molding trials.
Factory technicians and tooling engineers, on the other hand, often carry years of experience that is difficult to express in a datasheet.
They may look at a tool and say:
"I don't like this material change on this mold."
That statement may not come with a full polymer-science explanation, but it may still be based on many past failures.
So who should you trust?
The better answer is:
Do not turn it into a competition.
A stronger development process looks like this:
1. AI or engineering analysis expands the possible solution space. 2. Tooling and molding teams identify practical risks. 3. Controlled material trials are run. 4. Critical dimensions are measured. 5. Parts are assembled into the real mechanism. 6. Noise, load, movement, temperature, and durability are evaluated. 7. The decision is made using production evidence.
AI is useful for generating hypotheses.
Factory experience is useful for identifying hidden risks.
Testing decides whether either one is right for the actual product.
PP Can Also Create Surface-Treatment Challenges
There is another PP-related issue that is easy to underestimate: surface treatment.
PP is a low-surface-energy plastic.
That means printing, painting, labeling, and adhesive bonding can be more difficult than on materials such as ABS unless the material, ink, adhesive, or surface preparation is designed for it.
Depending on the product, manufacturers may use:
flame treatment,
corona treatment,
plasma treatment,
primer,
special inks,
special adhesives,
or modified resin grades.
On a previous project, we also explored laser marking on PP.
For that specific application, the result was quite acceptable.
That does not mean every PP grade can be laser-marked well. Laser performance depends heavily on resin formulation, color, additives, wavelength, and process settings.
But it reinforces the same lesson:
A simple material change can affect much more than the injection molding step.
It may also affect decoration, marking, adhesion, assembly, appearance, and long-term production consistency.
So Should Moving Toy Mechanisms Avoid PP?
A lower resin price does not help if movement, fit, and production consistency become harder to control.
No.
That would be too simplistic.
PP is successfully used in many moving products, automotive systems, home appliances, hinges, gears, guides, and mechanical components.
The important lesson is different:
Do not choose PP for a precision-sensitive moving mechanism only because it is cheaper.
If the component has any of the following characteristics, material selection deserves more attention:
gear positioning,
sliding movement,
reciprocating motion,
tight dimensional chains,
noise sensitivity,
alignment-critical features,
multi-part assemblies,
or narrow functional clearances.
In those cases, ABS can often be a more conservative starting point when dimensional stability and predictable molding behavior matter more than squeezing out the lowest possible resin cost.
And if PP is still the preferred material, it is better to decide that at the beginning of the project.
Then you can define:
the exact PP grade,
whether it is filled or unfilled,
expected shrinkage,
tool compensation,
critical tolerances,
sliding clearances,
warpage limits,
and worst-case tolerance stack.
That is material engineering.
Changing resin after tooling and hoping everything else remains the same is not.
One of the Most Expensive Questions in Toy Development
A question I hear often in product development is:
Can we make this part a little cheaper?
Sometimes the answer is absolutely yes.
But for moving structures, I increasingly prefer a different question:
If we save money here, where might we pay for it later?
That small change in mindset can prevent a surprising amount of trouble.
Material cost is visible.
Debugging cost is not.
A BOM may show that PP is cheaper than ABS.
It does not show the extra two weeks spent chasing noise, movement inconsistency, dimensional drift, or molding problems.
That is why I increasingly think about Total Engineering Cost, not just part cost.
ToyRD Note
This is exactly the kind of development lesson I want to document on ToyRD.com.
A material datasheet can tell you the shrinkage range of PP.
An AI system can suggest talc-filled or glass-fiber-reinforced PP.
A tooling engineer may tell you the existing mold is unlikely to like the change.
All three inputs can be useful.
But real product development happens where materials, tooling, mechanism design, supplier experience, and physical testing meet.
The most useful question is often not:
"What is the shrinkage rate of PP?"
It is:
"I already have a molded PP mechanism that is noisy and dimensionally unstable. What is the lowest-risk way to recover the project?"
That is a much harder question.
And that is the kind of question ToyRD is built around.
ToyRD.com — Practical toy development notes from real engineering problems.
*A real toy-development case showing why the best cost reduction sometimes comes from understanding a quotation—not simply pushing a supplier for a lower price.*
In toy development, small tooling charges appear everywhere.
A supplier may quote for an injection mold, silicone mold, printing jig, paint mask, spray fixture, assembly fixture, or some other production aid. The amount may only be a few hundred or a few thousand RMB, so it is tempting to approve it quickly and keep the project moving.
But small charges add up. More importantly, they often hide assumptions about how the supplier expects the product to be manufactured.
A recent silicone toy project gave us a good example.
The Original Quote: RMB 2,000
Clarifying the quoted quantity can reduce cost without forcing a lower unit price.
The product required two separate painted areas. To keep the paint in the correct position during production, the supplier's painting subcontractor needed dedicated spray fixtures.
The quotation was:
Spray fixture A: RMB 1,000
Spray fixture B: RMB 1,000
Total: RMB 2,000
At first glance, the price looked high.
We had already asked another source about similar masking fixtures, and the indicative price was only a few hundred RMB each.
The obvious reaction would have been:
"Your price is too high. Can you reduce it?"
That is how many sourcing discussions begin.
But price negotiation was not actually the most useful first step.
Instead, we asked a different question:
What exactly is included in the RMB 1,000?
That question changed the whole conversation.
The Quote Was Based on Two Sets, Not One
After checking with the painting factory, the supplier came back with an important detail:
Each RMB 1,000 quotation included two identical sets of the fixture.
The painting factory had apparently quoted according to its normal production arrangement. Two sets would give them more flexibility during mass production and help maintain throughput if both were needed on the line.
That may be reasonable for a larger or faster production run.
But it was not what our project needed at this stage.
We were dealing with a relatively small production quantity. We asked whether one set of each fixture would be enough and whether using only one set would affect the delivery schedule.
The answer was yes: one set was enough, and it would not delay the small production run.
So the quotation was revised to:
Spray fixture A: 1 set, RMB 500
Spray fixture B: 1 set, RMB 500
New total: RMB 1,000
The tooling cost was reduced by 50%.
But technically, we did not negotiate a lower unit price.
We corrected the assumption behind the quotation.
We didn't negotiate the price. We corrected the assumption behind the quote.
That distinction matters.
Price Problems Are Often Specification Problems
When two suppliers quote very different prices, it is easy to conclude that one is expensive.
Sometimes that is true.
But before making that judgment, check whether they are actually quoting the same thing.
For a small production fixture, useful questions include:
What material is the fixture made from?
How many pieces or sets are included?
Why are multiple sets necessary?
Is the fixture designed for sampling, a pilot run, or full mass production?
What production volume is the quoted configuration intended to support?
Does the price include adjustment or trial fitting?
Does it include replacement if the fixture wears out?
Who owns the fixture after it is paid for?
A quote of RMB 200 and a quote of RMB 1,000 may look wildly different until you discover that one supplier is quoting one simple mask while the other is quoting multiple production-ready fixtures plus setup work.
The first task is not to bargain.
The first task is to understand what you are buying.
Do Not Pay Today for Production Capacity You May Need Tomorrow
Build for the current production stage, then add capacity when the order volume justifies it.
This case also reflects a broader issue in toy development.
Suppliers often think in terms of production efficiency. That is understandable. Their job is to keep factories running smoothly.
Product developers, however, have a different problem: uncertainty.
A new toy may begin with:
a prototype,
a customer sample,
a 500-piece test order,
a 1,000-piece pilot run,
or a small first production order.
Nobody knows yet whether it will eventually become a 20,000-piece product.
If the supplier automatically prepares tooling for future high-volume production, the customer may end up paying for capacity that is not currently necessary.
This is especially important for ODM and new-product projects.
A useful principle is:
Tooling should match the current stage of the product, not the imaginary future volume.
If the product succeeds and production increases, additional fixtures can be added later.
That is usually better than building every possible backup fixture before the market has validated the product.
In our case, there was no reason to pay for two sets immediately when one set could support the current order without affecting delivery.
The Cheapest Fixture Is Not Always the Best Decision
Keeping fixture design with the supplier preserves clear responsibility for process performance.
There was another interesting part of this case.
We could probably have found an outside supplier willing to make the fixtures for less than RMB 500 per set.
So why not simply buy the cheapest fixtures ourselves and send them to the painting factory?
Because tooling cost is only one part of the decision.
The other part is process responsibility.
If the painting factory designs and makes its own fixture, then problems such as these stay within its process:
paint position is incorrect,
masking edges are poor,
the part does not locate properly,
the fixture does not fit consistently,
overspray becomes excessive,
or production becomes unstable.
The supplier has to solve the problem as part of delivering an acceptable finished component.
If we design or purchase the fixture ourselves and hand it to the factory, responsibility becomes less clear.
If the painted result is poor, the factory may reasonably say:
"The fixture was supplied by you."
Then a few hundred RMB of tooling savings can turn into a much more expensive argument about who is responsible for the production problem.
This leads to another useful rule:
Sometimes you are not paying for the tool itself. You are paying to keep process responsibility with the supplier.
For small differences in price, that can be worth more than the savings.
"Mold" Is Often Too Broad a Word
This case also highlights a terminology problem that appears frequently in toy sourcing.
In everyday factory communication, people sometimes use the Chinese word *mó* (模) very loosely. It may be translated into English as "mold," even when the item is not really a production mold in the conventional sense.
But these are very different things:
Injection mold
Silicone compression mold
Blow mold
Printing jig
Assembly jig
Paint mask
Spray fixture
Positioning fixture
Their cost structures, lifetimes, materials, ownership, and production purposes are completely different.
When reviewing a quotation, do not rely only on the label in the spreadsheet.
Ask what the physical item actually is and what function it performs.
That one clarification can prevent a surprising amount of confusion.
A Practical Checklist Before Approving Small Tooling Charges
Before approving a tooling or fixture charge, I now think it is worth checking at least these eight questions:
1. What exactly are we buying? 2. How many sets are included in the quotation? 3. Why is that quantity required? 4. What production volume is the tooling intended to support? 5. Can the project start with fewer sets? 6. Who owns the tooling after payment? 7. Who is responsible if the tooling does not produce an acceptable result? 8. Under what conditions would additional tooling be required later?
For more expensive molds, the checklist should obviously go much further: mold life, cavity count, steel grade, modification responsibility, maintenance, storage, ownership, and transfer rights all matter.
But even for a small RMB 500 fixture, asking the right questions can improve both cost control and supplier accountability.
The Lesson Was Not About Bargaining
The most valuable part of this case was not saving RMB 1,000.
It was understanding why the extra RMB 1,000 appeared in the first place.
The supplier was not necessarily trying to overcharge us. Their subcontractor had simply quoted a production setup that included more fixture capacity than our current project needed.
Once that assumption became visible, the solution was straightforward.
No aggressive negotiation was required.
No supplier had to "lose" the negotiation.
We simply aligned the tooling configuration with the real production requirement.
That is a much healthier way to manage product development.
Toy sourcing is often described as a battle over price. In practice, some of the best cost reductions come from something much less dramatic:
Ask better questions.
Before telling a supplier that a quotation is too expensive, first make sure you understand exactly what they have quoted.
You may discover that the real problem is not the price at all.
It is the assumption behind it.
*ToyRD shares practical lessons from real toy-development work: product engineering, sourcing, tooling, manufacturing, compliance, and the small decisions that determine whether a toy can move successfully from idea to mass production.*
Why approval gates, written decisions, and clear processes matter in product development
In a small product development team, informal communication can work surprisingly well.
The boss walks into the R&D office and says, “Go ahead with the tooling.” A salesperson tells an engineer that the customer wants a color change. Someone sends a supplier a message, and the project moves forward.
When there are only a few people and a few projects, this can feel fast and efficient.
But as the number of products, suppliers, customers, engineers, quotations, samples, molds, certifications, packaging files, and revisions increases, this way of working starts to break down.
The problem is not that people stop working hard.
The problem is that the company is still trying to run on memory, verbal instructions, and personal judgment when the organization has already become too complicated for that.
At ToyRD, I want to document the parts of product development that rarely appear in textbooks: customer requests that change halfway through a project, suppliers that say “yes” before fully checking, managers who disagree, prototypes that move forward too early, and tooling decisions that suddenly turn uncertainty into real cost.
From that perspective, a professional R&D process is not about adding bureaucracy. It is about making important decisions visible, traceable, and executable.
A good process turns “someone said so” into a decision the whole team can follow.
Note: The example below is adapted from real patterns I have seen in product-development environments. Identifying details have been changed and simplified.
A Familiar Problem in a Family-Run Company
Clear approval gates turn conflicting directions into a decision the whole team can follow.
Consider a consumer-products company managed by a father and his son.
The father founded the business. He has decades of experience and is comfortable making decisions quickly based on instinct. He knows the suppliers, understands the market, and often has a strong feeling about whether a product is worth pursuing.
His son is more involved in sales, customers, pricing, and commercial planning.
One afternoon, the father looks at a new product prototype and tells the R&D team:
“This looks good. Start the tooling. We need to move quickly.”
The engineers begin preparing files for the mold supplier.
The next morning, the son hears about it and says:
“Do not start tooling yet. The customer has not confirmed the target price.”
The team stops.
A day later, the father asks why nothing has happened.
“I already approved it. Why are we still waiting?”
Now the R&D manager is stuck in the middle.
Who should the team listen to?
The father?
The son?
The latest instruction?
The person with the strongest opinion?
At first glance, this looks like a conflict between two managers.
But the deeper problem is different.
The company has never clearly defined one simple question:
What exactly must happen before a project is officially approved for tooling?
Without that definition, every project depends on interpretation.
And interpretation becomes dangerous when money, tooling, lead time, testing, and customer commitments are involved.
This is one reason I believe process becomes most valuable not when people agree, but when reasonable people disagree.
A good process does not decide who is right. It decides where the disagreement must be resolved before execution continues.
The Real Purpose of a Process: Define Who Decides What
Many companies already know *how* to develop a product.
The difficult part is defining:
Who proposes a change?
Who reviews the technical feasibility?
Who confirms the cost?
Who checks the commercial assumptions?
Who approves the investment?
Who is allowed to tell the supplier to proceed?
Without these boundaries, everyone can be involved while nobody is truly responsible.
If one of these steps is missing, the project may still move forward—but the risk moves forward with it.
Sales may assume R&D has approved the change.
R&D may assume management has approved the extra cost.
The supplier may assume the customer has already confirmed the design.
And by the time someone realizes that the decision was never formally made, samples may have been produced, tooling may have started, or delivery time may already have been affected.
That is why the most important parts of a process are often not the arrows in a flowchart.
They are the decision gates.
At ToyRD, this is the distinction I care about most: a process should be designed around decisions that change risk, cost, or reversibility—not around forms for their own sake.
Written Decisions Are More Valuable Than “Everyone Knows”
One of the most dangerous phrases inside a company is:
“Everyone should know this already.”
A reliable team should not depend on what everyone *should* remember.
Important decisions should leave a trace.
For example, this is not a useful project record:
“Change the dog ear color.”
Six months later, nobody knows:
Which version was changed?
What color was approved?
Who requested it?
Did the customer approve it?
Did the cost increase?
Did the supplier already make the sample?
A useful record would look more like this:
V3: Dog-ear color changed from Pantone A to Pantone B. Spray-painting process added. Unit cost increased by RMB 0.35. Customer confirmation received on August 26. Approved to proceed with the next sample.
Now the decision has a version, a reason, a cost impact, an approval status, and a next step.
That is what “traceable” actually means.
It does not mean creating paperwork for the sake of paperwork.
It means that months later, another engineer—or even a new employee—can understand what happened without relying on someone’s memory.
In physical product development, this matters even more because decisions often become physical objects: a sample, a mold insert, a PCB, a printed package, a certification sample, or thousands of finished units.
Once a vague instruction becomes a physical object, correcting it gets expensive.
A Process Should Reduce Communication, Not Create More of It
A visible development process makes the current stage and the next decision clear.
People often associate approval systems with bureaucracy.
That can certainly happen when a process is badly designed.
But a good process should actually reduce unnecessary communication.
Without a clear system, teams repeatedly ask questions such as:
Has the boss approved this?
Has the customer confirmed the sample?
Is this the final version?
Can we send the tooling deposit?
Who approved this cost?
Are we allowed to release the drawing to the supplier?
These questions exist because the project is sitting in an ambiguous state.
A clearer development system might use stages such as:
When the status is clear, the team does not need to keep asking what they are allowed to do next.
The process answers the question.
This is an important principle for small teams in particular. A process should not be a second job layered on top of product development. It should remove repeated clarification, reduce rework, and make the current state obvious.
The Process Did Not Eliminate Disagreement
Back to the father-and-son company.
The company eventually introduced a more structured development process.
Tooling could no longer begin simply because someone said, “Go ahead.”
Before a project entered Tooling Approved, several points had to be confirmed:
The basic structure was frozen.
The tooling quotation had been reviewed.
The expected product cost was understood.
The customer’s target price or commercial direction was clear.
The expected order quantity had been discussed.
The person with final investment authority had formally approved the tooling.
This did not mean the father and son suddenly agreed on everything.
The father could still say:
“We should move now. If we wait too long, we will miss the market.”
The son could still reply:
“The customer has not committed yet. I do not want to spend on tooling before the business case is clear.”
Both opinions could still be valid.
The important change was that their disagreement now had a place to be resolved.
Before the process, disagreement leaked directly into execution.
After the process, the discussion had to end at a defined approval point before the team moved forward.
The process did not eliminate disagreement. It stopped disagreement from leaking into execution.
That distinction matters.
In my view, this is one of the strongest reasons to formalize a workflow. The workflow is not there because managers should never change their minds. It is there so that a change of mind becomes a visible new decision instead of silently overwriting the old one.
Good R&D Processes Need Gates, Not Endless Forms
A product development process should contain a small number of meaningful gates.
The exact structure depends on the company, but a typical toy or consumer-product development workflow might include the following.
Gate 1: Is This Project Worth Developing?
Before engineering resources are committed, the team should understand the basic business case.
Questions may include:
Who is the customer?
Is this ODM, OEM, or internal development?
What is the expected order quantity?
Is this a test order or a long-term program?
What is the target price?
What development investment might be required?
Not every idea deserves the same amount of engineering time.
Gate 2: Is It Technically Feasible?
The engineering team reviews the concept.
For toys and baby products, this may involve:
Mechanical structure
Electronics
Firmware or app requirements
Battery and power design
Material selection
Safety risks
Testing requirements
Regulatory considerations
This is where an attractive concept begins to meet engineering reality.
Gate 3: Does the Cost Make Sense?
The company should understand not only the unit cost, but also the development investment.
That may include:
BOM cost
Tooling cost
Decoration processes
Packaging
Testing and certification
Sample cost
MOQ
One-time engineering expenses
A product with an acceptable unit price can still be a poor project if the tooling investment is too high for the expected order volume.
Gate 4: Are We Really Ready to Start Tooling?
This is one of the most important gates in physical product development.
Once steel is cut, flexibility decreases quickly.
Before tooling begins, the company should know:
Which design revision is being tooled?
What is still open?
Who accepted the tooling quotation?
Who accepted the commercial risk?
What happens if the customer changes direction?
I keep returning to tooling in ToyRD articles because it is such a clear example of an irreversible decision. Before tooling, uncertainty is mostly discussion, CAD, samples, and engineering time. After tooling begins, uncertainty becomes money.
Gate 5: Is the Final Sample Approved?
The sample used for production should be clearly identified.
Ideally, there should be a defined golden sample or final approved sample, together with the relevant drawings, BOM revision, artwork, firmware version, and packaging files.
“Use the latest sample” is not a system.
A production team should know exactly what “latest” means.
Gate 6: Are We Ready for Production?
Before mass production, the team should confirm that critical open issues have been closed.
Depending on the product, this might include:
Product testing
Compliance documentation
Packaging approval
Instruction manual
Labeling
Software or firmware version
Quality requirements
Production sample approval
The goal is not to create a perfect document system.
The goal is to prevent known uncertainty from quietly becoming production risk.
Different Decisions Deserve Different Levels of Approval
One mistake companies make is treating every change as equally important.
They are not.
Changing the position of a small printing graphic is not the same as modifying a PCB.
Changing a packaging sentence is not the same as opening a new mold.
Changing a decorative color is not the same as changing a safety-related structure.
A useful principle is:
Different decisions deserve different levels of approval.
Low-risk changes should move quickly.
High-cost, high-risk, or difficult-to-reverse decisions should require stronger confirmation.
This is how a process avoids becoming bureaucracy.
The process should be proportional to the risk.
The cost of the process should never exceed the risk it is trying to control.
If a ten-minute problem requires three forms and five signatures, the process itself has become waste.
Process Is Also a Boundary of Responsibility
A good workflow does more than define project stages.
It defines responsibility.
For example:
Sales owns the commercial requirement and customer communication.
R&D owns technical feasibility and engineering judgment.
Purchasing owns supplier communication, quotation, and sourcing support.
Quality or compliance owns testing and regulatory requirements.
Management owns major investment decisions.
The exact boundaries vary from company to company.
What matters is that the team knows where one person’s responsibility ends and another begins.
Without this, companies often reach the same uncomfortable situation:
Everyone was involved, but nobody was responsible.
A process is not mainly useful when something goes wrong and management wants to find someone to blame.
Its real value appears earlier.
It tells people what they are responsible for *before* the problem happens.
What I Would Actually Implement in a Small R&D Team
A shared record keeps revisions, approvals, and open risks visible beyond any one person’s memory.
I do not think a small product-development team needs an expensive enterprise system before it can become more disciplined.
If I were starting from a messy, mostly verbal workflow, I would begin with five very simple things.
1. A Visible Project Status
Every active project should have one clearly defined current stage.
Not “almost ready.” Not “probably waiting for the customer.”
Something explicit, such as:
Prototype Testing — Waiting for Customer Approval
2. A Short Decision Log
For every meaningful change, record:
Date
Revision
Decision
Reason
Cost or schedule impact
Approver
Next action
This can be extremely simple. The important thing is that the decision survives the conversation.
3. A Few Hard Approval Gates
Do not create twenty approval points.
Start with the decisions that can create the biggest losses if they are misunderstood:
Development investment
Tooling release
Major structural change
Final sample approval
Production release
4. One Source of Truth for Revisions
The drawing revision, BOM revision, sample status, artwork revision, and firmware version should not live in five unrelated chat histories.
The team needs one place where the current approved state is visible.
5. Escalation Rules
When two managers disagree, the R&D team should not have to guess whose instruction wins.
The system should define who has final authority for different types of decisions.
This is less glamorous than a new PLM system, but in many small teams it creates far more value.
It is also the kind of practical system I want ToyRD to keep exploring: not process for process’s sake, but small mechanisms that prevent expensive ambiguity.
The Best Process Makes the Company Less Dependent on Individuals
There is a simple test for whether a development organization is mature.
Ask what happens when a key person is absent for two weeks.
If the project stops because nobody knows:
What was approved,
Which sample is current,
Why a change was made,
What the supplier promised,
Who has authority to make the next decision,
then the company does not really have a system.
It has experienced people holding the system together in their heads.
That can work for years.
But it is fragile.
A better organization allows someone else to open the project record and understand:
1. Where the project is now. 2. What has already been decided. 3. Why those decisions were made. 4. What risks are still open. 5. Who must approve the next step.
At that point, the company begins to operate more like a machine—not because people are treated like machines, but because the system remembers the rules while people focus on judgment.
That is an important difference.
When Experience Becomes Process, It Becomes Organizational Capability
An experienced R&D manager may carry hundreds of lessons from previous projects.
They know which supplier promises are dangerous.
They know when a sample is not ready for tooling.
They know which customer changes are likely to affect certification.
They know when a quotation looks incomplete.
They know what information must be confirmed before money is committed.
If all of this knowledge remains inside one person’s head, it is personal experience.
But when those lessons are converted into:
Approval gates
Checklists
Revision logs
BOM controls
Quotation templates
Tooling approval records
Sample approval forms
Decision logs
then experience becomes a repeatable system.
And a repeatable system becomes organizational capability.
When experience becomes a process, individual knowledge becomes organizational capability.
That is the real reason an R&D team needs process.
Not because every decision should be slow.
Not because every action needs a form.
And not because management wants more control.
The goal is much simpler:
Important decisions should not disappear into conversations.
They should become visible decisions that the whole team can follow.
Why I Am Writing About This on ToyRD
ToyRD is not intended to be a collection of abstract management theory.
What interests me is the practical layer between an idea and a product that can actually be manufactured: quotations, samples, tooling, BOMs, supplier follow-up, testing, approvals, revisions, and the hundreds of small decisions that determine whether a project stays under control.
Many of these problems look trivial when described one by one.
A missing approval line. An outdated BOM. A supplier working from the wrong drawing. A manager changing direction in a chat message. A customer request that never made it into the project record.
But this is exactly where physical product development becomes difficult.
Over time, I want ToyRD to do more than write about these problems. I also want to turn some of these lessons into practical tools: tooling approval checklists, quotation review tools, BOM controls, sample approval records, costing tools, and lightweight project-development templates that small teams can actually use.
That is the ToyRD approach I want to build around:
Real product-development problems, converted into practical systems and tools.
Because the goal is not to make a company look more organized.
The goal is to make fewer expensive mistakes.
ToyRD — Practical thinking, tools, and field notes for toy and physical product development.toyrd.com
In toy development, the most expensive compliance problem is not always a failed test.
Sometimes the bigger problem starts earlier: a new regulation is interpreted in a certain way, the product is redesigned around that interpretation, and the redesign then triggers a different set of safety requirements.
What looks like a conflict between two regulations may actually be a chain reaction caused by an earlier design decision.
We recently came across a good example involving a rechargeable electronic toy. The case is useful because it shows why compliance should not be treated as something that happens only after a sample arrives at the laboratory.
At ToyRD, this is exactly the kind of problem we like to examine from the development side: not only *what does the standard say?*, but also *what product definition did we create before the standard was applied?*
The Original Product Was Never Designed for Consumer Battery Replacement
Battery serviceability changes the enclosure design and must be considered alongside toy-safety requirements.
The product was a rechargeable electronic toy with sound and light functions.
Internally, it contained the usual components: a PCB, a rechargeable lithium-polymer battery, a speaker, LEDs, and a charging circuit.
The original enclosure was simple. The upper and lower plastic housings were joined by ultrasonic welding.
From a product-use perspective, there was no reason for the consumer to open the housing. The user could charge and operate the toy normally, while the battery remained inside the product.
In other words, the original design logic was:
Rechargeable product, sealed enclosure, no user battery replacement.
Then the EU Batteries Regulation entered the discussion.
"The Battery Must Be Replaceable" Became "The Consumer Must Replace It"
Regulation (EU) 2023/1542 introduced new requirements for the removability and replaceability of portable batteries.
Article 11 establishes a general rule that portable batteries incorporated into products should be readily removable and replaceable by the end-user during the lifetime of the product. It also explains that commercially available tools may be used; "removable" does not necessarily mean tool-free.
The requirement under Article 11 applies from 18 February 2027.
When the customer first heard about this requirement, the interpretation was understandable:
The battery can no longer be permanently sealed inside the product.
But the next assumption was more consequential:
Therefore, the consumer must be able to open the toy and replace the battery personally.
That assumption immediately became a mechanical-design decision.
The original ultrasonic-welded enclosure was changed to a screw-closed enclosure.
On the surface, this looked like a straightforward compliance improvement:
Ultrasonic welding = cannot open.Screws = can open.
But something more important than the fastening method had changed.
The product's serviceability definition had changed.
It was no longer merely a rechargeable product with an internal battery. It was moving toward being defined as a product whose internal battery was intentionally accessible for replacement by the user.
That distinction matters.
One Sentence in the Instructions Changed the Compliance Path Again
Later, the customer prepared the user instructions and included wording stating that the consumer could open the product and replace the internal battery.
That sentence reinforced the new product definition.
From a compliance perspective, the laboratory was no longer looking only at a rechargeable toy with an internal battery. The documentation now explicitly described a product that the user was expected to open in order to access and replace that battery.
That naturally raised another set of questions.
If the user is expected to open this part of the toy:
How is access controlled?
Can a child gain access to the battery?
What happens to the screws after the cover is opened?
Are the fasteners part of the battery-safety system?
Does the battery compartment construction meet the applicable toy electrical-safety requirements?
This is where EN IEC 62115 entered the picture.
The laboratory was not contradicting the EU Batteries Regulation. It was evaluating the product that had now been presented to it: a toy with an intentionally openable battery-access structure.
Then the 20 N for 10 Seconds Requirement Appeared
When a battery-access design is intended for users, its fastening and safety functions must be validated as a complete system.
EN IEC 62115:2020+A11:2020 includes requirements for fasteners used to secure doors or covers that provide access to a battery compartment.
Clause 13.4.6 addresses captive battery-compartment fasteners. Where the clause applies, the screw or similar fastener is expected to remain with the door, cover, or equipment after opening.
The associated test applies a force of 20 N for 10 seconds to the fastener.
An important engineering detail is that this is 20 N of force, not a torque value.
From the laboratory's perspective, this requirement makes sense. If a screw is part of the system that prevents inappropriate access to a battery, losing that screw after opening the compartment could undermine the safety function during later use.
But from the project team's perspective, the situation suddenly looked contradictory:
The EU wants the battery to be replaceable.
while at the same time:
The toy-safety standard places additional restrictions on the construction used to access the battery.
The natural reaction is to ask:
Which rule are we supposed to follow?
The better question is:
Did the first rule actually require us to define the product this way?
Go Back Upstream: What Does the EU Batteries Regulation Actually Require?
Article 11 of Regulation (EU) 2023/1542 does establish a strong general principle of battery removability and replaceability.
For many products, the intention is clear: a battery should not unnecessarily turn an otherwise usable product into waste simply because the battery has reached the end of its useful life.
But the regulation also recognizes that end-user replacement is not always compatible with product safety.
Article 11 includes derogation mechanisms under which certain products may be designed so that the battery is removable and replaceable only by independent professionals.
That distinction is critical.
"The battery must be replaceable" does not always mean "the ordinary consumer must personally open the product and replace it."
For a child-related product, that difference can completely change the engineering solution.
A product may need to be serviceable without being designed as a consumer-openable battery compartment.
July 2026 Made the Toy Case Much More Relevant
On 14 July 2026, the European Commission adopted Commission Delegated Regulation C(2026) 5031 final, supplementing the Batteries Regulation with additional derogations from the end-user removability and replaceability requirement.
One of the specifically listed categories is:
electric toys that incorporate rechargeable batteries
The proposed derogation applies until 31 July 2030 where, due to the nature or size of the toy, the derogation is necessary to ensure the safety of the toy.
Under that route, the rechargeable battery may be removable and replaceable only by independent professionals, rather than by the end-user.
This is an important development for rechargeable toy design.
It reflects a basic safety reality: the policy goal of making batteries replaceable should not force a toy manufacturer to introduce a new child-access hazard simply to make the battery easier for a consumer to reach.
There is, however, an important status note.
At the time of writing, 30 August 2026, C(2026) 5031 has been adopted by the European Commission but is still within the European Parliament and Council scrutiny process. EUR-Lex lists 14 October 2026 as the foreseen end of the objection period. The act enters into force only after the required procedure and publication in the Official Journal are completed.
So it should not yet be described as a fully effective exemption without that qualification.
The 2030 Toy Safety Rules Show the Same Direction
The regulatory direction becomes even clearer when we look at Regulation (EU) 2025/2509, the new EU Toy Safety Regulation, which will replace the current Toy Safety Directive from 1 August 2030.
Its electrical-safety provisions state that batteries constituting small parts must not be accessible without a tool. It also provides that, where the size or nature of the toy requires it, a rechargeable battery may instead be made inaccessible and removable or replaceable only by independent professionals.
This helps explain why the 2026 delegated act provides a temporary toy-related derogation through 31 July 2030.
The policy direction is not:
Make every rechargeable toy easy for a consumer to open.
It is closer to:
Make battery replacement possible, while preserving the safety level required for the toy.
Those are very different design objectives.
Now the Original Project Becomes Much Easier to Understand
If we map the project as a development chain, the problem is clearer:
EU Batteries Regulation introduces battery removability and replaceability requirements
↓
interpreted as
The consumer must personally replace the internal battery
↓
therefore
Ultrasonic welding is replaced by screws
↓
the instructions state
The consumer can open the product and replace the battery
↓
the product is now presented as
User-openable with accessible battery replacement
↓
the laboratory evaluates the resulting structure under the relevant battery-access requirements of EN IEC 62115
The Batteries Regulation did not directly create the EN IEC 62115 fastener problem.
The intermediate product-definition decision did.
That is why describing the situation simply as "two regulations are conflicting" misses the most useful lesson.
Do Not Start by Asking How to Make the Screw Pass
Once a laboratory raises the 20 N / 10 s requirement, the immediate engineering reaction is often:
How do we redesign the screw?
Maybe use a captive screw. Maybe change the thread. Maybe modify the housing. Maybe change the cover.
Those may eventually be necessary.
But at ToyRD, we would first move one step upstream and ask:
Does this product actually need to be defined as consumer battery-replaceable?
That question should be answered before committing to another structural redesign.
If the applicable regulatory route allows this particular rechargeable toy to use independent-professional battery replacement, then the product design, risk assessment, instructions, and laboratory test definition should all follow that same logic.
The instructions should not simultaneously tell an ordinary consumer to open the toy and replace the battery themselves.
On the other hand, if the commercial decision is genuinely to provide consumer battery replacement, then the product should be engineered from the beginning as a proper user-serviceable battery system, with all the corresponding toy-safety requirements considered.
Simply changing ultrasonic welding into several ordinary screws is not the same as designing a compliant consumer-accessible battery compartment.
Deleting One Sentence from the Manual Is Not the Whole Solution
Battery replacement must remain possible without turning a child-safe toy into a consumer-openable battery compartment.
In this case, removing the statement that the consumer can replace the battery may be part of the correction.
But changing the manual alone is not enough.
The project needs four things to agree with each other:
Regulatory path → Product design → User instructions → Laboratory test definition
If the intended route is professional battery replacement, the product and instructions should consistently reflect that.
If the intended route is end-user replacement, the enclosure and battery-access system should be designed accordingly.
A compliance document should describe the product that actually exists.
It should not be used to create a different product definition after the engineering work has already been completed.
This Is Why ToyRD Focuses on Design-Stage Compliance
Compliance is often treated as the last step of product development:
That approach works until a test failure reveals that the problem started much earlier.
By the time the laboratory identifies the issue:
the enclosure may already be tooled;
the PCB may already be frozen;
production samples may exist;
manuals may be written;
packaging may be in artwork;
schedules may already be committed.
At that stage, a misunderstanding that originally cost nothing to correct can become an expensive engineering change.
At ToyRD, we prefer a different question:
Before changing the product, are we sure we are solving the requirement that actually applies?
This is part of what we mean by a development-stage Second Opinion.
Sometimes the most valuable compliance input is not another test.
It is stopping a design change long enough to verify why that change is being made.
Four Questions Before Changing a Toy Because "The EU Requires It"
Whenever a new regulatory requirement reaches the engineering team, these four questions are worth asking before modifying the product.
1. What regulation or standard are we actually talking about?
"The EU requires it" is not a specification.
Find the regulation, article, standard, clause, or official guidance behind the request.
2. What does the original requirement actually say?
A regulatory objective and an engineering solution are not the same thing.
"The battery must be replaceable" is a regulatory requirement.
"Therefore the consumer must remove four screws and replace it personally" is an engineering interpretation.
There may be other compliant routes.
3. Does this exact requirement apply to this exact product?
Battery type, toy category, age grading, safety risks, product construction, intended use, and placing-on-the-market date can all affect the answer.
Compliance should always return to the actual product.
4. Will this design change trigger another requirement?
This is where engineering and compliance have to meet.
Changing one fastening method may change:
battery accessibility;
child access;
small-parts risks;
fastener requirements;
servicing method;
instructions;
risk assessment;
laboratory test conditions.
A product is evaluated as a system, not one regulation at a time.
Regulatory Misinterpretation Has a Real Development Cost
There is a type of product-development cost that rarely appears in a BOM:
Regulatory Misinterpretation Cost.
A tooling modification costs money.
Another prototype round costs money.
Another laboratory submission costs money.
Updating the manual and packaging costs money.
A delayed launch costs money.
But sometimes all of those costs begin with a sentence like:
"We heard the EU will require this."
The purpose of good compliance work is therefore not only to tell a team which clause to test.
It is also to help the development team determine what that clause means before it becomes plastic, tooling, documentation, and production inventory.
For ToyRD, that is an important part of R&D intelligence:
Understand the regulation. Define the product correctly. Then design the solution.
Sometimes a useful Second Opinion does not add another feature or another test.
Sometimes it simply asks, before the mold is changed:
Are we solving the right problem?
Disclaimer: This article discusses product-development and regulatory reasoning and is not legal advice. Applicability depends on the specific product, battery, intended use, age grading, market-entry date, final legislation in force, and assessment by competent compliance professionals or laboratories.
References
1. Regulation (EU) 2023/1542 on batteries and waste batteries — Article 11, removability and replaceability of portable batteries. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1542
2. European Commission, "Commission adds exemptions to rules on removability of portable batteries," 14 July 2026. https://environment.ec.europa.eu/news/commission-adds-exemptions-portable-battery-removal-rules-2026-07-14_en
4. Regulation (EU) 2025/2509 on the safety of toys — Annex II, Part IV, Electrical Properties. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32025R2509
5. EN IEC 62115:2020+A11:2020 — Electric toys — Safety, Clause 13.4.6, Battery compartment fasteners. Consult an authorized copy of the standard for the full normative text.
When a toy project begins, most people naturally focus on the idea.
Is the design attractive enough? Is the function innovative? Will customers like it? Will it make people stop and take a closer look at a trade show?
But after spending enough time in product development, I have gradually come to believe that many projects do not fail because of the idea. They fail because of execution.
A good concept may miss a customer’s internal review simply because the sample was two weeks late. A project that was already close to approval may slowly lose momentum because the supplier keeps delaying the sample. A product that still has room for cost optimization may end up in endless price negotiations simply because the quotation only shows one total number, with no visibility into where the cost actually comes from.
None of these sound like “technical problems.”
But in reality, they often have a bigger impact on whether a project succeeds than the technical problems themselves.
Deadlines Matter, but a Deadline Alone Does Not Prevent Delays
Smaller, verifiable checkpoints make delays visible early enough to act.
When we work with suppliers, we normally give them a clear deadline.
For example, a prototype, tooling sample, PCB sample, or packaging sample may need to be completed by a certain date. To be safe, we usually start following up one or two days before the deadline.
This is a very common approach.
But the reality is simple:
Even if you start chasing in advance, the sample can still be late.
I used to think the main reason was that the supplier lacked execution, or that our project was not high enough on their priority list.
Those situations certainly happen.
But I later realized that the bigger problem is this:
By the time you discover that the project is going to be delayed, it is often already too late.
A deadline is only the final point in time.
Imagine that a supplier originally planned to prepare materials on Monday, process parts on Tuesday, assemble on Wednesday, and test on Thursday.
If something already went wrong on Tuesday, but you do not ask about progress until Thursday, then no matter how urgently you chase them, the lost time is already gone.
So instead of only “chasing the deadline,” a more effective method is to break one large deadline into several smaller checkpoints that can actually be verified.
For example:
Have the raw materials arrived?
Has machining started?
Has the PCB been soldered?
Has the plush sewing been completed?
Has the mold gone onto the machine?
Can you send a photo of the current sample status?
What exactly is blocking progress today?
The purpose of these questions is not to put more pressure on the supplier.
The value is that they help you discover earlier when the project has already started drifting away from the original plan.
If you know on Tuesday that a key part still has not arrived, the R&D team still has time to decide:
Should we wait?
Should we switch suppliers?
Should we build a functional sample first?
Should we send the completed parts to the customer for early confirmation?
The real value is not how much faster you can push the supplier at the end.
It is knowing a few days earlier that the target date may no longer be realistic.
Those few days are often where project management can actually recover time.
One Core Part of R&D Management Is Making Risk Visible Earlier
A lot of R&D work appears to be about managing the product.
Drawing, revising structures, confirming electronics, testing functions, approving samples, following tooling, following packaging.
But if you step back, you realize that a large part of what an R&D manager actually deals with every day is information.
Who is working on what?
Which part of the project is already at risk?
When a supplier says “no problem,” is there really no problem — or have they simply not started yet?
When must the customer see the sample?
Which issue, if left unresolved today, will affect the whole project three days later?
So project management is not only about assigning a completion date.
More importantly, it is about creating a mechanism that allows bad news to appear as early as possible.
That may sound counterintuitive.
Everyone likes to hear “yes,” “no problem,” and “we can make it.”
But in product development, the earlier you know that something may not make it in time, the safer the project becomes.
Because there is still time to adjust.
The most dangerous situation is not that a problem exists.
It is that the problem has already existed for days while everyone still believes the project is on track.
Quotation Works the Same Way: One Total Price Is Often Not Enough
A transparent quotation makes cost a design decision, not just a negotiation.
Another interesting thing I have seen is how some highly experienced buyers handle quotations.
When they receive a price, they rarely look only at the final number.
They keep breaking it down.
How much is the plastic?
How much is the electronics?
How much is the speaker?
How much is the plush material?
How much is the packaging?
How much is the labor?
How much could be saved by removing one printing process?
How much could be saved by changing one component to a different material?
At first, this style of purchasing can feel like the buyer is simply trying to negotiate every line item down.
But over time, I have come to appreciate the logic behind it.
Because professional cost control is not really asking:
“Can you make it cheaper?”
It is asking:
“Where is the cost coming from?”
These two questions may sound similar, but they lead to completely different conversations.
The first usually has only one outcome: the supplier gives up a little more margin.
The second can actually change the product.
For example, a product may be too expensive not because the supplier’s margin is too high, but because:
one component uses an unnecessarily high material specification;
there are too many printing processes;
a metal part is structurally too complicated;
the packaging volume is too large;
the PCB includes components that are not really necessary;
one cosmetic effect requires an additional production process;
the order quantity is too small to spread fixed costs efficiently.
Once these costs are broken down, R&D, purchasing, and the customer can make much better decisions together.
Maybe the customer wants to keep the appearance but remove one function.
Maybe the electronics specification cannot be reduced, but the packaging can be optimized.
Maybe one expensive component is actually a key selling point, and another cost item should be changed instead.
The purpose of breaking down a quotation is not only to push the price lower. It is to turn cost into something that can be understood, discussed, traded off, and designed.
Good R&D Is Not Just About Getting the Product Made
I used to think of R&D mainly as “solving technical problems.”
Now I think that definition is too narrow.
A mature R&D engineer — or a mature R&D team — does not only need to make the product work.
They also need to keep asking several very practical questions:
Is the timeline still under control?
Are we spending money on the parts that truly create value?
Are risks being discovered early enough?
Are the supplier, purchasing team, engineers, and customer all working with the same information?
Very often, what determines whether a toy project succeeds is not one brilliant idea.
It is a collection of small, unglamorous execution details.
Was the deadline broken into process checkpoints?
When the supplier said “almost finished,” did anyone verify the actual progress?
When the quotation came in, did anyone understand the real cost structure?
When a risk appeared, was it discovered on the final day — or one week earlier?
These things rarely appear in a product brochure.
And people rarely talk about them.
But they are a very real part of toy development.
That is also what I hope to keep documenting on ToyRD:
Not only how a toy should be designed, but how a toy is actually developed and made inside a real supply chain.
