Can a machine work if the hardware and the chemistry aren't on speaking terms? Many business leaders think a product development team just needs a visionary at the top and engineers at the bottom. The story of Theranos proves that when technical groups live in different worlds, the result is a dangerous mess. This article examines why cross-functional teams must have deep alignment between physical engineering and lab science to avoid corporate disaster.

A product development team is the group responsible for turning a conceptual idea into a functional, market-ready asset. In biotechnology engineering, this requires a marriage between the "box" (the hardware) and the "wetware" (the biological or chemical testing). Without this alignment, you aren't building a product; you're building a prop.

Solving the Engineering-Science Divide

John Carreyrou explores this disconnect in his book Bad Blood, which chronicles the rise and fall of the blood-testing startup Theranos. Elizabeth Holmes founded the company with a vision to perform hundreds of tests from a single drop of blood. However, a massive gap formed between the engineers designing the machines and the biochemists developing the tests.

This disconnect matters because physical devices have rigid limits that biological samples often can't meet. If your engineers don't understand the chemistry, they will build a device that looks sleek but fails to deliver accurate data. Modern business requires leaders to act as translators between these technical silos. Failure to bridge this gap leads to the "folie à deux" described in the book, where leaders and teams share a delusion that a product works when it clearly doesn't.

Aligning the Product Development Team for Success

Siloed Information Blocks Real Progress

Theranos thrived on a culture of extreme compartmentalization. Elizabeth Holmes and Sunny Balwani kept the hardware engineers from talking to the biochemists. They believed this protected trade secrets from competitors like Quest or LabCorp. In reality, it prevented the product development team from identifying fatal flaws in the Theranos miniLab.

When information is siloed, engineers make assumptions about the "wetware" that aren't true. For example, engineers might assume a 10-microliter blood sample is enough to run a test. Meanwhile, the scientists know that such a small sample requires massive dilution, which ruins the test's accuracy. McKinsey research suggests that cross-functional teams with high information transparency are 20% more likely to deliver projects on time and within budget.

Miniaturization Obsessions Overpower Reality

Hardware engineers often prioritize size and aesthetics, especially in Silicon Valley. Elizabeth Holmes was obsessed with making her devices as small as a toaster. She even demanded the blood-collection tubes, called nanotainers, stay under two centimeters long. This forced the biotechnology engineering staff to cram complex robotics into tiny spaces.

Packing too many instruments into a small box creates heat. In the Theranos 4S or miniLab, this heat interfered with the chemical reactions needed for the blood tests. The scientists knew the temperature needed to be exactly 34 degrees Celsius. Because they were excluded from the hardware design, they couldn't tell the engineers that the stacked "six-blade" design was effectively cooking the samples.

Conflicting Success Metrics Kill Quality

Product development teams often fail when their goals aren't aligned. The engineers at Theranos were judged on whether the robotic arm moved correctly. The scientists were judged on whether the assays produced a result. Nobody was judged on whether the final result was actually accurate for the patient.

This led to the creation of the "Gluebot," a converted New Jersey glue-dispensing robot. It was an engineering hack that looked functional but lacked the scientific rigor required for medical diagnostics. When groups chase different targets, they create a product that works in a demo but fails in the real world. A unified team must share a single, non-negotiable metric for success.

Lessons from the Theranos miniLab Failures

Edmond Ku was a veteran Silicon Valley fix-it man who took over engineering at Theranos. He quickly realized that the prototype Elizabeth Holmes pitched to investors was just a mock-up. It didn't reliably reproduce results because the chemistry and hardware weren't synchronized. Ku's team spent months trying to force blood through tiny microfluidic channels that kept leaking.

While Ku worked on hardware, Gary Frenzel's chemistry team struggled with the minuscule blood volumes Holmes demanded. Because the two groups weren't encouraged to collaborate, Ku didn't know if failures were caused by his valves or Frenzel's reagents. This friction eventually led to Ku's firing and the abandonment of the microfluidic platform. It was a classic case of a product development team failing because the "box" and the "science" were developed in isolation.

