WGMaTM: AI Workflows, the SaaS Reckoning, and the Rise of Hybrid Operators
What Got My Attention This Month, as a Product Leader
Here’s what got my attention this month — a short list of things I read and watched that stood out to me as a product leader, plus my 2 cents.
Here we go.
1/ AI prototype workflows, pitfalls and guardrails
One of the first things I noticed this month was a growing number of tech teams publishing how they actually operate. One good example: Uber published a post on AI prototyping and how it has helped their teams build more intuitive customer experiences at scale.
“By opening up prototyping across the company, we created space for more perspectives to shape solutions earlier.”
— Aayush Agrawal & Akanksha Sharma, PMs at Uber
Traditionally, a lot of product work gets slowed down because people are debating abstractions. A PM writes a doc. A designer interprets it one way. Engineering hears something slightly different. Leadership imagines another version. Customers may be reacting to something that is still mostly conceptual. That is how you end up with a very expensive game of telephone, where everyone thought they agreed, but the thing in their head was not actually the same thing.
A prototype can cut through a lot of that by giving people something tangible to react to. It can expose misunderstandings earlier, make tradeoffs more obvious, and help a team move from ‘what do we think?’ to ‘what are we learning?’ much faster. Every idea does not need to become a polished prototype, of course. And no, docs and PRDs are not dead. But being able to translate a problem, opportunity, or idea into something real — even a rough version of what it could become, or maybe should not become — can be immensely helpful.
As a practical takeaway, Aayush and Akanksha ended their post with a useful breakdown of the pitfalls, signs, and guardrails for AI prototyping.
On a related note, Linear's CEO Karri Saarinen wrote a good post about judgment:
“Even if you can, maybe you should not. (The) more power we have to build should not reduce our need to think, it should increase it.”
— Karri Saarinen, CEO at Linear
He wrote about how teams can start celebrating the wrong product metrics — like tokens burned or the number of prototypes produced — and lose sight of whether the work is actually good. That feels important because AI can help us produce more work, ship faster, and build better products, but users ultimately care about outcomes. Anyone who has ever paid for software, or spent meaningful time using software, wants some kind of problem solved or pain removed. Maybe it is ending boredom, connecting with others, saving time, reducing risk, or increasing ROI. There is always a job to be done.
As the bar goes up for what users are willing to use and pay for, the quality bar for builders has to go up too. Faster production does not automatically mean better product work. It does not automatically mean a better experience. And it definitely does not automatically mean faster outcomes. So we should be thoughtful about the metrics we track, the things we celebrate, and the quality of our decisions and judgment.
The advantage will not come solely from generating more artifacts or shipping endlessly. It will come from judgment, contextual critical thinking, the pursuit of truth, and giving users something deeply valuable.
2/ SaaS is under pressure, but far from dead
It would not be 2026 without speculation about the future of SaaS. From public market pressure to layoff announcements to SaaS conferences pivoting heavily toward AI, it sometimes feels like everyone is trying to decide whether we are watching a temporary correction or a deeper reset.
SaaS is not going away. Enterprises still need systems of record, sources of truth, dashboards, workflows, integrations, and trusted vendors. Procurement still matters. Trust still matters. Operational complexity still matters. But the market is clearly asking harder questions about what SaaS is worth, where future value will accrue, and whether the classic seat-based model that rode a huge wave through the 2010s and early 2020s should still be the default. Valuation assumptions are being reworked in real time.
As Rubén Domínguez Íbar pointed out, some of the companies that defined the last decade of enterprise software are down 50-90% from their peaks.
Within that context, Kyle Poyar made the point that SaaS companies still have structural advantages they need to use.
That is where I think it gets interesting for product leaders. The incumbents that win will not get away with simply adding AI features to existing workflows and calling it a strategy. They will have to revisit more fundamental questions: what should be redesigned, what should be automated, what should become cheaper, what should be priced differently, where the company actually has a data advantage, and where the product is still creating work for customers instead of removing it. In some ways, as cliché as it may sound, they will have to disrupt themselves before someone else does.
‘We already have the customers’ is not a moat by itself. It becomes a moat when you use that access to learn faster, ship better, rethink assumptions, and solve the next version of the problem before someone else does.
Amidst all of this, there is an incredible opportunity for AI-native startups to solve the next version of the problem, with the next version of the solution, before anyone else does.
And while incumbents figure that out, there is an obvious opportunity for AI-native startups to attack the next version of the problem with a different product, cost structure, and user experience. Just look at some of the requests for startups that YC published for Summer 2026: ‘Dynamic software interfaces,’ ‘SaaS challengers,’ and ‘Startups that want to sell to huge companies.’
Which brings me to the org side of this: if the product, pricing, workflow, and GTM assumptions are changing, the roles probably have to change too.
3/ The rise of hybrid builder-operators across Product and GTM
There has also been a lot of thinking recently around hybrid roles: AI Design Engineer, Marketing Engineer, Agentic Operator, GTM Engineer, and other titles that sit somewhere between product, design, engineering, marketing, ops, and systems. Some of these titles will not last. That is fine. The underlying shift seems real though.
A DesignWhine piece on the emerging AI Design Engineer role captured one version of this well: The role is not just about using AI to make screens, but about understanding how design decisions become product and implementation decisions.
“AI Design Engineer is not an ML role. It is not a UX researcher. It is not quite a design systems engineer in the traditional sense, though it overlaps with all three.”
— DesignWhine Editorial
This is not just happening in product and engineering circles. It is happening everywhere.
James Cadwallader, Co-Founder and CEO at Profound, has been making the case for a new role to the marketing org: The Marketing Engineer. Part-builder, part-strategist.
Hubspot’s Kieran Flanagan announced he’s ‘officially no longer a Marketer,’ and that they’re focused on rebuilding their GTM around AI.
Marvin Chow, Google VP of Consumer and AI Marketing, also commented on Marketing Engineers becoming an important hire as Marketing becomes more systems-driven.
“We’re seeing a convergence of product marketing, design, and engineering in real time -- integrated systems that represent the brand. The gap isn’t ‘who knows the tools.’ it’s ‘who can architect the system that makes them work together.’” — Marvin Chow
Adam Schoenfeld, CMO at Inflection.io, wrote that he’s planning on hiring a GTM Engineer (not a Marketing Engineer or a Sales Engineer). He also pointed to Ramp hiring for an ‘Agentic Operator, Growth Marketing,’ which is one of those job titles that serves an emerging need but sounds very odd.
The old organization rewarded people who could coordinate work across functions. That still matters, especially at scale. But coordination cannot compete with end-to-end value creation. In a world where small teams can build more, the premium shifts toward people who can actually make things happen.
Not everyone needs to become a full-stack engineer. But technical fluency will become more valuable across more roles. The most useful team members may be the ones who can see across the rapidly shifting boundaries. They can understand the customer, prioritize the right problems, design the workflow, build or orchestrate the first version, measure what happens, and keep improving without requiring a long chain of command.
That is why we are hearing so much about the AI-native builder. In the video below, Replit’s CEO Amjad Masad talks about why the people getting the most value from AI tools are often not traditional developers, but founders and domain experts closest to the problem.
Product leaders should be asking a simple question: where are we still organized for the old way of doing things? That question touches role responsibilities, career progression, hiring profiles, team structure, and how much clarity is needed as the lines between functions blur.
The challenge is that none of this removes the need to deliver. Teams still need to drive outputs, outcomes, and results. Expectations are only going up. But the way teams get there is changing. They will need to rethink what processes and structures are still necessary, where builders can own more end-to-end, and where judgment matters most.
