I talked with Ruben Casas about product engineering at a moment when a lot of experienced engineers are finding their way back into building products directly.
Ruben has worked across product, platform, and developer tooling, and he is now working at Postman in the middle of the AI and MCP wave. What stood out to me in this conversation was not just that agents can help us ship faster. It was Ruben's point that they can let us combine two things that have often drifted apart: high-level product thinking and hands-on implementation.
That combination matters because implementation is getting cheaper, but judgment is not. If anything, deciding what is worth building gets more important when it becomes easier to build almost anything.
Start with the pain point
Ruben kept bringing the conversation back to real problems. Not "what would be cool to build?" but "what pain point are people actually feeling?"
His example from the MCP space was a good one. He saw people running into the limits of text-only agent interactions and started exploring UI for MCP tools. The important part is that he did not start with a polished product. He started with a prototype and a demo that made the problem and possible solution visible.
That is a useful product engineering habit. A demo gives people something concrete to react to. It changes the conversation from a theoretical debate into: does this solve your problem, is this useful, and what would make it better?
Demos are a product tool
One thread I really appreciated was Ruben's reminder that demos are not just for marketing after the product is finished. They can be part of how you discover and shape the product.
He talked about selling software earlier in his career and how much more effective it was to show a working e-commerce integration than to describe the possibility abstractly. When people can see their products, their workflow, or their pain point represented in a working demo, they understand the opportunity faster.
That maps well to how we can work with agents today. Build a prototype quickly. Show it to someone. Watch what they do with it. Let the feedback tell you whether you found a real problem or just built something interesting.
More shipping still needs guardrails
Ruben also named an important tension: agents make it easier to ship, but that does not mean every shipped feature is worth keeping.
We talked about feature product-market fit, not just product-market fit for the whole product. If a feature disappeared tomorrow, would users be upset because their workflow breaks, or would they mostly shrug? That question is uncomfortable, but it is clarifying.
This is where product engineering still needs engineering. Architecture, tests, maintainability, taste, and boundaries matter even more when more people can touch the codebase with AI assistance. The goal is not just to make shipping possible. The goal is to create an environment where shipping quickly can still produce a coherent, reliable product.
The homework
Ruben's homework was direct: find a problem that bothers you, build a quick prototype with an agent, record a short demo, and send it to someone for feedback.
I like that because it practices the whole loop. You have to notice a problem, make something real, communicate the value, and listen to what another person says in response. That loop is where product sense grows.