Another example is the miniLab's pipette drift. The device used robotic pipettes to move fluids, but these pipettes needed recalibration every few months. The engineers treated this as a minor maintenance task. The scientists, led by Ian Gibbons, knew that even a tiny drift meant the difference between a healthy diagnosis and a false positive. Because the teams didn't align on this reality, the machine was never ready for the patient testing it was forced to perform.

Why Every Product Development Team Needs Physical Proof

Effective leadership requires merging these disciplines before a single line of code or blueprint is finalized. You can prevent a Theranos-level disaster by forcing your technical groups into a shared physical reality. This process stops people from hiding behind theoretical models and forces them to confront the limitations of the actual technology.

  1. Define Shared Technical Constraints. Sit the hardware and science leads in the same room to agree on physical limits like temperature, volume, and power. Ensure every group signs off on these constraints before the build begins to avoid the heat issues that plagued the Theranos miniLab.

  2. Run End-to-End System Tests Early. Don't wait for a polished prototype to test the chemistry on the hardware. Use "ugly" breadboard versions of the machine to see how the biological inputs react to the mechanical movements. Finding out that a robotic arm snaps a pipette tip is better to discover in month two than in month twenty.

  3. Rotate Personnel Across Silos. Send an engineer to spend a day in the lab and a scientist to watch the assembly of the circuit boards. This builds empathy and helps each side understand why the other makes specific demands. This prevents the "us vs. them" mentality that destroyed morale at Theranos.

Why Intellectual Property Can Hinder Innovation

The Theranos story shows that extreme secrecy can sometimes be a mask for incompetence. Some critics of open management argue that total transparency inside a company leads to intellectual property leaks. They believe that keeping teams separate is the only way to ensure a disgruntled employee doesn't steal the entire blueprint. In high-stakes fields like biotechnology engineering, this fear is real.

However, most experts now agree that the risk of internal silos is far greater than the risk of an internal leak. When you hide the full picture from your own staff, you remove their ability to self-correct. The lack of peer review and internal critique at Theranos allowed flawed ideas to survive for a decade. While protecting trade secrets is necessary, it must never come at the expense of the internal cross-functional teams' ability to verify that the product actually works.

Building a functional product development team requires more than a grand vision. It demands the courage to let your specialists talk to each other and challenge the design. Success is found when the hardware and the science are built as one single, integrated system. Audit your current internal communication channels today and remove any barriers that prevent your engineers from seeing the raw scientific data.

Questions

Why did the Theranos product development team fail?

The team failed due to extreme compartmentalization and a lack of transparency. Engineers and scientists were not allowed to communicate, meaning the hardware was built with physical constraints that made the science impossible to execute accurately. This led to machines that overheated or provided inconsistent results because they were designed for aesthetics rather than chemical reliability.

What is the disconnect between engineering and lab science?

This disconnect occurs when the physical limitations of a device—like size, temperature, and mechanical movement—ignore the delicate requirements of biological or chemical reactions. In biotechnology engineering, if a device isn't designed around the specific needs of the chemistry, the resulting data is often useless. Bridging this gap requires cross-functional teams that share information and success metrics.

How do cross-functional teams prevent technical silos?

Cross-functional teams bring specialists from different departments into the same workflow. By encouraging engineers and scientists to work together on early prototypes, companies can identify conflicts between hardware and science before they become permanent flaws. This alignment ensures that everyone on the product development team is working toward a functional reality rather than a siloed assumption.

What lessons can be learned from the Theranos miniLab?

The primary lesson is that miniaturization must never compromise scientific accuracy. The miniLab failed because it tried to cram too many instruments into a tiny space, causing heat issues and mechanical errors like pipette drift. Leaders must prioritize the integrity of the core science over the aesthetic desire for a small, sleek device.

How can a product development team improve its accuracy?

Accuracy is improved by running end-to-end system tests early in the development cycle. Instead of testing hardware and chemistry separately, teams should combine them as soon as possible to see how they interact. This allows the product development team to find and fix errors in the real-world environment where the product will actually be used.