Proposals Are Like First Dates

By Deane Barker on June 6, 2016

True story: some development firms lie through their teeth in proposals.

Shocking, I know.  But sometimes the winner of a competitive proposal process is going to be the firm that lies the most convincingly.

Of course, they couch it in terms that let them sleep at night, but in the end, they either tell bald-faced lies, or they simply capitalize on the prospect’s ignorance to position themselves inaccurately or promise things they know perfectly well they can never deliver.

I’m proud to say Blend Interactive doesn’t do this.  God willing, I will always have the integrity and foresight to look down the road at the longer-term relationship and ask myself if what I’m writing or saying at any given time is the truth.

But, when responding to an RFP, all firms — Blend included — put their best foot forward.  Proposals are like a first date: you get all dressed up, try to look your best, minimize any flaws, and basically put forward an optimized representation of yourself, in an effort to impress the other person.

Let’s face it, you know you have problems, because everyone does.  Eventually, your date is going to find out that you can’t sing, you forget anniversaries, and that you don’t really engage in extreme sports every weekend. But you’re thinking, “By then, we’ll be invested in a relationship and so they’ll overlook it or we’ll work around it.”  Sound familiar?

Getting “first date ready” for every RFP is tiring, and there’s always an underlying anxiety for me.  Again, I don’t outright lie in proposals, but there might be sticky things that I’d rather not discuss or dig into that far.  Every proposal has weak spots.  I hate the idea that someone will bring them up, not so much because I don’t want to talk about them (I love to talk about content management and interesting solutions to sticky problems), but because it would remind me that the proposal process in this business is so broken that this is what firms have to do to get hired.  I hate the idea that I have to maneuver around this stuff in the first place.

Lately, I’ve turned over a new leaf.  I’ve tried to be as brutally honest as possible in proposals, even when it might reflect poorly on Blend.  Call it naivety, but I’m hoping that honesty will come across, and the prospect will be impressed by that. I figure that someone who wants to hire us in spite of any shortcomings is probably someone we’d like to do business with.

A few months ago, we received a large RFP.  This was for a project that would easily be $500,000, and perhaps even seven figures over time.  It was for a national organization that I promise you’ve heard of before.  For the purposes of this blog post, we’ll call it BigCorp.

The project was a great fit for us — a type of website we do well, and exactly in our vertical.  It was a big, complicated RFP. They had multiple pages of scenarios and follow-on questions.  And there was no boilerplate text in the response — all of it was a custom, unique, 17-page response to that specific RFP.  We easily had $5,000 invested in the response in my consulting time alone (looking back on all the costs associated with responding, we had about $15,000 wrapped up in it by the end).

What I did was write the proposal like I normally would, but then I read through it again.  Whenever I came across something that made me think “yeah, but…”, I highlighted that.  Then, I went back and wrote what I really wanted to say.  I told myself, “Pretend there’s zero chance you could ever win this deal, so you have nothing to lose.  What would you write then?”  I put this text in a shaded sidebar box, as if I lowered my voice an octave, cupped my mouth with my hand, and said, “Okay, now here’s the real scoop…”

For example, BigCorp wanted a bid for implementation services.  We get this all the time, but — let’s face facts — it’s pretty ridiculous at this stage.  We couldn’t know nearly enough to provide them an actual number.  So after providing the requested breakdown as very high-level, estimated numbers, I came out and told them the truth:

Let’s be honest: the numbers quoted above are, essentially, an educated guess. We crawled the entire site, analyzed the URL patterns, and browsed through the site for several hours. Based on that, all we can do is compare it to past implementations to come up with pricing ranges.

While this usually turns out to be fairly accurate, this absolutely doesn’t take the place of a formal, paid discovery phase. To pretend otherwise would be disingenuous.

What we live in fear of is hidden functionality (especially hidden integration with other systems) that we can’t see. Hidden processes are another wildcard: we see the published content, but we have no way of knowing how it got there, which could be a highly process-intensive process, for all we know.

Hence, our desire for a formal technical planning project. It’s the only way we feel we can provide an honest bid that both sides can live with.

The fact is, with a proposal like this, if they want a firm number, you have two options:
  1. Provide a firm number, but give yourself an out — like, a clause that let’s you re-evaluate for scope at the end of the first phase or something — and then hope they either don’t read it or don’t understand what it actually means.
  2. Pad the hell out of the number.  Just give a sky-high number that protects you, and pretend it’s the result of some responsible scoping process which couldn’t possibly be completed at this point.
I hate both of those options.  Generally, we try to do a paid, flat fee discovery process, and then scope the result of that for implementation.  And this is what I was trying to explain to the prospect in this case.

Later, they wanted to know our experience with a bunch of the items in their technology stack, or wanted us to explain how we would integrate with Software X.  We had zero experience with any of it (in fact, we had never even heard of half of it — they were Old School).

I decided to tackle it head-on:

[…] This is an example of where we’re familiar with the genre of software, but not the specific brand of software BigCorp is using.

[…] Another example where we have experience with the genre, but not the specifics. We’re simply theorizing here based on broader experience.

[…] again, this is an example of simply speculating on the functionality of a software package we have no direct experience with. We’re confident we could find some acceptable integration points, but it would be disingenuous for us to pretend to be more specific.

