Ten reasons to use a wiki for documentation

I’ve been very impressed by how useful the wiki has been in real world use: here are the reasons that have made the wiki very successful for us.

Thought Wikipedia was the only wiki? Think again! A wiki can be a great help in keeping all your documentation up-to-date and easily accessible. In this article I’ll explain why you should give a wiki a try.

For a couple of years now, I’ve been working with a FTSE 100 company that uses wiki software for keeping its internal IT documentation. This includes notes relating to development, testing, and how the various IT systems and business concepts work.

I’ve been very impressed by how useful the wiki has been in real world use, so I thought I’d share the reasons that have made the wiki very successful for us (and for me in particular, as a documentation author as well as a reader).

As knowledge management becomes ever more important, most companies should give serious consideration to using wiki software, not just within IT departments but in the wider business.

The wiki software I’ve been using is Atlassian Confluence, but no doubt using other wiki software will realise some if not all of these benefits.

So in no particular order, the benefits that I’ve personally found with using a wiki for documentation are:

1. Easy to find information

A wiki puts information is all in one place and is fully searchable.

With hundreds of topics, potentially written by hundreds of users, it’s easy to end up with a labyrinthine folder structure of Word documents that sit gathering virtual dust because nobody can find them. For example, I had been working with the company for about 8 months before somebody pointed me to some useful documentation that I could have used right from my first day with them!

A searchable wiki makes it quick to home in on exactly the information you require.

2. Easy to tell how up-to-date a document is

I recently read a corporate document, that’s still being issued, that discussed upcoming changes for 2005 – it’s now 2014 as I write this!

A wiki breaks a large topic into a series of sections, one per page, and with automatic date tracking for when each section was last updated you can easily say how up-to-date or out-of-date each individual section is.

If you read a sentence in the documentation similar to “John recently did some work on the payment system”, which is bad because it isn’t specific, you can at least roughly narrow down when this time period might have been. In a Word document that was started 10 years ago and periodically updated, you would have no idea as to even which year it might have been!

Since out-of-date documentation cannot be trusted, and might be either wrong or actively misleading, being able to tell the precise age of the documentation you are reading greatly helps with understanding how much or how little you can trust the documentation.

3. Easy to update, so gets updated more often

Updating the documentation is as simple as clicking the bookmark in your web browser to get to the wiki and making a few changes. There’s no need to fiddle around with version control or re-issuing documentation.

It’s also easy to do a very small change here and there, when you have time, and then build up the documentation over a period of time. I have wiki pages that I update probably once a week as I learn a new snippet of information. This contrasts with the approach of writing documentation into Word documents, where it feels more like you have to write a whole manual or definitive piece of documentation all in one go and then more formally distribute it.

So because wiki documentation is so easy to update, it tends to be more up to date.

4. Easy version control and roll back

A wiki lets you easily go back to a previous version of a page. You can take a more active approach to updating documentation, because you know you can never really break it, and can always roll back if you put the wrong thing in the wrong place.

5. No need for a single document owner

There are no bottlenecks centred around individual people for writing documentation or putting together everyone’s contributions. If you’re reading or reviewing documentation, and you know that something is wrong or out of date, you can update it immediately, without asking permission, and without waiting for somebody else. This helps to keep documentation up to date.

6. See who wrote what

Depending on who wrote the documentation (and your assessment of their competence!), you know more about the likely quality of the documentation, and exactly who to speak to if you have questions about it.

7. Links within the documentation to help users navigate

Being able to easily add links to other relevant sections of the documentation means it’s easier to guide readers to the precise areas of the documentation they will find more useful, and easier to make sure that the reader doesn’t miss other important topics related to the section they are currently reading.

8. See a list of recent edits to know who has been working on what

Atlassian Confluence has a dashboard view showing who has been editing what. It’s like a running commentary showing all the changes that have been made. It makes it easier to see who is working on what areas of the documentation.

9. Notification of changes

It’s easy to set up notifications for sections of the documentation that you are interested in, and then be told when those sections are updated. This way you can be made instantly aware of when important information might have changed.

10. Easy team collaboration for fast-moving information

For sections of the document relating to project status, or what will be released in an upcoming software release, where several authors may all be making changes in the same day, the wiki environment makes it very easy to make and share these changes.

