*The views expressed are solely my own and do not necessarily reflect those of my current employer.

Introduction to Hardware

Hardware. What exactly is it? Why is it important. Why is it hard? Since the dawn of time there has been hardware engineers.

I live and work in the Midwest — a region deeply rooted in manufacturing excellence. With its central location, established logistics networks, mild climate, and skilled labor pool, it’s an ideal place to explore how we can accelerate hardware innovation - particularly in Columbus, Ohio.

This post kicks off a series chronicling my journey to build hardware faster, smarter, and closer to the customer.

The V Model of HW/SW Development:

This model of software development was established by both Germany and the United States in the late 1980s as a way to effectively manage projects. Developed independently in the U.S. and Germany during the late 1980s, the V-Model was designed to bring structure and predictability to complex engineering projects.

The V-Model is still widely used in high-stakes industries like aerospace, automotive, and medical devices because it helps teams:

• Reduce project risks
• Improve quality and tracibilty
• Control costs
• Clarify communication between stakeholders

But it has one major flaw: rigidity.

Agile Hardware Development:

Most modern hardware should be based on the principles of fail fast fail cheap, learn quickly. The reality of hardware is that it is inherently hard, but it doesn’t need to be. I’ll be sure to note the exceptions to this - namely regarding safety critical systems and cover my thoughts on those in a separate blog post.

To build hardware one must be willing to iterate by understanding how to get close to customer and simulating when needed.

The biggest hinderance to modern development is the separation of hardware and software. The reality is that hardware and software must be developed in tandem. That requires integrated planning, continuous validation, and built-in feedback .

The traditional V-Model assumes that each step is linear and complete before the next begins. But real-world projects are messy. You don’t always know all the requirements upfront. Things change. And rigid processes struggle to adapt.

Hardware planning is uniquely difficult — it demands deep domain knowledge and hands-on experience to anticipate and mitigate problems.

The linear flow of current hardware development is reliant on this knowledge and experience. In reality there is no substitute for this gained real world experience.The V-Model’s rigidity often makes it difficult to adapt when real-world projects demand flexibility or rapid change. Items may occur simultaneously but often times that doesn’t produce customer oriented results.

A Comparison of Software vs. HW Development Time Frames

• An average software sprint time is anywhere from two week to one month.
• Whereas an average hardware development flow ranges from a shorter span of 1-2 years - or more.

But this gap is shrinking. Thanks to 3D printing, digital twins, better simulation tools, modular design, and rapid prototyping, we can now build physical systems with more speed and agility than ever before.

We no longer have to subscribe to the “build it and they will come” mentality. We can instead ask:

What does the customer actually need, and how can we get there faster — with less waste?

My goal is to create a series of posts highlighting what does an ideal LEAN hardware development flow. I hope to provide some insight and am open to feedback.

My Mission: Building an Ideal Lean Hardware Development Flow

Over the next few posts, I’ll explore what an ideal Lean-inspired hardware development process looks like. I’ll dive into:

• Where traditional hardware development breaks down
• How Agile and Lean can be adapted for hardware
• How to iterate faster without compromising quality
• Real tools and examples from the Midwest manufacturing ecosystem

This isn’t just a technical exercise. It’s about reshaping how we think about building physical products — from mechanical devices to embedded systems.

If you’re a maker, builder, engineer, or startup founder who wants to build hardware better, I hope you’ll follow along. And I welcome your feedback, insights, and challenges along the way.

Let’s build something together — faster, smarter, and with purpose.