The sunk cost fallacy is in action every time you:
Sit through a long boring movie even if you decided after the first half an hour that is was terrible
Finish a meal that tastes bad and after you’re already full
Continue a bad relationship or friendship, purely because of the time and energy you’ve invested in it so far
Put simply, it’s the motivation to continue on a bad course of action, where logically the future does not look bright, only because of the time/money/energy you’ve put into it up to that point.
These already spent costs, that cannot be recovered, are known as “sunk costs”, and there is a strong human resistance to giving them up. It feels like admitting failure. But being able to be agile and “pivot” when needed is the mark of an intelligent business, and the sunk cost fallacy is generally the main thing in the way of that.
A pivot is when, part way through developing a product or service, you decide to take it in a different direction than the current planned path. This might mean changing the main focus of the offering, or even making it do something completely different to the original plan, and should be informed by early feedback as much as possible.
The problem with the sunk cost fallacy is that you end up investing much more than necessary in to whatever you’ve sunk the costs into, leaving you with fewer resources to go down productive paths. For example, if you’re stuck in a bad relationship, you can’t open yourself up to a future good relationship. And if you’re constantly paying for ongoing product development on a dead product, you can’t be working on a useful product instead.
All you’re doing in this case is throwing good money after bad… but there’s a silver lining. What you’ve paid for up to this point isn’t all wasted. The validated learnings you have gained will stop you from repeating the same mistakes. You have tested the market, an idea, or a product line, and you’re better positioned for your next endeavour.
Every software product in development has a Product Owner who is in charge of supplying the requirements, and it is often misunderstood how important this role is. You can have the best engine in your car (the development team), but if you steer in the wrong direction, you’re not going to get to your destination.
Here are seven tips to make sure you’re doing this job well:
Represent the business
As the Product owner, it is your job to take requirements from any other business stakeholders, your own direct manager, feedback from the developers, and also the actual users of the software, and order them into a single funnel of prioritised work for the development team to work from. This is called the product backlog and is the main tool through which you can influence the success of the team.
Talk to the stakeholders
As well as taking requirements from the business, you also need to be able to report back to your various stakeholders with what the progress of the project is, and potential ETAs for features that they’re waiting for.
Maximise business value
Backlog prioritisation is all about making sure that the development team is always working on the most important thing that will provide the most business value. You can use a two dimensional matrix to help you with this decision. Think in terms of urgent vs important, and work in the following order.
If a PBI (Product Backlog Item) is urgent and important, work on it 1st
Work on important but nor urgent PBIs next
Then urgent but not important
Finally work on the PBIs that are neither urgent nor important
Since new work will constantly be coming in from feedback and other new ideas, if you follow this rule you will often find that your team almost only works on category 1 and 2 above, meaning you’re never working on unimportant work. Often you’ll find that if a PBI is urgent but not important, it will either no longer be urgent after a little while, or else it will become important.
Think in terms of Minimum Viable Product (MVP)
As a Product Owner, you have to be able to say when a feature is good enough for the team to stop polishing and adding bells and whistles, and instead move on to the next feature down the list.
This is especially important when budgets are tight (i.e. 90% of the time) to make sure that the business gets what it needs before you work on what it wants.
Be aware, however, that there is a slight cost in this, as if you want to come back to it later, you will have to let the developers get re-accustomed to that area of their code.
Manage Technical Debt
Technical debt is code or documentation that builds up over the course of any project, where some parts become legacy or shortcuts that were taken earlier cause headaches for work done later. Even diligent teams often find themselves with a buildup of technical debt as best practices change or new technologies emerge.
The solutions for this are varied, and include re-architecture, adding more measures such as unit tests or automated UI tests, and, most commonly, refactoring. Creating and prioritising these PBIs is one of the hardest things for Product Owners to do, as only the development team really knows extent of technical debt in any project, and often they won’t speak up about it because they caused the issue. See my other post about trust in teams to make sure you get full transparency in this.
My advice is to have a little bit of technical debt reduction in each sprint, as well as in your Definition of Done
Have a vision for the product
As well as taking requirements from others, the Product Owner should be in a very good position to have a holistic overview of the long term goals of the product, and this is known as the Product Vision. Keep this vision in mind as you’re shaping the product, to make sure it’s heading for a good destination.
Motivate and empower the team
There are plenty of ways for a Product Owner to impact the productivity and motivation of a team.
Show gratitude for work well done or particularly useful features delivered
Share the team’s success with others… always giving the credit to the people who did the work
Be available throughout the sprint for clarifications to PBI Acceptance Criteria (i.e. the requirements)
Try not to change your mind on priorities and requirements part way through a sprint as it can ruin the flow of a team that is on a roll
The General Manager 