When NOT to use a wiki

There are some downsides to using a wiki, largely relating to making sure that information is kept secure, but any documentation written down can theoretically be disclosed outside the company anyway, so this isn’t an issue solely related to wikis. Wikis can restrict access to certain pages to certain users anyway.

Wikis can tend to be quite free-form, with different authors doing things in different ways, so sometimes you need to try and impose a bit of structure.

If you need full distribution and approval controls, perhaps when issuing documents to third parties, then you might want to consider a fully-fledged Document Management System, but they are quite heavyweight and expensive, and you’re unlikely to really need it.


I’ve found that using a wiki for documentation brings the documentation to life. It’s no longer an old, stale and outdated document that gets written once and then forgotten about, never updated and never read. It keeps the information up to date, prominent, and searchable. I’ve been very impressed with using a wiki, so I recommend that you give it a try.

Action Points

If you want free wiki software then consider MediaWiki, which is what Wikipedia runs on. If you’d prefer a hosted wiki that you can get started with immediately, there are a variety of free and paid services.

Benefits of staying simple: Lewis Hamilton Formula 1 Style

Here’s an interesting BBC article on the benefit of staying simple when performance really matters.

Here’s an interesting BBC article on the benefit of staying simple when performance really matters, as seen from the high performance perspective of Formula 1 racing driver – and former world champion – Lewis Hamilton.

Hamilton’s central argument is that  “When it’s not simple, it can be stressful, and when you’re stressed you’re not working at your best.”

It’s well worth a read.


Technical Debt: say it like you mean it

When I hear people using the phrase “technical debt”, it’s mostly used as a buzzword. The actual meaning is lost. It’s a euphemism. When they say “There is a lot of technical debt on the project”, senior people nod sagely … and then ignore it.

What is technical debt?

It’s fashionable these days to talk about “technical debt”. If you need a primer on this, Martin Fowler gives a good concise explanation of Technical Debt.

The concept itself is fair enough: each time you hack something into your software code without doing it properly you store up problems for the future, and these problems are added to your technical debt. In that sense it’s a useful way to think about the problem of how a code base gets polluted and harder to work on as time progresses, as the debt either mounts up or gets tackled and reduced.

So far so good. But when I hear people using the phrase “technical debt”, it’s mostly used as a buzzword. The actual meaning is lost. It’s a euphemism. When they say “There is a lot of technical debt on the project”, senior people nod sagely … and then ignore it.

That’s because “technical debt” doesn’t really sound that bad. It’s the same reason the military say “collateral damage” rather than “slaughtering innocent women and children” – it just tends to sound a bit better!

If you could put an accurate financial value on technical debt, as you can with real financial debt, then maybe a conversation on technical debt would have some meaning. There have been some efforts to quantify technical debt, but you might argue that the methodologies are vague and the final numbers don’t really stand up to scrutiny. Maybe they never could.

Technical debt as a euphemism

So what I really dislike about the phrase “technical debt” is the Euphemism Factor, the way it can pull the wool over the eyes of management, and even people on the project, and make them think that things aren’t as bad as they really are.

Let me put it this way. If you were the boss, and a project manager was reporting to you on their progress, what would you think if they said this: “There’s some technical debt on the project, so it will be quite challenging to add the new features.” That’s a phrase I’ve actually heard someone use. And I saw the boss take it, nod his head, and move on to something else.

What the project manager actually meant was, “This code base is so wrecked we can’t do anything with it! Every time we try to add something new, we break a dozen other things. We’ve built fudge on top of fudge on top of fudge, and the whole thing is about to come crashing down around our ears!”

Let’s face it, what we’re really talking about here is honest conversation. Take a look at some of Jack Welch’s books. (Jack Welch was the CEO of General Electric from 1981 – 2001, and is widely held to have been a highly successful CEO). He often talks about the power of being what he calls “candid”. You might choose to call it honesty, frankness, or being straightforward. Or as Dan Kennedy puts it, “No B.S.”

Action points

My recommendation is to move away from euphemisms like “technical debt”, unless you’re attempting to do some kind of serious financial quantification of it, and move towards concrete, specific comments that quantify the problem in terms that are meaningful to the business, and emphasise the potential productivity that is being lost.

