It’s a bustling Saturday evening in the kitchen of a popular Quick Service Restaurant (QSR) chain. The screens are lighting up with online orders, and every member of the team is in overdrive. Kitchen Order Tickets (KOTs) are flying off the printer. One person is rushing to assemble ingredient kits, while another is sprinting across the kitchen to hand them off to the chefs. The chefs are juggling multiple pans, shouting over each other, scanning tickets, arranging and sorting ingredient kits, searching for missing sauces, and trying not to burn anything in the process. Outside, the queue is getting longer. Delivery partners from Zomato and Swiggy are growing increasingly impatient. Customer complaints are beginning to pile up.&nbsp;Everyone is working as hard and fast as they possibly can, yet delays are piling up. This is a familiar story playing out across QSR chains during their busiest hours. Each restaurant staff member is trying their best, sweating it out, working at full tilt. Still, orders don’t leave the restaurant on time. Something is clearly broken… Is it people? Is it the process? Or does the root cause lie somewhere else?&nbsp;Let’s find out...&nbsp;For QSR chains, the most critical performance metric is quick food delivery to customers and this lead time experienced by customers includes two parts:<figure class="image"><img style="aspect-ratio:8334/2711;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-01_1758784836.png" width="8334" height="2711"></figure>Delivery time is handled by food delivery aggregators, but the kitchen’s internal performance, KPT, is what the restaurant controls directly. And it matters the most. Online platforms assign delivery partners faster to those restaurants that consistently display better KPTs. That means reducing KPT doesn't just satisfy customers, it helps improve visibility, faster deliveries, and more orders.&nbsp;So what exactly happens inside the kitchen during that crucial KPT window?<h5>Breaking down Kitchen Preparation Time (KPT)</h5><figure class="image"><img style="aspect-ratio:8334/4152;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-02_1758785020.png" width="8334" height="4152"></figure>Typically, each task is handled by dedicated personnel.&nbsp;When orders are low, the entire process flows smoothly. From order receipt to packaging, an order can be completed in just 5-7 minutes. With low order volumes, everything works like a well-oiled machine. Each person handles their assigned task calmly and with precision. Errors are minimal. The kitchen is quiet, eﬃcient, and productive. No one has to rush, shout, or search. Each step flows naturally into the next.&nbsp;But as soon as the volume of incoming orders exceeds the kitchen’s processing capacity, the situation begins to change. Queues start forming at each work centre. Since delivery speed is the top priority, staff are told to work faster, to push through the queues. Everyone speeds up.&nbsp;But here’s the issue: some parts of the process are much faster than others. The KOT printing step, for instance, operates about 50x faster than food preparation. Even the ingredient kit transfer step is around 10x faster. As these faster steps ramp up, a massive pile of ingredient kits starts forming in front of the kitchen.&nbsp;<h5>The kitchen simply can’t keep up.</h5>With limited space, these queues quickly become unorganised. Kits are no longer in sequence. Chefs pick the kits that are closest to them, or the ones they find easier to prepare. Orders start getting broken apart.&nbsp;&nbsp;A single order might have one dish ready and another still stuck somewhere in the pile. When these partial orders reach the packaging station, it adds to the chaos. Packaging staff are left shouting for missing items, trying to piece together incomplete orders. Chefs, hearing the shouts, stop what they’re doing to hunt for those missing KOTs and ingredient bowls. The kitchen becomes a noisy, disorganised warzone.&nbsp;And so, the food preparation station, the actual constraint in the system where the maximum pile of orders is formed, ends up going idle, because the chefs are too busy sorting, searching, responding to shouted questions, or trying to replenish ingredients themselves. The burners stay off while the chefs handle all the clutter. No matter how fast everyone else is working, if food preparation isn’t happening, nothing moves forward. Queue grows longer. Delays add up. KPT keeps on increasing.&nbsp;Queues forming unevenly delay kitchen output.<figure class="image"><img style="aspect-ratio:8334/7243;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-03_1758785059.png" width="8334" height="7243"></figure>At this point, it’s tempting to ask: who’s to blame? Is it the chef who is diverting from cooking and doing other activities? Or for not sticking to the First-In-First-Out sequence? Is it the person transferring the ingredient kits too quickly? Is it the packaging staff for shouting and disrupting the kitchen?&nbsp;None of them is at fault.&nbsp;The root cause lies in a deeper operational philosophy, one that says everyone should work as fast as possible. Conventionally, the way to increase speed or output of the system is to break down the complete process into each step or work centre. Calculate the capacity of each work centre and the solution is to ensure near 100% eﬃciency of each work centre. This is very intuitive and sounds logical.&nbsp;“Want to increase the output of the system? Ensure highest output from each work centre.”&nbsp;This belief drives people to focus on maximising the speed of individual tasks.&nbsp;But that’s not correct. In any process, it is the slowest step, the constraint, that determines the overall speed of the system. Increasing the speed of the other faster steps - non-constraints - doesn’t improve overall performance. Instead, it creates overload and chaos.&nbsp;In the QSR kitchen, the food preparation step is almost always the constraint. Work builds up in front of it, not because the chefs are slow, but because the steps before it are so much faster. In traditional operations thinking, you would try to maximise eﬃciency at each step. But, doing so causes more harm than good.&nbsp;This is how, in a noble effort to be eﬃcient and faster, the team unintentionally adds to the delays.&nbsp;<h5>The solution</h5>Synchronise the release of KOT with kitchen outputThe solution is to align the release of work with the pace of the constraint. This means slowing down KOT printing and the transfer of ingredient kits to match the chefs’ actual food preparation capacity. By synchronising the release, you protect the constraint from getting overwhelmed.&nbsp;Once this alignment is in place, the difference is immediate and powerful. The person transferring the kits now has enough time to ensure they are complete and sequenced correctly. The chef sees only a handful of kits at any time, not plenty, and can focus entirely on cooking. There are no mismatches, no missing items, no need for the packaging team to shout or chase. The chef no longer has to sort through a sea of orders. The burners stay active. The system begins to flow.&nbsp;Additional solutions to ensure maximum output from the food preparation stepThis simple act of slowing down the release results in a dramatic increase in output. But it doesn’t stop there. Once the constraint is protected, further improvements can be layered on.<figure class="image"><img style="aspect-ratio:8334/7243;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-04_1758785115.png" width="8334" height="7243"></figure><h5>How to manage the implementation and sustenance of the solutions across stores?</h5>Most QSR chains operate between 200-500 stores or even more. Any process change or solution deployment and sustenance across this kind of scale is always a challenge.&nbsp;The first step is piloting the solution in a few stores to establish a strong proof of concept. This phase also allows the team to fine-tune specific solution elements and account for on-ground challenges that weren’t initially visible. Once the pilot results are clear and promising, it’s crucial to get buy-in from key stakeholders, store managers, area managers, and regional heads. Unless there is alignment on the problem and solution direction, implementation at scale won’t be possible. This is where the pilot’s success becomes an essential tool for persuasion.&nbsp;With stakeholder alignment in place, the next big question is how to implement it. Slowing down KOT inflow to match kitchen preparation speed is a great strategic direction, but the real challenge is execution. Who holds the KOTs? Where? In what order? During peak hours, it’s unrealistic to expect staff to manage this manually.&nbsp;This is where IT must step in. A robust system for KOT release must be developed and deployed. This not only makes implementation smoother, but it also reduces resistance from the ground team, because it makes their work easier, not harder.&nbsp;To sustain the improvement, continuous monitoring and reviews are essential. Helping stores overcome their individual weak spots, adjusting for real-time challenges, and having a structured process for ongoing improvement ensures that gains are not lost over time. Another effective lever is incentivising the team for better KPT performance. When the team’s goals align with the company’s goals, performance naturally follows.&nbsp;<h5>The manpower obstacle</h5>Even with the perfect system, one factor still poses a major threat: manpower. High attrition and unplanned absenteeism are chronic issues in the QSR industry. You never know when or where the next shortage will hit. Buffering every store with extra manpower would be prohibitively expensive.&nbsp;A smarter approach is to create a pool of three to four floating staff for every ten to twelve stores. This centralised manpower buffer can be deployed wherever a shortage arises, preventing manpower from becoming the new constraint. While a long-term manpower solution is more complex, this simple buffer offers an effective short-term fix.<figure class="image"><img style="aspect-ratio:8334/4916;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-05_1758785148.png" width="8334" height="4916"></figure><h5>Is this solution, ‘synchronise the release of KOT to kitchen’, applicable to all QSR chains?</h5>Well, there are exceptions. There are certain QSRs where one may not encounter this chaos in the kitchen even during peak hours. How are they managing then? These QSRs are also following the same solution of aligning the release of orders to the rate of output of the kitchen, but the tactic is different. These QSRs, usually with dine-in facilities, limit the number of available tables to ensure the inflow of orders remains aligned with the kitchen’s output capacity. As a result, one might see a queue of customers waiting outside the restaurant for a table. This way, the kitchen, the constraint, is never overwhelmed with excess WIP, and operations run smoothly. However, in the case of QSRs that are heavily dependent on delivery orders, this mechanism is not feasible. Customers won’t wait at an order window. That’s why the alignment of inflow to the kitchen has to happen internally, after the order is already received.&nbsp;Also, the necessary assumption for this solution to work is that kitchen preparation time is exponentially higher than other preceding activities. In QSRs where kitchen preparation time is not as high, the constraint might be somewhere else. And the solution in those cases is to ensure flow is aligned with that step rather than kitchen output.&nbsp;But the theme remains the same: align the speed of all activities with the slowest operation, the one where the queue of pending work is highest during peak times.<figure class="image"><img style="aspect-ratio:8334/3239;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-06_1758785167.png" width="8334" height="3239"></figure>In the end, this story is about more than just kitchen mechanics. It’s a story about how the urge to go faster can often slow us down. It’s a story about rethinking flow, constraints, and what truly drives performance.&nbsp;<h5>Conclusion</h5>When restaurants slow down just enough to match the speed of their bottlenecks, everything speeds up. Kitchen preparation time becomes more predictable. Sales grow without any new investment. Online platforms favour your store because of fast, reliable KPT. Delivery executives are assigned faster. Total delivery time drops. Customers are happier.&nbsp;Less haste really does mean more speed when you understand the system.&nbsp;

