Potential Shippable Increment (PSI) is not always a Minimum Viable Product (MVP)

As a young father, one day I was wasting my lunch time watching a funny moment on a baby video, while taking tips to teach a thing or two to my own munchkin. (Back to post? Good, read on). At that very moment, overheard a fellow Scrum Master explaining to one of his team members what an MVP is, on a lunch break ! Still not sure if they were wasting their lunch time or I was. Anyway, the conversation was something like this:

Member: Bored of these new terms like PSI, MVP.. what’s the difference anyway? I keep hearing this from the new PO.

SM: Potential Shippable Increment, which is basically the same as the MVP thing you read on the book “The Lean Startup”. The POs can throw any of the phrases to specify a working software which is ready to ship.

Member: Ok, so Minimum Viable Product is like the new brand for PSI.. lol.. got it.

SM: Yeah, different POs uses different phrases, just go along. If he likes calling it PSI, let it be.

Eavesdropping paid off, that’s how I remember where I paused my video earlier. Instantly found an opportunity to arrange a training workshop on lean startup to explain where it all went wrong in the conversation. If you have already spotted where it went wrong, you already know where I am going with this.

Potential Shippable Increment (PSI)

I will quote directly from the Source

“Potentially shippable is a statement about the quality of the software and not about the value or the marketability of the software. When a product is potentially shippable then that means that all the work that needs to be done for the currently implemented features has been done and technically the product can be shipped but it doesn’t mean that the features implemented are valuable enough for the customer to want a new release. The latter is determined by the Product Owner.”

PSIs don’t always add value. A team can build a hundred things which have an awesome quality which may not be needed. On a lazy refined backlog these PSIs can cost a business a fortune. As a great agile team, may be you are good at delivering efficiently but if a PO fails to recognise the benefit of that work, all of that can be pointless.

Minimum Viable Product (MVP)

“A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” – Eric Ries, author of The Lean Startup

MVP does not always have to be a Working Product/Software

It can be an concept which has been drawn on a paper, modeled by a UX designer or simply a bunch of screenshots which we can show to the end user and see what they think about it. Sure, it can be a working software because sometimes it is always good to see a piece of work in action. But it’s not mandatory for the validated learning. You may not need to invest time and money on a product which initially have received a bad review from potential buyers. It’s about working smart, not hard.

Explaining the Differences

MVP of Cars

Concepts of cars displayed to see public reaction, most of the times they are not ready to be shipped. MVPs are often more attractive as they lack practical usability or lack context. Which is why they need early feedback from the end users of a business.

PSI of Cars

Shippable cars being demoed to generate revenue which might be a MVP, before becoming a PSI. PSIs form part of or all of the MVP planned to be implemented. Not every PSI looks as attractive as the original MVP, because validated learning makes us aware beforehand what works and what not. That’s where Empiricism adds value.

MVPs of Smartphones

Concepts of smartphones (We wish these were real)

PSIs of Smartphones

Shippable Smartphones on 2017 (so they say)


So, next time you hear someone saying MVP and PSI are the same, you can share this blog and save the time explaining why they are not. There is a reason Product Owners (alike) call them differently, as to them they are different. Some work items don’t need to be developed before a feedback, some do. Hopefully this clears the confusion and this post finds you well.


Agile – It’s not about delivering working software faster

What is agile? Most cliched answer to this translates to “delivering working software faster”. Because, agile principles clearly states – “Working software is the primary measure of progress”. It doesn’t mention anything about the speed though. In rest of the article, where ever you see “value” translate it to “shed-load of money” if that works for you. It is very important to establish what is the definition of “value” for you, to understand the true meaning of what agility is.

If you buy a new bike or car, it’s performance will always be lower than a well oiled 2year old vehicle with similar specs. Agile teams are like that. The team members can be experienced and brilliant but to really know what part of the product is making the most value, requires investment on thought process. That’s where a Product Owner/Expert comes in with data to prioritise the most valuable work on top of the backlog and own the decision. It’s their job to also convey “why” it is more valuable to the team as well to validate the possibility.

Example Problem Statement

A company hired 10 team members paying £500/day. Screw prioritisation; an expenditure of £5k/day needs to be used up in anyway possible on that 8hrs contracted. Even if that means we make the member work on items no one really give a shit about or have any value. If we focus on priority we will end up wasting 3hrs a day, out of which the members will celebrate a 2hr lunch and will be milking the strategy. How do you propose to handle that?


Assuming a 20 days working month, paying £5k/day or £100k/month is actually a lot of money to go down the drain, if they work on features no one asked for. The cost can only be justified if they focus on the most valuable item first, instead of an item you may not need for a month. In many cases, as much as 80% work remaining are actually not necessary for early feedback, as the most valuable 20% decides the fate of a product. Work on them first and save your time and money and stop focusing on what the members are doing, as long as they are working on the right thing you require.

Pareto Principle

Does the above solution sounds familiar? Yes, I am referring to the Pareto Principle which is known for a century now. Albeit, saying that 4:1 distribution is “accurate” would be a wrong generalisation as it’s application varies. But it does make a point about how we should approach the product backlog. Empiricism, hence is the only way to go with faster feedback to continuously update the backlog as we know more and more about the product and end user’s expectation.



Working software is mandatory but the trick is to convey the message like this –

Agile is NOT about delivering working software faster, it is about delivering the most valuable software faster.

End Note

Prioritisation is all that matters. If you have adopted “Agile” and still focusing on speed or amount of work for monitoring purpose, then you are doing it wrong. There, Agile defined the way most businesses want to hear. Value can have different definitions for different businesses, “Money” being the most common form, which we should really focus on.

Hope this article makes it clear why “Agile” makes sense in development.