So maybe what the project manager should have said was something along the lines of, “Due to the speed with which we’ve had to release new features, and the number of different developers that have worked on the project over the years, the code base has got really difficult to work with now. We’re finding that we break quite a few things when we add new features, so we’re always treading on eggshells, and that slows us down a lot. We haven’t got enough automated test cases to give us confidence that we’re not breaking the old things when we add the new things. So adding this feature is going to take us at least 4 weeks, when if the code base was cleaner we could do it in 2 weeks at the most. The last feature took us 6 weeks, and we think really it should have been 3 weeks, but we broke existing features X, Y and Z in the process, and fixing them took us 3 weeks.”

It takes a bit longer to say, but it shouldn’t take long for the message to sink in!

I’m obviously not suggesting charging in with both boots and telling the CEO in no uncertain terms that we’re all doomed! But what I am suggesting is that you’ll get better results if you move away from vague terms and management speak, like “technical debt”, that can be brushed under the carpet and ignored, and start talking in practical, quantifiable terms about the poor state of your code and how it’s affecting your productivity. Then you might get the chance to do something about it!

How to interview a Business Analyst

As I see it, the primary aim of a job interview is to let the candidate prove his or her skills and show his or her ability to fit in with the team. You can then choose the best person for the job. Not everyone sees it like this!

If you’re not familiar with what a business analyst does, if we’re talking about producing software then it’s the business analyst who will understand the requirements for what the software should do, and will document this for the business people and the software developers. The business analyst acts as a bridge between the business and the technology.

A while back, when I was a candidate applying for roles as a contract Business Analyst, I went to two or three interviews before I found a role that I wanted to accept. I was struck by just how bad a job some of these companies were doing at interviewing Business Analysts. I also was very impressed by another company, whose offer I accepted, so I’ll talk about their Business Analyst interview process too.

Aims of interviewing a Business Analyst

First decide what your hiring process is aiming to achieve, then figure out a way to achieve it.

As I see it, the primary aim of a job interview is to let the candidate prove his or her skills and show his or her ability to fit in with the team. You can then choose the best person for the job.

Notice that I’m saying “prove” his or her skills, not merely talk about them. To my mind, you should be thinking more in terms of auditions than interviews. More of that later.

Competency-Based Interviews: the bad way to interview a Business Analyst

Let me fill you in on a horror story. I showed up for what turned out to be a Seriously Bad Interview. It was being run by two people; one seemed in some way to be connected with software development, but I wasn’t really sure what he did. He didn’t seem like he would be my manager though. The other person was from HR (Human Resources, Human Remains, you know the kind of thing.)

So straight away, you can see that at least one of the two interviewers, maybe both of them, doesn’t really understand the Business Analyst role, what a BA does, how it’s done, and what separates a good BA from a bad BA. Presumably the HR person was there for some kind of spurious compliance reason, to make sure some kind of obviously massively flawed process was being properly followed.

The type of interview was what in the jargon they call a “Competency-Based Interview”.

The questions were all of the form, “Give an example of a time where…”. And yet the scenarios were all so boring, so bland, and so commonplace that I seriously doubt that any candidate has ever given an interesting and illuminating answer that allows them to prove their skills. They were asking for the sort of things that you do all day every day, without really giving it a second thought, don’t tend to stick in the mind. “Give an example of a time you have held a pen.” It was that kind of moronic thing! No way to sort the wheat from the chaff.

There are two main problems with this kind of competency-based interview approach:

Problem #1: As a candidate, you really need to see the questions in advance to be able to think of interesting and enlightening scenarios that fit the question you’re being asked. Although tedious, some of the scenarios I was asked to give an example of were actually quite complicated. You’ve got about two seconds from when they ask the question to search your memory banks, combing through every day of your working life, to pluck out the most relevant and interesting scenario. That’s never going to happen! You’re probably just going to pick out the first thing that comes to mind. So even if the question tries to get at something interesting or useful to discuss, the candidate probably isn’t going to come up with the best example of that work on the spot, so as an interviewer you’re never going to see the best of them.

