Projects to Products: The Mindset Shift Behind Data Products
The mechanics can be designed in a quarter. The mindset is the work of the transition, and it is the part no reorganisation can do for you.
The Shift Is In The Head, Not The Process
There is a great deal being written now about how banks should move from projects to data products, and almost all of it describes mechanics: operating models, ownership roles, funding lines, governance forums. That work matters, and I have argued for it elsewhere. But it misses the thing that actually determines whether the move succeeds, which is not a process at all. It is a change of mind. Before it is a shift in how work is organised, projects-to-products is a shift in how people think about what they are doing and what they are responsible for. Get the mindset wrong and the finest operating model on paper will be run by people still behaving as though they are on a project.
The distinction is easy to state and surprisingly hard to live. A project is something you finish. A product is something you keep. Everything else follows from that single difference, and most of the difficulty of the transition is that it asks people to give up the deep satisfaction of finishing.
What The Project Mindset Rewards
The project mindset is not a flaw. It is a discipline the industry spent decades instilling, and it instils it well. It teaches people to define a scope, drive to a date, close out, and celebrate delivery. The reward is the moment of completion – the go-live, the sign-off, the team dinner, the movement on to the next thing. That reward is powerful and it shapes behaviour all the way down.
Watch what the project mindset does to a data initiative. It treats the launch as the finish line, because finishing is what it is for. It treats the team as temporary, because teams are meant to disband. It treats support as someone else’s problem, because the project’s job was to build, not to run. It treats adoption as a box to tick at the end, because the deliverable was the thing, not its use. None of this is negligence. It is a well-trained person doing exactly what the project mindset rewards them for doing.
A project is something you finish. A product is something you keep. Almost every difficulty in the transition comes from asking people to give up the satisfaction of finishing.
What The Product Mindset Demands
The product mindset inverts each of these instincts, and that is why it is uncomfortable. It treats the launch not as the finish but as the beginning, the point at which the real work of earning and keeping trust starts. It treats the team as standing, not temporary – someone is accountable for this thing indefinitely, and there is no dinner to mark the end because there is no end. It treats support and quality as the core of the job rather than an afterthought, because a product that is not supported stops being trusted. And it treats adoption as the only measure that matters, because a product no one uses has failed no matter how well it was built.
The contrast can be put simply. The project person asks, “Have we delivered it?” The product person asks, “Is it still trusted, and is it still used?” The first question has an answer and then you are done. The second question never stops being asked. Learning to live inside the second question, rather than racing to escape it, is the whole of the shift.
- The project person hands over and moves on. The product person stays and owns.
- The project person is proud of the go-live. The product person is proud of the third year of steady, trusted use.
- The project person measures effort by what was built. The product person measures value by what is relied upon.
Why The Mechanics Fail Without It
This is why I am wary of banks that reorganise into a product operating model and expect the behaviour to follow. It does not work in that direction. You can rename a team a “product team,” give it a “product owner,” and draw a persistent governance forum on a chart, and still have every person in it thinking like a project: driving to the launch, planning their exit, treating the running of the thing as a lesser task to be handed away. The structure will be product-shaped and the behaviour will be project-shaped, and the behaviour is what determines the outcome.
I have seen the reverse too, and it is instructive. A team that genuinely thinks in products can keep a data asset trusted and used for years with quite modest formal machinery around it, because they own it in their heads. They notice the quality drift before a consumer does. They treat a lost consumer as a failure to investigate, not a statistic. They resist the urge to declare victory and leave. The mindset does the work that the org chart was supposed to do, and it does it better.
The Feeling You Have To Give Up
If there is one thing that makes this shift hard to complete, it is emotional rather than technical. People like finishing. Completion is satisfying in a way that stewardship is not. The go-live gives a clean, visible, celebrated end; the quiet, ongoing custody of a trusted product gives no such moment, ever. Asking a delivery culture to move from projects to products is, at bottom, asking it to trade the pleasure of the finish line for the slower, less glamorous pride of something that keeps working because someone keeps caring about it.
That is a real thing to ask of people, and it should be named honestly rather than buried under an operating model. The banks that make the transition are not the ones with the best diagrams. They are the ones whose people have genuinely stopped asking “when is this done?” and started asking “is this still trusted?” – and who have found, in the answer to that second question, a quieter but more durable form of pride. The mechanics can be designed in a quarter. The mindset is the work of the transition, and it is the part no reorganisation can do for you.