Do you own your Design Record?

Assuming your Design Record exists (it should!), do you own it?

This seems like a pretty easy question to answer, but I’ve found that it’s not often clear, especially in an early stage product business.

When you’re still young, you’re doing whatever it takes to keep the business alive long enough to become stable. Often, this means working with partner companies, either for design, engineering, manufacturing, or something else that isn’t part of your core business.

Let’s say we need a circuit board designed to fit in our cool new device. We’ve defined the schematic internally, and have a rough Bill of Materials defined. We don’t want to produce the boards ourselves, so we go find a PCB fab shop to manufacture a small run of 100 boards. They quote the project, we agree, and get started.

Our schematic describes the function of the board, but doesn’t describe a physical PCB, so our partner translates our schematic and BOM into a manufacturable board design. They do the work, we approve the design, and then they produce our prototype or production run. 

In the end, we get 100 PCBs, which is exactly what we asked for, great! 

If that’s the end of the story, then there’s no need for this post. 

Far too often though, time passes, and now we want to do a design update before launching into full volume production. In order to revise the design, we change the schematic, then change the board design. 

Except we can’t change the board design because our partner did it as part of the production run, and it wasn’t part of the deliverable package. All we asked for was the boards, so that’s all we got! 

Now, we’re stuck using the same vendor for our larger volume production run (this may be just fine, but often isn’t), or redoing the PCB design ourselves.

The point I’m trying to make isn’t that decisions like this are always wrong, it’s that they’re often not decisions at all!

We just wanted 100 PCBs, but didn’t account for the design work we were having our partner perform. Looking back, it might have made more sense to pay a bit more money upfront in order to own the design at the end.

Either way, let’s make sure we know when decisions are being made about Design Record ownership. They’re sneaky, but important!

-Brian Schoolcraft

What’s a Design Record? And why do I need one?

We’ve talked a lot about the strategic importance of the different steps in the product development and validation process. Today, let’s take a look at something a bit more tactical - our Design Record.

There are many ways to describe the Design Record, so let’s try to capture the definition that means the most to a business owner.

The Design Record allows you to get your product built and shipped - without “tribal knowledge”!

If you’ve ever been in an early stage product business, you already know how easy it is to leave important details about your product floating around in the heads of your team. Everyone on the team is good at what they do, they know the product inside and out, so there’s little need to write anything down. 

This works OK for a while, but quickly becomes a bottleneck to profitability.

Jim’s out for the week? All of a sudden something critical slips through the cracks. 

Need to scale up production? Now we have to get Mary to show the new team members what she knows.

You see where this is going, right?

What if we do all the same things, with the same great team, but instead of leaving it in our heads, we practice the discipline of writing it down?

Sounds like a game changer to me!

-Brian Schoolcraft

Do I really have to do all those steps before I launch my product?

Yes. And no. It’s complicated.

In an ideal world, with time, money, and staff, we’d work through each step in sequence for every new product or feature. We’d work through Proof of Concept, Concept Validation, Design Validation, and Production validation before we sell anything.

But we don’t live in an ideal world, do we?

In the real world, where we work with limited budgets and schedules, we’re often pressured to skip steps in the process, to sell sooner, produce faster, etc.

We can do this, of course, but to be successful, we need to start with an understanding of the “right” way to do things. From that foundation, we can make educated choices to combine phases, skip low-risk testing, etc. 

We run into trouble when we blindly compress schedules, without taking into account the risks of each step we’re eliminating.

Have you ever taken a shortcut in your product development process? How did it turn out?

-Brian Schoolcraft