Problem #2: You’re likely to favour someone who talks a good game, even if they can’t actually do the job. As an interviewer asking questions, you’ll probably weed out the total fools who somehow slipped through the CV /resume screening process. That gets rid of maybe the bottom 50% of candidates. But of the remaining candidates, how do you know who’s best? You’ve got a base level of competence, but beyond that, it’s anyone’s guess as to how they’ll actually perform. If you were this kind of interviewer, and someone asked you “Are you 100% sure this person can do the job? What proof do you have?”, then you have to answer that no, you’re not sure, because you have no proof beyond the candidate’s assurances of their miraculous powers to analyse the business benefits of the water that they walk on! You haven’t proved anything!

The result: No candidate can possibly shine under this kind of amateurish questioning, and no interviewer can confidently identify the best candidate.

After this interview, I turned this role down. I reasoned that if the quality of the interviewing process was so poor, then the quality of the people I would be working with would probably be poor too, since there was no effective quality gate to identify the best people. Also, if this was the process that had been designed and rigorously followed (thanks to the HR policing), then whoever designed the process (and was likely to be in charge of something important) probably wasn’t much good either!

I hope whoever accepted the role is now enjoying it. (They won’t be.)

Case study interviews: The good way to interview a Business Analyst

The good company, whose contract role I accepted, decided to do an interview based around identifying requirements in a case study. The study was based on a real-world scenario that the company has actually faced, and then feeding back the requirements from this case study to the interview panel. The panel was made up of a senior business analyst, and also a senior software developer and project manager from the project the successful candidate would be working on.

I don’t want to say too much about the details of this exercise, since I’ve heard it’s still in use by that company and I don’t want to spoil its effectiveness for them.

There are some important lessons to learn from this approach:

  1. The case study approach isn’t just about talking the talk, you’ve actually got to do some work and prove your skills! Show, don’t tell, as they say in Hollywood!
  2. The case study simulates being able to work quickly and accurately under pressure.
  3. The interview panel has a senior business analyst, who understands the job, does the job himself, and knows what to look for. He’s not a generic HR person!
  4. The interview panel has people from the actual project that the candidate is being recruited for, so that the chemistry between the existing team and the candidate can be identified. The BA usually sits as a bridge between the development team, the project manager and the business, so it’s good to have multiple perspectives on the interviewing panel.

As a candidate, I felt that the case study approach let me demonstrate my analytical skills and my communication skills. It also let me slip in some facts and figures about the company I was being interviewed for, and their industry, to show I’d done my homework! (I’m always amazed by people who turn up to interviews without knowing anything about the company… and are surprised at how short the interview is for them!)

The case study approach was a much more effective way of simulating the real-life job than a competency-based list of half-remembered scenarios that happened several years ago!

During the time I was feeding back on the case study, I said various things that hinted at my previous experience, and along with the notes on my CV/resume this formed a second part of the interview, where the interview panel asked direct questions to get a feel for my level of experience on past projects in certain areas.


I’m sure there’s more than one way to effectively interview for the role of Business Analyst, and maybe a competency-based interview by a more skilled interview panel could be more useful, but a case study exercise, where the candidate proves their effectiveness with a real-world scenario, is a good place to start. When I was a software developer, interviewing other software developers, we used a technical test based on a computer programming exercise – a similar process with similar good results. It’s not a perfect process, but it definitely gets you a lot further than competency-based interviews! As a candidate, you can’t BS it, you can either prove you know your stuff or you can’t.

Action Points

If you’re interviewing someone for the role of Business Analyst:

  • Find a good case study based on some work you’ve actually already done, so that you know the points that a good candidate should pick up on.
  • Prepare a checklist of things the candidate should identify from the case study. Split the checklist into two: essential issues the candidate must identify, and secondary issues that give them bonus points.
  • Prepare two or three questions to give to the candidate that relate to the case study, asking them to identify and analyse the case study. Then you can talk about this during the interview and get them to verbally give you their findings, as they would in a project meeting.
  • Find an interview panel that represents the people the successful candidate will be working with.

Simplify your data: stop capturing data you don’t need

Three reasons to simplify your data capture.

One of the most common issues I see when trying to simplify all kinds web pages, and even offline paper forms, is asking for information that isn’t being used anywhere. This applies to sign-up processes, sales funnels, insurance applications: pretty much everywhere you are capturing data from a user.

