One reason for “Business Value Engineering”

I said recently that business value engineering is the place we can improve the most.

By this 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:
(c) identifying a “business model” that is reasonably attractive to customers and successful for the firm.

This includes: 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. At least many products 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.

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, with 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.