Twitter’s blue checkmark drama is something that anyone in the tech world is likely aware of. With the new acquisition of Twitter but Elon Musk, and his unorthodox approach to running this company’s first couple of stints, one of the critical main changes is introducing this $8 “paid subscription model”.
The focus of this analysis is not going to be Twitter, nor Elon Musk or his approach to this, but we will only focus on what we can learn about this launch so that when you launch your next new feature, it can help you reflect.
Good: The agile incremental release of a new feature, fast as everyone had their eyes on it
This is an approach that everyone in the tech world recommends. If you want to introduce a new feature, execute an MVP of it, and push it out to production.
This puts a specific deadline, a sprint goal that is agreed upon by all the stakeholders, that can be reached and it is tangible.
Bad: Rollout was global
Especially when it comes to adding new features to your core offering, make sure that when you roll out something new, you do it in batches, or to a select few users. This concept is called feature toggle and you can read more about it in this Wikipedia article but in layman’s terms, these are the core approaches:
- Randomly rolling out to x% of users
- Using specific users
- users who have already opted-in
- users that fit a specific group (more than x followers, more than x years, active to what active means for your business)
Good: Thinking about monetizing diversification
As Twitter is an advertising-based business, introducing a secondary means of monetizing is always a great idea. This enables secondary revenue streams, while at the same time providing a bit of value to the end users (aka your product).
Portfolio diversification is a risk management technique old as the world itself.
Bad: Making major organizational changes in the process
Change is hard, and pushing an organization forward while making major changes in the process (e.g. cutting 50% of the workforce) introduces a lot of risks.
These risks can be managed, by keeping other stable building blocks. While organizational changes are inevitable, them being a restructuring, new management, or even a new product release, they can introduce a series of unknown and unplanned risks.
One of the key elements to consider is to engage yourself in risk analysis, and if you do not have time for it, maybe just simple pros and cons of all your decisions, just so you are aware, of the potential repercussions.
i.e. if you fire half of your dev team, and there is a backlog of prioritized bugs, engaging the rest of the team on new feature development, means that these already prioritized bugs will not get done, so consider pushing the new feature development
Good: rolling back when something goes wrong
Rolling back in this industry is like the definition of “a wasted time” or what lean six sigma notes as “waste” – but when something goes wrong, then it is a great time to roll back to the last stable version that you had.
i.e. before you release something new, make sure that whatever is on production is stable, but your own definition of stable.
