One of the biggest drawbacks in a large organization is the increased network of communication that eventually slows down its operational and execution capabilities. Inversely, a startup’s greatest advantage is its friction-less environment and getting things done attitude.
The biggest challenge of a large and growing organization is to accept a small inevitable slow-down and strive to adopt methods to bring its speed as close to a startup’s speed as possible.
The slow-down mainly concerns the development process, not daily routines. The term development can refer to a new feature, an initiative, a sales or a marketing campaign, a process inspection, pretty much everything that enhances the organization’s product or operations.
A start-up that wants to build feature X has only a few things to consider, almost all of them related to the feature at hand. An established organization, on the other hand, needs to consider all sorts of things: how to market it, will it have any performance / legal / PR / repercussions, how to make sure that all teams are aware of new functionality, and so on and so forth.
There is also a common misconception that heavily researched projects are well designed and easier to execute. Even if that held true there is a problem on the receiving end: the user.
For as long as the project is being researched, debated, and internally communicated, the user still uses an inferior product. Ask anyone: would you like a car 10% better than the one you are driving today or wait for a 50% better car in 5 years? The answer would most definitely be the 10% increase today. Sure, some car manufacturer is working on a flying prototype that runs on solar power with an AI autopilot that will go into production in 10 years, but that doesn’t help me today. If you want to take the above example to the extremes, think of not having a car at all.
Now switch to any product or service. If a user doesn’t have useful feature A at all, she won’t mind having 30% of it tomorrow than 100% of it in 3 months. Instead of going from 0% to 100% in three months, you can go in steps of 33% each month.
The counter-argument here is that small changes usually take longer because of all the operations that have to be executed more than once. This subject is heavily debated, but for the sake of the argument let’s consider that there is a 10% slow down indeed and three months will get us to 90% instead of 100%. This progress is portrayed in the following drawing masterpiece:
It is evident that the total surface of the area where progressive release cycles are better is much bigger than the surface area where complete release cycles are better even when taking into account that progressive is a bit slower to get to 100%.
Consider an example from an eCommerce platform: we’ve identified that category X is outdated and we need to update its filters, or add more pictures and videos. If we bundle all those changes in a huge block that will require 20 days of work, the users will see an inferior category for those 20 days. In a worst-case scenario, a category that needs only minimal changes will be de-prioritized until it justifies a complete cycle. Until then, users will see an inferior category, getting worse by the day, until the grand revamp.
Meet Kaizen
Any successful product can be greatly improved with small incremental changes that eventually have an important impact. Even a 1% increase in an important KPI is of great value for the business but most importantly for tthe consumer.
Kaizen is the concept of applying continuous small improvements in all aspects of a business with the aim of achieving gradual but noticeable performance enhancements.
We are particularly interested in one variant of Kaizen, Point Kaizen:
It is one of the most commonly implemented types of kaizen. It happens very quickly and usually without much planning. As soon as something is found broken or incorrect, quick and immediate measures are taken to correct the issues.
These measures are generally small, isolated, and easy to implement, however, they can have a huge impact.
In some cases, it is also possible that the positive effects of point kaizen in one area can reduce or eliminate the benefits of point kaizen in some other area. An example of point kaizen could be a shop inspection by a supervisor and he finds broken materials or other small issues, and then asks the owner of the shop to perform quick kaizen to rectify those issues.
The first step to embrace Kaizen is to embrace methods to continuously monitor your product even when we are not actively monitoring it:
- If you are lucky enough to be able to use your product as a user (e.g. an eCommerce site) you’ll certainly identify various problems. If it is a small one and within your area of influence, fix it as soon as possible. If not within your influence or seems like requiring a lot of effort report it.
- When testing the product for anything make sure to look around as a user, not an employee or a manager. Fix small problems right on the spot, don’t wait for them to be prioritized.
- Make sure to spend a small amount of time every now and then to inspect the platform as the user. For every action that you make ask yourself the question: would I do that if I didn’t have all the internal knowledge that I have? Strive to make even the smallest improvement.
- When researching a project with your team lean towards a design with small intermediate deliverables than a huge one after some time.
One positive aspect of Kaizen that we have not discussed is team spirit. Small incremental changes that have a visible impact will remove the frustration of missed deadlines and provide all the necessary dopamine kicks.
Finally, small changes allow us to validate our assumptions, gather feedback, and steer accordingly if required.
George Hadjigeorgiou 