Dave Thomas, the founder of Wendy’s, used to visit the various franchises around the country. If the restaurant was busy, he would put on an apron and make burgers. How many in your company could do that? In my experience, there are far too few employees – and too few execs – who understand the mechanics of creating products. Everyone needs to know the business of creating products.

We ask developers for an impossible set of product features and say, “It doesn’t look that hard to me.” Hmm, how much production code have you written? Years ago I worked with a development crew who asked me to explain development to their own VP. He kept changing the requirements after each weekly senior staff meeting and didn’t understand why they couldn’t keep up.

Nothing seems hard to people who don’t know what they’re talking about.

Here’s how I explain it: Building software products is like moving a train. It takes a long time to start, and once started, it’s very difficult to change direction. Everyone on the train must agree on where we want to go before we leave the depot. There’s another train coming along in an hour, so those who aren’t on this train will have to wait for the next one.

Like a train, a product project doesn’t easily change direction. New requirements mean new designs, often new resources, and always new schedules. And since in most cases there’s a release planned after this one, many requirements can just wait for the next cycle.

Developing products ain’t easy, friends.

Here’s another approach: change every development request to a sales request and see how silly it sounds:

“I don’t see why development can’t make the ship date without de-scoping”

• I don’t see why sales can’t make quota without discounting

“Can’t you just add more developers to ship sooner?”

• “Can’t you just add more sales people to close the deal sooner?”

Developing products is hard. So is selling them. As much as we want to believe that development is a science, there’s still a fair amount of art required to do it well. And as much as sales people like to think that selling is an art, quota-busting sales people know that it’s more like a science. It is procedural; it is planning; it is numbers. We should hold development and sales to the same standards. We should expect development to make their schedules without de-scoping only if we expect sales to close their forecasted deals on schedule without discounting.

One of the signs of impending doom is an executive team that is unaware of what the company really does. They’ve been “breathing their own air”, believing their own press releases. Executives and marketing professionals need to be constantly grounded in the market with frequent visits to existing and potential customers.

In a world where outsourcing is constantly in the news, people who are insured of continued employment are those who know the business of creating products.

It seems ignorance is bliss for many in tech companies but it really doesn’t matter if you’re a product manager, a product marketing manager, or a product owner, there are six technical practices you should know about: Version control, Continuous integration, Automated testing, Refactoring, Simple design, and Collective code ownership. If you’re in a tech role–or work with technical people– you should understand these concepts, and make sure they’re in use by your team.

(Oh, and also, you need to know the characters of Battlestar. Of course, you already know Star Trek and Star Wars.) (Plus, who Douglas Adams is.)