Don’t Pay For A Website

It’s perfectly rational: you’ve got a budget, and you want to get a thing for it. Your CEO, Whitey McBaldguy, has set a strategic objective to capture leads, so you need a lead-generation microsite, damnit.

You meet with some agencies and hire the one with the most plants in their lobby. They send you some shiny designs, you tell them to make the pixels nicer, and after a few feedback rounds it’s looking hotter than a seatbelt clip in summer.

The development team uses computer language and black magic to recreate the pixels you approved, and at last, it’s published to www.PleaseGenerateLeads.com.

The project is over, and after only 6 months!

Then, you launch your microsite, and find out it’s shit at capturing leads.

“If you aren’t embarrassed by the first version of your product, you shipped too late.” ―Reid Hoffman

Hoffman hit the nail on the head. It’s a problem you still see to this day, and it’s rooted in the nature of the client/agency relationship.

Too often, clients are focused on a tangible deliverable, and agencies only care about sweet cash money. Unfortunately, what that means is that the budget is used to try and perfect the design before it is released, and then there’s a hard handover to the client’s operations team, who lack the design capabilities required to iterate.

Here’s the secret: there is no such thing as a perfect first release. Anybody who tells you differently is selling something.

At DIJGTAL, we believe you should always treat a website like a digital product. You’re not making a new lead generation microsite that will operate perfectly from day 1, you are investing in a new product that will continually evolve, and add real long-term value to the business.

If you reframe your projects in this way, and actively plan for post-launch iteration and optimisation, you’ll be amazed just how quickly you get results – even if it is a little embarrassing at first.

But if I release something that sucks, won’t that damage my brand?

It depends on how it sucks. There’s acceptable suckage and unacceptable suckage.

If the designer has done sloppy work that misuses your brand, is poorly considered, and doesn’t match user needs at all, that is unacceptable suckage.

If your first release only achieves one small part of the business objective but does it really well and meets a user need, that is acceptable suckage.

Likewise, if your product tests well in the lab, but falls a bit flat in the market, that is acceptable suckage – so long as you’ve launched quickly and have budget allocated for iteration. Fail fast, remember – it’s far better to get into market in a week and learn that your idea is total garbage than invest a million dollars in making a very polished piece of crap.

Here are some tips on getting a prototype of acceptable suckage to market:

• Constrain your scope. Pick one problem to solve, and bloody nail it.
• Embrace manual processes if they save you development effort. Eg. how often will a customer change their address once they’re in your system? Not often enough to justify the design and development work on your first release, I’d wager. Let them contact your customer support centre, and you can manually edit their details in the backend.
• Consider building throwaway proof-of-concept prototypes. If you rein in your inner perfectionist, you can leverage a template to get a basic, stable site live within days, which will enable a whole heap of learning.

Summarise your article please, Jack

Ok! In summary, don’t pay for a website; pay for an evolving product.