Why going fast slows you down: A deep dive into QSR kitchen chaos

It’s a bustling Saturday evening in the kitchen of a popular Quick Service Restaurant (QSR) chain. The screens are lighting up with online orders, and every member of the team is in overdrive. Kitchen Order Tickets (KOTs) are flying off the printer. One person is rushing to assemble ingredient kits, while another is sprinting across the kitchen to hand them off to the chefs. The chefs are juggling multiple pans, shouting over each other, scanning tickets, arranging and sorting ingredient kits, searching for missing sauces, and trying not to burn anything in the process. Outside, the queue is getting longer. Delivery partners from Zomato and Swiggy are growing increasingly impatient. Customer complaints are beginning to pile up.&nbsp;Everyone is working as hard and fast as they possibly can, yet delays are piling up. This is a familiar story playing out across QSR chains during their busiest hours. Each restaurant staff member is trying their best, sweating it out, working at full tilt. Still, orders don’t leave the restaurant on time. Something is clearly broken… Is it people? Is it the process? Or does the root cause lie somewhere else?&nbsp;Let’s find out...&nbsp;For QSR chains, the most critical performance metric is quick food delivery to customers and this lead time experienced by customers includes two parts:<figure class="image"><img style="aspect-ratio:8334/2711;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-01_1758784836.png" width="8334" height="2711"></figure>Delivery time is handled by food delivery aggregators, but the kitchen’s internal performance, KPT, is what the restaurant controls directly. And it matters the most. Online platforms assign delivery partners faster to those restaurants that consistently display better KPTs. That means reducing KPT doesn't just satisfy customers, it helps improve visibility, faster deliveries, and more orders.&nbsp;So what exactly happens inside the kitchen during that crucial KPT window?<h5>Breaking down Kitchen Preparation Time (KPT)</h5><figure class="image"><img style="aspect-ratio:8334/4152;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-02_1758785020.png" width="8334" height="4152"></figure>Typically, each task is handled by dedicated personnel.&nbsp;When orders are low, the entire process flows smoothly. From order receipt to packaging, an order can be completed in just 5-7 minutes. With low order volumes, everything works like a well-oiled machine. Each person handles their assigned task calmly and with precision. Errors are minimal. The kitchen is quiet, eﬃcient, and productive. No one has to rush, shout, or search. Each step flows naturally into the next.&nbsp;But as soon as the volume of incoming orders exceeds the kitchen’s processing capacity, the situation begins to change. Queues start forming at each work centre. Since delivery speed is the top priority, staff are told to work faster, to push through the queues. Everyone speeds up.&nbsp;But here’s the issue: some parts of the process are much faster than others. The KOT printing step, for instance, operates about 50x faster than food preparation. Even the ingredient kit transfer step is around 10x faster. As these faster steps ramp up, a massive pile of ingredient kits starts forming in front of the kitchen.&nbsp;<h5>The kitchen simply can’t keep up.</h5>With limited space, these queues quickly become unorganised. Kits are no longer in sequence. Chefs pick the kits that are closest to them, or the ones they find easier to prepare. Orders start getting broken apart.&nbsp;&nbsp;A single order might have one dish ready and another still stuck somewhere in the pile. When these partial orders reach the packaging station, it adds to the chaos. Packaging staff are left shouting for missing items, trying to piece together incomplete orders. Chefs, hearing the shouts, stop what they’re doing to hunt for those missing KOTs and ingredient bowls. The kitchen becomes a noisy, disorganised warzone.&nbsp;And so, the food preparation station, the actual constraint in the system where the maximum pile of orders is formed, ends up going idle, because the chefs are too busy sorting, searching, responding to shouted questions, or trying to replenish ingredients themselves. The burners stay off while the chefs handle all the clutter. No matter how fast everyone else is working, if food preparation isn’t happening, nothing moves forward. Queue grows longer. Delays add up. KPT keeps on increasing.&nbsp;<figure class="image"><img style="aspect-ratio:8334/7243;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-03_1758785059.png" width="8334" height="7243"></figure>At this point, it’s tempting to ask: who’s to blame? Is it the chef who is diverting from cooking and doing other activities? Or for not sticking to the First-In-First-Out sequence? Is it the person transferring the ingredient kits too quickly? Is it the packaging staff for shouting and disrupting the kitchen?&nbsp;None of them is at fault.&nbsp;The root cause lies in a deeper operational philosophy, one that says everyone should work as fast as possible. Conventionally, the way to increase speed or output of the system is to break down the complete process into each step or work centre. Calculate the capacity of each work centre and the solution is to ensure near 100% eﬃciency of each work centre. This is very intuitive and sounds logical.&nbsp;“Want to increase the output of the system? Ensure highest output from each work centre.”&nbsp;This belief drives people to focus on maximising the speed of individual tasks.&nbsp;But that’s not correct. In any process, it is the slowest step, the constraint, that determines the overall speed of the system. Increasing the speed of the other faster steps - non-constraints - doesn’t improve overall performance. Instead, it creates overload and chaos.&nbsp;In the QSR kitchen, the food preparation step is almost always the constraint. Work builds up in front of it, not because the chefs are slow, but because the steps before it are so much faster. In traditional operations thinking, you would try to maximise eﬃciency at each step. But, doing so causes more harm than good.&nbsp;This is how, in a noble effort to be eﬃcient and faster, the team unintentionally adds to the delays.&nbsp;<h5>The solution</h5>Synchronise the release of KOT with kitchen outputThe solution is to align the release of work with the pace of the constraint. This means slowing down KOT printing and the transfer of ingredient kits to match the chefs’ actual food preparation capacity. By synchronising the release, you protect the constraint from getting overwhelmed.&nbsp;Once this alignment is in place, the difference is immediate and powerful. The person transferring the kits now has enough time to ensure they are complete and sequenced correctly. The chef sees only a handful of kits at any time, not plenty, and can focus entirely on cooking. There are no mismatches, no missing items, no need for the packaging team to shout or chase. The chef no longer has to sort through a sea of orders. The burners stay active. The system begins to flow.&nbsp;Additional solutions to ensure maximum output from the food preparation stepThis simple act of slowing down the release results in a dramatic increase in output. But it doesn’t stop there. Once the constraint is protected, further improvements can be layered on.<figure class="image"><img style="aspect-ratio:8334/7243;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-04_1758785115.png" width="8334" height="7243"></figure><h5>How to manage the implementation and sustenance of the solutions across stores?</h5>Most QSR chains operate between 200-500 stores or even more. Any process change or solution deployment and sustenance across this kind of scale is always a challenge.&nbsp;The first step is piloting the solution in a few stores to establish a strong proof of concept. This phase also allows the team to fine-tune specific solution elements and account for on-ground challenges that weren’t initially visible. Once the pilot results are clear and promising, it’s crucial to get buy-in from key stakeholders, store managers, area managers, and regional heads. Unless there is alignment on the problem and solution direction, implementation at scale won’t be possible. This is where the pilot’s success becomes an essential tool for persuasion.&nbsp;With stakeholder alignment in place, the next big question is how to implement it. Slowing down KOT inflow to match kitchen preparation speed is a great strategic direction, but the real challenge is execution. Who holds the KOTs? Where? In what order? During peak hours, it’s unrealistic to expect staff to manage this manually.&nbsp;This is where IT must step in. A robust system for KOT release must be developed and deployed. This not only makes implementation smoother, but it also reduces resistance from the ground team, because it makes their work easier, not harder.&nbsp;To sustain the improvement, continuous monitoring and reviews are essential. Helping stores overcome their individual weak spots, adjusting for real-time challenges, and having a structured process for ongoing improvement ensures that gains are not lost over time. Another effective lever is incentivising the team for better KPT performance. When the team’s goals align with the company’s goals, performance naturally follows.&nbsp;<h5>The manpower obstacle</h5>Even with the perfect system, one factor still poses a major threat: manpower. High attrition and unplanned absenteeism are chronic issues in the QSR industry. You never know when or where the next shortage will hit. Buffering every store with extra manpower would be prohibitively expensive.&nbsp;A smarter approach is to create a pool of three to four floating staff for every ten to twelve stores. This centralised manpower buffer can be deployed wherever a shortage arises, preventing manpower from becoming the new constraint. While a long-term manpower solution is more complex, this simple buffer offers an effective short-term fix.<figure class="image"><img style="aspect-ratio:8334/4916;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-05_1758785148.png" width="8334" height="4916"></figure><h5>Is this solution, ‘synchronise the release of KOT to kitchen’, applicable to all QSR chains?</h5>Well, there are exceptions. There are certain QSRs where one may not encounter this chaos in the kitchen even during peak hours. How are they managing then? These QSRs are also following the same solution of aligning the release of orders to the rate of output of the kitchen, but the tactic is different. These QSRs, usually with dine-in facilities, limit the number of available tables to ensure the inflow of orders remains aligned with the kitchen’s output capacity. As a result, one might see a queue of customers waiting outside the restaurant for a table. This way, the kitchen, the constraint, is never overwhelmed with excess WIP, and operations run smoothly. However, in the case of QSRs that are heavily dependent on delivery orders, this mechanism is not feasible. Customers won’t wait at an order window. That’s why the alignment of inflow to the kitchen has to happen internally, after the order is already received.&nbsp;Also, the necessary assumption for this solution to work is that kitchen preparation time is exponentially higher than other preceding activities. In QSRs where kitchen preparation time is not as high, the constraint might be somewhere else. And the solution in those cases is to ensure flow is aligned with that step rather than kitchen output.&nbsp;But the theme remains the same: align the speed of all activities with the slowest operation, the one where the queue of pending work is highest during peak times.<figure class="image"><img style="aspect-ratio:8334/3239;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//websiteimageqsr-06_1758785167.png" width="8334" height="3239"></figure>In the end, this story is about more than just kitchen mechanics. It’s a story about how the urge to go faster can often slow us down. It’s a story about rethinking flow, constraints, and what truly drives performance.&nbsp;<h5>Conclusion</h5>When restaurants slow down just enough to match the speed of their bottlenecks, everything speeds up. Kitchen preparation time becomes more predictable. Sales grow without any new investment. Online platforms favour your store because of fast, reliable KPT. Delivery executives are assigned faster. Total delivery time drops. Customers are happier.&nbsp;Less haste really does mean more speed when you understand the system.&nbsp;

