Tag: Approval Gates

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

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.

A typical development change might look simple:

Customer request → Sales communication → R&D feasibility review → Supplier quotation → Cost evaluation → Management approval → Customer confirmation → Execution

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

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:

Concept → Feasibility Review → Quotation → Commercial Approval → Prototype → Testing → Tooling Approved → Final Sample → Production Release

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.

For example:

| Change | Typical Approval Level | |—|—| | Minor artwork correction | Designer + project owner | | Color change with no cost impact | Project owner | | Cost increase | Sales/commercial approval | | Structural change | R&D approval | | Tooling modification | R&D + management approval | | New tooling investment | Formal investment approval | | Safety-related change | Engineering + compliance review |

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

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