Development vs Production

When I think of development vs production I’m thinking of manufacturing specifically. These terms mean slightly different things in, say, software, where development is where you make the thing stable enough to run and production is where you run it.

On the other hand maybe that’s not so different after all. Development makes it run, production runs it.

But that’s all very obvious. I want to think about product development and production in more conceptual terms, thinking about how each area does what it does. And I want this to be a little abstract. So I’m going to talk about development and realization instead of “production”. (Just to prevent any confusion here, I’m using the term a little differently than the ISO 9001 spec does, where design, development, and production are all subsets of realization.)

First, product development and realization are two separate things. This isn’t obvious to some people. You know who these people are. I once heard a developer friend of mine years ago (he worked at a bank, which in kind of super-scary) describe his co-worker as a “cowboy”. The sort of person who doesn’t value (or worse, understand) the difference between development and production, who pushes changes from development to production with minimal or no check (or worse, develops in production).

This was software, but manufacturing has the same sort of thing. In a system like ISO 9001:2008 development and realization are considered two different domains, each with their own sets of paperwork, processes, work instructions, and potentially different management teams.

In a large company you might have development plants or skunkworks. This makes the separation super obvious. And obvious for a reason, you don’t just push development changed into a realization scenario where you can make 10 million widgets wrong.

In a small company the domains get a little muddier. This is why a conceptual framework is useful. The same people might be managing the development, producing prototypes, doing testing, as are managing the production lines, running the production lines, and doing inspections.

There might not be a clear reason to separate development from realization (at least at first), especially as a 1-person or few-person outfit. When you’re a small company, you’re probably not making 10 million widgets where development is a much smaller part of your overall cost structure. If you’re developing a lot of one-offs and specialty products, maybe most of your time can be taken up with development.

This is why a development/realization conceptual framework is important. It helps separate domains, and by doing so helps you to stop making the same mistakes over and over again.

