One of the big buzzwords in ELT publishing at the moment is iterative publishing – the idea, borrowed from the software and startup world, that products should be in a constant state of evolution and improvement in response to changing market conditions, requirements from big customers or new technologies. The whole concept of ‘editions’ is apparently past its sell-by date in the internet age – too redolent of the dusty old print era. An iteratively published course doesn’t need editions, since it’s never more than a few months since the last update or improvement. One of the commonly cited advantages of digital (and particularly online) publishing is the ability to make updates to an already-published product in a way that just isn’t possible with print. Think corrections, general enhancements, topical content, implementing features requested by customers. All sounds great, and is what everyone is already used to with websites.
Of course, we’ve always had iterative publishing to some extent – reprint corrections are standard practice, and the gap between new editions of coursebooks has been decreasing – sometimes to as little as two or three years. So, maybe iterative publishing is really a matter of dramatically increasing the speed and impact of those updates – more actively looking for ways to make improvements as frequently as possible and putting in place structures and processes that make it feasible to do so. Doing that has a number of pretty big implications, though. Implications for schools and teachers, too, not just publisher themselves.
Five reasons why iterative publishing is necessary
1. The agile and lean approaches require it
If publishers are going to do what so many people (including me) say they must do, and become more agile, then a new edition of a course every few years is obviously not going to cut it. And if you’re going to follow the Lean Startup approach, then rapid iteration is at the heart of what you do. You can only ‘fail faster’ if you’re always trying new things. Learn from how people respond to real saleable products and not just from market research based on mere descriptions or mock-ups.
2. Technology and the market are changing fast
Circumstances can force you to update your product sooner than you may have wanted to. For example, if you have an online product built using Flash, you’ll be looking at how to replace it with HTML5, since Flash won’t work on iPads or most other tablets. You wouldn’t have been thinking that three years ago, because the first commercially significant tablet had only recently appeared, and we didn’t know Flash would soon be dead. That’s a big change to have happened in a very short amount of time. This kind of thing can force you to iterate more quickly than you might otherwise have wanted to. If you’re already in the habit of constantly enhancing your products, then dealing with technology ’emergencies’ like this shouldn’t be such a stretch.
3. Everyone else is doing it
Looking around at language teaching start-ups, the speed at which they iterate and their products evolve is almost always faster than that of traditional publishers. The likes of OpenEnglish, EnglishUp, Busuu et al are constantly working on their core product. The idea of an ‘edition’ for these guys wouldn’t make a great deal of sense. Of course, they generally only have one core product, whereas traditional publishers have dozens or hundreds – and this is significant when considering the feasibility of iterative publishing (see below).
4. Digital products are expected to be updated regularly
A printed book suggests permanence and stability. A website or an app does not. A digital product is expected to be tweaked and updated frequently, with a major update every year or two. Don’t let your website or app become a fossil.
5. It reduces risk
A big digital product costs a hell of a lot more to develop and support than a book. Many times more. So, you need validation that you’ve created something that students and teachers actually want to use, and schools want to spend money on. And the earlier you can get that, the better. And even if you’ve got it spot on, things will change over time and you’ll need to respond. If you’re already in the groove of frequently updating and improving, your chances of remaining relevant are that much higher, and the risk of blowing millions on something no-one wants any more are that much lower.
Five reasons why iterative publishing could fail
1. What about stability?
How many teachers or DOSs really want the course they’re using to be changing all the time? Most people want stability. That means an easier life and less time spent preparing lessons. However much publishers are keen on the idea of iterative publishing, and are told they need to do it, we all know that a constantly changing ELT course would probably bomb. Does that mean this can only really work in self-study products? Not necessarily, but it’s certainly tricky, and I don’t think anyone’s really got the answer to this one yet. If you have, let me know.
2. MVP or just half-baked?
The Lean Startup approach says you need to build a minimum viable product (MVP) as early as possible so you can get real feedback on whether you’re doing something that people will actually buy. More on that here. The danger, of course, is that this can be used as an excuse to push something out that’s just not finished. Key feature not ready yet? “Well, we don’t want to miss the launch date, so let’s just go live anyway, and we can release an update a week or so later – most people probably won’t even notice.” Hmm.
3. Once v 1.0 of a product is finished, your team is already moving on to the next project
This is a really big problem for a publisher with a packed publishing plan and wide variety of publications to support. When you have finite resources, the team that’s just finished Course A is immediately required to work on Course B. That’s the way it’s always been. Sometimes the commissioning editor can start work straight away on the next edition, but not the whole team. A big ELT course might need a team of 10-20 staff to get it done. Can that whole team really be tied up indefinitely in the development of a single course? If the aim is iterative publishing, then it has to be, surely?
4. It doesn’t suit an organisation built around strictly separated functional departments
Publishers are divided into specific functional groups, each with responsibility for a different part of the process: editorial, production, manufacturing, marketing, sales, finance etc. Central to this structure is the idea of handing over a product from one function to another at key stages in a project. Editorial and marketing might work together to research and define a product; then editorial develop the content to the point where a final manuscript is ready before handing it over to production who oversee the process of turning it from Word document to nicely designed print-ready PDFs. Each group needs time to do their bit. And they don’t want to have to rewind to a previous stage, since it screws up the schedules. Once a product is in production, you don’t want to be messing with the content too much. And once it’s been printed, you can’t change anything. In the world of print, this all makes some sense. In digital it doesn’t, and yet it’s still how most publishers run their digital projects – because it’s just how they’re used to working. So, to make iterative publishing work, I think the whole organisational structure probably needs to change. That means product-focussed cross-functional teams with in-built flexibility.
5. Confused sales teams
This could go either way for a sales rep. The product you’re trying to explain and demo to people is changing all the time – is that good news because you always have new things to say about it, or a total nightmare as you get caught out by a load of changes you weren’t fully prepared for? In a publishing company, if the sales teams don’t like a publishing proposal, there’s a good chance it won’t get off the ground, since a large part of the business case is built on their sales forecasts.
To me, that second list doesn’t seem as strong or compelling as the first five. I guess that suggests that iterative publishing is a valid aim for any ELT publisher – but one that will require resolving a number of difficult questions. In fact, the key thing will be not to try and develop a definitive approach to this up front and try to implement that in one ‘big bang’ as a new workflow. Best to take a more iterative approach, perhaps.