Digital products are a special kind of product. They are the same as tangible ones in many ways, but differ in one key aspect: they are, by definition, mouldable. Designed to evolve with our behaviours, which is why good software companies always build for the long term. Software should always be prepared for the next pivot — the next big technological, behavioural or market shift. These days, product life cycles are becoming longer and more prosperous. This is perhaps because we understand users and business far more than we used to. But the version we deliver today will not be suitable for next year’s market, because companies aim to move quicker with less steps, and their software must follow suit.
The reason behind this is simple. Software is a tool that helps teams reach a business outcome, and the outcome is a moving target. So when business hires more staff, relocates, changes supplier or even updates its positioning, it’s reacting to those shifting factors and forces. So why is software not being realigned with these updated parameters? Because the misconception is that software, much like a desk or chair, is finished and unchangeable. This limited view of digital products holds companies back from making small but meaningful (and inexpensive) tweaks to existing software in order to meet new challenges, adapt to evolving technology or simply improve on the user experience — productivity is the result of a great experience.
A practical way to avoid digital products from going stale, or design problems going unnoticed is a quarterly software review. Reviewing what the objectives are and gauging the success (speed, efficiency, effectiveness etc.) with which your current software is achieving those objectives. By reviewing these metrics and interviewing your team about their experience, it is possible to assign a score to a product. If quarter after quarter you notice a dip in performance, it’s time to iterate.
When built and documented properly, a software product can be updated to meet your changing external and internal conditions. Start by asking your team what they think of it and what they would improve to make the tool better suited for their current needs.