{"id":1000,"date":"2018-06-26T09:59:00","date_gmt":"2018-06-26T09:59:00","guid":{"rendered":"https:\/\/f1studioz.com\/blog\/?p=1000"},"modified":"2026-03-03T10:52:18","modified_gmt":"2026-03-03T10:52:18","slug":"how-to-revamp-an-enterprise-product-p1","status":"publish","type":"post","link":"https:\/\/f1studioz.com\/blog\/how-to-revamp-an-enterprise-product-p1\/","title":{"rendered":"How to revamp an Enterprise product? P1"},"content":{"rendered":"\n

Working with enterprise UX has it\u2019s own challenges which are simply not easy!<\/p>\n\n\n\n

Enterprise products are huge and often the product owner is much younger than the product itself. In essence, the product has a past history which may or may not be fully known by any of the product team members. There could be parts of the product which dates back to the product\u2019s inception and may not be relevant anymore. Shaking up this archaic beast is no easy task.<\/p>\n\n\n\n

Imagine the product to be like a ship which is carrying the passengers and cargo and has limited resources (food, battery etc). And the UX revamp to be like fixing the ship. The captain of the ship (the product owner) is having the responsibility for the safety of the ship and passengers.<\/p>\n\n\n\n

Broadly there can be two ways to revamp an enterprise product:<\/p>\n\n\n\n

  1. Ship of Theseus \u2014 Doing repairs with passengers on the ship<\/li>
  2. Build a new ship \u2014 Parking the passengers to a mid sea island<\/li><\/ol>\n\n\n\n

    Ship of Theseus<\/strong><\/p>\n\n\n\n

    The ship of Theseus method refers to continuing with the product\u2019s day to day life yet selectively identifying modules of the product which can undergo UX revamp. And ensuring the entire product is revamped module by module. This is analogous to the famous Ship of Theseus paradox where the ship is being replaced part by part as they get older but never the ship remains the same effectively keeping the identity of the ship same forever.<\/p>\n\n\n\n

    Advantages<\/em><\/p>\n\n\n\n

    1. The risk of business dis-continuity is avoided<\/li>
    2. The management can see some quick results and doesn\u2019t have to wait<\/li><\/ol>\n\n\n\n

      Disadvantages<\/em><\/p>\n\n\n\n

      1. The product\u2019s identity cannot change as this method has to respect the legacy of the product (some great and some bad) and hence the revamped product is at the risk be being irrelevant to the new market even after revamp<\/li><\/ol>\n\n\n\n

        Build a new ship<\/strong><\/p>\n\n\n\n

        This method refers to starting to build the a new product fresh and once completed slowly retiring the old product back to it\u2019s elements. However, a lot of old product\u2019s wisdom taken into account during the inception of the new product.<\/p>\n\n\n\n

        Advantages<\/em><\/p>\n\n\n\n

        1. The product has now every possibility of retaining it\u2019s great legacy (shedding the bad ones) and yet rediscover itself with a new identity.<\/li><\/ol>\n\n\n\n

          Disadvantages<\/em><\/p>\n\n\n\n

          1. The risk of business discontinuity looms over the management until they start seeing some screen or interaction sweeps them off the feet (which unfortunately takes time). The management\u2019s anxiety can sometimes lead to breakdown of the project.<\/li><\/ol>\n\n\n\n

            As you can see there are pro-and-cons in both the methods both of them could meet a terrible fate if the management do not understand the difference between the two methods.<\/p>\n\n\n\n

            In my next blog post I will elaborate how to get the best of both the worlds mentioned above!<\/p>\n