Making decisions in an information vacuum is a publishing speciality.

Every time you acquire a book, you have to weigh up any number of factors: some predictable, some entirely made up. Often it comes down to what I’ll euphemistically call “passion”: they who shout loudest, wins, because editorial decisions, no matter how analytical the approach, always come down to something of a leap of faith. (If they weren’t, every book would be a bestseller.)

But our familiarity with making such leaps for subjective decisions means we don’t get much practice at making other decisions more rigorously.

Choosing a new platform for your B2C Web site, for example. You know what it should do, and how it should look, but you don’t know which platform to choose. It’s a decision that will have far-reaching, long-lasting effects on your company. So it’s worth trying to adopt the most rigorous, least risky approach to decision-making.

The first thing to do is to ditch the hubris. No-one knows everything about everything. Accept that you are not an expert at specifying a website. Your plan should involve asking for help and accepting that your gut feeling on subjects you know little about is probably wrong. Your brief should include an information-gathering aspect, tapping in-house expertise, and also that of external contacts who can share their insight. Ask people who’ve done this all before a hundred times to help you — and then trust them, unlike the managers in this short, fly-on-the-wall comedy sketch. (I’ve been in meetings like that a horrible number of times).

Above video: The Expert, written & Directed by Lauris Beinerts, based on a short story, The Meeting, by Alexey Berezin.

One approach to information-gathering is to learn a bit about the field, yourself.

It’s like if you’re planning to go on holiday to France. You want to know enough French to get from the airport to your hotel, and to enquire about the regional cheeses. Enough to have good manners, and to show some interest in what people are saying. Same with technology. A month’s interested evening reading will get you to the able to ask sensible questions stage. If your interest is piqued, and you want to know more, there is no shortage of crash courses on programming — in fact, we run one periodically, tailored just for publishers — and the Internet is awash with information.

If you’re the person who signs the cheques, the happy side-effect is that you’ll know enough to sensibly, knowingly challenge your team to build new, interesting things that will add to your bottom line. You’ll adjust your recruitment strategy to attract technologically-competent people to your team. Your strategic planning will improve when you know what’s possible, what’s easy and what’s not. It’ll be easier for you to sign-off — or not — on your IT project implementation planning. If you don’t know anything about code, you don’t know what you don’t know, and that’s dangerous.

If you are a technical expert and need to convince the hierarchy to sign the cheque for the platform of your choice, there’s one rule: don’t use jargon. If you’re lucky enough to have a boss who will listen to and act upon your opinion, it’s incumbent on you to find a way to translate your technical understanding into what it means for the business. You’re the French fromagier in my increasingly tortured French holiday analogy. Use simple, familiar words with the plucky tourist who’s trying his best in pidgin French, and maybe you’ll be able to sell him some of your unpasteurised Camembert. (Ideally, he’ll just hold out cupped palms full of coins and notes that he doesn’t understand, and you’ll pick out the ones you want.)

If you know that WordPress is a mess under the hood, explain about the cost, time and business-risk implications of maintaining and extending horrible code, rather than trying to get your boss to care about how awful it is to have SQL embedded at the view layer, or that code should be ordered according to the MVC principle. You might be better at communicating in writing rather than face-to-face. A good boss, keen on reaching the right decision for the good of the company, will understand that and read your recommendations, rather than insist that you pitch your opinion in front of everyone.

Whether you take the blue “learning the technology” pill, or the red “trusting your experts” pill, you should always use a decision-making framework: a tool to help you take the emotion and confusion out of complex decisions.

Something like the Kepner-Trego matrix (see below) helps you to figure out what business objectives you’re trying to achieve, and which option is going to help you the most. You write down the things you must have, and the things you want. You might want to be able to integrate with your title management system, meet your functional spec, and to avoid buying a physical server.

Then you score your desires, giving them a weighting out of 100. Integration with your title management system would be very nice, so it gets a 20. Getting up and running quickly would be handy but it’s not the end of the world: it gets a 10. Costing no more than £3k is a must. Then you score your options against your desires, rejecting any which don’t achieve your musts. Multiply the scores by the weighting and you get a score for each of your options. It’s amazing how this approach helps to cut through the confusion of a complex decision to achieve clarity of thought.

Here’s an example.

To help create your Kepner-Trego matrix, you should keep asking the question, “What problem does this solve?“ For a B2C Web site decision, is your problem Amazon’s market share of your online sales? Or that there’s nowhere on the Internet for people to see all the photos from your books? Is it that your authors aren’t proud of you and won’t refer their contacts to your Web site? Or do you have no way for readers to join your mailing list? You need to articulate your problems if you’ve got a hope of finding a solution.

How much should you spend? When it comes to knowing how much money is reasonable for any technology project, you should consider the uniqueness of your requirements, and the complexity of the required functionality. The problem of selling books on a Web site is fairly complex, but it has been solved tens of thousands of times over: you shouldn’t pay someone to reinvent the wheel. Build on the shoulders of giants.

Conversely, Foyles’ recently-commissioned app, which allowed shoppers to search inside the real-life store, is a fairly simple piece of programming, but it’s unique and new. And it should cost more. Doing something for the first time costs money, not necessarily in hammering out lines of code, but in paying for the spark of invention.

When any decision needs to be made, keep asking, “What’s the problem?” until you get to the nub of things.

Make decisions knowingly. Then you’ll be sure that you’re getting a solution, not another problem.

Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?

We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.

Contact us via our contact form, or email us.