Tag: Project Management

  • Many Toy Projects Don’t Fail Because of the Idea — They Fail Because of Execution

    Many Toy Projects Don’t Fail Because of the Idea — They Fail Because of Execution

    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

    Toy manufacturing checkpoint board, supplier update, test checklist, fabric samples, and electronics board.
    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

    Toy components, cost sheet, calculator, packaging notes, and product sketch used to review toy development cost.
    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.