I’ve spend a great deal of my time in the aerospace engineering community writing proposals as well as white papers and other persuasive documents designed to bring in money for a particular technology program or to make sure the funding doesn’t go away (those are usually government-to-government documents). What follows here are some suggestions for improving the strength of your case.

It’s not all about the tech

I’ve said this before, but it bears repeating: you cannot talk only about the technology you’re supporting and what it does and hope to win your case.

I can hear some of you now: “But that’s what they asked for, dummy!” Yes, if you read a request for proposal (RFP) or questionnaire from a government agency, they might ask for something direct like “Describe your program and its outcomes to date.”

Simple, right? Not entirely. This is where you need to do some history writing and yes, I will dare to say it, marketing.

For instance, you might be tempted to dive right in and talk about your product’s features: “The Gargantua XL 01. SuperProgram processes data at 500 megaburps per spleef in a Linux/UNIX environment and can calculate orbital parameters within .4449321q43 arc-seconds per minute.” And yes, to another engineer who uses your program, that might make all the sense in the world. However, this approach makes one critical and quite probably fatal assumption: you’re assuming that another is reading it.

Depending on the size (dollar amount) of the program in question, you might have a much more diverse reading audience. They will most likely have a technical background of some sort, but they might not be specifically versed in your tech.

Ideally, rather than starting with what the technology can do, you want to talk about what problem your particular flavor of technology will allow its end users to do. That’s not to say you won’t have the opportunity to brag about your 500 megaburps, but not right out of the gate. What you want to be able to tell your reader–someone who might hold the money to your paycheck in his or her hand–is that the Gargantua XL 01 SuperProgram allows rockets or spacecraft to get to their target or destination with a precision 10 times greater than anything currently flying, or that your widget will reduce the likelihood of an error to drop from 1 in 10,000 to 1 in 100,000.

Or instead of a computer program, you might have a rocket to sell. What makes it better than any other rocket out there? Who benefits? How much money is saved? How much more capability does it provide? What types of missions does it support better than any other competitor? Is your technology faster, better, cheaper, more efficient, or higher quality? In which ways?

If the format of your proposal/white paper allows you the freedom to provide background, I’d explain things in the following order:

• What is the problem being solved?
• What has been done before?
• How is your particular gadget/vehicle/process different?
• How is your particular gadget/vehicle/process better?
• What are the benefits of doing things with your gadget?

Keeping it simple

On occasion I’ve written internal white papers defending existing programs. The readers could have been White House or Congressional staff members. As I learned from The Citizen’s Guide to Lobbying and my own experience as a citizen lobbyist, staffers on Capitol Hill tend to be young (mid-20s), might or might not be familiar with the history of your program, and are notoriously overloaded covering multiple issues for their particular member of Congress. This is not meant to bash congressional staffers, just a reality that you have to face. And given those realities and the likely constraints on their time and attention, you need to keep your language clear, simple, and relatively free from jargon.

How does this translate in your writing?

First of all, you will need to reduce the amount of technobabble. Speak in laymen’s (i.e., non-engineering) terms about the technology and its benefits. That might mean using “computer chip” instead of “integrated circuit” or “rocket” instead of “launch vehicle.” I can imagine someone saying, “You’re dumbing it down!” or “You’re making it less precise.” Okay, fair enough. If there’s a reason you need to specify “integrated circuit” rather than “computer chip,” explain that terminology briefly and move on.

Remember that the goal is to reach your audience and win them over. If they spend ten minutes puzzling over what you’re even saying, you’ve lost them. Most staffers are college educated, so you don’t have to be condescending, but you should be clear. For instance, you probably don’t need to provide the dictionary definition of what an algorithm is (if that’s what you’re supporting), but you should take a sentence to explain what the algorithm does in its designated environment.

Graphics are good

If you have the time and a good graphic designer on hand, you should include relevant graphics that depict or amplify the story you want to tell. For example, bar charts to compare your performance with others, line charts to show trends for why your tech is necessary, area charts to show how much smaller your program’s operational footprint is compared to others’, etc.

Naming names

This can mean several things.

Showing off the team

If you’re writing to the government and you want to show who the players are on your particular project, you should name them and their locations–this is important for members of Congress, especially, who will want to know which districts/constituencies benefit from a particular program being funded.

Showing off the beneficiaries

Your widget/process undoubtedly benefits someone, or you wouldn’t have built it. You should mention designated beneficiaries first–the people who will most immediately benefit from your work–and then move on to secondary beneficiaries. Lastly, you can talk about future beneficiaries or customers. This is especially important on Small Business Innovation Research (SBIR) or Small Business Technology Transfer (STTR) proposals, which include a section that specifically asks how you will commercialize your product or service beyond the designated government customer(s). Ideally, the benefit of your product should be concrete and easily achievable. Telling your reviewers that “everybody on Earth will benefit” from using your product, you’d better make a convincing case. (Hint: it’s usually easier to do some research on your intended target market and work the numbers from there.) And, again, pointing out the geographical locations of known or anticipated beneficiaries can help a member of Congress (or their staff) better justify the notion of supporting the program.

Underpromising vs. Overpromising

Not going to lie: I’ve had the privilege of writing about some very cool things, from avionics to launch vehicles to telescopes. The technological wizardry behind them gives me hope for a better future. However, the risk exists for inventors to overpromise on the eventual outcomes of their inventions. This usually happens when engineers get ambitious about anticipating their secondary effects. Hypothetical: Company X’s new widget reduces the cost of launching a rocket from ABC Space Center. The ambitious engineering marketer then goes on to presume that lower launch costs from ABC Space Center will resort in more launches, thereby improving the local economy in the municipalities closest to the center. That might be taking things a bit too far.

On the flip side, a technical team can get so focused on the specific application for their particular widget that they miss out on identifying how the widget could, with a little tweaking, work in another market or technology area. As Gene Kranz says in the movie Apollo 13, “I don’t care what something was designed to do, I want to know what it can do!” This type of thinking is especially important when discussing potential commercialization opportunities.

Ghosting the competition

You might find yourself in a situation where you know that your program is being evaluated competitively against another. In that situation, you should research the competition (odds are, you know who it is already), and be honest about the advantages and disadvantages of other products/services. Sometimes you don’t name the competition by name, just cite their differences and why your stuff is better–this is called ghosting. Then you need to provide reasonable rebuttals to their advantages and show how your product/service has an advantage. If there are unknown criteria where you know your product or service has an advantage, mention those as well.

Closing Thoughts

Again, it’s a common mistake in the engineering/tech community to cite capabilities and features and to then assume that the technology will speak for itself. You can’t just talk about what your widget will do, you have to explain why it’s better, faster, cheaper, with more sparkles than any other competing product and why that should matter to the end customer. Providing those answers can make a difference when there are dollars and jobs on the line.