Ever wrote a piece of text with blood, sweat and tears? Trying to make it perfect before you sent it to the editors or for peer review? Only to find that no matter how great you thought your article was, people always come up with something to improve on your piece, sometimes with corrections that touch the core of your story? A very painful moment, which makes it hard for any normal human being to remain open to feedback and learning.
By the time you have rewritten your piece, gone through the review cycles and are ready for publication, the subject you wrote about has already expired. Too bad, you were too late to get the views and the discussion you were hoping for.
Software developers have experienced this for decades. So many software projects, even when they are relatively succesful, are delivered too late for the features to be what the user wants in this moment in time. In the current speed of change, everything has to be deployed yesterday in order to be up-to-date with current needs.
In this article I propose to use the principles of agile software development and apply them to content creation. My goal is to encourage you to see your content as something that is valuable to others in many stages of the process, and not just when it is “done”. And that the collaborative process is valuable in itself, maybe even more valuable than the end result.
Introducing: The Minimal Viable Publication
When applying an agile mindset, life is all about knowing that you will be wrong at some point, and it is best to know where that is as soon as possible, before you have put a lot of time, money and energy in the wrong path. This is true for software development, but also holds for a lot of other fields, such as authoring. Therefore we will introduce the notion of an MVP: a Minimal Viable Publication.
What is an MVP?
In software development, MVP stands for Minimal Viable Product and is the name for the first version of a product that has value and could be deployed to users. On the basis of the user feedback, developers iterate on the first version, which will improve the aspects the users value most. And in the meantime, it has brought value before being perfect or complete.
In authoring the MVP stands for ‘Minimal Viable Publication’. This MVP is the version that contains all necessary information to be potentially valuable to collaborators and/or readers and can therefore trigger feedback.
How does agile authoring work?
Set a goal
When you start writing, you start with determining the goal of your publication. If you have not set a goal, the purpose of your piece is unclear, and the feedback will not help you to determine whether your goal was reached.
Make an outline
Make a first version really fast, that outlines your ideas. Your MVP should potentially reach the goal that you are aiming for with your content. Just like in software development, your MVP must be a slice of your eventual product. So your whole story must be done, but at this stage, only in a minimal form. In order to create the MVP you have to stay true to the principle of ‘maximizing the work not done’. At the intersection of maximizing the work not done and potentially reaching your goal is where your MVP lies. Do the work that is necessary to make your piece valuable, but do not fall into the trap of wanting to make it perfect.
Publish
Once this is done: PUBLISH. Fail early in order to succeed sooner. Show your content either to your collaborators, peers, or the world. Make sure you get the feedback you need. Ask people very specific questions about whether it is reaching the goal you have in mind.
Get feedback
With this MVP you can test a number of things: this can be to see whether the topic is of any interest to anyone, to see whether your content is indeed answering to the goal you are trying to achieve and/or there is viable information from your collaborators or users that can improve your content. When you are working collaboratively with other authors and/or editors, the MVP can be even just an outline of what you are trying to convey.
Make sure your readers, whether they are collaborators, peers or reviewers can give their feedback in a shared tool, preferably with excellent version control and always in the cloud. If you can get a conversation between your readers going, you know you’re onto something good!
Iterate
And then, it’s only just begun. Publication is not the end, it is the beginning. Don’t ever stop iterating on the basis of the feedback, even when your content was published years ago. Isn’t that the fun thing of online content! Building on the previous version of your content with new ideas, while still maintaining the same goal, will keep your content up to date without having to write new content all the time.
What are the advantages?
More structured writing and less writer’s blocks.
Often, in trying to achieve a ‘ready for the world’ publication, people tend to spend a lot of time on phrasing and rephrasing what they would like to say. Especially for the MVP, but possibly for all versions of your publication, having a good story is more effective than creating a perfect text.
If you follow the steps above, you will reach a complete story sooner, and the structure of your piece will not be cluttered with digressions. The feedback that you will get will help you through the next stage.
Faster publishing — less risk, more value.
If it so happens that your content is not interesting, useless or plain faulty this is painful. But it is better to know before you spent a lot of hours (not) working on it.
Always a publishable version, so you can make the deadline at any time.
Although you probably would rather spend much more time on your piece, there will always be that time where you can do no more because life happens. In this way of working there will always be a complete good enough version, instead of a version that is perfect, but only half-done.
Early feedback from collaborators/reviewers. A broader perspective and an open mind.
If you only receive feedback on your final piece it is almost impossible to stay open-minded and to find the energy to redo your piece. When you know there is still lots of room for improvement, your collaborators will show you where to work on first on the basis of your MVP.
And if you think that you will be able to do this by yourself, think again. Information is too abundant to see and know everything. The crowd is always right, and always smarter than you. Yes, also than you.
Sounds easy? Here’s reality.
Although this may sound almost too easy, it is not. Knowing when to publish is a learning process on its own, and you can only learn by publishing too early. If you feel comfortable about your publication, you have published it too late.
While writing this piece, I tried to follow my own rules, again. Here is what happened to me this time.
- I made the outline
- I sent to a friend
- I got his feedback
- I started elaborating on one of the bullets in the outline
- I continued to elaborate on this one bullet
- I stopped working on it
What I had done is that I had transformed my piece from a far from perfect, but ‘done’ version to a half-done, unpublishable version. And got lost in the process of perfectioning.
Three months later, I mentioned my article to someone and sent it over. His feedback got me back on track and then, when I got stuck again, I figured I’d just publish. And got, again, valuable feedback which led to this current article.
I am at the fourth iteration now, adding this personal piece, which is quite challenging and which I am again afraid to publish, but as you can see, I have.
It tells me that showing your process is so scary, but also so much fun. I hope it inspires you to show your process and smile at it.
Most important to realize
The key to agile publishing is that it is not the end result that counts. It is the process of collaboration that will determine the value of your work. After all, writing something perfect that nobody reads is less valuable than writing something effective that people are involved in and can be inspired by.
Credits
This article was previously published on Medium and has evolved to its current form because of the valuable input and feedback of Isaac, Jeroen, Wouter, Leon, Jeremy and Boris. Thank you very much!
Practice what you preach
Was this article in this form useful to you? Do you have any questions? What else would you like to know? How can I improve the usability of this article? Your feedback is invaluable. Please share it on LinkedIn or through the Medium platform.