ar·chi·tec·ture

/ˈärkəˌtek(t)SHər/

the complex or carefully designed structure of something.

We use the term most when discussing the design of buildings and structures.

But any complex product has an architecture, whether you think about it or not.

Software?

Electrical?

Mechanical?

Yep.

When designing a building, we often start with a floor plan. 

A large format, 2D representation of the “function” of that building.

We can see the whole thing at the same time.

How rooms are connected.

How they function.

We can’t see the rooflines or the tile in the shower, 

but we can see enough to know where they’d go.

The floor plan describes the function of a building.

A system diagram describes the function of your product.

And it should have similar qualities.

Large format, 2D

All on one page 

Show connections between components

Show component functions

Just like a floor plan, our system diagram allows us to understand how our system works at a glance.

Does your product have a floor plan?

-Brian Schoolcraft

Ask the Right Questions🧠. At the Right Time 🕝.

Any new project is full of questions. 

In a way, the main job of the product development cycle is to answer them.

A key to a successful program is

asking the right questions

at the right time.

Here are some examples, based on the maturity of our project:

Proof of Concept - Is this even possible?

Concept Validation - Does my idea solve the problem I want it to?

Design Validation - Can I make this into a real product?

Production Validation - Am I able to produce reliably in the quantity I need?

Sustaining Engineering - How can I make things a little better?

As you can probably tell, getting these questions out of order can cause problems. 

If I wait until PV to ask my customers if my idea solves their problem, I run the risk of having to redo a lot of work that should have been completed in the CV phase.

If I’m in CV, and the main questions I’m seeking to answer are focused on reliability and production processes, I’m going to get mired in details and never find the spark I need to innovate.

Have you ever considered the questions you’re asking? And when you’re asking them?

-Brian Schoolcraft

When do I learn it myself? When do I get help?

Your new idea is, unsurprisingly, ⭐new⭐. 

But in most cases, 80% of the effort is put into applying decidedly not new technologies.

Tech that’s been around for years or decades.

Tech that the major players in your industry are already good at.

What sets you apart is the new stuff. You’re agile, creative, and moving fast.

You have time to become an expert at your ⭐new⭐ stuff - who else is going to?

But do you have time to gain all the experience the big guys already have?

I’d wager you don’t!

If you can make a list of all the design work that needs to be done to get to your goal, you can begin sorting it along two axes:

Innovating <---> Implementing - Are you learning something new or applying something that’s known?

Proprietary <---> Commodity - Is this special to your business, or something anyone could use?

Here’s a suggestion for each quadrant:

1. Innovating and Proprietary - This is you. Learn it, own it.

2. Innovating and Commodity - This probably doesn’t exist 🙂

3. Implementing and Proprietary - Find someone with experience. Contract with them to get the job done, and give you the design record when you’re done.

4. Implementing and Commodity - Try to buy this as a product. If you can’t, find an existing supplier and approach them about a custom offering. Let them keep ownership of the design if it helps the deal go through.

How have you handled these decisions in the past? Do everything yourself? Outsource everything?

-Brian Schoolcraft