Dealing with the elephant: Build the software you need, then sell it.

This is the fourth post in a short series I’m pretty much done with about the business model for online news before I go back to my usual routine of pointing out the obvious to people wearing dark glasses.  The starting point, the givens in the equation, are listed here.  Suggest which windmill I should tilt at next using the Skribit widget in the sidebar of my blog while it’s still there.

elephant by droolcup on Flickr
“elephant” by droolcup on Flickr

There’s something funny about software for publishing online news.

Newspapers don’t develop it.

There’s an exception or two to that rule of course, but I hope I’ve force-fed you enough fine LJWorld.com products at this point to hammer that exception home.  (I almost wish they had an affiliate program.)

But usually, instead of spending money to hire developers to build software to match the specifications of their own needs, newspapers and the companies that own them reach out the third-party vendors on a daily basis in order to provide basic functionality to online readers, consumers, and advertisers.

Follow along with me for a moment, substituting your own organization for the Royal We, in the parlance of our times:

  • Classifieds? Let someone else build it, sell it, and profit from it.  We won’t have much input into what they build for us, but we won’t need to worry about the servers or credit card processing.
  • Databases? If we know what to do with them, we certainly haven’t hired anyone who can build them with journalistic intent.  We outsource them, or we trust the one developer in the newsroom who knows what they’re doing to build a framework we can use more than once, or that we can use when they move on.
  • Calendars, content management systems, even project management tools? We seem to have been out sick from school on the day “vertical integration” was covered in AP Economics.

No, I wouldn’t recommend you drop everything you’re doing so you can re-invent the wheel, especially when some of those wheels are pretty darn good at filling your needs for a relatively small short-term price.

But yes, I heartily recommend you build an extensible Web application for the next unserved need in your organization.  Just pick any one of those that pops up in the next month or so, and go at it.

After you’ve launched it and earned the praise of your peers, slap a price tag on a license and get to work marketing it.

You’ve made a long-term investment by hiring developers.  The capital is coming back in the form of the application that’s useful to your organization; think of the license fees for the software as interest income.  You’ll be supporting the software for your own papers, anyway; might as well serve a few other organizations at the same time, for a price.

So ask yourself which software needs are going unmet in your own organization.  If you can’t find the right tool for the job, chances are, no one else can either.

A caveat: I’ve given out a lot of advice (some of it unsolicited) to newsrooms about using free, Web-based tools for online news production.  I still think that’s the right approach for many news-related purposes, but as soon as you find yourself paying for a mediocre service that’s part of your core business routine, it’s time to build something better.

Working with developers and designers

I wrote a post for IdeaLab earlier today.  It’s a short update on ReportingOn development, framed as a weighing of the pros and cons of a few different development platforms.

It occurred to me near the end of it that I should treat this project as if the developer was someone other than myself.  (Yes, at some point in the next year, I’m planning on hiring out some design work on the site, and possibly some development for a specific purpose or two, but not right away.)

So here are five tips for working with Web developers and designers:

  1. Content is king:  Your new hire or freelance pal can’t magically build a site out of nothing.  You need to know exactly what type of content lives on your site.  That doesn’t mean you need to write a bunch of fake entries or create phantom profiles, although that couldn’t hurt.  It means you need to know what belongs in each space on the front page, and where the links on that page lead.  Please don’t tell a designer what you want “it” to look like if you haven’t talked about what “it” is.  This happens all the time.
  2. Start with a pencil:  That’s right, it’s time to whip out ye olde dead tree times two — paper and pencil.  Personally, I prefer swiping a sheet of 11×17 from the nearest printer.  Lots of room for notes at that scale, plus, you’re going to want to draw all sorts of crazy arrows and add captions and numbers and diagrams and… maybe that’s just me.  But either way, this is your first prototype: Paper and pencil.  Pen if you prefer to live dangerously.
  3. Prototype in HTML if you can:  If you know enough HTML (and preferably, CSS) to build a little dummy page with links that go nowhere, by all means, do it.  Not only will this exercise help you build out a map of your site, showing you and your developer friends what needs to be a link and where it might lead, but if you’re good with HTML and CSS, these dummy pages might even become templates you can plug dynamic code into later.
  4. See more than one option:  Once you’re relatively settled on branding and a rough color scheme (stick with words for colors at this stage, not hex codes), you’ll want to see multiple iterations of the design.  Consider these rough drafts, not final products to accept or reject.  Now is the time to finalize that color scheme, make some decisions about where to place those blocks of content, and eliminate any features that feel superfluous.
  5. Don’t pixel-push:  Seriously, do you really think it’s going to matter in the end whether or not there’s just a little bit more whitespace around that heading?  It’s not going to matter to your users.  If precise design and perfect typography is your thing, hire someone who is an expert at putting those elements in just the right spot.  It’s nice if you can get it all looking just the way you pictured it in your head, but you should really just hire people you can trust, and then trust them.  Chances are, they have built more of these than you have, and their judgment (and experience) is there for a reason.

And a bonus tip: Pay attention to the dominant trends in Web development and design.  If you’re involved at all in the building of Web sites these days, you should at least be taking a cursory glance at A List Apart, 37signals, and the work of Khoi Vinh, Dan Cederholm, and everyone you see in the blogrolls or posts on all these sites.

The goal here isn’t to throw around buzzwords; it’s to better understand the real words your developers and designers are using.  Don’t say “AJAX!!!” without reading about it first, for example.  You’ll have a better time talking with the construction crew if you have some level of familiarity with the materials.

Your tips for working with humans who work with code?

In the comments…