Indian auto OEMs' & EV startups face challenges with managing mulitple NPD projects. This article offers a solution that helps them both to manage NPD projects with better collaboration & discipline.

From ICE to EV: Steering India's automotive industry forward

India’s fast-growing EV market is seeing frantic activity with many launches, especially in the two-wheeler segment (>200 players in the segment). This is leading to rushed launches, which are actually resulting in quality issues and customer dissatisfaction. This article explains why newer OEMs struggle with synchronisation across development, manufacturing, service, and dealer networks and outlines a disciplined approach for a more reliable approach to new launches.

The launch dilemma in India’s e-mobility race: First-mover advantage or hidden trap?

India's e-mobility revolution has set off a gold rush, drawing in legacy OEMs and nimble start-ups alike. Nowhere is this more visible than in the two-wheeler EV space, which boasts &gt;200 players, each vying for an early foothold. But in this race to launch, many are discovering that being first is not the same as being ready. Despite the urgency, most EV launches in India have either been delayed or plagued by post-launch issues. Long and uncertain wait times for customers, poor after-sales service, and product recalls have become distressingly common. These issues disproportionately affect newer entrants, while traditional ICE players seem better prepared. This begs a critical question:<h6>&nbsp;</h6><h6>Why are new players unable to learn from the playbooks of established OEMs, or even from their own past mistakes?</h6>Most internal combustion engine OEMs have gone through their learning cycles and now have enough guardrails embedded in their DNA to manage the complexities of launching new platforms. New players, on the other hand, often comprise a handful of experienced individuals from the auto industry, but they are yet to fully grasp the complexity of what they are undertaking.&nbsp;<h3>The criticality of synchronisation</h3>A successful vehicle launch is not just about product readiness. It requires tight alignment across multiple fronts: product development, scale-ups, service readiness, and spare parts supply. Misalignment between these areas can have serious consequences.Booking vehicles without inventory leads to long delays. Expanding the dealer network without ensuring spare parts availability stretches service turnaround times. Opening showrooms without trained staff results in poor customer engagement and lost bookings. Each of these missteps erodes customer trust and brand equity.In most newbie OEMs, each of these streams-product development, supply chain, and dealer readiness, is treated as an independent project, typically managed by different functions. The only coordination mechanism is a shared launch date. This approach assumes alignment will happen naturally, but more often, it results in unmanaged variability and unpredictable delays.&nbsp;<h3>Product development: The first trap</h3><h4>The misappeal of the Scrum approach</h4>Many new-age OEMs, especially startups and tech-driven firms, have adopted agile methodologies like Scrum. The appeal lies in its promise of quick iterations and short feedback loops. The core philosophy of Agile is to deliver a product that is 'good enough' and to keep refining it over time. This works reasonably well for embedded systems, where one can afford to address bugs post-launch through over-the-air updates. However, an EV is not just a software platform, it is a tightly integrated product that combines embedded systems with significant mechanical systems. Unlike software, the physical elements of an EV cannot be left with known issues to be fixed later. Mechanical systems require rigorous upfront validation, including endurance testing, component life testing, and integration trials. Because of the prevailing mindset of ‘let's correct it later,’ these critical checks are often compromised when deadlines come under pressure. Scrum also doesn't adequately support the embedded systems portion of the project because it assumes dedicated, stable teams—a condition rarely met in automotive R&amp;D environments. In practice, key specialists are spread across multiple programs and sprints. As a result, sprint cycles go incomplete, and decision-making suffers due to the unavailability of subject-matter experts.&nbsp;<h3>Variant explosion and scope creep</h3>As technologies evolve and competition intensifies, OEMs frequently add features, configurations, and models mid-stream. This leads to rework across engineering, sourcing, and testing. With multiple platforms being developed in parallel, R&amp;D capacity becomes overstretched. Suppliers also fall behind. Alpha and Beta builds are created using prototype tooling. Validation cycles are compressed or skipped altogether.Uncontrolled load on NPD teams, frequent scope changes in running projects, and the application of software project management approaches all contribute to system congestion and incomplete work. These factors not only lead to undesirable waiting times and rework but also make delays inevitable and highly unpredictable.&nbsp;<h3>Scaling up: The second trap</h3>Even after overcoming development hurdles, scaling up production presents a significant challenge. Transitioning from pilot builds to full-scale manufacturing is rarely smooth.At output levels of even 200–300 vehicles per shift, quality issues persist. Yet, under pressure to show numbers, bookings are often opened prematurely. When demand exceeds installed capacity, OEMs rush to expand production. This puts immense pressure on manufacturing and sourcing. Alternate suppliers are hastily onboarded, pulling R&amp;D teams back into validation activities and away from future development.The result is a firefighting mode of operation. Output increases, but defect rates rise. Quality suffers, and the launch comes under pressure. This is how customers suffer from delayed vehicle deliveries or worse end up buying vehicles which have quality issues.&nbsp;<h3>Spare parts project: The silent crisis</h3>As new models move through development, supply chain teams are expected to ensure supplier readiness, finalise tooling, validate components, and secure after-sales stock. While structured tools like APQP and PPAP exist, timelines often slip.What does not help is the a problem of design instability during the development cycle, which keeps the supply chain in flux. Engineering change requests remain open late into the cycle, preventing the Bill of Materials (BOM) from stabilising.Delays in part releases, tooling issues, and unresolved testing results create bottlenecks. Under pressure, in some cases, suppliers are asked to deliver parts using alternative tools and processes, while in others, inventory levels can't be locked, and warehouse planning becomes impossible. Launch readiness collapses.When new vehicles finally reach the market, spare part inventories are inadequate. Service centres lack replacements, customers face long waits for simple repairs and dealers’ confidence diminishes.&nbsp;<h3>Dealer readiness: The visible gap</h3>Dealer readiness is the most visible aspect of a launch, yet often the least prepared. Building an EV-capable dealership network is not a copy-paste of ICE strategies. EV dealerships require significant investments in charging bays, diagnostic tools, and specialised training.Coordination issues between sales, marketing, and service eventually lead to dealers being on-boarded without adequate infrastructure. Marketing activates campaigns in areas where service teams are not yet present. Training programs for EV servicing-covering battery management, software integration, and safety protocols, are conducted too late. The result is a fractured experience.In some cases, feedback from dealers during early product showcases is ignored or delayed, leading to further rework. By the time vehicles arrive at showrooms, staff are under-prepared, service tools are missing, and customer support is patchy. Smaller towns face additional challenges, as dealers hesitate to invest due to unclear ROI and low footfall.&nbsp;<h3>What's the way out?</h3>The real issue is trying to do too many things with limited capacity, which results in desynchronisation across various projects. Eventually, business pressure overtakes the need to follow the rigour of NPD program management. What is required are following the below mentioned steps to ensure tight discipline in execution.<ul style="list-style-type:disc;"><li>Step 1: Throttle the R&amp;D pipeline OEMs must align their product ambitions with their actual execution capacity. The focus should shift to fewer models with clearer deliverables. Controlling variants and limiting scope creep is critical. More importantly, OEMs should prioritise finishing existing projects over starting new ones. Maintaining a fixed WIP of projects ensures better flow, minimises resource contention, and keeps development timelines under control.</li><li>Step 2: Enforcing discipline around stage gates Concept, Alpha and Beta reviews should be non-negotiable. These gates are not mere paperwork exercises but vital coordination checkpoints. Static and dynamic dealer clinics should be integrated into these stages to capture feedback, build alignment, and prepare the network.</li><li>Step 3: Launch phasing If service, supply chain, or dealer readiness is lacking in some regions, stagger the launch. Begin in markets where the ecosystem is ready. Expand only when readiness is confirmed across all functions. Good companies ensure dealers in a restricted launch area earn the desired ROI and are able to manage service load before they open newer geographies.</li></ul>Ultimately, program governance must evolve. Launches should be managed as integrated programs with real-time visibility across all streams. Status dashboards alone are insufficient. What's needed is high-frequency interventions to resolve issues, while developing the ability to shift tactics dynamically, with the sole purpose of maintaining the effectiveness of a synchronised launch. This implies taking hard decisions to delay intermediate deadlines for better effectiveness of the overall processes.Yes, the suggested approach may appear slower. It might even seem risky in a competitive market. But durability is a better strategy than speed. In the e-mobility space, credibility is rare. And it is earned not by being first but by being ready.The real question is no longer who launches first. It's who endures. This is already seen in the market shares, the legacy OEM entrants who know how to play the game are slowly eating up the market shares of the newbies.

