I have been through the "Fish vs Shark" dilemma a number of times before. It was like:
The team has a product/tool/service/system called "Fish". Fish works, but has shown a lot of signs of aging. And the team/company/business/people have almost outgrown the Fish. So the team started to build the Shark.
Building Shark and helping users to migrate to Shark takes time, and takes resources from that team who owns Fish and Shark.
The team now struggles: Fish is getting worse, and the users are increasingly unhappy with Fish. Plus, knowing Shark is coming, themselves and the users are more hesitant to invest in Fish. That only makes things deteriorate even faster in Fish. Meanwhile, Shark isn't there yet.
The dilemma is: how much time should the team spend on Fish? Double down on Shark? It's risky. If Shark delays for some reason (including those out of the team’s control), they are dead in the water: Fish is so broken, while Shark isn't there yet.
Should the team carve out some time to keep Fish floating? In both Chinese and English there is the phrase “a bird in the hand is worth two in the bush”. That will keep business going and buy some time for Shark, but that will probably delay Shark.
That’s really a hard decision to make. We surely can look at the data: How close is Shark? How much effort does it take to keep Fish float?
But how "floating" is enough "floating"? How long can users bear with "just floating"? How much confidence you have to get Shark ready on time? At the end of the day, it might still rely on some judgement and gut-feeling.
Comments on “Fish and Shark”