Things like this remind me of politics.   In situations like this, you normally talk like a politician and go around the problem — “Yes, yes, we’ll lower taxes.  It’ll be phenomenal and taxes will be lower and everyone will be happy!  How will we do that?  Well, let me tell you a story about Bob from Omaha, who I met on the campaign trail last week…”

I hate this.  I hate it in politics, and I hate it in proposals.  Fact is, Blend has worked with a lot of stuff, but we haven’t worked with everything.  But, we’re smart people, and there’s a good chance we’ve done something similar to what you (or BigCorp, in this case) want to do.  So we’ll start there, and talk through it.  If we have absolutely no idea how to work with it, we’ll find something who does, or you should hire someone else.  If we get to that point, I’ll do my best to help you find that someone else.

Further down, they wanted to know Blend’s financial viability.  So, we attached financial statements, and I decided to put those into context.

Honestly, Blend could be more profitable than it is. Over the years we’ve learned that the two secrets to profitability in this business are: (1) pay as little as possible and suffer through the resulting employee turnover; and (2) commoditize your services as much as possible by coercing your clients to adapt to a rigid platform and process which takes as few risks as possible.

We refuse to do either. We have virtually no employee turnover (it’s so low as to be almost impossible to measure), and we aggressively pursue innovative and interesting work. Thus, Blend is merely solidly profitable, not wildly profitable.

(In reading that again, it sounds like I’m trying to apologize for poor financial numbers, but I’m honestly not.  I won’t go so far as to post my actual P&Ls here, but suffice it to say that Blend does quite well.  We’ve been in business for 11 years, and I don’t think we’ve ever had a money-losing quarter. We have financials that a lot of firms would envy.)

(Edit: in the spirit of full disclosure, I went and checked.  We have had a couple of money-losing quarters. However, we resell software, and for a long time we didn’t account for large sales as inventory. So when a license sale crossed reporting periods, we often lost money in one quarter, only to make a ton of money in the next quarter. In the last couple years, we’ve changed how we account for this, so I doubt this would ever happen again.)

I didn’t want to humble-brag too much, so when I discussed Blend’s status as the very first North American Partner of the Year, I wrote this:

The 2009 Partner of the Year Award is certainly nothing to overlook, but at the time there were maybe five partners total in North America.
I explained that when something breaks on a website, it’s usually our fault:
[…] 99% of problems will either be with (1) the server infrastructure, or (2) Blend’s implementation.
They wanted to know about EPiServer certifications.  I told them we have a couple, but…
Admittedly, our EPiServer certifications are for older versions of the product.
I called out EPiServer in some places:
[…] EPiServer’s category system is workable, but imperfect.

[…] The ability for clients to directly inject new functionality into production environments [via the Add On Store] was not received well by the EPiServer integrator community.

[…] EPiServer’s default functionality doesn’t redirect, it actually delivers the content under the vanity URL directly. We don’t think this is a good idea.

And I explained that marketing automation integration is basically a pile of theoretical features that hardly anyone uses:
Marketing automation is an example of where CMS is long on theory and opportunity, and short on actual practice. When it comes to marketing integration, the vendors – EPiServer included – are far out in front of the customers.

Additionally, customers’ eyes are bigger than their appetites. We regularly have clients who have grand plans for extremely complex marketing integrations, but these plans never quite seem to get underway. As such, the advanced marketing tools built into the current generation of CMS are incredibly under-utilized, which is a fact CMS vendors try very hard to gloss over.

Understand that this is true across the industry. When asked for case studies, vendors will cherry-pick from an extremely limited number of customers actually using the technology they offer. Every vendor knows full-well that they’re offering functionality very few customers have the sophistication to use.

[…] A/B testing, like the marketing automation discussed previously, is something that remains wholly theoretical for most clients. A few marketing departments have the capacity or wherewithal to actually implement A/B testing effectively. The tools are certainly available, they just rarely get used.

I gotta tell you — writing this stuff was enormously therapeutic for me. I basically took the filters off and told the client what I actually wanted to tell them, not the censored stuff that you normally spew to sell software and services.

And what was the result?

Well, I wish I could tell that we won the deal…but we didn’t.  We came in second.  We did quite well, and got all the way to the final round, but they picked a larger firm that was 100 yards away from them geographically.  Headcount and remote location are two problems that Blend will always struggle with.

Regardless, I was happy with the process.  We went down swinging, and it felt good to just write a proposal with complete honesty and disclosure.  Despite losing, I dropped this organization a note when I was coming to their city last week, and they were happy to meet with me and just talk shop in general.  The guy who managed the proposal process introduced to the project manager (the one managing the project we had lost), to which I offered my expertise if I could help in any way.  I feel like there might still be a relationship there somewhere in the future, and perhaps that’s because of how I framed the relationship with the original proposal.

This is the new normal for me personally, and Blend as a company. If you send us an RFP, expect a response that might border on…strange.  If we don’t know how to do something, we’ll tell you.  If we think your idea sucks, we’ll tell you that too.  If we don’t think you should hire us at all, we’ll decline to respond and explain why.

Ask me on a date.  I’m going to show up looking like I normally do. I can’t sing, I’ll forget our anniversary, and I’ve never actually climbed Kilimanjaro.  But we’ll work through those issues, and I promise you that I have lots of other things going for me.

Talk to me in a year.  If I’m still in business, then perhaps it was the right way to go.

Gadgetopia