June 2026 • 5 min read
Tags: Product, Design Process, UX Design
TL;DR: It is easy to think that a good product is born from a good idea. In practice, it is often born from insisting on good execution despite constraints, objections, scope cuts and compromises. High quality is not only a design or technical decision. It is a business asset, and it almost always comes with a cost.
Have you ever worked on a feature and not been asked to remove something, make it smaller or simplify it?
It is rare that I have worked on a feature that people agreed to release exactly the way I wanted it to be. There is almost always a reason why it is not possible: development does not have time for it, we do not have backend support, it is not in the design system, it will take too long, we have to reduce scope, it can wait for phase two.
And sometimes simply: why do we need all of this?
So many objections, blockers, technical constraints and organizational constraints stand between the idea and the product that eventually gets shipped. That is why every time I see a good product, where the core features are genuinely convenient, thoughtful and logical, I get excited.
Because I know it probably did not just “come out that way.” I know that someone, or several people, pushed, insisted and did not give up in the face of all the objections and constraints, so that something genuinely good could come out.
This may sound a little dramatic. At the end of the day, it is just a product, not life-saving work. And there are also many products in the world that are not amazing and still succeed.
But since we invest so much of our time and energy in building products, since the market is more competitive than ever, and since people are still willing to pay a lot of money for something valuable - a good product matters.
Not every product needs to be perfect, and not every feature needs to get its dream version. But there are moments when quality of execution is not a “nice to have.” It is the thing that creates the value.
Do you know the story of Figma versus Adobe?
When Figma came out, it changed the world of design through real-time collaboration. Before Figma, working on design files was much more cumbersome: files, versions, sending things around, exports, links to development, fixes, another version, another update.
In the launch post for Multiplayer Editing in Figma, Evan Wallace wrote that Figma spent a year building this capability, even though it was a major technical investment that required time, resources and changes to the foundations of the editor itself.
This is exactly where a product is tested. Because it is easy to imagine how this could have been cut: live collaboration is a lot of effort, so maybe we only update after refresh. Maybe we show a message that “the file has changed.” Maybe we create an interim solution. Maybe it waits for the next phase.
But if Figma had shipped an experience where you had to refresh to see a change, or where collaboration kept getting stuck, it probably would not have felt like the same category shift.
The idea mattered. But the execution was critical.
That insistence was not only about a “nice user experience.” It became a business asset.
Figma pushed aside older tools, including Adobe products that had dominated the field for years. In 2022, Adobe announced that it planned to acquire Figma for about $20 billion. The deal was eventually terminated in late 2023 because of regulatory difficulties, but the offer itself says something about the business value that had been created around the product.
And this is the point for me: successful execution is no less important than the idea itself. Sometimes it is even the difference between an interesting idea and a product that changes the working standard of an entire market.
High quality is often the result of human insistence in the face of organizational and technical constraints. And it is not always romantic. It comes with a cost: criticism, arguments, frustration, another meeting, another explanation, another attempt to convince people why this matters.
A friend who was once a CPO at a company that built a product is still proud of product decisions he insisted on against everyone, decisions that still exist in the product today. In the same breath, he says he is completely done with those exhausting arguments. There was a cost, and that sounds very real to me.
Because often, when we look at a good product from the outside, we see the result: the feature works, the flow is pleasant, the interface is clear, everything feels logical. But from the inside, the road there was often full of compromises that almost happened, cuts that were almost accepted, and discussions nobody wanted to have again.
There is a cost even now.
Insisting on quality is not always worth it in every moment. Sometimes we really do need to reduce scope. Sometimes there is no time. Sometimes there is no infrastructure. Sometimes the right thing is to release a lean version and learn from it.
But this is exactly where judgment is required, because not every compromise is the same compromise. Some compromises remove noise, some focus the solution, and some remove the very thing that was supposed to make the feature good in the first place.
Good judgment will always have significant value in the job market. The question is not whether to insist on everything, but where quality truly matters, and how much we are willing to pay to protect it.