Lean ELT Publishing (or, How to publish an ELT course in three months, Part 2)

In the first post in this series, Nick set out a challenge to see if – and how – it might be possible to radically speed up the process of ELT course creation. The simple fact is that established ELT content providers don’t have much of a choice – radical change is needed because the EdTech startups are coming and they’re going to eat the publishers’ lunch – unless they can learn to operate more like those startups, while making the most of the advantages they still have: better market knowledge, more resources and far superior content development expertise.

So, with that in mind, let’s take things a step further than agile project management, and look at the closely related phenomenon of the Lean Startup, as popularised by Eric Ries, and now wildly popular among Silicon Valley startups. Lean startup is about more than how best to execute a project – it’s about how to use the agile approach to build a sustainable business in an environment full of unknowns. Which seems a good description of the challenge facing anyone publishing materials for English language learners at the moment.

The Lean Startup movement

Photo by http://www.flickr.com/photos/betsyweber/

The claim of the learn startup movement is that product development cycles can be made quicker and more effective by a process of hypothesis-driven experimentation and iterative products releases, with constant customer feedback. Once these customers have shown willing and actually paid money for the early versions of your product, you can consider your hypothesis validated and then confidently invest heavily in scaling up and taking your product to a much larger audience. This is in contrast to the usual approach of carrying out market research which essentially asks people what they want (through surveys, focus groups etc), and then investing a lot of time and money in developing a product to deliver exactly that. And then, only once you’ve delivered it, do you find out if customers really want what they said they wanted.

The key thing here – and I think the crux of the whole lean startup approach – is that you can never really know whether people want your product until you put something in front of them and ask them to actually hand over money for it. And lean startup tells you to get a real saleable product in front of your customers as early and as frequently as possible – and not to invest heavily until you know it’s what they really want. It’s about minimising risk and avoiding wasted effort – something that ought to speed things up a lot. And it’s not just for startup companies – it’s really an approach for developing products in any situation of uncertainty or change in the market. For example, an ELT publishing market that’s in the process of being disrupted by the rush to digital.

Build -> Test -> Iterate

Photo from http://www.flickr.com/photos/qilin/
Photo from http://www.flickr.com/photos/qilin/

This is the heart of the lean approach. Build a product very quickly. Test it with real customers. Adjust according to what works and what doesn’t. Repeat until you’ve got something you know works. Then throw the kitchen sink at beefing up the product and marketing the hell out of it. This in stark contrast to the more usual method: Research -> Build -> Promote.

This is actually quite challenging if you have a strong product vision or piece of content or technology that forms the core of your business. Ries is quoted as saying that startup failures he experienced in his early career were caused by “working forward from the technology instead of working backward from the business results you’re trying to achieve.”

In ELT publishing, market research is a big deal. But the vast majority of it is done before the product development starts in earnest. Customer surveys. Focus groups. Class observations. Reviews. Piloting. But testing of a real product which then immediately leads to development of the next version? Building a product based on nothing more than a hypothesis? Not so much.

If you manage to use an agile approach, you should be able to develop your product in stages, with each sprint more effective than the last, as a result of user feedback. In lean startup, it could be the whole product proposition and business model that you’re testing and then improving at each iteration.

Minimum Viable Product

Minimum Viable Product, or MVP. This is one of the pieces of lean startup terminology/jargon that’s really taken off in the last year or so – and it’s one that’s often misunderstood. According to Ries, an MVP is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” An MVP is not supposed to be a real, polished product. It’s the minimum required in order for you to learn whether your product idea is on the right track. That could be as minimal as a fake website which tracks how many people click the “Buy” button for a product that doesn’t even properly exist yet. But it has to be something that demands a commitment to pay money. No mockups or prototypes.

It’s not simply a case of putting out a full product in the normal way, and then calling the first released version an MVP on the basis that it’s still missing a few features and you hope to improve it at a later stage once you’ve got some customer feedback. Those later improvements often never happen because everyone’s moved on to the next project.

