» admin

Do patents pay off?

This case study is an example of a patent that became very valuable for the inventor. It’s an illustration of what constitutes a truly valuable invention.

Do patents pay off?

Is it worthwhile to incur the effort and expense to get patents?

The answer (squishy but true) is: It depends on how good the underlying idea is. This case study is an example of a very good underlying idea and how it made money for the inventor. It is an example of what to look for when trying to decide whether to pursue a patent.

A former work colleague of Clint was an inveterate inventor. He would spend hours on end thinking about products and technology, trying to come up with new ideas and inventions. The guy was prolific – he generated a lot of ideas in a lot of different fields. He formed a small business, Positive Technologies, as a vehicle for commercializing some of his new ideas.

One day he started talking to Clint about how images are rendered (or drawn) on LCDs. This was back when CRTs were everywhere and LCD display panels were relatively rare. The inventor used words like “inefficient” and “dumb” and “stone age” to describe the state-of-the-art display rendering algorithms. Then he started talking about a better way to render images on LCDs. It entailed a completely new approach that was intelligent and efficient and would improve display quality; would allow displays to be updated at a higher rate; and would prolong the life of the LCD.

They continued to discuss this new idea over the coming days. The discussion eventually became fairly technical, getting into details of cumulating DC bias voltages and liquid crystal relaxation rates and differential image mapping. It took awhile to absorb the concept, but eventually it became clear that every display in the world (at that time) really did use a “stone age” algorithm to render images, and that this new method was indeed superior. Clint pointed out that no microprocessor in the world had sufficient processing power to deploy this new algorithm. The inventor’s response was, “So what! Remember Moore’s Law! In three years, chips will be fast enough.”

This better algorithm was groundbreaking new technology that had the ability to change the way displays work — an idea that definitely merited a patent application. The inventor asked Clint to write the disclosure. (The disclosure is the main body of the patent, in which the invention is disclosed, or described in detail.) He asked Clint to do this because (paraphrasing his words), “You understand the technology. You write better than the average lawyer. And you cost less than a patent attorney.”

Clint wrote the first draft of the patent disclosure for this invention. The patent next passed through the hands of patent attorneys and patent examiners and then through the patent approval process and was finally issued. It has become a landmark patent in the display world.

As technology gradually caught up with this new idea, display manufacturers around the world began adopting the new algorithm, and the inventor pursued licensing arrangements with all of the major display manufacturers. This algorithm is now used in virtually every video display made today and the inventor has reaped handsome rewards from the better technology that he invented.

The lessons in this case study: Patents can be valuable – very valuable – but to become valuable, there are a couple of requirements. The underlying idea must be very strong and must enable new technology that improves significantly on existing technology. And you must pursue the patent diligently. It’s not enough to just get a patent. You must develop and sell the technology, or you must sign up licensees (or both).

A patent doesn’t make money; enforcing the patent makes money.

This is an example of a role Clint can fill in product development. He can help identify and define patentable new ideas, and can assist with the patent preparation process.

If you would like an unbiased assessment of a new idea, if you would like help refining the idea and identifying patentable inventions, if you would like help with patent preparation, please contact Clint.

Four Tips for Better Project Management

Four things you need to know to be a great project manager.

Business school libraries are filled with books about how to manage product development. There are many approaches to managing projects, and much discussion (sometimes heated) about which approach is best.

Clint feels that good project management can be distilled down to these four key principles:

Planning and preparation

Many companies rush into product development without proper planning up front. Often there is a feeling that the sooner you start engineering, the sooner development will be completed. Usually this is a fallacy. Take time at the outset to carefully and thoughtfully map out the course of the project. A rule of thumb is that each hour of planning at the start of the project saves 10 to 20 hours of engineering at the end.

Aggressive and active risk management

A good project manager constantly looks for risks that could derail the product development process. These could be cost risks, technical risks, schedule risks or market risks. If you identify risks early, you can address them before they derail the project.

Assiduous and meticulous project management

It’s impossible to overstate the importance of keeping a close and constant eye on every task and detail of product development. All of your up front planning and risk management will be of no avail if product development heads down the wrong path. If deviations from the project plan are not detected and addressed quickly, they can grow into engineering black holes that will cost a lot of time and money to correct.

Have the right people on your product development team

If development of your new product requires skills or expertise that you don’t have in-house, you need to find outside talent that fills the void. Finding and retaining key talent – as new employees or on an as-needed basis – can often be the difference between success and failure in developing a new product. Identify the outside talent that you need, find the best person/people you can to fill that need, and pay them fairly. A few hours of input from a domain expert can save dozens of hours of work by engineers who are well intentioned but lack expertise in a key area.

If you follow these four key principles of project management, you’ll be 95% of the way to a well-managed project. If you would like help with management of your product development projects or if you would like mentoring to improve your project managers, please contact Clint.

Building Rockets at General Dynamics

This case study illustrates one of the most valuable lessons that Clint has learned in more than 30 years of product development. This is about how small companies can compete against – and beat – much larger companies.

Two guys in a condo in La Jolla build some rockets

In the mid-80s Clint teamed up with another technology lover (Bob Hotto) to form a two-man tech company working from a condo in La Jolla. They were developing products – some on contract for other companies and some speculative product development on their own.

The General Dynamics (GD) facility that made Atlas and Titan-Centaur rockets was just a few exits down the freeway. A friend of a friend heard that GD was going to award a big engineering project – a project that entailed complete overhauls of the motors and motor control systems that are used to weld the rocket bodies. This sounded like an interesting project.