Rising technology and regulatory costs have made VA/VE essential, yet many initiatives fail due to idea overload, execution delays, and service complexity. The article argues that significant efficiencies can be unlocked for both OEMs and suppliers by adopting a flow-based planning approach and aligning production with actual consumption. This can deliver sustainable cost reduction while creating a true OEM–supplier win-win.

VA/VE 2.0: A value 'creation' approach

In New Product Development (NPD), two truths collide. First, the need to measure individual productivity is real: assign the same design problem to different engineers, and you will often see vastly different cycle times, driven by differences in experience, problem-framing, and cognitive approach. When time-to-market (TTM) pressure is high and engineering capacity is constrained, as is common in most NPD environments, failing to measure individual productivity leaves leaders blind to load, cost, and risk. Second, the way we typically measure: hours worked, number of tasks completed, lines of code, number of drawings completed, number of design changes, number of CAD models released, number of engineering change requests closed, and so on, often misrepresents progress. It treats NPD as purely executional work, even though design engineering work is inherently non-linear, non-repeatable, interdependent, uncertain and knowledge-intensive. Engineers contribute through problem-solving, experimentation, design decisions and learning, many of which do not translate cleanly into short-term, countable outputs. What appears ‘slow’ in a weekly report can be essential learning; what looks ‘fast’ can mask unresolved risk that surfaces downstream. In addition, NPD is system-constrained rather than effort-constrained, with queues, Work-in-Progress (WIP), and decision latency dominating cycle time far more than an individual effort.&nbsp; &nbsp;The result is a persistent conflict: measure, and you distort; don’t measure, and you fly blind. This article explores why measuring individual productivity in R&amp;D is fundamentally challenging, why conventional metrics often generate misleading signals through false positives and false negatives, and how leaders can interpret productivity data more constructively to improve flow rather than distort behaviour.&nbsp;&nbsp;<h3>Seeing through false signals: False positives and false negatives&nbsp;</h3>Individual productivity numbers in NPD are noisy. Short time windows and uneven work contexts generate two kinds of systematic errors: false positives (metrics say ‘high productivity’ without real progress) and false negatives (metrics say ‘low productivity’ despite essential, value-creating work). Recognising and interpreting these signals is the difference between a learning system and a blame system. The figure below illustrates how metric signals can diverge from system reality, leading to misinterpretation unless context is applied.&nbsp;&nbsp;Let’s examine these false signals in more detail:&nbsp; &nbsp;<ol><li>False positives: When productivity looks high but isn’t&nbsp;A false positive occurs when a metric indicates exceptional productivity while the system’s underlying reality remains fragile or unfinished. These inflate confidence, mask risks, and create perverse incentives.&nbsp; &nbsp;Common causes<ul style="list-style-type:disc;"><li>Premature task/subtask closure to show progress (with assumptions untested or inputs unvalidated)</li><li>Inflated planned durations during high-level planning to later ‘beat the plan’ and look faster</li><li>Frequent replanning that optimises optics rather than clarity and flow</li><li>Working predominantly on low-risk or mature items, while others absorb first-time integrations and ambiguity&nbsp;&nbsp;</li></ul>Why are they harmful&nbsp;<ul style="list-style-type:disc;"><li>Create heroes without removing bottlenecks; unresolved risks travel downstream into costlier phases</li><li>Delay honest escalation; teams optimise for closure rather than design maturity</li><li>Push teams to look busy instead of learning and validating properly&nbsp;</li><li>False negatives: When productivity looks low but isn’t&nbsp;</li></ul></li><li>False negatives: When productivity looks low but isn’t</li></ol><ul style="list-style-type:disc;"><li>A false negative occurs when an engineer appears unproductive even while performing crucial work. These misclassifications penalise thoughtful engineering and push talent towards safer, lower-impact tasks.&nbsp;&nbsp;Common causes<ul style="list-style-type:disc;"><li>Waiting for inputs: supplier feedback, prototype results, validation data, and cross-functional approvals</li><li>Exploratory and iterative work that produces learning (and risk burn-down) rather than immediate task closures</li><li>Complex, high-risk assignments (first-time integration, safety-critical systems, architecture definition) that absorb ambiguity and coordination load</li><li>Underallocation in the period due to planning gaps or pipeline starvation (the person can’t finish work that was never assigned)&nbsp;&nbsp;</li></ul>Why are they harmful&nbsp;<ul style="list-style-type:disc;"><li>Demotivate high-impact contributors; nudge them to avoid complex problems</li><li>Delay honest escalation; teams optimise for closure rather than design maturity</li><li>Shift effort towards visible but low-value activities; accumulate technical debt</li><li>Distort portfolio choices by favouring easy work over critical uncertainty reduction&nbsp;</li></ul></li></ul>&nbsp;In effect, variability in observed productivity often masks real differences in capability. In NPD, as outlined earlier, much of what appears as individual productivity is driven by context, like WIP levels, input maturity, decision latency, and interface quality, rather than by competence alone. As a result, short-window performance metrics confound skill with system noise.&nbsp; &nbsp;Until variability is separated from capability, measurement will continue to mislead. The remedy is therefore twofold: interpret individual productivity signals in context and redesign the flow of work so that remaining variability increasingly reflects skill rather than system effects. &nbsp; &nbsp;How do we put this into practice?&nbsp;<h3>Reframing productivity: From scoring people to improving flow&nbsp;</h3>Reframing productivity requires addressing two distinct but complementary dimensions.&nbsp; &nbsp;<ol style="list-style-type:decimal;"><li>System first: Remove context noise (Flow design)&nbsp;Focus on interventions to reduce system-driven variability so that individual signals become legible.<ul><li>Control WIP: Avoid opening all work fronts simultaneously for a given individual. Limiting WIP exposes queues in bottleneck areas, makes overload visible, and prevents effort from being diluted across too many parallel tasks.</li><li>Enforce a clear and explicit priority system for queuing: Without a well-defined priority order, resources tend to work on multiple items in parallel, making queues invisible and undermining WIP controls.</li><li>Stabilise inputs before expecting speed: Flow improves only when prerequisite data, parts, and decisions are available; busyness without input readiness simply lengthens queues.</li><li>Shorten decision latency via clear escalation paths and predictable review cadences. (Keeps queues from growing and reduces time-to-unblock.)</li><li>Enforce gate discipline for maturity: Use gates to protect learning and readiness, not to accelerate superficial closures.&nbsp;</li><li>Tighten cross-functional interfaces (design–test–supply–manufacturing) where recurring queues or rework appear.&nbsp;Prioritise these systemic levers first; when they move, individual metrics start aligning with reality, without pushing people harder.&nbsp;</li></ul></li><li>Then people: ‘Interpret and enable’&nbsp;Focus on practices that interpret individual signals in context and build capability without turning metrics into scorecards.&nbsp;<ul><li>Treat individual productivity data as diagnostic, not dispositive: Use numbers to inform conversations, not replace judgement.</li><li>Rely on line-manager interpretation: Line managers or technical leads are best placed to interpret individual productivity because they understand the current work fronts, dependency load, and technical risk an engineer is handling. This context allows them to identify false positives and false negatives in productivity signals, to distinguish skill gaps from delays driven by system constraints or input immaturity, and to judge whether iteration reflects learning or defect-driven rework.</li><li>Time horizon for meaningful judgement: Individual productivity should be assessed over longer horizons (typically multi-month, ~3 months) and within comparable contexts, similar roles, phases, and complexity. Short-term snapshots (weekly or monthly) tend to exaggerate sequencing effects, planning quality, and dependency timing; stable patterns emerge only with sustained observation and lead interpretation.</li><li>Invest in tools, training, and knowledge transfer where repeated false negatives indicate skill or interface gaps by strengthening design standards, improving access to simulation or validation tools, formalising handoffs across interfaces, or providing targeted coaching in areas where engineers consistently absorb ambiguity without visible progress.</li></ul></li></ol>&nbsp;<h3>Limits and conditions of ‘interpret and enable’&nbsp;</h3>Contextual interpretation improves signal quality but raises the bar on leadership. It depends heavily on the judgement and technical depth of line managers; where these are uneven, assessments can become subjective or inconsistent. Reduced reliance on scorecards can also create perceptions of unfairness unless expectations, criteria, and time horizons are made explicit and clearly aligned.&nbsp; This approach demands more leadership time and discipline, and longer observation windows can delay detection of genuine skill gaps. Most importantly, it only works in systems with basic flow discipline without controlled WIP and stable inputs, better interpretation cannot compensate for systemic noise.&nbsp;&nbsp;<h3>Conclusion: When measurement meets judgement&nbsp;</h3>The more time one spends around design work, the clearer it becomes that numbers rarely mislead on their own; it’s how we read them that matters. False positives and false negatives aren’t statistical noise; they’re early signals. They reveal where learning was rushed, where risk was quietly deferred, and where progress appears complete but isn’t yet mature. Read as judgements, these signals prompt teams to adapt and survive the metrics. Read as diagnostics, they reveal the constraints that quietly shape the flow.&nbsp; &nbsp;In the end, productivity in NPD isn’t a scoreboard; it’s a relationship between people, their craft, and the system that carries their efforts forward. When we control WIP, ensure inputs are ready, make decisions timely and keep priorities clear, the numbers begin to tell truer stories.&nbsp; &nbsp;This brings us back to the original collision of truths: ‘measure’ because we must, but read those measures with empathy and context. When we do, we don’t just ship better products; we build teams that trust the work, and systems that allow good engineering to be seen for what it truly is.

