obviousity's posterous

obviousity's posterous

Casse No-i  //  The unfiltered ramblings of a 20-something designer/dev with a bad case of the people-watchies... a girl who just needs to get it off her chest once in a while.

Filed under

professional development

See all posts on posterous with this tag ยป
Oct 13 / 10:11am

How To Write Bad Proposals and Alienate Clients

**NOTE: Read at your own risk - If you don't understand, appreciate, or are otherwise not keen on satire, please leave now ;) **

Reviewing competing proposals is not uncommon in my day-to-day, especially with existing clients who are shopping for a new build after a number of years. I have to admit, I've been absolutely inspired by the quality of some work that has come across my desk in this regard. So inspired, in fact, I've almost felt a fear in me not to proceed with my counter-proposal.

But, I'm a fighter.  So instead of cowering under my desk as I've threatened to do so many times before, I took this is an opportunity to learn and apply some new techniques to my current work process. 

The following is a combined list of my observations and recommendations on how to write a proposal that's a guaranteed winner:

  1. Techy words are scary and sound self-important. Use them frequently, especially out of context.
    -
    Normal people love to feel lost in a sea of unfamiliar words and impersonal half-thoughts. They also love reading paragraph after paragraph about the inner workings of a build: plug-ins, taxonomies, you name it. Littering your proposals with jargon is guaranteed to flood your business with willing clients.
  2. Spend at least 40% of your proposal saying bad things about the current build.
    -
    Never mind the fact the client came to you with a list of current gripes. Maybe they were already aware that their site was old and doesn't do what they need any more. Don't waste your time getting the prospect excited about a new solution; just keep beating the dead horse. It works every time.
  3. Spend another 20% filling pages with lofty buzz words and fluff. 
    -
    Tell them about how they need a "website 2.0+ redesign" built on "software that will be everything you want it to be" and how you're going to "set up a social network" as part of "providing a very powerful internet marketing experience." - (note: the more you can write like a non-native speaker, the better) 
    -
    Here's another great one that plays on #1 as well: "your software shouldn't be limited to itself. The user should also be able to pull in multiple API's, creating a whole new user experience and making the site totally user-driven"
  4. Misinform as much as you can
    -
    Clients love to be mislead, especially when they come to you because they trust your expertise. Not sure about a subject or if it even applies to what you're quoting? That's fine!! Just make it up as you go!!  This is especially great as you will begin to discredit other developers in the process - as the prospect swallows down your false rhetoric, everyone else will begin to leave a bad taste. More work for you! Yay!
  5. Don't let the client know why any of what you're saying is of value to them.
    -
    Tying the first 4 points together, it's incredibly important that you produce bullet point after bullet point of semi-related facts and quasi-important observations without telling the client how it affects them.  Don't ever mention helping attract new customers or using content to direct qualified users into the sales funnel. And never, EVER speak to them in terms they understand.  Clients absolutely hate to be told how investing in a website is going to help their brand or their business, especially when you do it clearly and with purpose.
  6. Whatever you do, don't encourage the client by speaking as if you are the ones who will provide that value.
    -
    In case you do slip up and mention how your work is of value to the client, at least make sure not to give them the idea that YOUR work explicitly is the best fit. Use the third person and speak in a passive voice: "your developer would need to" "the website should" -- saying things like "we will do X to give you Y" or "we've had A results with related B, we are excited to C for you" is a terrible idea.  Talking about the project like it's already yours is an even worse one.

To sum it all up: talk out your ass and don't bother thinking about, much less addressing the client's needs. I mean, they came to YOU for work because they can't do it themselves anyway. Who cares if you give them a reason to stick around?

It's not like there's others out there who are going to take the time to make that client understand and feel good about their investment. There's definitely no one out there ready to build a lasting relationship by taking a genuine interest in the prospect's ultimate success.

...

That said, let me leave you with what is one of the greatest compliments I've ever been paid, by what is one the best clients I will ever have:

"If I could meet some of these developers, I'd kick them in the teeth myself! ...

...not you, Casse. You actually know how to talk to PEOPLE."

Filed under  //  advice   madness   professional development   satire  
Oct 6 / 6:58pm

Know When to Ask for Help - Don't be Stupid Tuesday #2

I really wanted to give you something good today. Some blow-your-mind-from-left-field piece of prose that knocked you straight out of your socks into next week.

But, alas, it's  Tuesday night and I haven't managed to give you a thing. I apologize for that. Apparently last week's challenge wasn't enough, and so this week I had the pleasure of playing IT & super-site-saver since early Sunday morning. No, I'm not complaining.  It's all in a day's work as a senior developing small firm project managing dev-seo-marketing-web-wizard.  And I do love what I do.

I am also still human.

So after three days of restless fighting with some damn-nasty-catastrophic failure; in between swearing, finger-crossing, fighting with backups, sifting through raw data, and digging into the magic top hat on my desk... Three days later this Swiss Army dev has been reduced to a mere pile of blinking, drooling, barely keystroking, mush. 

