The MVP Trap and Psychological Safety
From my vantage point I see a lot of conversation about psychological safety. (The fact that this conversation has so much traction in the age of layoffs has a certain irony to it but stick with me for a minute). We see leaders talk about or adopt talking points around emotional intelligence. Speaking up is encouraged. Fear of failure is supposed to be reduced if not eliminated. We are experimenting, learning, and feel good doing so. We are showing up as our real authentic selves!
These are the common ideas and aspects we talk about when we talk about psychological safety. And I will not diminish the importance of them in the slightest. But it is my intention to shed a bit of light on a seemingly less obvious - or willfully ignored - area that in my mind plays an important part, too.
Most of people in tech are familiar with the idea of releasing something imperfect. Something to be iterated on. Some call it MVP, some call it MLP, but the premise is similar. It is not intended to be the final version.
For people who take pride in their craft releasing these version is a delicate balance. They know its imperfections, the compromises they made, the needs it still doesn’t meet. But they are are mindful of business realities, of speed to market, of budget constraints. They are also bought into the idea that an early release is intended to be a learning tool to inform future iterations. So they support such releases. They were told that it’s “only a first release, we will iterate on it.”
Yet all too often they see a flawed version, intended to be an early release to be learnt from, become a permanent solution. The ticket is closed, the team is told to move on. This, too, is a factor of psychological safety. Can a team trust its leadership? Do they share a similar level of care for their product and for their users? Or are they being gaslit into releasing something that never was intended to be a learning opportunity, but was instead just an underfunded project with an arbitrary release deadline?
When leaders promise iteration and don't deliver, trust erodes. Teams stop raising quality concerns at launch because it won't get fixed anyway. They stop investing in good instrumentation because nobody's coming back to read the data. They stop believing that their work is part of something ongoing and start treating each release like a fire drill. Get it out. Move on.
That's the opposite of an experimentation culture.
A culture of genuine psychological safety goes beyond talking points about speaking up, taking risks, making mistakes. It has to also include reliability. It means not borrowing credibility from a continuous improvement process you don't actually intend to follow.
And beyond the impact on team culture, it should be obvious that this negatively affects the product and its quality, too. If teams know tehy will not come back to fix things, why would they invest in tracking metrics, in measuring quality? If they have an honest experimentation culture, they define what they want to learn from a release, what data they need to capture to get the answers, and they design the learning process itself. They will improve products accordingly. If not, they just release. Check the box. Close the ticket. Move to the next one. And it will show.