One reason for "Business Value Engineering"

I said recently that "business value engineering" is the place we can improve the most.  By which I mean:
(a) identifying the small features that the customer will want the most (once they get them), and
(b) identifying the MMFS (minimum marketable feature set).

Perhaps we should also add to this:
(c) identifying a "business model" that is reasonably attractive to customers and successful for the firm.

By this we mean, all the pricing and servicing and delivery things we put around the product.  If these don't work, the "product" per se may be wonderful, but it will fail.

We need to at least briefly mention the time dimension. For most products, the customer explicitly or intuitively realizes that he is entering into a long-term relationship with you. (At least with all the new products that I deal with.)  So, you must also have something like a "product life cycle" approach that is reasonable.  If you want to succeed longer-term.

I think that improving velocity (as defined by story points) is important (as suggested by recent posts), and important in many ways.  But I think improving business value engineering is, virtually always, the path to more success quicker, for the team.

Almost always, the biggest impediment for a Scrum team is a weak Product Owner (who is responsible for business value engineering).  Usually the person per se is very strong (smart, articulate, etc), but largely untrained and ill-equipped to be a fairly good product owner. Much less an excellent one.

***
When I talk about business value engineering, I always want to talk about the full end-to-end "process".

I think many people have many wonderful ideas about how to improve things.

But, I find that...
(a) no one can implement all of these proposed improvements at one time (usually it would take years to fully implement them)
(b) some of the proposed improvements are contradictory, or at least don't work well together with certain other things
(c) for a given company in a given industry, given their own current "processes," Improvement A is often much more useful than Improvement B.  While, for another company, Improvement B is more important.

So, as with Lean Value Stream Mapping, one of the key reasons to do a business value engineering map (with hypotheses and assumptions) is to identify the priority of the improvements.

Prioritizing the improvements is very important.
I'd rather make a little progress each month than "lots and lots" of progress that is supposed to arrive in 3 years.