How Not to Propose

Impostor syndrome rears its head in weird ways.  

Take proposals.  My early proposals were highly technical.  Imagine page after page of feature descriptions, mock interfaces, and sample reports.  They were mind-numbingly boring and I often committed myself to features that turned out to be more difficult to implement than I had imagined.

I was desperate to prove to my potential client that I knew how to build software.  I would explain how a dropdown box would automatically populate with common entries.  I would seriously devote an entire paragraph to explaining this concept because it was such a killer feature.

The crazy part is that I put all this work into these proposals and it wasn't even what the clients wanted to see.  I regularly got responses like this from my clients:

"Thanks for the proposal. I looked at the first few pages, but I haven't had a chance to read through it all yet. I still need some time to go over it all."

Who could blame them?  These were often 10 to 15 pages long and full of minor details that, frankly, they really didn't care about.

Looking back on it now, I realize that I was writing my proposal for the wrong audience: me.  

Know your audience

When I choose a piece of software, I want to know its capabilities.  Will it integrate with these other applications that I already use?  Can I export into these three file formats?  What is my vendor lock-in risk?  These are the sorts of questions I would answer in my proposal.

But I was the intended audience in another way, too.   The proposal was as much--or more--about me responding to that voice in the back of my head that kept telling me, "Other people could do this better than you."

Remember, though, that you are ultimately selling a solution to your client.  You need to establish a meaningful connection with them.  You want them to have a fear of missing out by the time they read to the end of the proposal.  Trust me when I say that a laundry list of features will not elicit that response.

Features don't sell software

I'm about to tell you something that might hurt.  Clients don't care about features.  Not even the really cool features.  And even if they did care about cool features, they're not going to be able to construct in their head how a feature will work by reading about it in your proposal.

Here's the thing about features.  Great features remove friction from the user experience.  And the absolute best features are the ones that users don't even realize are there.  That's why features don't sell software.  Because you want them to be invisible.

Users won't have any clue what you're talking about if you tell them that all the most commonly used buttons in your software will be four times bigger than the rest of the buttons.  When they're using the program, though, and they almost never click the wrong button accidentally, they'll feel better than if they spent all day fighting with the interface.  

Even if you ask them what they liked about it, they will never say, "I like that you made the 'Create Invoice' button really big."  No, they'll say, "I can't really put my finger on it, but it was really easy to use."  

Features don't sell software.  Features deliver satisfaction.

Emotions sell software

Did that heading trigger your snake-oil-salesman radar?  That is a common reaction for programmers.  It conjures up images of tricking our clients into buying our software.  That's not what I'm talking about, though.  This is not about emotional manipulation; it's about emotional connection.

As human beings, we have a yearning to be heard.  To be understood.  It's why empathy is so powerful.  The ability to put ourselves in our clients' shoes allows us to connect with them on a deeply personal level.

I wrote earlier about how I used to put together proposals.  I did not talk yet about how I do them now.  My proposals are never more than five pages long now.  I use a slightly modified version of Jonathan Stark's proposal template.  

The first section of the proposal is a description of the problem.  This was never something I included in my proposals in the past, and I really didn't understand its purpose the first time I used it.  I thought, What was the point? After all, my client already knows what her problem is.  Why am I wasting everyone's time reviewing what we already know?

I wrote the section anyway, because I wanted to stick to the original format for at least the first draft.  Literally, all I had done was write down what we talked about in our discovery meeting.  I made sure to use the same words the client had used in our meeting, especially when it was tied to any kind of emotional language ("I hate...", "I would love...", etc.).

I read it back when I was done and I was blown away.  Mind you, I had not written a single word yet about what my solution would be or how it would work.  Yet I knew exactly what my client would think when she read that section. "This guy gets me!"

Understanding the problem

Of course, the key to eliciting that reaction is to actually, you know, get your client and understand her problem.  That requires going into your discovery meeting with a completely open mind.  You've probably only got one shot at this, so don't blow it like Ray Stantz.  Resist the urge to build a solution in your head while your client is talking.

Instead, take the time to dig into the root cause of the client's problem.  Peel back the layers of the onion.  Jonathan Stark refers to this as the "Why Conversation."  A good way to facilitate this is with Chris Voss's "mirroring technique."  The basic idea is to repeat back the last 1-3 words the person says, but with an upward inflection in your voice so that it comes out like a question.  It feels awkward saying it, but it accomplishes two important goals: 1) it naturally elicits an explanatory response (as opposed to a one-word answer) and 2) it prevents you from biasing the conversation (even unconsciously).

Conclusion

I'll leave it to Jonathan Stark to cover the remainder of his proposal template.  If you write client proposals, I highly recommend looking into Jonathan's template.  And if you bill for your services by the hour, I highly recommend you rethink that, too.

Image by Adina Voicu from Pixabay