It seems almost trivial to say this, but for each piece of data you capture, it’s worth asking how that data will then be used. How will it be processed? What decisions will be made based on this piece of data?

If it turns out the data is not being used at all, or is not being used meaningfully, then consider removing that field and not capturing that data any more.

Why simplify your data capture?

There are three main reasons to consider making your data more simple:

1. Simplifying data will save time for the user filling in the information, and especially in cases where you can remove more than one field this might make the difference between a user filling in a form, or giving up and going elsewhere. Often (but not always), the less information you ask for, the more people will fill in the form (so the higher your conversion rate, if you’re building a sales funnel.)

2. Simplifying your data will make processing the data easier too. Every line of code in software theoretically needs testing, and might also fail regression tests and break during later changes to the software, so there is a maintenance overhead and a cost for every piece of information that you capture.

3. In the UK, the Data Protection Act 1998, Schedule 1, states that, “Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.” So by simplifying the data you capture, and removing fields that are no longer used, you’ll help with legal compliance too.

Action Points

Review the places where you ask for data from users. For each piece of data you capture, decide whether it is being meaningfully processed or used to help with decision making. If not, consider not capturing that data any more.

Ten ways to improve your technical blog writing

Simple things you can do to quickly and dramatically improve the quality of your technical blog writing.

Recently, several of my technical friends have spoken to me about their blogs, saying that they lack confidence in their writing style. They asked me for advice on how to improve their technical blog writing, so as the editor of ViewsHound, and a software developer myself, here’s my top tips for technical blog writing:

1. APT: Audience, Purpose, Tone

I learned “Audience, Purpose, Tone” during my A-levels, and it was probably the most important thing I learned in the whole two years! I recommend this tip to everyone who I help with their writing, and it never fails to improve their work. Just spend a minute thinking of this before you write. It’s very simple:

  • Audience: Who are you writing for? What knowledge and skills do they have?
  • Purpose: Why are you writing? To inform, entertain, persuade?
  • Tone: What attitude will you take? Friendly, harsh, formal, relaxed?

There’s not much to say about tone, but let’s look at audience and purpose in more depth.

2. Audience: Don’t fall between two stools

One of the most common failings I see with technical articles is that the author has no idea of who his reader will be, so the article swings wildly between being too basic and being too advanced. As a result, the article is no use to anyone. So decide right at the start whether you are writing for novices or for advanced readers, and stick to it. You can explain a few terms as you go, to broaden the appeal of the article, but decide how much knowledge your reader is likely to have *before* you start writing.

3. Purpose: What is the benefit to the reader of your post?

Another common mistake in technical blog posts is to forget why you are actually writing! You always want the reader to come away from your article with something: knowledge, an opinion, an emotion, a better impression of you, etc. So before you start to write, figure out what you want your reader to do at the end of the article. It’s not complicated: in the case of this article, all I want is for you to come away being able to write better blog posts (and, as a result, increase the traffic to your blog).

4. Write your headline and summary first, but check at the end

Writing your headline and summary first will give you clarity, give you a focus for your article, and will help to keep you on track. (Some blogs don’t have a summary, but articles like this one do.) After you finish writing the article, go back and make sure you didn’t drift, and then either reword the article or change the headline/summary to make sure you’re still consistent.

Good headlines are hard to write—I toyed with about ten before I settled on the one I used here, and it’s still not perfect. However, in these days of Reddit, Hacker News and other aggregators, you often *only* have the headline to make someone decide whether to read your article or not, so it’s worth spending the time on a good headline.

5. Plan before you write

If you set off into the unknown without a map (or, let’s face it, without your phone!) you’re going to get lost. That’s exactly what happens to a lot of bloggers. The post meanders, never really goes anywhere, and most people will stop reading. The solution is to make a plan.

Some people find it hard to believe, but good planning doesn’t *cost* time, it actually *saves* time. All I did to plan this article was to grab a sheet of paper and a pencil and jot down the subheadings for the things I wanted to say. (I prefer planning on paper, where I can quickly scribble, cross out, draw arrows, etc, but it doesn’t matter how you do it.)

6. Use a story

When children are small, they all have stories read to them. As adults, many of us read fiction and watch films. The desire for stories and narrative seems to be hard-wired into us. So if you can weave a story into your article, so much the better. You don’t need to be the next Stephen King, a few sentences will do. To start this article, I chose to tell the story of why I was writing this article, and it took me literally one and a half sentences.

