Imagine this: you desire to be a better writer, so you decide to drink in countless articles and books on the craft of writing and editing well. Months fly by as you research. But…you don’t actually write anything.
This exact situation has happened to me.
I realized, eventually, that if I wanted to improve my writing skills, I would need to, well, write something. I decided to get started, trusting that I would learn as I practiced.
Now, every time I write an article, I evaluate what I create and look for ways to improve for the future. As I repeat this process, I learn more about my writing style. And lo and behold, I’ve become a stronger writer over time.
In the start-up world, my second approach — writing and evaluating my work, again and again — is called iteration.
What Does It Mean To Iterate?
“We need to iterate on this feature.”
As the head of a development agency, I say this often to my clients.
When I use the term “iterate”, what I really mean is this: Our team has only a rough understanding of what a desired feature should look like. So we’re going to build an initial version of that feature, then request feedback from you. Based on what you suggest, we’ll do another round of work and request more feedback. We’ll undergo several cycles of creation and evaluation like this, our goal being the formation of a final, viable feature that works for you.
Iteration is a process that originates in the practice of agile software development. In an agile process, the goal is to begin implementing a feature right away as opposed to spending months analyzing how to implement it. It’s a learn-by-doing approach that rejects overthinking in the early stages of a project. (Kind of like my first approach in improving my writing skills.)
The iterative process isn’t always efficient. That’s because each iteration typically includes something that won’t go into the final product. For example, I once worked for a client who wanted my team to create a custom CRM for their enterprise. Their original idea was to create a mobile app, though they had a very rough understanding of what should be in that app.
Over the course of a year, our team did about 10 iterations. The project evolved from a small app to a fully-featured desktop CRM with an app as a quite limited feature set. In the process, we completely re-designed the app three times, because after each major release we received feedback that required us to make changes. This affected the UX and data flow, along with many other parts of the application.
But being inefficient isn’t bad. The idea behind iteration is to ship fast and get feedback early. To save time and prevent headaches, you need to get as much feedback as quickly as possible because most of the time, your users won’t magically tell you what they want from the get-go. You need to show them an initial feature, then ask if it works for them or not. If not, ask them what needs to be added or changed. Perhaps they’ll share that X is missing and that Y has to be changed to Z. With that feedback, you can now do another iteration — then show them the updated feature again. You’ll do this again…and again. And again.
In my writing practice, it took me some time to realize that reading endlessly about writing was just delaying me. Similarly, it takes start-up founders some time to figure out that spending hours trying to decipher the best set of features or write an all-inclusive, perfect spec isn’t the best approach. Actually doing something is useful — not spending all of your time just crafting a plan.
Iterate With An End Goal In Mind
There’s quite a bit of risk in this iterative approach because you don’t know when you will finish iterating. I once worked on a project where we were iterating and iterating indefinitely — for several years — because the client didn’t have an idea of what he wanted in the end. The project had an almost infinite budget. Requirements and goals kept changing and changing, resulting in most of the team leaving due to exhaustion and burnout.
It’s important to know where you are going with iterating. You need to have boundaries and an understanding of your desired outcome. For example, if it’s a tech product you’re working on, you might be iterating until you achieve a certain metric: for example, your retention rate drops to X or your number of daily average users grows to Y. Understanding when to stop is a crucial skill of any successful founder or product manager.
I think that the key is to move in small steps, with each ‘iteration’ delivering something of value. This way, you can stop the process at any time and still have a viable product. Think of it in terms of building a house. First, you need to lay a foundation that will hold everything else. A foundation isn’t viable because, well, the purpose of a house is to protect you from the outside world, and having just a foundation doesn’t help with that. Having a foundation with walls won’t help you, either. Your viable iteration would be creating the foundation, walls and a roof.
But what if you need to build a house that should span multiple square feet? Or if you need to build not one but a hundred houses? One approach would be to first create foundations for all of the houses, then walls, then roofs. But in this case, the first viable house would be built only at the end of the project. The families moving in to these houses would be waiting for a long time. Instead, you can build one viable and livable house at a time, helping families to move in as soon as possible.
Will this process be efficient? Probably not. But if you have no idea how to build houses, each house you create will be better than the previous one. You will learn faster and you will deliver value much faster — the families will move in one after another.
The same thing happens during the product development process. Each product is different from the other. If developers were just using the exact same blueprints in each of their software products, there would be no problem with estimating, managing and delivering projects. Instead, we deal with a high level of uncertainty. Thus, we need to iterate.
Originally posted on Medium
