Problem- vs Solution-oriented Software Design in 3 minutes


Every single SKU calls for mundane daily decisions, such as moving in more stock or changing the underlying price tag. Naturally, sticking to a fully manual process for those decisions is labor intensive and companies have been adopting varied software-based automation solutions. However, most software vendors, and most in-house initiatives as well, remain stuck in the perspective of replicating the existing practice, which itself emerged by mimicking the original fully manual process.

Most companies still distinguish the planning team, the people who establish the demand forecast for each product, from the supply team, the people who pass the purchase orders based on the demand forecast. This approach fails to appreciate that future demand isn’t independent from present decisions. The solutions - originally designed to replicate a purely manual process - have been in place for so long that people have lost sight of the more fundamental aspects of the problem they are trying to solve.

The intimate understanding of the problem to be solved is key to figure out whether the existing solution is worth preserving, or whether it should be simplified for newer software capabilities that call for a simpler, more direct, resolution of the problem.