Your technical writing will come to life if you can bring in stories and human experience, without rambling or being long-winded. It’s often enough to explain the story as to why you happen to be writing your blog post. What chain of events—meetings, failures, successes—led to the thoughts you are now writing about?

7. Use subheadings for structure and to break up the text

Subheadings are under-used. I think this stems from school, where you had to write essays with no subheadings. Well, like a lot of the useless junk they taught you at school, ignore that and get some subheading action going!

There are three main uses for subheadings. First, they give structure for you as a writer, and help stop you from wandering off at futile tangents. Second, they signpost to the reader what is coming up, to help the reader make sense of your work and place it into context. The brain takes in information better if it understands ahead of time what it is going to be learning, and a subheading lets you do this. Third, a subheading is a cosmetic device to break up large amounts of text. It’s just more comfortable for the reader if you use regular subheadings.

As a side point, you can use little signposts like “First, second, third”, as I did in the paragraph above, to almost act as mini-subheadings and keep things on track.

8. Use fairly short paragraphs

As with subheadings, it’s easier for the reader of a blog if you keep paragraphs short. Paragraph length isn’t as important if your work will end up on paper—in a book or magazine—but for reading on screen short paragraphs help keep the eye from physically wandering. There’s no hard and fast rule, but five sentences or so is a reasonable length for a paragraph.

9. Back up your opinions with facts and links

A popular failing of bloggers is to state opinions without backing them up. Use facts, with links to the sources, wherever you can. The more authoritative the source, the more useful the fact or link will be in helping you to make your case. Wikipedia is OK to quote, but not great; it carries weight in the eyes of a lot of people, but of course the content is open to being abused. If your readers trust your sources, they are more likely to trust *you*.

10. Lay your work to one side, and proof read later

You should always proof-read your work before posting it. I always like to lay my work aside for a few hours, or preferably a few days, before coming back to it to proof-read it. If you allow time for your brain to recover from writing, and then come back to your post afresh, you will find mistakes, poorly-worded phrases, things that don’t make sense, and all kind of nasties! So unless you’re desperate to rush something topical onto your blog, it’s worth the wait and then doing a proof-read.

Bonus: Write your blog posts in Microsoft Word or Open Office

Whether you use Microsoft Word, Open Office or another product, just be sure to write in an actual word processor. This way you get a spell checker, and a grammar checker (which is mediocre but better than nothing). I recently exchanged some emails with a person who wrote his articles in a raw text editor, and they needed a lot of editing, much of which he could have avoided by writing in a word processor.

Final thoughts

These tips are all simple. Hopefully they’re all obvious too. There’s really nothing complicated here, but if you focus on these things your technical blog writing will noticeably improve, and so should your traffic.

Thirteen simple steps to planning a killer blog

If you’re going to start a blog, or want to plan a blog, here’s a useful 13 step blog planning worksheet.

If you’re going to start a blog, or want to plan a blog, here’s a useful 13 step blog planning worksheet.

If you think about these questions while you’re planning your corporate blog or personal blog you’ll keep your writing on-track. Good planning is the first step to success, so here’s what you need to consider.

Section 1: The basics

Q1. Audience: Who is your intended audience? In other words, who is your blog aimed at?

Q2. Purpose: Why will people read your blog? Examples include: for information, for entertainment, for relaxation, learning “How-To”.

Q3. Tone: What style of writing do you want? Examples include: formal, relaxed, conversational.

Section 2: Topics and categories

Q4. Topics: What general topic areas do you want to write about?

Q5. Categories: What categories will you divide your articles into?

Q6. The yawn test: Why will your readers care about each category you’ve chosen? If you’re struggling to think of a reason, ditch it!

Q7. Types of media: What media do you wish to use? Examples include text, images, video, audio.

Section 3: Ideas for articles

Q8. Sites to watch: Which sites are you going to regularly scan in order to get ideas for articles?

Q9. Life experiences: Which experiences in your day-to-day life are you going to use as a source of ideas for articles?

Section 4: Getting it written

Q10. Frequency: How often do you want to add a new article? (Once or twice a week is a good starting point).

