Right out of college, after my dream to work for ESPN was smashed to smithereens, I started a career in sales. I know, I know, save your indignation for another day. It’s a long story on how I got to my current field, so I’ll save you. Needless to say, I have felt both sides of the table in software.

Business versus development.

In the realm of product management (as well as ownership), we are always caught somewhere in between both sides. Development just wants to be left alone to write and test code in their own timetable. Business wants the work done by the time they promised or wrote into the contract. One of the hardest parts of the product team is we need to care about both.

Let me say that again: to be successful in the realm of product, you need to care about appeasing both business and development to deliver the best products to your customers.

I had a recent conversation that I think is an example of walking this tightrope. Like most companies, communication can be hard with so many moving parts and priorities. This results in every feature seemingly taking forever from a business perspective, and every defect seems to be a showstopper from a development perspective.

So there I sat in the office of our support team director, trying to make a mess of what had happened a day before. A high priority feature request came from one of our biggest customers, and I had my team hard at work to meet that deadline. At the same time, a major defect had come up that was deemed to need an immediate fix. From a development perspective, that is a huge paradox. From a business perspective, both items needed to be done.

Once all the fires were put out, and everyone had taken a deep breath, I wanted to circle back to figure out a lesson learned. The director informed me the development team doesn’t always understand what goes into the value of a defect. They merely look at the technical limitations and level of effort needed to resolve.

The solution was to determine a business value for defects much like product would attach to new features. In the end, the more information development can share with business, and vice versa, the easier it is to place yourself in the other’s shoes. When that occurs, doing a little extra to keep our customers happy.

In some circles of product, the term “business value” gets a little grief because it can be a bit hard to quantify. After this situation, I would argue that it can be a versatile tool to give visibility and value to a work item.

Look for the business value in each of your work items. If you are having a hard time communicating the severity of your issue you need worked, start with the value. Quantify it the best way possible. There will obviously be gray areas, which only provides an opportunity for further communication.