With some finagling and bit of luck, they managed to get their name added to the bid list for the project. About a month later General Dynamics invited Bob and Clint to a project preview meeting to go over the requirements of the project and the criteria for submitting proposals. The other companies who were bidding on the project were also at that meeting. This consisted of teams from every major aerospace engineering firm in America (along with Bob and Clint).

Each company had sent a team of between 6 and 10 people to the meeting. Each company had a total staff of between 5000 and 25,000 employees. All of the companies had long histories of doing contract work for GD, and it seemed like everybody in the group knew each other from past projects. This was a meeting of the professional rocket builders club. In their eyes, the rockets being assembled out on the factory floor were about as exciting as oversized tin cans. The closest Clint had been to a rocket prior to that meeting was watching launches from Cape Canaveral on TV. Comparing Clint and Bob to the other project bidders made David v. Goliath seem like a close match.

Everybody at the meeting treated Clint and Bob politely, not unlike the way in which a kindergarten teacher is polite to her not-so-bright pupils.

At the conclusion of the pre-proposal meeting everybody was given the RFP package – a stack of notebooks about three feet high. Each notebook was filled with pages of project requirements, quality standards, safety criteria, government regulations, and other insomnia-curing minutiae. Everybody had ten days to review all the documents, prepare a proposal, and then return to GD to present their proposals.

“We didn’t have a snowball’s chance in…”

Clint and Bob didn’t have a snowball’s chance in a pizza oven to win that contract. They could have offered to do the job for free and wouldn’t have been awarded the contract because the perceived risk was too high. It was impossible for them to read and digest the entire RFP package in ten days, much less write a proposal that addressed every point in the package. They had three options:

1. Go through the motions; write and submit a proposal; and get promptly dismissed.
2. Tell GD that they didn’t want to waste anybody’s time, and request to be removed from the bid list.
3. Ignore the rules, do what they do best, and try to win the project.

I’m sure you already know which option we chose. We found the five key pages buried in the RFP – the pages that listed the technical requirements for the project. We made copies of those pages then set the whole pile of notebooks in the back of a closet. Then we got to work designing and assembling a fully functional prototype of the system that we proposed to deliver to GD. We ordered components for rush delivery; we had some custom parts fabricated at a local machine shop; and we pulled a few all-nighters designing, assembling and testing.

Ten days passed very quickly and it was time to present proposals. Clint and Bob were the last of the bidders scheduled to present to GD. When we entered the meeting room, all of the GD engineers looked at their watches, wondering if they could usher us out of the room in time for lunch.

The kabuki dance

The other engineering firms had followed the rules perfectly – they knew the kabuki dance of aerospace contracts. They brought in teams of five or six senior managers. The 3-foot tall stacks of notebooks had morphed into stacks of proposals that were equally tall and that regurgitated every point in the RFP and added a few more points of their own. They presented slide shows (in the glorious days before PowerPoint) full of org charts and flow charts and man-hour allocations and project phases and schedules for the coming year. Clint and Bob didn’t have any of that.

Clint and Bob started their presentation by laying their proposal on the table – a paper binder containing five pages typed double-spaced (because if it were single-spaced, it would have only been two and a half pages). Everybody looked at their watches again and squirmed in their chairs and scowled. Then Clint and Bob said that they didn’t want to go over the proposal because that wouldn’t be a good use of everybody’s time. The scowls around the table deepened. Clint and Bob said that they would prefer to show GD what they intended to deliver. The scowls were now mixed with looks of confusion. Clint and Bob weren’t doing the kabuki dance properly!

We set a box on the table. We pulled our prototype system out of the box, plugged it into the wall, and told the GD engineers, “If we are awarded the project, this is what we will deliver, and this first unit can be installed and up and running within a week.” The prototype had a complete operator control panel and functional motors with enough torque to rotate the rocket bodies. It met or exceeded all requirements for accuracy, repeatability and reliability.

The scowls around the table turned to smiles, and then to grins that they couldn’t suppress. Every GD employee in the room took turns pushing buttons and rotating knobs on the control panel and watching the motors turn. After about 10 minutes of testing the prototype, they said, “Officially, we have to go through a series of internal approval procedures, but unofficially, you’re getting this project. Your bid has the lowest price and there is almost zero risk associated with it because a complete functional system is sitting on the table at our facility.”

That prototype was the first of six controllers to be installed at GD, and it started a three-year stream of nearly continuous projects at General Dynamics for the little two-man company.

To this day, every Atlas and Titan-Centaur rocket that is launched is made using equipment that Clint and Bob designed, assembled and installed at General Dynamics. And that 3-foot-tall stack of notebooks is probably still collecting dust in a closet in a condo in La Jolla.

Lessons

There are three important lessons in this case study:

Don’t be intimidated by bigger, more experienced competitors. Your small size makes you more nimble and responsive.
Recognize your strengths and have faith in them. If you think you can do it and if the big boys tell you that you can’t do it, believe in yourself and ignore the big boys.
When something looks impossible, often it’s because the “impossible” things are blocking your view. Shove the pile of impossible things into a dark corner and clear your desk. Then try to understand the real goals and figure out how you can achieve them.

If you could benefit from some “outside the box” thinking to help you compete – against the big boys or against your peers – please call or email Clint to see if he can help you.