Q11. Authors: Who is going to write your articles? Will you do this yourself, invite other contributors (free of charge), or pay people to write?

Section 5: Promotion

Q12. Announcing new articles: Where will you announce new articles? Publisha automatically posts to your Facebook wall and Twitter feed. Consider other specialist news sources, such as putting technical articles on Hacker News, and general sites such as StumbleUpon, Reddit and Digg.

Section 6: Tracking and improvement

Q13. Tracking: How will you see which articles are most popular, and decide which direction to take your blog in future? Publisha has built-in analytics, and you can easily link Google Analytics. These are likely to be your best choices.

Your traffic sources have a half-life

A couple of quick lessons from an interesting article.

I read a great article a while back that will be of interest to all publishers promoting their online publications. It’s called Your Traffic Sources Have a Half-Life by Rob Walling.

Here are a couple of quick lessons I take from the article:

1. Consider how much lasting, long-term value each piece of promotion has.

Every article you write goes towards boosting your SEO rankings, and attracting new readers, so each time you write an article you are investing in the future of your publication.

Advertising to get fans or followers can often be a good investment when you’re just starting out. But I found through real life experience when I was working with Publisha that once you hit a certain magic number of followers, around 1,000, you can stop advertising and things take off under their own steam.

2. Build your list of followers like crazy.

In this day and age, you’ll know that by sharing articles on Facebook and Twitter (and Google Plus if you like), you can increase your audience. Having Facebook “Like” buttons (or similar) on your articles encourages people to become a fan of your publication, where they will see messages you post on your wall from that point onwards.

How to get the best out of Seedcamp

Since my company Publisha was a 2010 finalist and winner of Seedcamp, I thought it would be helpful for future teams taking part if I gave my thoughts on how to get the most out of Seedcamp.

Since my company Publisha was a 2010 finalist and winner of Seedcamp, I thought it would be helpful for future teams taking part if I gave my thoughts on how to get the most out of Seedcamp.

The short answer: be prepared

First and foremost, go in prepared! If I’d been properly prepared I would have got 10 times the value out of Seedcamp. (I didn’t really know what I was preparing for though, so read this post!)

It’s not just being prepared with a great presentation, but being prepared for the Question and Answer sessions. (Get a good night’s sleep, the Q&A session is really tiring!). Here’s what to prepare:


For the presentation, try and get hold of a few previous Seedcamp presentations and see which format you like most. Whatever you do though, get to the meat quickly! Sitting through about 20 presentations can be pretty heavy going, so grab the audience quick! Don’t mumble on about background detail, come straight out and say this is what we do and this is why we’re amazing!

By the way, everyone else will appear amazing and you will feel like your business is a big old sack o’ the brown stuff. Believe me, appearances can be very deceptive here, so don’t worry about that!

Many of the teams from the Seedcamp 2010 heats and finals seemed to have some trouble describing their business and what they actually did! Quite a few resorted to a pitch of the form “We’re like (Company X) for Y”, eg “We’re like FourSquare for Gardening”. Given that this was quite a few months ago, quite a lot of people in the room didn’t know what FourSquare was, so that description fell flat! (For the record, FourSquare is a service for you to tell burglars you’re not in your house, so they can come round and steal your TV.)

Some people did those presentations where they don’t really put any words on the Powerpoint slides, just pictures. Personally I absolutely hate that style of presentation – you may as well just turn the damned projector off if you’re going to do that! Then again, other people will worship you as a God for doing it. It’s a funny old game!

One random tip while I think of it: don’t look like a famous person when you’re giving your speech. One bloke last year looked exactly like Jarvis Cocker out of Pulp, and I spent the whole time he was on stage thinking “Let’s all meet up in the year 2000”!

Your presentation will be recorded on video, but don’t let that freak you out. I practiced my presentation about ten times (literally), to get a good feel for the timing and what I wanted to say. This will also make you get your slides in the right order – I usually find that when I practice a talk I realise that my argument is all over the place and makes about as much sense as the sudden rise to fame of “comedian” Michael McIntyre, ie none whatsoever! So practice, practice, practice. I personally don’t like to practice in front of people, because you always think you’re rubbish and get embarrassed. Incidentally, if you are rubbish, lots of practice on your own will give you confidence. But heck, I was still shaking like a leaf when I grabbed the mic, and nobody seemed to mind!