First, product development and product realization have different inputs. An input, of course, is just something you dump into a process in order to do some work on it and get something out the other side. This can be materials, specification, people, processes, etc. (And usually realization has as one of its inputs the results od

They also have different causes and effects. Things that go wrong in development often are (but don’t have to be) very different from things that go wrong in realization.

Even more abstractly, they have different purposes. So let’s start there.

Different Purposes

Realization exists to make a product, to bring it to market in a certain form. It might seem at first that development also exists to make a product (as prototype), but that’s not exactly true. Or, if you’re doing in that way, you’re potentially doing development wrong.

Development actually exists to make knowledge. Specifically, reusable knowledge.

Why would you develop, let’s say, “a tool that doesn’t vibrate while cutting Titanium”? That’s a narrow goal. It’s applicable to just one thing. A more abstract and useful expression of this development process would be “a type of geometry that doesn’t vibrate in a material with certain properties”.

Then you can take that knowledge and reuse it for different items of that class. I think of this as a sort of don’t repeat yourself (or DRY) for product development.

Instead of ending up with a tool, you end up with a set of criteria than can be applied to tool, plural. And instead of that knowledge accumulating in one person’s head, it accumulates as a set of specifications.

I’ve seen this so very many times. Someone says “My customer wants a tool that does x and y”, a single person does the development and realization process at the same time, no specification is written, the tool goes out, and the knowledge is nowhere to be found. This makes for a very valuable person but a useless procedure.

(This doesn’t even touch on the amount of waste generated by this kind of process conflation; think of all the extra time spend developing the same tool again and again, reinventing the wheel, only to have the product returned because something went wrong somewhere in this crazy whirlpool of a development process. It might seem like time has been saved in the short term, but as with most things, it’s a long-term disaster.)

Different Causes and Effect

When you do development and realization at the same time, you risk conflating cause and effects, which are different in each domain.

Typically in development, causes of failures are related to development type things (experimentation going wrong as it always does, etc). Since you’re developing a specification and creating knowlege, you’re venturing into the unknown where unknown things can happen.

In realization, causes of failures are usually related to process type things. The processes should be nailed down enough that when something goes wrong (apart from the usual acts of God) you can track down where the process hasn’t been followed or where the process needs to be changed.

These causes and effect, when taken together, when development and realization are bundled, become exponentially more tricky. Suddenly your production causes and effects are no longer bounded by adherence to processes, instead you have to look at your processes and your development criteria, and so on. Suddenly your troubleshooting tree has way, way more branches. It can become so complex that you just can’t troubleshoot at all, and you just ship and pray.

I don’t think I need to say why guess & test plus ship & pray is a terrible, terrible idea.

Different Inputs

My final thought is that development and realization have different inputs. In fact, one of the inputs of realization is a specification from development.

Development takes existing knowledge, engineering expertise, and customer specifications, and outputs a specification. This can be an prolonged period of prototyping and testing, but if you’re doing similar things quite often it can be simply spitting out a specification with small modifications. (Eg, my customer wants this thing that we already make, just with a different dimension or material.) In fact, with the proper ongoing research and development efforts, even a small company can radically shorten development engineering lead times with reusable knowledge.

Not only that, but reusable knowledge doesn’t have to be domain-specific. For instance if you’re improving one process, it’s quite possible you can reuse that improvement in many processes. The knowledge generated by development can be diffused across both development and realization. This is the kind of thing that can save serious cash by improving processes across the board and shortening lead times.

Realization on the other hand takes as one of its inputs (possibly one of many) the specification produced by development. With proper modularization it may even be possible to create a series of specifications that can be mixed and matched to achieve different results as required.

For instance where I work we could have a meta-specification that simply calls out other specifications and mixes in the customer’s special requirements.

Or if the customer needs something truly oddball, a new specification is created. (From my experience 90% of our custom work would easily be covered by a meta-specification.)

Different Inputs

Just to wrap things up, this is why I see development and realization as two different domains. They accept different inputs, they produce different outputs, they have different causes and effects, and they exist for different purposes.

I hope I’ve done a decent job of explaining why I see conflating the two domains as a really dangerous idea.

That said, I think a lot of companies, especially small outfits, don’t see the immediate benefit of decoupling development from production. Maybe this is because of cost concerns (I need to make a whole new division!) or because of lead time concerns (I have to do two things in line instead of at once!).

The problem is the value proposition here is kind of hard to quantify. If you’re worried about those things you’re probably also not doing proper analytics on scrap rates, production breakdowns, customer satisfaction, nonconforming product returns, and all the other fun stuff that comes along with doing too many things at the same time.

And there’s no way to really make this sexy. This is sort of the least sexy possible domain. There’s nothing really clever, there’s no Suits-esque maneuvering here.

All I can say is that decoupling development from production is a proven long-term success story. It’s going to be one of the ways you make your company (at least, if that’s what you want) into an organization instead of a random collection of people and things those people do. It’s going to result in fewer lost man-hour trying to reinvent a process or specification (again). It’s going to cut down on the amount of lost time and money on returns, replacing faulty tooling, dealing with upset customers, and scrapping out nonperformant parts.

The greatest benefit, though, is something really intangible. It’s peace of mind. You’re not relying on one guy who just “knows” things. You’re not guessing and testing. You’re not shipping and praying.

I don’t know about you, but peace of mind if kind of a big deal for me.

How to fail at manufacturing

1. Start With Unclear Goals

Anyone can succeed at something if they know what they’re doing. If you want to fail at something, a pretty good way to do it is have hidden goals, too many goals, or no goals at all. In manufacturing, doubly so. You can only do so much with the time you have. You’re limited by man-hours, and you can’t exactly throw more people at a production line to make it go faster. Start off by not knowing what you want to do. Don’t hone in on any one thing with laser precision. Throw a wide net. Do as many things as you think you possibly can, and then do some more.

For instance, don’t focus on just custom widgets, or just focus on mass-manufacturing and stocking common widgets, or repairing widgets. Do all three! And then figure out something tangentially related to widgets and make/stock/repair them too.

No-one will have any idea what you’re doing, no-one will know what portion of the business is most effective, and no-one will be able to become expert in one single area. Guaranteed failure!

2. Use The Wrong Tools

There are tools for every task. There are tools that make every task easier, or improve quality, or make a process happen faster. Don’t use any of these tools. Use different tools. Jury-rig everything. Ensure that your slapdash improvisations are never improved on. For instance, if you should be using a piece of software to schedule production, don’t bother! Software takes a lot of work to maintain properly, and snafus always happen, right? Forget software! Write stuff on a piece of paper. If that doesn’t help you fail, just go verbal. Your employees are good at remembering every little thing you tell them, right?

3. Have Lots Of Scheduling Flexibility

Broken promises? Who cares! If someone needs something yesterday, everything has to stop to make that happen. Better yet, don’t discriminate. Your largest account and your smallest account should have equal opportunity, right? If Joe Public walks in off the street and really, really, really needs a widget, that means he’s important. Inculate in your employees a culture of saying “yes”, even when saying “yes” will lose you money, customers, reputation, and respect.

One of the best ways to do this is let sales run the schedule. After all, salespeople are making their bread from their customers, and probably feel (even if they’d never say this) that they work for the customer more than they work for you. That’s where their loyalty lies, and that’s not a problem! If sales can’t say no, neither can you, and neither should you.

This is a particularly wonderful way to fail, as everyone down the chain of command will feel like they’re doing something. You’re making executive orders, you’re rushing around getting things done, you’re telling people what to do–it’s quite the rush! You can guarantee, with this method, that your largest and your smallest customers are regularly disappointed in your service, and don’t trust a word you say, as the latest rush will always supersede yesterday’s suddenly-unimportant rush.

But there’s more! You can regularly anger anyone in your company trying to stick to a schedule, and use this as opportunity to tell them how bad they are at scheduling. After all, if they can’t handly a few daily panics, how good can they really be?

Remember to keep a constant aura of semi-panic. Constant catastrophe builds character, and will help you fail spectacularly, especially as your company grows. And grow it will, in fits of crisis and disaster, as every tiny account wheedles and cajoles and threatens and begs its way into your anit-schedule.

4. Don’t Specialize

Everyone can do everything. This is a fact. Your salespeople should be delivery boys. Your managers should be doing shipping. Your operators should be designers. Don’t let any one person get good at any one job. Don’t accept divisions of labour. The assembly line is a liberal myth! Instead of an assembly line, your manufacturing process should resemble Katamari Damacy. If anyone gets any ridiculous ideas in their head about competency and effiency, send them over to do some packaging!

5. Don’t Make Plans

Finally, and this is perhaps the most important point of all, don’t make plans. Plans are boring. You know what’s not boring? Doing thing. Don’t plan out your day, don’t plan out your processes, don’t plan out your production. Just do things. After all, no-one ever got anywhere by making plans, right? They just stumble into success randomly. It’s all chance. So do a bunch of stuff and hope something works. Make snap decisions that radically affect the direction of your company. Develop products (lots of products! the more the better!) with no feasible plan for actually manufacturing the products. Then, tell everyone about your wonderful new products, have your salespeople sell the new products, and you can go right to #3!

If you can avoid having a set schedule for your week, that’s great too! A fantastic way to fail is never regularly do anything. Don’t pick a day of the week to empty your email inbox, or catch up on paperwork, or brainstorm. Just do things as they come, which will ensure that you never have a chance to focus, never have a chance to get a block of steady work done, and as an added incentive, you’ll always feel incredibly busy!

6. Succeed As You Fail

The best thing about this kind of failure is that you can succeed while you fail! You can build a reasonably flourashing business held together with duct tape, sweat, tears, and anger. Of course you’ll never be able to take a vaction, but vacations are for software companies and Europeans! You might have to work until you’re 80 and unable to actually drive yourself to work, but hey, that’s stability! You may no be able to change your company’s direction without actually failing, but why change what works?

In short, do these 6 things and you’re on your way to a very difficult lifetime, and possibly a stress-related ulcer. Good luck!