Modern Skill Stack — Real stories on how product professionals are keeping up with a constantly changing skills landscape. Hosted by Gene Kamenez, CEO of Uxcel.
Watch on YouTube.
Daniel Zherenkov is a Senior Product Manager for AI and ML at Delivery Hero, a company of around 70,000 people, working where data, machine learning and product strategy meet. Then one day he noticed something odd about his own setup. He was building AI products all day at work and had nothing of his own.
So he hired a team of agents. A coding agent, a product agent, a marketing agent, a researcher. He gave them a real product to build, an AI interview coach called Afterview, paid for the tokens and the ad budget himself, and watched what they did with it.
What I didn’t expect was where the hard part turned out to sit. The code wasn’t the problem, and neither was the prompting. It came down to guardrails, memory, and one firm line about which decisions he was never going to hand over.
You’ll learn:
Why the skill he is personally focused on is AI guardrails, and why that has little to do with cybersecurity
How he structured a team of agents (coding, product, marketing, research, design) around one real product
The three layers of agent memory, and the file-splitting habit that keeps them usable
Why he plans with an expensive model and builds with a cheap one
What happened when his marketing agent and his product agent independently reached the same pivot
His honest numbers, and his answer to feeling behind on AI
My biggest takeaways
The skill he is building is guardrails, and it has little to do with cybersecurity
We open every episode with the same question: what is the one skill you are personally focused on developing right now? Daniel’s answer was AI safety, and he separated it straight away from the kind of safety most people picture.
In Daniel’s words:
Safety for AI. And I don’t mean only technical safety, everything around cybersecurity. I mean safety nets and guardrails for when you hand AI over to wider usage, to colleagues, to your team, to users. You need to make sure every agent and every flow has very strict guardrails.
The reason this matters more at scale is simple arithmetic on the cost of a mistake. At Delivery Hero, he pointed out, AI isn’t confined to engineers. Operations, finance, back office, PMs, designers, analysts, all of them are using it. Every one of those people is a place where an unvalidated change can enter the system.
He used the Cloudflare outage as his example, and his read on it wasn’t the obvious one. A very visible failure, he argued, is close to a best case:
The worst case scenario is when you miss something and then you realize it only weeks or even months later. The bigger the company, the higher the stakes.
The action here is uncomfortable but clear. If you’re rolling AI out past your own desk, the question isn’t whether it produces good output. It’s whether you’d notice a bad one, and how long that would take.
He hired his agents like employees, then kept the final call for himself
The origin of the project was closer to curiosity than ambition. He wanted to know whether a setup could carry a product with him only supervising.
In Daniel’s words:
Can I build a setup that would relatively independently create a product with just my guidance? Can I hire AI agents like they were real employees, give them a task, follow the results and iterate? It was a completely experimental idea.
The framing works because of the boundary he drew at the start, and because it never moved:
AI can speed up our job and how we interact with each other. What it can’t replace is the final decision making. That’s been on us and it always will be on us.
You can see that boundary in the least glamorous part of the whole build. His marketing agent produced the campaign strategy, and he ran the Google Ads setup by hand, because he was spending his own money and wanted to see every change before it went live. In his experience there was no clean way to automate that platform, and he didn’t trust browser automation with his own budget. His description of his role in that loop is the line I keep coming back to: he was “just a human proxy service.”
The principle: delegate the work, but never the decision.
Two of his agents recommended the same pivot, independently
The most useful part of this story is the shape of it, not the headline.
His researcher agent had originally pointed him toward blue-collar roles, nurses, couriers, people working in the field, on the reasonable grounds that plenty of interview tools existed for tech and almost none for them. That’s where he started.
The data pointed somewhere else.
In Daniel’s words:
The marketing agent analyzed the data and figured out we have a lot of blue-collar workers. Then the product agent analyzed how people actually interact and engage with the product. After months of performance data, both agents, the marketing one and the product one, agreed independently of each other, and I agreed: we need to pivot. Most of our users are IT folks.
Two agents were looking at different slices of the same business, one at ad performance and one at product engagement, and they landed on the same recommendation without coordinating. He agreed and refocused on IT roles: software engineers, data analysts, product managers, designers, site reliability engineers.
One detail stops this from being a story about agents replacing product work. When his product agent wanted user research, it asked him to go and do it. He made the calls himself, and those conversations are part of what confirmed the pivot. The agent could see the pattern. It couldn’t go and ask a human why.
Memory in layers is how he stops agents losing the thread
I asked him about the thing people run into after the exciting first build: maintenance. Context gets lost, features get duplicated, the agent forgets what it did last week. His answer started with memory, and it was more structured than I expected.
This is how Daniel describes the setup:
You have a few layers of memory in Claude, and it’s the same for most LLM agents nowadays. You have the project one, you have the global one on your local machine, and you have the fundamental one the model always checks first.
Underneath those layers he keeps one shared store that any agent can read. The part worth copying is that it isn’t tied to a single vendor. Claude, Perplexity and Gemini all read and write to the same place, which stops standalone tools from starting cold every time. He also instructs agents to write back to that store when a session ends, rather than hoping he remembers to ask.
Then the small habit that makes the whole thing survivable:
A tiny life hack: don’t store everything in one file. If the file gets too gigantic, tens of thousands of rows, it gets tough for the model to digest. Better to split it by category, by logic, or even by time.
He splits Afterview’s memory by topic, product, marketing, and the interview engine. At Delivery Hero, where a single week generates more context than that, he splits by date instead. Pick your axis, topic or time, before the file gets too big to fix.
The expensive model plans, the cheap model builds
The cost question comes up with every agent setup, and his answer is a division of labor between models rather than a compromise on quality.
This is how Daniel describes this:
I use a setup with a more sophisticated model for coming up with the plan and the ideas. I generate the plan with Opus, especially if I want to implement something difficult or tricky or with a lot of layers, and then hand it over to Sonnet, because Sonnet is way cheaper. Opus also acts as another layer of guidance.
Paired with that is a habit he was firm about, and it costs nothing to adopt:
I know some people ignore plan mode. Plan mode saves a lot of tokens, and it helps you validate, because in some cases the model proposes something redundant. Not wrong technically, but a duplicate of a feature you already have.
Two things happen when the plan comes before the work. You spend fewer tokens, and you get a chance to catch the redundant build before it exists. That second one answers the maintenance complaint people have, one step earlier than they usually look for it.
He goes further and challenges the plan a second time before anything gets written. Plan, then question the plan, then build.
He was equally direct about the parts he can’t do himself. He’s not a designer, so he connected Claude Design to his GitHub repo and let it build a design system. I’ve built design systems the slow way, and the result he showed on the call was better than I expected, real components with sensible spacing and radius values, plus a technical handoff written for the coding agent to follow.
The gap between LinkedIn and reality is total
We ended on the anxiety, because he had just been speaking about it at a few events and had a blunt answer ready.
In Daniel’s words:
It might look scary when you look at LinkedIn. Everyone is building something and you feel so far behind. It’s not true. Trust me. The gap between LinkedIn reality and our reality is total, they don’t intersect at all. If you want to stop feeling anxious and behind, just give it a try. And if you don’t know how to approach it, ask AI. It’s already at the step where it can suggest how.
His own numbers back up the modesty. At the time we spoke the paying subscribers were still a small crowd, set against a few thousand euros of ad budget and his own time. He was clear that he isn’t earning thousands of euros from it yet, and equally clear that the experiment was worth it.
There’s a good answer here to the blank page problem, and designers will recognize it. People tell him they want to build something but have no idea what. His response is that you don’t need to arrive with the idea. Open the conversation, say you want to build something and don’t know what, and let it ask you questions about your own experience until something surfaces.
The principle worth taking: the entry cost of trying is now low enough that being behind is mostly a story you’re telling yourself.
Episode timestamps
01:41 AI guardrails, not cybersecurity
05:24 Learning a skill with no curriculum
07:08 Career path into AI product work
14:02 Why he built Afterview
34:51 Weekly product analysis agent, demo
43:30 Three layers of agent memory
48:44 Staying the initiator and facilitator
A note from Gene
I started Uxcel because I knew what it was like to want to level up with no affordable way to do it. When I started designing, the real options were courses that meant getting on a plane, or bootcamps at five to ten grand.
That gap hasn’t closed, it moved. Daniel graduated in economics, then taught himself Python and SQL so he could talk to his data team properly. He isn’t a designer, and he still shipped a working design system. Nobody handed him a curriculum for either one, because there isn’t one yet for most of this.
That’s the part I keep coming back to. AI is widening what a single product person is expected to do, and it’s moving faster than anyone can write courses for it.
If you’re a designer or PM trying to close gaps across UX, product and AI, we’d love to help.
Resources mentioned
Tools
Claude, including Claude Code, Claude Skills and Claude Design (anthropic.com)
Claude Opus for planning, Claude Sonnet for execution
Perplexity, for market and competitor research (perplexity.ai)
Gemini and Nano Banana, for image generation (gemini.google.com)
VS Code (code.visualstudio.com)
Google Ads (ads.google.com)
GitHub (github.com)
Frameworks
The STAR framework, for structuring interview answers
Companies and products
Afterview, Daniel’s AI interview coach: afterview.ai
Delivery Hero (deliveryhero.com)
Where to find Daniel
LinkedIn: Daniel Zherenkov
Afterview: afterview.ai
One question before you go: if you handed an agent something that mattered tomorrow, would you notice when it got it wrong, or would you find out months later?
Cheers,
Gene