As you’re talking, try to look everyone in the eye at least once. It helps to make a connection with them.

One last thing about the presentation: DON’T USE NOTES! A few people came up with notes written on a piece of paper and they got totally crucified! Thanks to the folks at www.crucifyr.com for helping with that (they’re like FourSquare for death.) As long as you’re not reading word-for-word off your slides you can just use the headlines and bullet points on your slides to jog your memory.

Preparing for Q&A

Let’s get back to talking about how to prepare for the Q&A sessions that follow the presentations. I didn’t make a particularly good job of prepping for this, because I didn’t know what to expect, so hopefully you can avoid falling into the same trap.

The thing you’re going to really need to prove, as a start-up, is that you’ve got a market. And you’ve got to prove it fast. Yesterday a 12 year old kid came to me asking for business advice(!) about starting a business selling X-Box controllers that he’d modified with custom graphic designs. I told him to buy one, modify it, then put it on eBay. Figure out if anyone wants to buy that stuff as quick as you can, before you put much time or money into it. (If I’d been really hardcore I’d have told him to put it on eBay first, and don’t actually bother making it until someone had bought it!)

It’s the same for your business. You’ve got to find a set of customers who love the product and will pay for it in some form.

So the sort of questions you should prepare if you want to get the most out of the Q&A are about testing and proving your market (unless you’re already raking in cash hand over fist). To give an example, our business, Publisha, targets four key segments: bloggers, digital magazines, print magazines and corporate communications. You need to know what your segments are. Then you need to think about which segment to address. Before the day, think of the sorts of criteria you could use to help you decide on the issues you’re undecided on. Make sure you know what questions you need mentor help with. Then you can spend the time getting down to brass tacks, not skirting around the issue.

A final thought for the mentor sessions: get the mentors to introduce themselves. I didn’t really find a good form of words to ask for these introductions without sounding like a game show host, but you might have more luck.

The key question

Don’t lose sight of one key thing: in a sense, all you’ve got to do to succeed in business is keep selling lots of things to lots of people. That’s it, really. No “paradigm leveraging” required.

So the one key question is “How are you going to make money?”. Make sure you can answer this one. If you can’t, just spend the day talking about that. I was on a panel discussion at Oxford University and I told some wannabe hotshot that if your business doesn’t make money “It’s not a business, it’s a hobby!” Well, he didn’t like that much! Make sure your mentors don’t say that to you! I know Twitter started without a plan to make money, and so did Google, but they’re the exceptions. You need to have a really silly name if you’re going to pull that one off! (Surely that’s how Evan and Biz did it at Twitter 🙂 )

If your business can’t easily make money, I’d recommend doing what in Seedcamp world they call a “pivot”. Everywhere else they call it “Give up and try something else.” You’ll hear a lot about pivots.

In terms of the main way of making money, there’s two main ways. One is monthly subscriptions, the buzzword being “SaaS revenues” (pronounced “Sass”, to rhyme with mass). The other way is “Everything else” (pronounced “ads”). You’ll find passionate mentor advocates for both positions. I had one person tell me that if I did SaaS I’d be crazy, and another that if I didn’t do SaaS I’d be crazy. With some simple mathematics I soon cancelled this down to “You’re crazy”, and went to lunch. You need to either develop a firm view on which of these types of revenues is good for you, or you need to develop a set of questions and criteria that the mentors can help you to work through in order to decide.

“The Dirty Dozen” marketing processes to master

Continuing the topic of really focussing in on what’s important, to get the most out of your time with the mentors, it helps if you map out in advance what you actually do, and what you plan to do.

At Publisha I identified 12 key marketing processes that we needed to master. I think they’re the same for pretty much every business. You’d do yourself a favour to read my blog post on the dirty dozen marketing processes, and see how they apply to your business. You can then spend time with the mentors figuring out which of these processes you need to work on, and how best to go about it.

Final thought: don’t panic

So that’s what you need to do to have a good day. I’m sure you will have a good day: everyone I’ve met through Seedcamp has been really nice, and very helpful. So above all, have fun, because if you’re not having fun you may as well be called Nigel and work as a corporate salary man in Milton Keynes. And that’s not you!

Good luck!