I once read software products should always be in beta version, and there is no such a thing as a final release. Although it can sound harsh, the more I think about this the more it makes sense.
Beta version in the sense that it is never finished and not regarding having something incomplete.
As I normally try to do with my articles I won't focus on the technology side of things.
If I were to summarise this topic in a few words, I will define it as the importance of iterations. Considering an iteration as a timebox in which the development of something new takes place.
I have recently come across this topic again because I have started to experience procrastination while working with devs that I mentor and of course some of my side projects that are slowly getting bigger. Action wherein most of the cases happen due to a mix of lack of planning, confusing prioritization, and very ambitious projects.
So let's try to find out why having iterations can help us fight that problem.
Although having an ambitious mindset is important to develop great products, sometimes they can bring on frustration to the table due to having unreachable goals.
Beta Version
What I want to emphasize with the phrase "always beta version" is the feeling of improvement and the fact that it is ok not to cover everything on an initial release of any piece of software.
But Wait! there is an important disclaimer that I would like to make, I am not saying that versioning isn't important, or that Milestones and Changelogs have to be removed from existence. It is just a catchy phrase to show that it's hard to get to a final version because there are always things to improve, fix or add.
Looking at iterations from another angle, we shouldn't see them as a way to "feed the lions". In some places that I have worked, I remember us sharing and doing demos or deliveries just to have proof that we have done something, while the main objective should have been to get feedback.
If we take a step back into the ideation and development of a new idea we can notice that most of the product companies usually start with something simple, to gather some meaningful information, feedback, do some user research about the impact of the new features, and finally move forward with new iterations.
It might sound trivial, but it is important to keep our minds fresh with this pattern. Linked to the continuous delivery approach from an engineering point of view.
So basically, think smaller to accomplish big things.
In terms of methodologies, it helps to move away from the good old waterfall way of working, where long terms plans and preparations were making things harder to develop and difficult to react to last-minute changes.
By installing this thinking we can motivate the ambition to make a product to get better, and not the sense of relaxation that we reached the end line at the moment we do a big release.
The feeling of progress after every iteration will be the fuel to continue growing what we are building. And that goes hand in hand with Agile Methodologies, which will let you learn and adapt way faster to newer changes.
Another good side effect of having this is the limitation of the scope because it prevents us (developers/engineers) from over-complicating things. Which is something that happens when the limits are broad and the cases that we have to cover are not clear, thus reducing the boundaries makes the capturing of all the requirements a lot easier.
Normalize failures
Happy paths are not always with us. There are times where plans don't evolve as we imagine, and the objective and problem we were trying to achieve are not accomplished.
But instead of seeing this as a total failure or waste of time, we should take it as a lesson learned. And just because we are using iterations, we are going to be able to detect this at an early stage.
To make this idea a bit more clear let me share a nice story that really reflects this benefit.
There was a time when Twitter decided to develop something new to "encourage more people to join the conversation" (from their own words) and to make the onboarding of new users smoother.
If you are a Twitter user you have probably noticed this feature was mainly used to promote tweets from the same user to amplify their audience and wasn't encouraging people to get into a conversation, and neither was attracting new users.
Assumptions aside, the story continues, and they have collected data about how this feature was used and discovered that their main hypothesis about people joining conversations was not resulting as they thought.
A few days ago they have published a tweet saying they are going to remove the feature from Twitter.
we're removing Fleets on August 3, working on some new stuff
we're sorry or you're welcome
— Twitter (@Twitter) July 14, 2021
If you are curious about the reasons, find more info in this blog post.
There are two takeaways from this story that I like.
The first one is, that it is ok to make mistakes, there will be times were your expectations and assumptions are not met, and the possibility of doing experimentation of new feature with small iterations will make it easier to not invest much time/effort in something that can be possibly deprecated.
And the second point is the importance of defining a good metric. Before introducing something new to your software define the best way to measure success or failure. Decision-making based on real data is really valuable and removes the need of having to make subjective assumptions about where to put the focus and the priority.
Metrics are important during the development process and something that we tend to forget or ignore. This subject really deserves a full article, but if you would like to dive deeper on this topic I recommend this article, pay close attention to what a north star metric is.
Perfection is out of the table
Ain't no perfect product!
Remove the feeling of perfection, you can constantly improve things. Don't hold your back trying to create something perfect that will cover every particular scenario that you can think of.
Without even knowing your audience this mission is out of your league.
Analyze the competition and see in which area your product is different from the rest, what feature you have to offer that makes it unique. And use the power of iterations to continue growing that way, always looking back and reflecting on what is your main goal.
If you are building your own portfolio, make your story the unique feature.
Especially if you are working on a personal project, don't let the sense of perfection hold your back, define an MVP of your product, collect feedback and keep iterating, I promise this will encourage you to make it better every day.
Having a list of atomic and tangible items, sorted by priority will help to define your road. As I have mentioned before metrics play an important role here. And don't forget that during the prioritization game, leaving things aside will be part of the process.
Before closing the article let's remember what we all probably know, extremes are bad! So, although we have checked the benefits of having small iterations, don't go to the opposite end and deliver unpolished features.
To sum up, I hope I can open your mind about why other topics are important to be aware of when developing apart from the coding. As a frontend developer (and wanna-be Product Manager) I started to look into these matters more often, and I must say they are truly making my coding skills and work more impactful than before.
Top comments (0)