NPD productivity is often misread through ‘false signals.’ This article reveals why measuring R&D requires shifting from rigid metrics to flow-based design, using data as a diagnostic tool rather than a scorecard.

Productivity is designed, not measured: Rethinking individual efficiency in New Product Development

In <a target="_blank" rel="noopener noreferrer" href="https://www.vectorconsulting.in/en/research-and-publication/articles/three-rules-for-rapid-new-product-development/">New Product Development</a> (NPD), two truths collide. First, the need to measure individual productivity is real: assign the same design problem to different engineers, and you will often see vastly different cycle times, driven by differences in experience, problem-framing, and cognitive approach. When time-to-market (TTM) pressure is high and engineering capacity is constrained, as is common in most NPD environments, failing to measure individual productivity leaves leaders blind to load, cost, and risk. Second, the way we typically measure: hours worked, number of tasks completed, lines of code, number of drawings completed, number of design changes, number of CAD models released, number of engineering change requests closed, and so on, often misrepresents progress. It treats NPD as purely executional work, even though design engineering work is inherently non-linear, non-repeatable, interdependent, uncertain and knowledge-intensive. Engineers contribute through problem-solving, experimentation, design decisions and learning, many of which do not translate cleanly into short-term, countable outputs. What appears ‘slow’ in a weekly report can be essential learning; what looks ‘fast’ can mask unresolved risk that surfaces downstream. In addition, NPD is system-constrained rather than effort-constrained, with queues, Work-in-Progress (WIP), and decision latency dominating cycle time far more than an individual effort.&nbsp; &nbsp;The result is a persistent conflict: measure, and you distort; don’t measure, and you fly blind. This article explores why measuring individual productivity in R&amp;D is fundamentally challenging, why conventional metrics often generate misleading signals through false positives and false negatives, and how leaders can interpret productivity data more constructively to improve flow rather than distort behaviour.&nbsp;&nbsp;<h3>Seeing through false signals: False positives and false negatives&nbsp;</h3>Individual productivity numbers in NPD are noisy. Short time windows and uneven work contexts generate two kinds of systematic errors: false positives (metrics say ‘high productivity’ without real progress) and false negatives (metrics say ‘low productivity’ despite essential, value-creating work). Recognising and interpreting these signals is the difference between a learning system and a blame system. The figure below illustrates how metric signals can diverge from system reality, leading to misinterpretation unless context is applied.&nbsp;<figure class="image"><img style="aspect-ratio:4096/2374;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//image_1772616582.png" width="4096" height="2374"></figure>&nbsp;Let’s examine these false signals in more detail:&nbsp;<ol><li>False positives: When productivity looks high but isn’t A false positive occurs when a metric indicates exceptional productivity while the system’s underlying reality remains fragile or unfinished. These inflate confidence, mask risks, and create perverse incentives.&nbsp;Common causes<ul><li>Premature task/subtask closure to show progress (with assumptions untested or inputs unvalidated)</li><li>Inflated planned durations during high-level planning to later ‘beat the plan’ and look faster</li><li>Frequent replanning that optimises optics rather than clarity and flow</li><li>Working predominantly on low-risk or mature items, while others absorb first-time integrations and ambiguity</li></ul>Why are they harmful&nbsp;<ul><li>Create heroes without removing bottlenecks; unresolved risks travel downstream into costlier phases</li><li>Delay honest escalation; teams optimise for closure rather than design maturity</li><li>Push teams to look busy instead of learning and validating properly</li></ul></li><li>False negatives: When productivity looks low but isn’t A false negative occurs when an engineer appears unproductive even while performing crucial work. These misclassifications penalise thoughtful engineering and push talent towards safer, lower-impact tasks.&nbsp;Common causes<ul><li>Waiting for inputs: supplier feedback, prototype results, validation data, and cross-functional approvals</li><li>Exploratory and iterative work that produces learning (and risk burn-down) rather than immediate task closures</li><li>Complex, high-risk assignments (first-time integration, safety-critical systems, architecture definition) that absorb ambiguity and coordination load</li><li>Under allocation in the period due to planning gaps or pipeline starvation (the person can’t finish work that was never assigned)</li></ul>Why are they harmful&nbsp;<ul><li>Demotivate high-impact contributors; nudge them to avoid complex problems</li><li>Delay honest escalation; teams optimise for closure rather than design maturity</li><li>Shift effort towards visible but low-value activities; accumulate technical debt</li><li>Distort portfolio choices by favouring easy work over critical uncertainty reduction &nbsp; &nbsp;</li></ul></li></ol>In effect, variability in observed productivity often masks real differences in capability. In NPD, as outlined earlier, much of what appears as individual productivity is driven by context, like WIP levels, input maturity, decision latency, and interface quality, rather than by competence alone. As a result, short-window performance metrics confound skill with system noise.&nbsp; &nbsp;Until variability is separated from capability, measurement will continue to mislead. The remedy is therefore twofold: interpret individual productivity signals in context and redesign the flow of work so that remaining variability increasingly reflects skill rather than system effects. &nbsp; &nbsp;How do we put this into practice?&nbsp;<h3>Reframing productivity: From scoring people to improving flow&nbsp;</h3>Reframing productivity requires addressing two distinct but complementary dimensions.&nbsp; &nbsp;<ol style="list-style-type:decimal;"><li>System first: Remove context noise (Flow design)&nbsp;Focus on interventions to reduce system-driven variability so that individual signals become legible.<ul><li>Control WIP: Avoid opening all work fronts simultaneously for a given individual. Limiting WIP exposes queues in bottleneck areas, makes overload visible, and prevents effort from being diluted across too many parallel tasks.</li><li>Enforce a clear and explicit priority system for queuing: Without a well-defined priority order, resources tend to work on multiple items in parallel, making queues invisible and undermining WIP controls.</li><li>Stabilise inputs before expecting speed: Flow improves only when prerequisite data, parts, and decisions are available; busyness without input readiness simply lengthens queues.</li><li>Shorten decision latency via clear escalation paths and predictable review cadences. (Keeps queues from growing and reduces time-to-unblock.)</li><li>Enforce gate discipline for maturity: Use gates to protect learning and readiness, not to accelerate superficial closures.</li><li>Tighten cross-functional interfaces (design–test–supply–manufacturing) where recurring queues or rework appear.</li><li>Prioritise these systemic levers first; when they move, individual metrics start aligning with reality, without pushing people harder.</li></ul></li><li>Then people: ‘Interpret and enable’&nbsp;Focus on practices that interpret individual signals in context and build capability without turning metrics into scorecards.&nbsp;<ul><li>Treat individual productivity data as diagnostic, not dispositive: Use numbers to inform conversations, not replace judgement.</li><li>Rely on line-manager interpretation: Line managers or technical leads are best placed to interpret individual productivity because they understand the current work fronts, dependency load, and technical risk an engineer is handling. This context allows them to identify false positives and false negatives in productivity signals, to distinguish skill gaps from delays driven by system constraints or input immaturity, and to judge whether iteration reflects learning or defect-driven rework.</li><li>Time horizon for meaningful judgement: Individual productivity should be assessed over longer horizons (typically multi-month, ~3 months) and within comparable contexts, similar roles, phases, and complexity. Short-term snapshots (weekly or monthly) tend to exaggerate sequencing effects, planning quality, and dependency timing; stable patterns emerge only with sustained observation and lead interpretation.</li><li>Invest in tools, training, and knowledge transfer where repeated false negatives indicate skill or interface gaps by strengthening design standards, improving access to simulation or validation tools, formalising handoffs across interfaces, or providing targeted coaching in areas where engineers consistently absorb ambiguity without visible progress.</li></ul></li></ol>&nbsp;<h3>Limits and conditions of ‘interpret and enable’&nbsp;</h3>Contextual interpretation improves signal quality but raises the bar on leadership. It depends heavily on the judgement and technical depth of line managers; where these are uneven, assessments can become subjective or inconsistent. Reduced reliance on scorecards can also create perceptions of unfairness unless expectations, criteria, and time horizons are made explicit and clearly aligned.&nbsp; This approach demands more leadership time and discipline, and longer observation windows can delay detection of genuine skill gaps. Most importantly, it only works in systems with basic flow discipline without controlled WIP and stable inputs, better interpretation cannot compensate for systemic noise.&nbsp;&nbsp;<h3>Conclusion: When measurement meets judgement&nbsp;</h3>The more time one spends around design work, the clearer it becomes that numbers rarely mislead on their own; it’s how we read them that matters. False positives and false negatives aren’t statistical noise; they’re early signals. They reveal where learning was rushed, where risk was quietly deferred, and where progress appears complete but isn’t yet mature. Read as judgements, these signals prompt teams to adapt and survive the metrics. Read as diagnostics, they reveal the constraints that quietly shape the flow.&nbsp; &nbsp;In the end, productivity in NPD isn’t a scoreboard; it’s a relationship between people, their craft, and the system that carries their efforts forward. When we control WIP, ensure inputs are ready, make decisions timely and keep priorities clear, the numbers begin to tell truer stories.&nbsp; &nbsp;This brings us back to the original collision of truths: ‘measure’ because we must, but read those measures with empathy and context. When we do, we don’t just ship better products; we build teams that trust the work, and systems that allow good engineering to be seen for what it truly is.

The white paper explores the challenges and solutions in India's domestic pharmaceutical distribution sector. Despite the industry's strong growth, companies continue to face significant operational gaps.

Beyond the pill: How distribution failures are undermining India's pharmaceutical giants

India’s apparel industry struggles with 6–9 month lead times, resulting in inventory mismatches and lost sales. What if a smarter, faster approach could transform profitability? Discover how brands can gain agility and control.

From threads to trends: Navigating supply chain complexity in apparel retail

Explore how Engineering Change Notices (ECNs) impact New Product Development in India's auto sector, highlighting the challenges, costs, and opportunities for faster, more innovative solutions through improved execution and supplier collaboration.