Most companies do not lose speed because engineers work slowly. They lose speed because the organization makes the work wait.
That was the strongest thread in my conversation with Joe Justice. Joe is best known for WikiSpeed, Agile Hardware, his work with Tesla, and his consulting work with companies including Toyota, Honda and Mercedes-Benz. His message is simple and uncomfortable: physical product development can move much faster than most companies believe.
The limiting factor is rarely the material.
Metal can be cut quickly. Plastic can be molded quickly. CAD models can change quickly. Tests can run quickly when they are automated and designed for fast feedback. The real delay sits in handoffs, approval loops, supplier queues, functional silos and unclear authority.
That is also the core of Product Velocity. Different language. Same enemy. Read on to watch the interview or read the summary.
Hardware is not the bottleneck
Joe’s WikiSpeed story still sounds almost unreal. His team built a new car design every week. They drew the car in CAD, cut the body shape from foam, wrapped it in carbon fiber, showed it to potential customers and ran tests through government labs.
The shocking part is not the carbon fiber. The shocking part is the cadence.
Most large organizations treat testing and approval as late-stage events. WikiSpeed treated them as part of the loop. The team did not wait for a perfect design before testing. Testing was how the design improved.
This is where Agile Hardware and Product Velocity meet. Product Velocity is not about moving faster by skipping engineering discipline. It is about shortening the time between a decision, a design change, a test result and a business outcome.
A slow system turns every learning moment into a meeting chain. A fast system turns learning into the next version.
The business problem is decision latency
In the interview, Joe Justice made a point that applies far beyond automotive. When people say, “This would not work here,” they often mean, “I am not allowed to change what blocks it.”
That distinction matters.
A procurement leader can improve procurement. A testing leader can improve testing. A software leader can improve software. None of them can fix the product flow alone if the flow crosses all of them.
Traditional organizations divide authority by skill set. Accounting reports to accounting. Software reports to software. Hardware reports to hardware. Testing reports to testing. The product, however, does not care about this structure.
The product flow cuts across organizational structures.
That creates decision latency. A team close to the work sees a problem, sends a decision upward, waits, receives a partial answer, negotiates with another function and repeats. Each step looks responsible. The whole system becomes slow.
For business leaders, this is the economic issue. The question is not whether the process looks professional. The question is how much value sits idle while the organization waits for itself.
Architecture decides what can move
Joe uses the term “designs that don’t wait.” I like that phrase because it cuts through a lot of platform language.
A platform only creates speed if it reduces waiting. A module only creates speed if it can change without forcing unrelated parts of the system to change. A stable interface only creates value if teams can rely on it.
Many companies invest heavily in platforms and still move slowly. The reason is simple. They build shared assets, but they do not reduce dependency. Every new product still waits for decisions from the same committees, the same test queues and the same supplier negotiations.
A useful platform absorbs complexity. A weak platform redistributes it.
The smartphone is a good mental model. App developers build physical experiences without thinking about camera integration, GPS electronics, battery management or secure installation. The platform hides enough hardware complexity to let product teams move.
Automotive, aerospace, industrial equipment and medical devices need the same logic, adapted to their safety and regulatory context. The goal is not to make a car behave like an app. The goal is to make product change less dependent on everything else changing at the same time.
Conway’s Law is not an IT problem
Conway’s Law says that organizations build systems that mirror their communication structures. In software, this is now widely understood. In hardware, many companies still treat it as an interesting quote rather than an operating constraint.
If a product is organized around functions, the product architecture will preserve functional dependencies. If the product architecture preserves dependencies, teams will spend their time coordinating them. The result is predictable: more meetings, more planning, more escalation and slower change.
This is why agile frameworks alone disappoint. They improve coordination, but they leave the waiting system intact.
Joe was blunt about fake agile. If a system does not make design, build, test and deploy faster, it is not moving in the right direction, regardless of what it is called.
That is a useful test for any transformation program. Does it reduce elapsed time from idea to tested result? Or decision latency? Does it give a team enough authority to complete a real loop? And does it change the product architecture so fewer teams have to wait for each other?
If the answer is no, the organization has improved the theater around the work.
The 30-day experiment
Toward the end of the conversation, I asked Joe what a traditional hardware company should try in 30 days.
His answer was practical. Find something the company can design, build and test in-house. Create a team with everyone required to move end-to-end. Give that team permission to say yes to what is needed for 30 days. Then see whether they can complete a full iteration.
That is close to how I use Product Velocity interventions.
I usually start with the value flow. Where does the business lose time, and where does engineering wait? Or delivery? Where does the cause sit somewhere else than the visible symptom? Then the team defines a measurable target and runs a 30-day intervention.
The goal is not transformation theater. The goal is evidence.
After 30 days, the organization knows more than before. It has either reduced the constraint, or it has exposed the structure that prevents reduction. Both outcomes are useful. Both are better than another maturity assessment.
Where Agile Hardware and Product Velocity meet
Joe comes from the hardware side. He has built cars, worked inside Tesla and coached industrial companies on Agile Hardware.
Product Velocity comes from a broader systems view: business flow, engineering flow, delivery flow and system stewardship. It looks at how companies convert decisions into product outcomes, and where that conversion stalls.
The overlap between Agile Hardware and Product Velocity is substantial.
Both approaches treat speed as a system property and reject the idea that more coordination solves dependency. They both put architecture and organization in the same conversation. Both value testing as a feedback mechanism, not a late gate. And both use short experiments to create evidence instead of arguing about theory.
The difference is useful. Joe’s work makes the physical reality impossible to ignore. Product Velocity connects that reality to business outcomes, decision latency, value flow and leadership choices.
For companies building complex products, that combination matters. The future will not be won by copying software methods into hardware organizations. It will be won by designing product systems that can learn faster than competitors.
That includes architecture, teams, validation, and leadership permission.
Open for serious experiments
Joe and I approach the same problem from different directions. That is why the conversation was so valuable.
There is a practical opportunity here for companies that want to test faster product development without launching a large transformation program. Start with one real product flow. Pick one constraint. Give one team enough authority. Measure the result after 30 days.
Joe is open to working with companies on Agile Hardware. I am open to working with companies on Product Velocity. In some cases, doing this together would make sense.
The starting point is not a framework.
The starting point is a product flow that waits too much.
Contact Michael Jastram
Meeting: https://meetings-eu1.hubspot.com/meetings/michael-jastram
Email: michael.jastram@formalmind.com
LinkedIn: https://www.linkedin.com/in/jastram/
Product Velocity: https://productvelocity.org
YouTube: https://www.youtube.com/jastram
Contact Joe Justice
X: https://x.com/JoeJustice
Facebook: https://www.facebook.com/Joe.A.Justice
LinkedIn: https://www.linkedin.com/in/joejustice/
Books: https://leanpub.com/u/joejustice
Classes: https://en.abi-agile.com/
YouTube: https://www.youtube.com/@JoeJustice0
Email: Joe@ABI-Agile.com