This time last week, after I had wasted almost six hours of my life diligently enriched my skillset cramming my brain with code I may never need again - I at least had the motivation afterward to put my conclusions and story morals into words.  I formed (at least what I think was) a semi-coherent piece for you from that camel-back-breaking straw of an experience.  But, no.  No, that is not the case right now.

Right now, today, in my post traumatic stupor, I am pulling some glowing morals and wisdom from the embers - but nothing is quite lucid.

I'm pretty sure I want to tell you about how it's ok to ask for help.  Not just in the obvious "hey I can't lift this piano myself" sense, either. But the kind of help where you offer your clients everything without having to do it all yourself.

That's the most important help you can get when you know how to get it right.

Now I don't mean hiring cheap, faceless, unaccountable labor from who-knows-where. Well, do what you will, but that's not what we're talking about here. I mean building strong, symbiotic relationships and making the right choices that allow you to profit while strengthening your pool of resources and offering your clients the full service they're asking for.  I *also* mean knowing where that balance is and further knowing what "full service" means for you.

I mean using all that's available in today's almost over-connected world to your best advantage.

I mean running lean like a small firm should, but being mean like a big firm can. 

Not bad mean. Tough mean. Flexible. Capable. Indisposable mean.

It is fortunate that over the past year I have worked to establish policies and procedures with this team while continuing to move forward with new builds and projects.  To show where it's ok to get that sort of "help" and still build our business internally.  I work every day to help us achieve that balance, and the end result was an issue whose damage was minimized to a fraction of the catastrophe it *could have* been.  Yes, there were a few heart stopping moments. Yes, it is unfortunate that similar practices weren't there in the first place.  But, it's something we'll recover and move forward from. And, it is what it is. And what it is is something I've seen before many, many times.

And that's fine because it's also something that can be fixed. 

(!!WARNING SELFISH ASIDE!! It's also fine for me because helping teams become lean, strong, indisposable mean is one of the things I do best.)

As my brain finally begins to reboot here, I'm finding inspiration to talk more about those things you can do to be mean like that. I'd like to follow up with more details, insights, and recommendations: I just don't have it in me to do it now. So let me leave you with this:

Success, especially these days, isn't determined by size nor is it fostered by greed.  Sure it goes against a lot of stodgy old conventional wisdom, but it is possible be everything to your clients without having to do it all yourself.  It's not just acceptable to ask for help - it is in the greatest interest of your sanity, your strength, and your livelihood to embrace that notion.  To reach out in pursuit of perfecting that balance.

As I hope you will see, the benefits are endless.

Sep 29 / 7:10pm

The Importance of Documentation - Don't Be Stupid Tuesday #1

I wasted almost five hours of my life this morning because of the (what I consider to be) poor choices of the person in my position before me.

Five hours of playing IT-for-free when I could have been doing my "real" job building a billable web project.

Five hours of learning about something that, although related to my day-to-day, doesn't serve me as much more than a tertiary bullet point on the laundry list of my career goals.

Five hours that skewed the day so badly it was hard to accomplish anything relevant in the afternoon.

Five hours of pain I wouldn't wish on my worst enemy.  Not even that person-before-me who ultimately made today possible.

And while I'd like to discuss all the events that led to today's debacle - I'm focusing my first Don't Be Stupid Tuesday post on what I think is the most important point of the lot because I think it's the easiest to accomplish.  And, that's the importance of appropriately documenting your project for future reference and maintentance, whether its for you or whoever comes along to take care of it next.

This isn't the same-forever-only-2-people-know Coke Secret Formula. This is a live build that real, normal people need to use in every day situations. It needs to be adaptable, fixable, and understandable.

I shouldn't even have to say this, but the number of issues I hit with things I didn't build - issues that would have been moot with the right notation - issues that are normal concerns of someone in my position, managing the care of 100+ sites, and building new constantly ...I don't know how to stress the importance of taking that little extra time to DOCUMENT YOUR SHIT.

Comment your code. Provide a README or similar notation.  Tell someone else where you keep your list of passwords. I'm not saying publish it to your Facebook - be smart about it. And whatever it is, consider the person that may be fixing it later: a PHP file may need some commentary to suit another developer, but a mail server may need some direction in layman's terms in case the IT is out of the office. 

Point is, whatever you've put together, you're not going to be there forever to take care of it. And even if you are, who's to say there won't be a day some catastrophe hits and you're not there to troubleshoot, or maybe 3 years go by and you plumb forget what you did in the first place. It happens.

I mentioned earlier that this was the easiest to avoid of all the causes of today's mess-i-wouldn't-wish-on-anyone, and I stand by that statement. Stop leaning on excuses, and start breaking the bad habits.

I'm not just asking for my own sake as the "person that fills your shoes next."  Do it for your development as a professional. As someone who cares about being a Senior This, a Lead That, or simply a hard worker who is seen as a competent, accountable whatever you are.  I know when you stop and think about it, you'd hate to be in my shoes: wasting time, keystrokes, and sanity on things that could, and more importantly SHOULD, be much less stressful.

I'm even willing to bet you've already been there once or twice before.

Filed under  //  accountability   advice   document   professional development   stupidtuesday   tips