While on the other hand, a product is something that is offered to the client to solve a problem. A product has a life cycle of multiple stages. First, the product is designed, then it goes to the developing stage, and finally launched and managed in the market. A product is something that lives forever. It should progress and develop over time according to the needs of the clients.
Several businesses often find it difficult to introduce product thinking in teams. Developers working on software believe that they are only on a temporary project- when it gets delivered, they can move on to other projects. The software is hardly ever treated as a ‘product’, that needs to live in the production stage much after the project is completed. We see that this might be harmful to businesses in many ways:
It is often seen that the project approach of any software supports big bang releases. A huge amount of work is piled up and released close to the project end date.
This hardly allows any alterations or improvements because the software has barely been tested by the end users before the budget goes overboard or the team gets scattered.
We rather follow an approach called developing an MVP (Minimum viable product). In this approach, even a little addition in the software is delivered to the real users. It helps us to gain valuable feedback so that we can create the best possible software which ultimately leads to future investment.
On the other hand, the investment plan for projects is slightly different. The projects have a huge initial budget, but it gradually starts running dry right after the first release.
Making the software team measure success in terms of “on budget, on time” delivery reduces the focus on commercial goals, like how the product will be useful to the end users.
Many teams become more focused on delivering the fixed set of features on the fixed deadline. They often do not care about how the features will benefit the end users.
Success is often seen in software when the teams keep in mind the commercial goals of the product launch.
Product owners and product managers have quite different roles. However, product managers quite often play as a substitute for the PO during project engagements.
Encourage the people in the business to take the responsibility of the product and lead its direction for the overall success of the product.
We generally see that the teams which are responsible for setting the ownership and leading the direction of a product in the long run focus on building something that is maintainable and easier to run.
When a project team decides to develop a software, they do not involve the operations team in ceasing the development. The project team just orders the operations team about what is to be executed. This approach creates organizational silos and a lack of responsibility.
Online technologies move at a frightening rate, and sometimes it becomes difficult for businesses who operate online to keep up with the latest trends or technologies. Because of this, the shelf life of a software may become less and might need constant upgrades to keep up in the market. Many people are under the impression that when a software is built, it is perennial and can run without any further investment.
But a software is highly dependent on third-party libraries, which might require regular updating. It is dependent on third party services whose interfaces can regularly change and it might probably increase the size of the dataset it manages.
Factors like these, affect how a software runs and behaves. It needs continued investment. Software rot poses a challenge to many software products.
Many times, we see that the customers are tied up in the endless cycle of re-platforming of the software. As soon as a software is released, another software is created to replace it with the latest technology.
It is possible to improve a software platform continuously by using appropriate software architectures. We always replace small parts of the software as they start to rot, instead of throwing everything away and starting from page one.
At TheWorkshore we don’t believe in spending huge amounts of money every year for a big project. Instead, we always motivate our developers to look at the bigger picture and maintain an ongoing budget and upgrade the software as a continued effort.
This point of view also works when delivering new products in the market. At TheWorkshore, we don’t believe in developing strategies that need a big team to develop a product and later is narrowed down to a smaller maintenance team. Strategies like these often result in poor investment without benefitting the end users. Rather we have developed a system which starts with a smaller team upfront and expands into a larger maintenance crew. This approach has a lot of room for feedback from the end users which can be acted upon.