> simply going to the customer and asking them, "Out of these 10 things, if you could have 3 by the end of the month, which would you pick?"

This is only simple for a limited number of businesses. If you're building a product and not selling a service, it's much harder to nail down what is actually important to potential customers. Even talking to existing customers about new features is never a fool-proof way of getting the right prioritization.

Even when you do have a customer you can go and ask, they are rarely a single entity. The person in charge of the buying decisions may think some features are important, but the people who will end up using the product may have other priorities. Even then, prioritization may be hard on their part. If I were building a word editor for you and I came and asked whether word counts are more important than page numbers for you, would you be able to give a confident answer? Would your colleagues give the same answer? How about prioritizing both features over some stability work (e.g. you get both page numbers and word counts, but the product is still a little crashy)?

"We need to add unit tests" "That brings no value to the business!"

"We need continuous integration" "That brings no value to the business!"

"We need version control" "That brings no value to the business!"

"We need to upgrade from JDK 1.4" "That brings no value to the business!"

"We need to safeguard user's data" "That brings no value to the business!"

And on, and on, and on.

That's because "bringing value to the business" is confused with "increasing quarterly profits."

The problem is poor valuation. All of the above can be process lubrication. The actual value comes from the process that goes on top of them. But if they're not in place, process implementation is going to have a lot of unnecessary friction, which reduces the eventual value of the core business process.

Some businesses get this, others don't.

For those that don't, it helps to explain the effects with real financial metrics. If your product is six months late and customers hate it because it's full of bugs, your process has failed to "bring value."

Exactly right. Building cowboy software with intense schedule pressure and best practices corner cutting it's likely to give you both late releases and bug backlog long enough to circle Earth three times.

There will be more bugs, and bugs will be more time-consuming to fix.

And the people who could rectify the situation get the message that their opinions/judgement aren’t valued and give up or go to work someplace else.

I think perhaps people don’t realize that “you get what you measure” has deeper layers to it. You get actions, you get people who are comfortable with those actions, and then you get friction to change this new status quo.

Yes, that's how that question is normally used. But it's a lie, those often bring value to the business.

If you are trying to answer it honestly, you will certainly get better results. But I am still not sure it won't bias you in a harmful direction.

> "We need to add unit tests" "That brings no value to the business!"

"Yes it does, it allows to make needed changes quickly and confident that they won't break other functionality."

etc.

This kind of thinking is how you run a good business into the ground chasing local maxima.

Ask Kodak

As other people mentioned, this is shortsighted. What you want to target is a balance between exploitation, 'bring value to the business', and process improvement, 'how do we simplify our processes to make it simpler to bring value to the business in the future'.

Both can be argued with concrete scenarios and data.