When the Agile manifesto was created in 2001, software practitioners were calling for a change in the way that software was delivered. The waterfall model of software development, which was predominant, required that software specifications and business requirements were frozen upfront. There was very little room for change. Change had to be avoided because changing anything midway would increase costs and timelines. Waterfall had evolved as a way to handle software development processes based on the limitations of the software technology of that time. Much of software development then was about automating manual processes or building bespoke technology solutions. Technology has since evolved a lot. It has become increasingly flexible and inexpensive to build technology solutions with direct consumer impact. The focus for software builders has expanded to include customer satisfaction and is no longer about just meeting budgets and timelines.

There are many frameworks (Scrum, XP, and so on.) that offer a methodology for software teams to focus on user experience and customer value. They foster team collaboration and enable teams to respond to change. The guiding principles behind these frameworks are noble, but failures always happen in how these principles are put into practice.

Without context, intent, and outcomes being defined, even well-meant advice can go waste. This is because we're humans and not honeybees. We are driven by purpose, we are lazy and we are imaginative. People can conjure up images of success (or failure) where there is none. They plan, speculate, and adapt. They try to optimize for imagined future situations. We know that a sense of purpose is crucial to rallying a group of diverse, independent, and creative people to come together and effect change (or even build great products). The problem is this is exactly where we seem to fail time and again.

We fail because we focus on the wrong stuff. We try to predictably measure productivity in a creative profession. We over-engineer solutions to nonexistent use cases. Software engineering is an interesting field of work. It's like an artist and a mathematician coming together to generate business value! Yet, we treat software engineering like automobile manufacturing. I know amazing software engineers who can churn out beautiful and working software, but their pace of delivery is not predictable. Every person has their own pace, and style of working, which is a problem for project managers. When we have strict timelines and budgets to meet, how do we commit if there is so much subjectivity? Software teams have spent a lot of time inventing processes to accurately predict engineering efforts. Estimations, planning activities, functional scoping, and progress reporting have gained a lot of visibility in this context. We focus too much on engineering practices.

Software product development is missing out on a great opportunity here. By carrying over software delivery frameworks of meeting timelines, budgets, and customer satisfaction, we are in a way restricting ourselves to looking at outputs instead of outcomes. It is time that we changed our perspective on this. Product management shouldn't be about measuring effort or productivity. Product management shouldn't be about measuring output. Instead we should focus on product outcomes. What value are we creating for the customer? What outcomes is the product helping the business to meet? How can we execute a plan to achieve this in the smartest way possible? So how do we measure these outcomes?