There definitely a tendency for MVP to be used to refer to something way too polished and expensively developed to be worthy of the name. If it’s taken a significant amount of resource to develop, it’s not an MVP. Even more importantly, if the reputation of anyone within the business could be negatively affected by its failure, it’s not an MVP. An MVP is almost supposed to fail – otherwise, what can you learn from it?

Continuous deployment

In publishing, it’s common to put out a new version (or ‘edition’, as we quaintly call it) of a print product every few years. For digital, it may be every year. Or even every few months for the bold. Lean startup would suggest that for online products, it should be every time any change is made. In some cases, that could be 50 times a day. That’s what Google do. Let’s go over that again… in the publishing industry, it’s considered acceptable to update your product every few years. In startup land, it’s considered normal and good practice to do so every half hour. Didn’t Darwin say something about the most adaptable being the ones best equipped to survice?

A/B Testing

This is becoming absolutely standard practice in software development and on the web in general. Release a new version of your product, but only make it available to half of your users. Then track whether the people getting the new version use the product more, spend more money (or whatever it is you want to see improve). If that shows that the new version performs better, put it live for everyone. And then keep doing the same thing again and again. Google have a tool to make this straightforward to do. This is all consistent with the approach that you should base your decisions on the evidence of actual customer behaviour. Never trust what people say; only what they do.

If you’re not doing this (and I’m not!), you’re missing a trick. Your competitors in Silicon Valley do it as a matter of course.

The pivot

Photo credit: marfis75 / Foter / CC BY-SA
Photo credit: marfis75 / Foter / CC BY-SA

What if you do all of the above, and it doesn’t work? Well, the pivot is a just a less negative-sounding way of saying “My hypothesis turned out to be wrong, and this clearly isn’t going to work, so let’s try a different hypothesis and see if that works”. I’m not sure how different this really is from giving up and starting again with something new, but there you go. The important thing is to do it before you’ve spent years and millions of pounds on developing and marketing something so big you can’t afford failure. You need to have the energy and resources left to have a go at something different.

Lean publishing

download (2)How can we apply lean startup principles in publishing? Well, there is actually a thing called Lean Publishing already. You can read its manifesto here. The basic definition is that you publish books that are still in progress. The premise is that the book business is like the startup business in many ways: both require funding (from a publisher or a venture capitalist), both are high risk and the majority of projects fail. But the small number of hits makes the whole thing profitable. One of the key tenets of lean publishing is to get out of ‘stealth mode’ as early as possible. Stealth mode could mean a startup working away secretly on an amazing product and raising VC cash before the ‘big reveal’ of the product launch. Or it could mean an author sitting in a garret honing the masterpiece. Peter Armstrong (the co-founder of Leanpub) is coming at this very much from a fiction publishing point of view. Could we say that ELT publishing actually has (or should have) some of the characteristics of both fiction publishing and business startups?

Lean ELT publishing

Publishing work in progress would be a pretty radical thing for an ELT publisher to do. As would removing ‘stealth mode’ and the concept of the big product launch. If you’re a teacher, would you be happy to use a work in progress course with your students? In what ways would it have to be better than the carefully honed courses you’re used to using in order for it to be worth living with the rough edges and incompleteness? How on earth could you run a school when the materials are constantly shifting?

Nick’s post on Agile set out a method for publishing which is basically the same as the lean startup approach I’ve described. And the conclusion seemed to be that it ought to be possible – although extremely challenging – to adopt this way of working in the creation of digital ELT courses; but that for print it would be hard to imagine how it would work. Obviously, that’s a debate that will continue to run – because there’s no clear cut answer.

One of the big problems seems to be the fact that it feels like you might be using your customers as beta testers. And I’m not sure I’d necessarily be up for doing that on a regular basis if I was running a chain of language schools or a university language centre. It just sounds too disruptive. But here’s the real difference between just applying agile, as Nick described, and going for lean startup. In lean startup, you wouldn’t be using your customers as beta testers, because there’s not really any such thing a beta. You’re not putting out prototypes or samples in order to get the feedback needed to guide your next iteration – you’re putting out your actual product (even if it’s in MVP form) and, if possible, charging money for it so you can find out if people will buy it. As opposed to standard market research, where you’re finding out if people will say they’ll buy it. It still might only be the first unit of a course, and only made available to a handful of schools – but it’s pitched to them as an actual product, and not as a sample or prototype for review.

