Project Management

Do You Deliver Product or Value?

From the Taking the Plunge Blog
In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.

About this Blog


Recent Posts

What's in Your Project Management Tool Belt?

Scale Your Product Owners

When is a Good Idea a Bad Idea?

Is it a Project or Maintenance?

Do You Deliver Product or Value?

Categories: Agile

Hopefully, the product of every project you finish delivers value.  It doesn’t have to be an either/or proposition.  If your projects are like mine, however, you don't always realize the value in the products you deliver.

It's not that you don't see value in what you're delivering, or that value is never realized.  It's just that once the product of your project is delivered, your team might provide support for a short time, and then you're off to the next project.  The reality is that the product you just delivered might not deliver tangible value to the business until you are getting ready to finish your next project. 

It is difficult, to say the least, to assign a date to value realization.  It can also create a bit of a conundrum when you are told you are responsible for delivering value, but you're assigned to do other things by the time someone else quantifies the value realized from the product you delivered.

Let me take a step back.  What I'm really describing is a more traditional, big bang approach to delivering value.

Enter Agile.

One of the touted benefits of most flavors of Agile is that they deliver value faster than other project approaches.  This can be true, but one of the caveats I would place on this is that you must have one or more Minimum Viable Products (MVPs) and be able to deliver your MVPs early enough to begin realizing value before the project is finished.


SIDENOTE - For those of you asking if you can benefit from using a flavor of Agile, my opinion is that one of the requirements to realizing the full value of Agile is that you have one or more MVPs.  If you can't deliver value incrementally, or, in other words, if you can't deliver the finished product until everything is done, and you can choose your project approach, a flavor of Agile might not be the right approach for your project.


What is an MVP?  Minimum Viable Product is the smallest discreet subset of functionality that can be delivered to and used by customers, or sold if your company sells product.

Should I repeat that in English?  The MVP is not the finished product or a beta, demo, or proof of concept.  It is something usable, and usable enough that your customer(s) would be willing to pay for it, before you deliver the finished product.  When you deliver a true MVP, you are delivering value in the sense that the company you work for can begin generating revenue (or goodwill, for internal projects) months, or longer, before you deliver the finished product.  You might deliver several MVPs before delivering the finished product.

The finished product is just that; finished.  It contains all of the planned features and functionally that have been specified, or a decision is made that it is finished and no more work goes into that version.

You can take the big bang approach and try to deliver everything at once.  Big bang can be your only choice on some projects, even if you can develop iteratively.  But, if you can build AND deliver MVPs iteratively, and realize value incrementally, why wouldn't you?

I'm guessing you've noticed that I've used a couple of expressions that you don't normally hear in discussions about Agile.  You might often hear about incremental and big bang delivery, but not incremental and big bang value.  The difference is mostly, but not completely, mindset.

Incremental and big bang delivery is about delivering product.  You can deliver working code almost every sprint (Agile), or you can deliver everything at once (Big Bang).  These descriptions are most often used to describe one of the differences between Agile and Waterfall.

I am distinguishing incremental and big bang value from delivery because of my experiences.  I've broken a project into phases and delivered value, incrementally, without iterative development.  I've seen "agile projects" that were basically iterative development with a big bang product delivery.  Let your decision about how to deliver value inform your decision regarding your project approach.  Your project may be over long before the business realizes the value of the product your project delivers, and the amount of value that the business is able to realize may be beyond your control, but you can still keep value as the driver behind the product you are delivering.  Look for ways to deliver value before the project is finished, whenever possible; delivering product is not the ultimate goal.  Don't force an either/or proposition.

Posted on: May 07, 2017 12:03 AM | Permalink

Comments (16)

Please login or join to subscribe to this item
Thank you, Aaron. It was the MVP in a project recently that completely saved the project from continuing down the wrong path. Although the vision was agreed to, it was the MVP that provided enough insight and the 'aha' moment that gave us the opportunity to course correct.

The benefits realization post delivery are held with the business owner/group. The product should be to solve a business need and problem to show its value, otherwise, what is the justification?

Great thought. Thanks for sharing.

Yes... In my organization we do work on MVP and prioritize our work as per MVP.

Good article Aaron,
Once you deliver the MVP, are subsequent delivery still call MVP?

We should deliver value!

Any example of MVP in other field then IT?


Once you deliver an MVP, yes, there can be another MVP. Technically, you could argue that the word Minimum no longer applies, but if you look at it from where you are, not what you've done, the next MVP is the next smallest set of sellable functionality. It may, or may not, be an add on to what was previously released.

Based on Aaron's guidance would I be right in assuming the following as delivering a MVP in a non IT environment.

Building a road by-pass around a city and they decide to open sections of the by-pass to the public in advance of the whole road? As it will deliver benefits to the public quicker.

Thomas, yes, that would fit the description.

Thank you Aaron, great article!

great post, our focus should be on delivering products that brings value

Good article Aaron.

Thanks for sharing your view

Thanks for sharing!

Great article

Dear Aaron
Interesting your perspective on the topic: "Do You Deliver Product or Value?"

Thanks for sharing

Please Login/Register to leave a comment.


"There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more."

- Woody Allen