Web Development: Operations or Development?
In the project-based, big corporate world that many of us live in, there is a constant obsession with “finishing a site and putting it in ops mode.” The premise here being you do all the work, you spit-shine your product, and when it launches you say goodbye. Someone else, usually an off-shore third party, takes over. You then watch as your creation is slowly strangled, mangled, and forgotten.
I’ve got two objections to this line of thinking. First of all — why bother building something if you’re going to toss it on the trash heap? Be honest with yourself, if you want the best product you use the best team. Unless, of course, your plan was just to come up with a quick experiment and have no intention of letting it live.
Secondly, no one seems to understand operations vs. ongoing development. When someone says “Okay that didn’t work great, can you switch around the CTA and add a product call-out? Maybe include a promo?”, that is not operations. I mean, someone is operating a computer to do it, but that’s active, ongoing development. Sure, a low cost resource could do it, but should they?
Don’t build products to put on ice, put failed ideas on ice
At work I obsessively use the phrase:
Feed the winners, starve the losers.
This for me embodies ongoing development on any digital property. As rule number one, you should constantly be experimenting, driving towards a better consumer experience. You can always make your “thing” easier, faster, simpler, and more valuable for your customers. You’re bound to make a lot of bad judgement calls — people simply won’t like a feature or layout or design. Fine! Throw that one out, try again. Do that 100 times a quarter.
When we approach a project or product with the inherent intention to let it wither after deployment, we do our customers and ourselves a disservice. Instead of truly determining if something should live, we’ve doomed our baby Frankenstein to the annals of interweb history before it’s even been zapped alive amid the maniacal cackles of a late-night deployment team.
The bare minimum should be learning from what you’ve put out there.
- How did customers respond?
- Did your conversion theory work? Could a small tweak make it work better?
- Were consumers excited about your idea/product/solution/service? Why not?
An operations team cannot solve any of this for you. Creative professionals and smart developers do that.
The actual work itself is development and creative output
When you want to really experiment with your product and grow it, you don’t want a bunch of “yes women/men” executing on your ideas. You want smart creatives pushing the envelope, exploring other digital properties for ideas, and studying the consumer and market. Every idea (that isn’t terrible) should be treated as viable. Not every idea can be tried, but give them a chance with mental triage.
To that end, site launch is just a dot on the timeline: launch. After that, you keep developing your product. Let me reiterate:
After you launch a digital product, you keep developing your digital product.
Operations has nothing to do with ongoing development
Well, that’s not entirely true. But they aren’t the same thing.
Operations is:
- Is the site running well? Why not?
- Are there a bunch of bugs for some reason?
- Could CI/CD run better/faster/cheaper?
- Hell, could the whole thing run better/faster/cheaper?
- Someone submitted an issue — where does that go?
- Are we up-to-date on audits?
- Are we up-to-date on patching and other security issues?
Operations absolutely isn’t:
- Let’s run some experiments on calls-to-action!
- Implementing new designs
- Adding new site functionality
- Instrumenting components for A/B (split) testing
- We’re switching from X API to Y API, do that!
- I need ideas on technical benefits for the consumer
- I need ideas on partnerships/features/horizontal growth opportunities/lunch