Could the lean startup approach put into effect using agile project management deliver a really good ELT course in a massively compressed timeframe? I believe the answer is yes, but not in any organisation that’s structured around functional departments (Editorial, Production, Technology etc), with a requirement to prove there will be large revenues before a project is given the green light for investment. Or in a situation where most of the work is outsourced around the world, with just a core of project managers in-house. Or where team members are spread across a number of different projects, so they can’t really get into the guts of the main project. Or where, as soon as the first iteration of a product is done, they’re needed on a different project.

I don’t think we’ve found the answer to our “Course in 3 months” challenge yet. But I think lean startup and agile are part of the answer. Some of the comments on Nick’s post showed that people are finding ways to make agile work in ELT content development. Let’s keep exploring the theme and see if we can start to chip away at some of the hardest challenges in making it work on a bigger scale.

Photo: http://www.flickr.com/photos/betsyweber/

10 thoughts on “Lean ELT Publishing (or, How to publish an ELT course in three months, Part 2)”

  1. Lots of interesting ideas here. What strikes me is why do we have to start off at the level of the ‘course’? We hear so much nowadays about teachers rejecting coursebooks and taking (and adapting) materials from different sources to suit their own students/teaching – why not start with smaller-scale resources (lessons, modules, etc.) and market them to exactly those more flexible and generally, more-experienced teachers first? Then you adapt and improve based on feedback. You expand your resource (based on a structure or syllabus rather than just as ad hoc ‘resource bank’) and eventually, you find yourself with a whole course – tried and tested – that you can market to a wider group of teachers/schools who like to have a complete course.

    As an ELT writer who’s just been completely wiped out by the ridiculous slog of trying to get a coursebook out within stupidly tight deadlines, I’d be more than happy to work on that kind of basis. Ongoing work, proper feedback from teachers, time to develop ideas … what’s not to like?

    • Hi Julie – that’s a very interesting thought you’ve raised – if agile and lean startup are very tricky to apply to the development of a full-blown course, why not change the terms of reference and not think in terms of coursebooks in the first place? But if you happen to develop one over time, then so be it. The majority of teachers do want coursebooks, of course – but why not start by serving those who would welcome the kind of materials that lean startup would be best able to create and then broaden things out from there…

  2. Great article Laurie. I think that structure and how teams are organised is a key point that you have hit on. Organising teams around a product life-cycle model, as you have outlined, is very effective – easy for a start-up to do and not at all easy for larger companies. Also, in order to be scalable for a large publishing business – focus is absolutely key. This way of working will become more and more important, as change is so rapid research has become less reliable and it is easy to make (expensive) wrong assumptions about a product. Being lean requires a solid understanding of the problem trying to be solved, and arriving at the solution with those that the solution is for. Having seen this work effectively before I know how rewarding that can be.

    • Cheers Ben. I think the question this raises is whether lean or agile publishing is remotely possible without restructuring the entire publishing organisation around lean startup principles. If organising teams around projects rather than functional divisions is hard for a larger company, why is that, and what would it take to make it happen?

  3. Interesting article. Some aspects remind me of what we are doing ourselves. We started producing a course for young learners about three months ago and the pilot schools will start using the course in August. Not everything will be ready, but by the time we go for offset printing early next year, it should complete. We certainly won’t have the course completed in three months, but within 12 months we will have 15 student and corresponding teacher books finished. This also includes an online area.

    The close cooperation mentioned in the article is very familiar. We don’t have the daily meetings, rather, we just walk over to someone’s desk when we have something to discuss.

    Feedback from our customers (state schools) is essential and takes place regularly. We really try to have a personal relationship with them and this seems to pay off.


Leave a comment