Let’s say some smart people have given you some great ideas about “business value engineering.”

Let’s say those ideas include:

• More customer demos
• Having the implementors visit the customers as they “do work” or “live” (depending on your product)
• A better BV Model
• Don’t talk to customers (they don’t know they want an iPad)
• Taking BV metrics after each release
• Using the Pareto rule more to skinny down how many stories go in a release
• Better PMO governance, to assure that problem teams are helped sooner (so that deliveries happen faster)
• Improving the creativity of the Product Owners
• Better brainstorming by the Business Stakeholders (or whatever you call them…the people that ‘assist’ the Product Owner)
• Priority Poker (wide band delphi to estimate business value, using Fibonacci cards)
• Agile Specs
• Rely less on documentation and more on conversation to assure the Implementors understand the story
• Story Boards
• User Story Mapping
• More wireframes
• Focus on “bang for the buck”
• A story breakdown structure, to use to manage with senior Business Stakeholders
• Completing more projects “early”, eg, when we see that the benefit-cost ratio of the project has deteriorated to below alternate projects (and other criteria are met).
• Light use cases
• Etc, etc, etc

Note: I personally like some of these ideas a lot.  On the other hand, some I tend to shy away from.

First thing to observe (and the above is a short list of all the ideas out there): Too many ideas to implement all at once.

Second: Some of these ideas are contradictory.

Third: “Many seem very good ideas for us, but how do I prioritize?”

Yesterday I explained how we can use “BV process mapping” to enable us to see enough to prioritize the improvements we want to make.  (This really includes more than mapping, but let’s over-simplify and call it just “mapping.”)

As a minor benefit, BV mapping enables you to hear talks, and identify which part of the BV engineering process the person is talking about. In other words, you can put others’ ideas in a context that, hopefully, makes the ideas more useful or at least actionable.

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.

Imagine that it is not Scarlett Johansson. Just a girl or young woman. Or maybe any customer who buys your new camera. You don’t make any profit on that camera, just she smiles.

How do we evaluate the Business Value of that smile?

“Would it have been worth it, after all,
Would it have been worth while”?  (TS Eliot)

When I got my MBA at a school just off Wall Street, they said (or some of them said) that the firm was there to maximize shareholder returns.  Not that that was bad, since firms in the end are owned by widows and orphans…it is they who mainly use all the value there.

But the message was: money.  Measure it in money.

My ancestors are (or were) practical crazy New Englanders. (Well, crazy in the sense that they left the comforts and known-ness of England to live in strange unknown land where half of them died the first year.)  They were practical.  I cannot say money is bad. It is only a means, and a very practical means.

I found out also, at that same school, that Peter Drucker (arguably the best management guru still) said that the purpose of the firm was to provide customer satisfaction.  (That, for example, making money for the shareholders was a constraint, not a key purpose.)  Frankly, as I get older, I tend to agree.

And one finds that firms never can charge for each specific increment of customer satisfaction.  Charge, they must, at different times, but never exactly bit-by-bit for each increment of satisfaction.  Can Starbuck’s charge by the sip?  No, I think not.

And then one ponders, Maslow-like, the satisfactions for the producer and the wise consumer, of various products or services.  Truly “satisfaction” is an inadequate word for a trip to Paris. When you buy a copy of The Count of Monte Cristo (Dumas), is it exactly satisfaction one seeks?  Or adventure? Or to be at-one with others?  Does one know?  And how to measure it?

The metaphor of Maslow’s hierarchy of needs might be useful here.

Now, people will pay for these things. But how much to charge, and how much real “business value” they receive….these are hard things to understand.  Well, indeed, a human being is a hard thing to understand.  And hopefully you are in business to serve not one, but many human beings.  Quite complex.

My main point today is that people must re-gain an appreciation for the difficulties of the work of understanding business value.  To me, it is very very important, and also very hard to understand. So, we should start with the assumption that we need a lot, a whole lot, and mean gobs, of feedback.  To help confirm to ourselves that we have not totally mis-understood.

But God!, as a producer, when she (well, she, especially if you’re a man… your wife, your daughter, your girlfriend, your mother, someone you care for) when she smiles. When she is happy with what you have produced.  It is a wonderful day.  When you don’t get the puzzled look of “well, he tried hard, but it’s not what I want, and how will I tell him?”  No, not that. But the smile of “I really like it!”  It is very satisfying as a producer, is it not?  (And the women readers who are producers know what I mean too. Although there are different difficulties.)

So, Scrum is trying to enable all these moments of truth to happen.  To feed your head and warm your heart.