Leader Spotlight: Why product management is becoming platform-first, with Yair Neumann
Yair Neumann is Senior Vice President of Product at Kaltura, a video cloud platform. He began his career as a photographer and technician at Kenes Group before transitioning to frontend web development at WebPick Internet Holdings, where he eventually joined the product management function. Yair later joined AdMaven as a product manager and then worked on mobile app product strategy at Digital Turbine. Before his current role at Kaltura, he served as Director of Product Management at Playbuzz, a Disney-backed storytelling platform.
In our conversation, Yair shares his vision for what product management looks like in an AI-native world, where interfaces become intent-driven. He explains why product organizations need to think platform-first, as well as how AI is reshaping roadmaps and experimentation.
The transition to conversational UI
You’ve laid out several provocative predictions about the state of product in 2026. The first is that software will no longer be organized around pages and navigation. If interfaces become conversational, how does product design change?
I think the word “design” will no longer be limited to just the design of a website; rather, we’re designing intent. When a product designer begins designing a product, they will no longer focus on how it looks, but on designing the journey. The journey doesn’t have to be something that you see with your eyes. In the case of conversation, I can simply speak and receive my answer. In the end, you’re designing a journey, but it doesn’t need to have a visual interface, necessarily.
The fact is, you can’t design an interface that makes sense to everyone. We’ve tried over the years, and we’ve also seen a one-to-many relationship between the website experience and users. The rare cases where it was more binary had to do with elements like locale or dark versus light themes.
What I have in mind is something much bigger. You still need a design system, but it needs to be very strong to create a website built on intent — one that understands the user’s context, the context of your available content, and the data you’re collecting all the time. Based on those things, it builds itself while staying on-brand. It should still feel cohesive.
Thinking that you and I need the same website, despite our different ages, interests, and goals, no longer makes sense. Today, AI can crunch billions of parameters in real time and build a layout tailored to exactly what the user needs. The CFO sees three KPIs and a cash flow chart. The analyst sees 14 filterable cohort tables. The CEO on mobile sees one number and a thumbs- or thumbs-down icon. Three generated UIs from one platform, and not one compromise layout. We can’t continue to think in terms of a one-website concept.We can’t continue to think in terms of a one-website concept. That’’s outdated.
How does this change the skills or background you look for when hiring product designers?
Many functions and positions are now converging within the space. We’re no longer looking for an expert in a single field of capabilities. There’s a concept of a full-stack product manager — someone with design capabilities who’s analytical and also invents things. Historically, those people were anomalies.
Today, you don’t need to have every capability yourself. You just need to know what question to ask and when to ask it. With the strong suite of tools we have now, you’ll likely get a very sound answer.
If you were only doing product design in the past but were afraid that the technical side of product management was a barrier, that’s no longer the case. There’s now a higher expectation that people entering product management know more disciplines and move closer to being full-stack product managers, all because they have these superhuman tools at their disposal.
Why platforms become the product
You recently said, ‘The website of tomorrow is built the moment you ask for it.’ What does that imply for product discovery and roadmap planning?
It makes it much more difficult, and we find ourselves investing a lot more in planning. The tectonic shifts in product and technology are so big that even basic building blocks of product management are changing as we speak. The place you need to invest in most is your platform.
If UI is commoditized and everyone can build applications simply by prompting AI, then the most important thing you can do is have a very strong engine and platform on which those applications are built.
In Kaltura’s case, we’re a video cloud platform. If you’re building a video application, we want to provide a cloud platform, APIs, and a strong MCP so your AI can talk to ours. Because here’s the threat: a mid-market sales team can now replace a monolithic product with Airtable, Clay, an AI agent, and a custom Slack UI in one Saturday — no code. What they can’t replicate on a Saturday is transcoding at scale, real-time event orchestration, or ML inference chains. The API is the door. The engine behind it is the moat.
AI has lowered the barriers to building software, but has it also changed what creates durable competitive advantage?
Absolutely. Companies that existed before the AI boom have important advantages, like customers, for one. If you already have customers, selling them AI capabilities is much easier than convincing entirely new and unfamiliar prospects to trust a new AI company — especially in enterprise environments with long procurement cycles.
The second advantage is content and data. If customers have worked with your product for years, you’ve accumulated content, behavioral data, and context. That translates into skills, which later become agents. This is the breeding ground for good AI. Understanding your customers’ behavior inside your systems and translating that into skills and agents is a huge competitive advantage in the AI race.
Going back to UI and the idea that customers could build or modify their own experiences, are there architectural decisions you’re making today to support customers building on top of your platform?
Building UI isn’t all the same. Building navigation or a carousel is simple, but building products like a video player or a Zoom-like real-time client isn’t. Because of that, we’ve built those advanced UI components as reusable platform features that developers can simply incorporate into larger applications.
For example, imagine someone wants to build a speed-dating application. They need a way to connect people to talk with one another in real time in a private room. That’s not something AI is likely to build easily today, even if you have the APIs to connect to it.
We have a micro-frontend framework called Unisphere that is embed-first. A developer can import one ES module from our CDN, initialize a workspace, and have a full AI conversational avatar with video search and interactive content running inside their app in under 20 lines of code. Even before AI, we believed embedding should be a first-class citizen. With AI, it’s even more important because the interface layer is whatever the agent assembles.
Documentation as part of the product
You’ve said your agent’s understanding of your product is only as good as your documentation. Should product teams start treating documentation as part of the product?
Yes. What was once a side dish is now maybe even more important than the showcased product itself. If documentation is the instructions for how other applications and AI agents build on top of your product, and agents can’t easily find your product or can’t easily build products from your documentation, then something is wrong.
You can test this immediately. Give an AI agent your documentation, ask it to build a feature, and see what happens. These agents are very good at translating documentation into working code. If they get lost or hallucinate, you know your documentation isn’t good enough.
From a product perspective, we have two requirements before we’re ready to deploy. First, it has to be API-first, which today also means MCP. Second, ii must be documented. If it is not documented, it does not exist. If a feature isn’t discoverable, then it hasn’t really made it to production.
On a product team, should documentation belong to a specific function or be shared across the team?
Today, the moment we open an epic, a documentation ticket is automatically created within that scope of work. There’s no option to push work to R&D without linking documentation to it. That already changes behavior because documentation becomes part of the workflow.
Who writes the documentation is another matter. You could have a technical writer. Product managers have always written documentation as well. R&D can write it, especially when you’re building API-first products for builders. Ideally, though, agents should do it. Once you have code and everything is explained semantically, translating that into human-readable documentation is easy. Agents don’t necessarily need human-readable language, but they still need taxonomy and hierarchy.
This entire process should be automated. Documentation shouldn’t consume an hour of anyone’s time — it should simply be part of the product lifecycle.
The future of product teams
Product teams have talked about failing fast for years, but you’ve argued that the mechanics didn’t really exist until now. What changed?
In the past, if you had an idea, maybe you’d build a landing page with a wait list and measure signups. Today you don’t need to stop there. You can build the core of the idea — not the entire thing, but the essence of it — and immediately see whether people find it useful, whether the hook works, whether the aha moment is there.
As a product person, you can start getting signals before you’ve even spoken with a developer or designer. I shipped two extensions and opened seven GitHub repositories in one week just to see whether people actually wanted to use the ideas.
Today, if you’re sending a product into development without already having market signals, you’ve done something very wrong. Ideally, you should fail every week and succeed once a quarter.
The barrier between product and code continues to dissolve. PMs can prototype, designers can generate code, and engineers can run customer experiments. As responsibilities become more fluid, what remains distinct?
Everything is converging. The PM whose identity is anchored in process management, standups, backlog grooming, mediating between design and engineering — that role is dissolving. The PM whose identity is anchored in judgment, taste, commercial conviction, and the infrastructure to test that judgment at speed — that role is multiplied. Now we have smaller teams, bigger accountability, and agents as first-class team members. The PM who wins in 2026 is not the one with the best intuition about what to build. It’s the one who built the best machine for finding out what to build.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.