Transcript: In 2026: Fewer Engineers, More Product Managers - Daniel Marcous (April)

Meet Daniel and April (Calcalist's 50 most promising startups)

Eyal David: [00:00] Daniel, what's up? Good, thanks, how are you? Excellent. I'm not going to the port after this, there's an event there.

Daniel Marcous: [00:08] Too bad, too bad, we could share a cab. Do you want to say for a second why you're going? In a word? Yes, so April was recognized by Calcalist, we were selected for the list of Israel's 50 most promising startups in the latest Independence Day issue, and there's an event to celebrate it. It's very nice. All the parents of all the employees at the company are very, very proud.

Eyal David: [00:33] Wow, congratulations first of all. Thank you, thank you very much. So we'll say you came from April, and you're actually one of the two founders, right? Very much so. Excellent. So I want to start with what you told me. You told me how you used vibe coding to basically overcome some bottleneck you had, right? Tell us about that for a second?

DIY vs. human in the loop in the tax world

Daniel Marcous: [00:54] Yes, sure. Let me give a bit of context. April is a suite of tax tools: for American citizens, we create a kind of virtual accountant that does everything from tax planning to tax optimization to tax filing. So it basically handles everything tax-related for you. Now, in that same app, which already has millions of users, we have a few flavors, and for this painful, terrible event that happens once a year and is mandatory in the United States, called tax filing, we have the app that's 100% DIY. Meaning you go into the app, fill in your details in a flow with minimal friction, click submit at the end, and of course we calculate everything behind the scenes and file it for you with the IRS and all the states. But there's another flavor, with a human in the loop, an accountant, OK? Who either does some review for you or actually helps prepare your taxes for you. Because overall there's still a very, very large part of the population that wants that trust and that human, to see a person's face and talk to them, and so on. Now, last season, rich people's problems basically, but we ran into a bigger scale than we'd prepared for, and when we looked at the metrics and the funnels, we started to understand that we had bottlenecks in the pipeline of those accountants who review users' taxes. Especially since suddenly there were users we didn't expect to use this tier, with complexity, where suddenly someone comes and uploads 40 different documents. Like, go review that. It's a service that would cost thousands of dollars if the person did it somewhere outside, and in our tier it was, in most cases, a few dozen dollars. Now, we concluded right then that we had to come up with creative solutions to solve this issue, and we had a lot of preliminary materials. We had our deterministic tax engine, which knows how to do all kinds of tax calculations, take numbers and produce outputs. We had checklists of exactly what a reviewer, an accountant, is supposed to look for in a review, and we had data from hundreds of users who had already done it. So we had both the inputs and the outputs of what an accountant would say, and we decided to do a kind of blitz, basically a weekend hackathon: let's try a new approach, fully agentic, 100% vibe coding, writing an agent that does the preliminary review. It takes all of the user's documents, all the data, uses our tax engine, runs that whole checklist, finds things like omissions, meaning things the user may have missed, missing items, answers the user's questions, which sometimes come in advance, and does all kinds of things, even somewhat more complex ones, like comparing whether you should take what's called the standard deduction or the itemized deduction, something super... I killed you right at the start, yes, OK. So in the end, after a very packed weekend, we got to Monday with this system live. To the accountants: yalla, use this, run it. We got the feedback, did super fast iterations, mainly on the prompts, within two days, and after two days we said, OK, excellent, all the accountants are now moving from this product to another product that really needs to do the preparation for users, and this product becomes, basically, 99% AI. It worked amazingly, it was an exciting experience.

The bottleneck that blew up on us last tax season

The weekend we built an agent with vibe coding and made the review 99% AI

Eyal David: [04:49] OK, so from here we get two things. Just long story short, we've already explained what you do; your name also represents the deadline for filing the documents in April, the return, it's a tax return, if we translate it to Hebrew, do I understand correctly? Exactly. And you had a bottleneck, the humans couldn't go through all this content fast enough, so you brought in a component you built with vibe coding that simplified the whole thing, and that leads us to a few things that come up. The main thing: when we spoke in the prep call, you told me, we talked about your growth plan, or your hiring going forward, and you told me, listen, right now I need fewer developers, I need more product people. Let's add an asterisk here, maybe even juniors, maybe there's an opportunity here. There's also the other school of thought: hey, why not more developers to produce more? So explain that a bit. And the second thing I was thinking about, and I'd be happy if you tell us too, is what's your process today between a product idea and an experiment and launch? Because you did this really fast, so I'll sum up... Right, it's not an entirely standard case. Spot on. We have other cases,

The PM-to-engineer ratio has changed: 1:10 no longer holds

Daniel Marcous: [06:01] or let's say, the best-practice process, which sometimes we follow and sometimes we don't, as every startup needs to; the main thing is being explicit about when you're cutting corners and when you're not. So wait, let me go back to your first question, about hiring. So yes, we do have open positions today across the board, both engineering and product, but yes, in recent months a somewhat deeper understanding hit me, that the ratio between, let's call them, builders who aren't engineering, meaning product managers and designers, and for us designers means product designers, someone who does everything from UX research to the finalized Figma, not just someone who moves pixels around, it's really everything, versus the number of engineers needs to change. Personally I was in a very extreme school, where the ratio of PMs to engineers at our company was about 1 to 10, OK, and at some point I was alone as the only PM with 20 developers, and gradually we're starting to change that, and we also see the trend that it's become much harder for PMs to keep up with engineering's pace as velocity gets faster, mainly because of AI tools that came in over the last few years and simply get dramatically better month over month. It just doesn't stop, velocity only goes up, to the point that I really understand that my next bottleneck is going to be product managers who can't produce precise requirements fast enough for what needs to be done, and I'll have an engineering team sitting idle and working on, say, technical debt, God forbid,

Engineering velocity grows 1.3-1.5x: what it means for R&D

Eyal David: [08:01] instead of product features. Yes, so I have to ask, do you think this is representative, or is it something that maybe represents your product, because you went through a certain technical journey, a very large technical debt you needed in order to stand up infra,

Daniel Marcous: [08:15] and now you're in that place all the more so, or is it, what do you think? I think we ran into it a bit faster, partly because we maybe did things a bit more orderly and precisely, and all kinds of infra changes for scalability, so now we're a bit less bound to it and run faster, but the trend is unequivocally there. Every founder I talk to talks about how velocity in engineering is growing, and you see it everywhere, to the point that when I now plan a roadmap for the next year ahead, say a year, plus or minus a year, I like to plan, because our business is really strange, and taxes are very seasonal, filing is once a year, so we really do one massive planning round a year. I'm planning that for the coming year, the velocity of my engineering group should be between 1.3x and 1.5x what it has been historically up to today. Given the linear rise in velocity, and how I see things progressing, and how I see tool adoption getting stronger and stronger, I understand the bottleneck is moving somewhere else. Now, I already see these bottlenecks forming in product in all kinds of specific nuances, in certain sprints, every so often, where suddenly it's a bit harder, and you see the tickets are a bit less precise, and the engineers, let's say, have more freedom to invent. You know, on one hand it's nice that once in a while there's a slightly freer sprint, but on the other hand it's a trend. And to solve that problem you need to do some rebalancing in the organization. And the more you do these things, the more extreme the practices of how the organization works, the more I see the balance shifting. So for example, things we did even in the last two months or so: we did a super serious double-down after the last war with Iran. Expand, what does that mean? A lot of the engineering team in Israel couldn't really work, and we were a stone's throw from tax season, so we said, OK, creative solutions now. So 1, we double down on vibe coding; 2, let's invest for a moment. Basically for me, as a founder I don't really have the privilege of being with my family at a time like this, and I need to think about the solution for April 15, and with the VP R&D, who's in the US, we did some brainstorming, a hackathon, on how we improve our agentic coding capabilities in the organization, and we built a multi-agent system with Cursor that has a software architect, a software engineer, QA, automation and test engineer, product manager, designer and so on, to boost velocity for the next few weeks. It worked much, much better than we could have expected. We try to make that kind of leap once every six months, and you know, sometimes it works, sometimes it doesn't. It depends on the technology, when it's there and when it isn't.

How the Iran war became a catalyst for the next leap

A brainstorm/hackathon every six months

Eyal David: [11:43] Wait, wait, wait, wait, one second, let's park, because you ran, wow. Maybe it's lucky that... not lucky, but the fact that there was a war basically pushed us. Totally, it pushed us into a corner, and with your back to the wall you find creative solutions. Right, but you ran through it really fast, let's park there for a moment. OK, there's a war, and tax season is really coming, so what were the other bets you could have taken in that situation?

April's B2B2C business model and the pressure of tax season

Daniel Marcous: [12:07] What else was on the table? I didn't say this before, but our business model, our go-to-market model, is B2B2C, OK? So I don't approach you directly as a customer of my app, I approach financial institutions, and I sign deals with them months to years in advance, for a certain number of users they'll bring, to whom I'll provide that product/service of tax filing, optimization and so on. Now, a war breaks out at the end of February, which is already inside tax season. I'm already live with all these customers, I can't stop serving them, and for some of them at least, you know, it's not the worst; it could have happened in December, before the season starts in January, that would have been terrible. Terrible. Because then they wouldn't have uploaded materials, right? Yes, and then we wouldn't have been able to meet our launch commitments, but this was already after the launches, and we had extra commitments, for all kinds of features where we said, OK, yes, we'll do this for you during the season in March, or before the April 15 peak, which is the deadline, and everyone likes to do things at the deadline, because everyone's human in the end, so we're launching another such-and-such feature. One option was to not meet the commitments, go to our customers, apologize, tell some sad story with a few tears: yes, our whole engineering team is in Israel, and there's no choice, and so on, and we'll compensate you. And another option was to try to find a creative solution, OK? Let's put it this way: nothing would have broken, it's not like the app would have gone down or something, everything worked, and we had more commitments that we couldn't deliver without a working engineering team for that period.

Eyal David: [13:52] And then, OK, there were probably more options around it, but OK, you decided to go this way. So how did you scope it, how did you actually build this team, and what did it look like?

Building a multi-agent team: architect, engineer, QA, PM, designer

Daniel Marcous: [14:02] Uh... so... how do you even define success for something like this? Because it's completely opportunistic. Excellent question. It's completely opportunistic. We like doing these moonshots every few months, to try things, to take the technology to the max, and we hang around on Twitter and see people doing things like this around the world. Simply not relying on miracles. Yalla, we don't overthink, we just do it, and while doing it we look at best practices and also do our own independent research, the VP R&D and me. I see these practices, he sees those, and we run them, and we test them on real features. So that same week, basically, plus or minus, the VP R&D and I delivered a sprint of almost a full team,

Eyal David: [14:49] just the two of you. How does that work? You basically define scope. Define scope. And then meet them at the end? What does it look like?

Daniel Marcous: [14:57] And we ran on it with a method of, OK, here are the things we're more confident can be done with vibe coding. Ah, OK. Let's start with those, let's start with the easy things. A UI change: this doesn't look good in dark mode, this needs to move to the side, easy. This button doesn't work? A bit harder, OK? You need to understand what this button does. A whole document management feature, OK, wow. Let's try that, let's stop here. It also has a public API, it also needs a webhook, all kinds of other things. Let's see how we do. And during these iterations, every time, like, what's critical in everything you do with vibe coding, as you iterate, OK? As you build something, is to look at the reasoning with tweezers. OK? Every tool you work with today can show you its thoughts as it goes, the reasoning, to see exactly what it's thinking, what it's doing, and it explains brilliantly why. Read every line, don't miss anything. It's much, much more important to read the reasoning than the code it produces at the end, OK? See the reasoning and see why it made certain decisions, and basically what you need to understand from it is what context it was missing. When it makes a wrong decision, stop for a second and understand why. And sometimes, even when you don't understand why it made a decision, the best iterations with agents are to ask them: wait, I see you wrote this and that, why did you do this and not that? And then it tells you, and you iterate from there. And every time you grow it and add and add another agent to this team, and iterate on whether something should be a skill instead of an agent. And this is a bit funny too, but you're basically building the multi-agent vibe-coding system with vibe coding, because who am I to know whether this would be best for Cursor with Opus 4.6 as a skill or as an agent?

Eyal David: [16:48] So I'll ask it and it'll tell me, of course. So that's what I was trying to understand, how active the two of you actually were in this whole thing,

Daniel Marcous: [16:55] and what counted as success? Was it a week? How did you define it? It was a week of us doing a blitz from 0 to a working system where we could develop features, and then another two weeks of iterations while developing real features. So you were on it, you were on it at full capacity. Yes, it was pretty much full capacity, and it was exactly that first week of the war, when everyone dropped to almost 0 capacity to regroup. So we used that to go up to 100% capacity on one moonshot or another. Now the obvious question is, what does it mean?

The real cost: $1,000-$2,000 a month per power user

Eyal David: [17:33] Excellent question. So once you have something like this that works, and does a good job, OK? Then the question is, how much does it cost? How much does it cost? Like, relatively, significantly, like no, significantly you can now run

How to work on 3 features in parallel

Daniel Marcous: [17:50] hundreds of teams like that. Right. Listen, it's not, because at the end of the day you're a person. As of today, at least the way we use it, you're a person using that team of agents, and when you use a team of agents you look at the reasoning, and at the end you sometimes do some code review, see what's happening. It's not like you're running ten such teams in parallel on all ten of my biggest features. You do roughly three in parallel, which is also an interesting concept about how we work now. You don't work on one ticket or one feature, you work on three in parallel, because while this agent is working, what will I do? You have ADHD, and I'll answer that anyway, fine, OK. So you work on about three in parallel, and you iterate, and every time it finishes an iteration you need to make changes, and you need to think, and it takes you much longer to write prompts, so the nature of the work changes. But basically, someone who really doubles down on it, hammers the system for a month, comes out between 1,000 and 2,000 dollars a month; someone who works with it here and there, 500; someone who barely does, 100 dollars. OK? And my expectation is that if everyone works in the 1,000 to 2,000 range, overall the ROI they generate is so much bigger than it was before that I'm happy to pay it for the velocity impact.

Eyal David: [19:09] Exactly, no, so that's where I'm taking it. Fine, the specific dollar sign doesn't interest me, but basically at the end of that week you come out with an understanding that, OK, there's obviously a future here, but there's a future here that fits us. Very true. And then, again, if there are hundreds of such teams you can run, how many people are you today in development, including product? We're around 30, including product and design. So you have an understanding that, OK, anyone who has domain understanding, what shall we call it, project understanding, to,

Daniel Marcous: [19:39] can run, say, three features in parallel, for example? Yes. Three teams? Yes. And now the question is, what do you assign to whom? Exactly, that's where I'm thinking. An engineer is a domain engineer, right? They have very, very high technical abilities, they know how to write code. At the end of the day, in a system, especially in taxes where I deal with financial data, I need everything to be deterministic, I need everything to be tested and go through QA, at least as of today, before it goes into production, OK? So the complex features go to engineering. I expect engineers to use that same multi-agent vibe-coding system to produce a baseline, always, OK? And iterate from there. Those iterations can be 100% vibe coding in some cases, and they can not be. It depends on the complexity of the feature, and a lot of the time what you learn from it, especially if it didn't work well, is what I need to change in the agents and what context was missing. Because overall there are almost no cases where all the context is there and it doesn't work well. Most cases are simply missing context. But there's another type of features, changes and fixes, where suddenly I say, I can hand them 100% to product managers, to designers, and even more than that, to other builders in the organization. A few examples. The obvious one for product managers is data analysis, OK? Understanding why something works this way and not that way, and how many people use it, and the MCP behind the scenes connects to my BigQuery, runs the queries and so on, produces the charts, research. How the code looks and how it works, like what this thing does, and when it returns this answer and not that one; suddenly PMs are no longer bound to engineers to give them answers, OK? Planning sprints ahead, and small features, for example features that are mainly user-experience oriented. For example, we said this doesn't flow smoothly enough, or here we understood, we had a thing with document management where we realized there was a use case we hadn't thought of in advance: users want to view all their documents one after another, OK? And the way to do that in our system was to open one, click x, open the next, click x. So we added next and previous arrows, exactly that kind of circulation like the LinkedIn carousel. 100% vibe coded, a small feature, super simple, a PM does it end to end, and the same for the design team. Every time they see some mismatch in the design, something they thought would work a certain way, but when they see it live, it doesn't work well, they can do it with 100% vibe coding. They do it, and the 100% vibe coding is so simple that you do it through Slack: in Slack you tag, in our case, Cursor, you tell it roughly what you want, you can give it a link to Figma or to a ticket if there is one, and within a few minutes you get a live environment you can click on and get a remote desktop where this thing is running, and see it live, whether it really worked or not.

What PMs can now do on their own: data analysis, sprint planning

How CS and Finance at April build apps too

Making sure PMs don't build gilded balconies

Eyal David: [22:52] That's how I edit podcast episodes, by the way. I have a real question: how do you keep your finger on the pulse, so that employees don't take this ability and build, as they say, gilded balconies, and you still manage to get the important things moving? Because it's much easier to go to those places, right? For example, I could take this team, this team you just gave me, and build all kinds of extra polish with it, add navigation to carousels, all kinds of things like that, or I could go now and dig into the things that really move the needle.

Daniel Marcous: [23:30] How do you keep your finger on the pulse, do you measure it somehow? So totally, the PM's role, of course, is to prioritize which feature will move the needle, right? And what needs to be worked on. And what goes into Linear and the roadmap and the next sprints should really be the tickets that matter. And given the velocity, we're back again to the same cycle of the problem: engineers suddenly became faster, they can run on everything, and then there's more work left for product to understand what really matters, to build a bigger pool of tasks, because you can run on more tasks. And more than that, if you really take to the extreme this understanding that suddenly we're running faster and can run on many more features, then strategically too, a lot of the time you want to think differently. A PM, instead of prioritizing as aggressively as was customary until now, can say, OK, wait, instead of doing some small A/B test on copy 1 versus 2, I'll create five variants, and they won't just be copy or color, they'll be genuinely different behavior, and there's no problem running with them, and then I'll be a thousand percent sure, because it'll be in production, what really works better. So strategically it becomes different too. So I'll take that question somewhere else.

From an A/B test of 2 variants to 5 complete variants

Eyal David: [24:57] Now it also becomes, again, improving your existing product versus making new bets.

Daniel Marcous: [25:03] Right. How do you prioritize between them? Wow, that's always a really, really hard question. So look, we do try, like every company I think, to look at all kinds of product-market-fit indicators in existing products, to understand whether you keep prioritizing things in an existing product, or move to new bets, or new segments, and so on. And then the product-market-fit indicators, there are all kinds. There's the NPS score, there's your conversion in your product versus competitors, there's that classic question of how you'd feel if you lost this product, and so on. And we always try to run these things in parallel, to put some cap on it and also see the pace of progress, to see whether we're hitting glass ceilings in certain places or not, and move on. But yes, as a founder of the company, I'm much more open to bets in a world like today's. Especially when I see that after an hour of vibe coding, suddenly I produce something that makes an impact in production.

Eyal David: [26:09] My mindset is totally changing. Because it's not just you, it's your competitors, and is everyone running like this in this world, the tax world, what does it look like? No, not at all. A super old-fashioned world,

Why the US tax market is a 30-year monopoly

Daniel Marcous: [26:25] it's very centralized. There's a monopoly in the US, Intuit's TurboTax, which controls between 70% and 80%, depending on how you count, of the market in this space, and precisely because of the regulatory and logistical barrier that comes from that, getting licenses to file taxes in all the different states, every state in the US has a different tax law, there's basically a huge barrier to entry that not many companies are interested in or aspire to cross. So we made a decision when we founded the company, which we laugh about, that it's really, really lucky we didn't know how complicated it was going to be: we'll go for it, and now is the time to disrupt an industry that hasn't seen innovation in 30 years. We're fairly ahead of the industry in this way of thinking and working, but there are definitely buds you can see, all kinds of new startups trying to do mainly, let's call it, analysis with AI. Taking data that already exists somewhere else, without regulatory barriers, without trying to calculate or file the taxes, just doing analysis on top. That gives some piece of the pie, and that's good and cool, but we really believe in our ability to be uniquely positioned, to do the... really the full cycle of everything related to taxes, because we have both the rails and the capabilities to do the AI analysis,

Eyal David: [27:59] and also the user experience and so on. And the agreements you mentioned, and the human in the loop, the accountant, so that gives all the... OK, maybe we'll come back to that. So yes, I want to take this somewhere for a second. OK, we started, you started pointing out skills that are important to you when you hire people, right? When you build your team. Let's tighten them up for a moment. Can you go back to them? Yes, sure. So something that used to be said a lot... Actually, maybe you can tell it through your story with Yonatan,

Vibe coding with Yonatan (Jon-Jon), age 5.5

Daniel Marcous: [28:32] and then... with joy, with joy, yes. So let me put it this way, I have a son, a sweetie, named Yonatan, or Jon-Jon. Today he's five and a half, not exactly today, today, around now. And a few months ago we started doing, every weekend, a project of about an hour together where we do vibe coding, OK? Now, it started from a small idea: OK, let's build a game together. Let's do something cool. He started getting excited about games, he'd just gotten a Nintendo for his birthday, and we said, we can build a game. Let's make a game too. We tried the first time, spent around two hours trying to build a game he imagined in his head, with a bird walking between castles, with 3D and stuff, with Unity, with 3D and so on. We did it with Cursor, and it was an awful failure. We used a lot of vibe coding and a lot of tips to write the code, but on a super complex platform, with very slow iterations and a lot of configuration. I should mention that my kid at least, a five-and-a-half-year-old Israeli, can't read or write English. Meaning every time we need to do these iterations, I have to explain to him exactly what I'm doing. Wait, OK, now I need to configure exactly the boundary of the world and blah blah blah. It didn't work, OK, we dropped it for a month or so, then we came back and said, let's pivot, a completely new approach, we'll look for something with a much lower barrier to entry, much, much simpler, and we'll do it in very small, slow iterations. We did a session together of a kind of ideation: tell me about the game, tell me, I want the bird, OK, the bird will be like this, and what will be in the world, and this, and I want there to be bad guys, and I want to be able to hit them, and I want to be able to jump. OK, fine, I understand all the things. Let's start slowly, let's do a bird that can walk. OK, one thing led to another and we got to Google AI Studio, an amazing product for vibe coding with kids, really, because it doesn't expose the code that much. It's not code-forward, it's prompt-forward and UI-forward. Amazing for games: you have a small prompt window and a huge UI window where you can see the games live, and it really makes the changes for you live. We did one prompt, and within two minutes we had this product with Karkara the Eagle, that's the name of Jon-Jon's character, that he could play, and along the way Jon-Jon said, OK, now let's add bad guys, now let's add this, and slowly we started iterating. We started prioritizing. Jon-Jon started spotting the bugs, that suddenly the bad guys walk crooked, or suddenly we walk through walls, things like that, and Jon-Jon suddenly started to understand that if we add too many things and give it a really big prompt, it suddenly breaks other things. Then I tried to teach him the concept of regression, that something that already worked suddenly doesn't work now, and what works well, and then we learned to do smaller iterations, and we learned to spot these things. And it's fun. So let's, let's do it, I'm also looking at the pictures as we go,

Eyal David: [32:06] the first game was amazing, and then graphically things deteriorate, but they look more complete. So no, let's wrap it up, but one second, really. So it's a parable, a parable, it's really an example of, in the end, a learning process of working with agents, but at a very basic level. Come on, but take it now and really connect it to what you're looking for. How you see your staff at the company. Totally. So a lot of the things about that

What a builder mindset is, and how to spot it

Daniel Marcous: [32:37] barrier to entry into this world of vibe coding, how to do things with vibe coding, how to make an impact and how to create products that really work, are a barrier to entry that isn't very technological at its core, but much more related to a builder character, a builder's view, and a lot of the time, from what I see, to the courage to cross that entry barrier. There are a lot of excuses: wait, I'm not technical enough, I can't read code, I don't know how to install things on my computer. All these are barriers that can be removed very, very easily. Once you have the courage and the motivation and that fire of I want to create something, and I want to make it relevant, and I want to solve a real and relevant problem, OK? Then that leads to the skills I really like finding in people who do things like this, in the people I hire at April: people who are generalists, OK? That was always customary, but people who are really comfortable doing everything, and people who love pushing things forward. And once you give such people the ability to suddenly push something forward end to end, without getting stuck in red tape and bottlenecks of other people in the organization, suddenly you see the 10x velocity and the crazy impact. And people who know how to identify problems and think creatively about how to solve them, even if they're not very technical, even if they don't know the solution in advance, but they identify the problem well, and they know how to consult with their favorite agent, whether it's Claude or whatever, on how to solve the problem and what to do, and how to access the organization's tools and solve it. Suddenly you see things manage to progress and reach production, once you have that builder mentality, and someone who really has ownership of things. And it's to the point that I see... I see people with these skills at April in all kinds of groups that aren't just engineering or product or design. We have customer success and we have finance, where there are people who built end-to-end vibe-coded apps for amazing things, with Slack bots and with dashboards that connect to our stuff and replace all kinds of other tools, and we actually created a path for them for how they bring these apps to production. With a DevOps-style path: here's a system prompt, and here's the path for how we put vibe-coded apps into production,

Eyal David: [35:19] and they use it and do their work ten times more efficiently. Wow, so first of all, yes, that's very impressive, the last part in particular, I don't hear about many companies like that right now. But basically what you answered for us is, A, what a builder is, and what I hear along the way are more things you didn't say. Beyond a good understanding of the problem and running forward, there's stubbornness here, a bit like Jon-Jon sat there, really sat on his butt and waited, waited, waited until he got the result and polished it a bit more and a bit more and a bit more. There's a matter of taking ownership, again, walking through walls, you called it, I think, or that's how I heard it, really making the thing happen.

Daniel Marcous: [36:05] And also creativity that you need to be very careful not to extinguish. In kids of course, but also my first reaction, when someone from finance suddenly builds a vibe-coded app and asks me for access to data from BigQuery, is: oh no. And if so, OK, I'll do it, now I need to invest more time to do some code review on... So you need to be very careful not to extinguish this creativity, to give it room and simply channel it into some path you create for it, like the path we created for non-engineers to bring vibe-coded apps from zero to production, with a certain blast radius and in a certain form, and guide them to work in a certain way. And these people really take it, because they want to make an impact, and they want to work, and they love it, and the super fast iterations you can do, really seeing your things take shape in the vibe-coding world, is something very appealing,

The danger of gatekeepers and why you need to let go

Eyal David: [37:06] to the point that it's almost addictive. They call it god mode in all kinds of places on Twitter. But there's another thing here, I think. Obviously it's also managing agents, but I hear there's some soft skills involved here too. Right. I need to come and present my request in a certain way, and persuade people who are basically gatekeepers and all kinds of things, right?

Daniel Marcous: [37:27] Yes. I need to persuade with my story, I need to. Yes, yes, unequivocally. And to disconnect from that mentality of gatekeepers and red tape in the organization to some extent, and letting go is something that's very hard, because there's basically a spectrum there. Obviously you can't do it 100%, because you don't want chaos and you don't want these things to bite you back later. On the other hand, if you don't let go, you stop the velocity and you stop the innovation, so you need to find where you are on the spectrum, for each organization, where it's comfortable, and that's not easy. Especially for me, since my role in the past, before April, at Waze/Google, was that I set up a CTO office there with the VP R&D and so on, and my role was to be the gatekeeper of everything related to technology. I was the person who had to say no to everything. So suddenly my role here, as a startup CTO, is the complete opposite. It's to silence the people who say no and push forward, and yes, we will figure out later how to scale it. That's exactly the soft skill you need to apply here, I think.

What a PM job interview at April looks like

Eyal David: [38:38] OK, so for a second I just want us to touch on: when you interview people now, what do interviews look like? What are you looking for? How do you notice those sparks or those abilities? What does it look like?

Daniel Marcous: [38:51] So we have several interviews, and of course it depends on the role, the interviews are a bit different for each... OK, let's go in the direction of PM, R&D, something like that, OK? Totally, yes.

Eyal David: [39:01] So at the beginning we have a PM interview that's more product-focused. You know what, sorry, let me ask again. Yes. Do you even have open positions for builders?

Daniel Marcous: [39:13] Is there such a thing? We have them, but they're positions like PM, designer, engineer and so on. OK, so then it's still split by track. It's still split, yes. It's just that the expectation is for the work within the role to be much more holistic, OK? That a PM doesn't just, say, produce tickets and a roadmap, but does more than that, and a designer doesn't just receive a PRD from the PM and produce a Figma, but does more than that, and an engineer doesn't just receive perfectly done, ready tickets and produce code. OK, we're pulling every role much further toward the edge and much more toward the other roles, to break down those walls. And the ways to find these skills, which of course, you know, if I had a magic crystal ability to see a person in an interview and say whether they have it or not, I'd be somewhere else right now. But the indicators or proxies I like to look for are giving people problems and seeing how they approach solving them. There are versions of this in engineering too, something more like an architecture interview, and for PMs with product sense. A lot of the time what I do in a product sense interview is try to give a problem about some existing product and see how the person thinks, but to solve it, not invent a new product from scratch, because then it's harder for me to talk about walls and how you get through those walls. And while the person tries to solve the problems, I keep piling on more difficulties. OK, I say, and now the requirements changed and the scale is 10x, and now the requirements changed and the users behave like this, and now I don't understand why, but the metric is like this. And seeing what creative solutions, how people think about the problems. And something I love most to see in interviews, and it's super rare, is people questioning the very identification of the problem, the initial solution I gave them, and so on. That's super rare, but wow, it's amazing to me if I see someone trying to understand completely. That's what you do in most of the work with an LLM, that's what you do. Totally, totally. So I'm trying to understand,

Eyal David: [41:40] so the interviews are basically as I imagine them, like what I'm familiar with. And what you're basically saying is, fine, it's still split into the existing roles, blah blah blah. Today the expectation, you said, is more from them. So basically the expectation from the candidates is to be closer, to be closer to showing something real. Taking a bigger bite, you said: if it's a designer, maybe they'll build some prototype, or a product person who will produce some prototype probably. I'm going there for a second. But the expectation in a year or two will be completely different, much more around what you did that week.

Daniel Marcous: [42:23] Very likely. I try not to, you know, be presumptuous and claim to know where the technology is going, but if the pace continues, Elon Musk said it, yes, but... fine, not allowed. If the pace continues as it is now, the timelines keep shrinking, the quality keeps rising, and the path from an idea to production keeps getting shorter, and that idea can also reach production at very high quality. It doesn't have to be something scrappy that doesn't work and can't scale, but at the level where from a few sentences and the right context you can get to a feature in production. And then the strategic view of what a startup should do, how to prioritize, how to build a roadmap, how many things we run in parallel, what my moat is as a startup, because four years of code is nothing. Yes, for you I think it's fine. Knock on wood, well, every moat. Taxes, I don't know, yes, like that. Taxes aren't going anywhere, it seems. We have a huge logo in the office of "The only thing certain in life", a saying from long ago, "The only thing certain in life is death and taxes". We have "death" crossed out, and it says tech and taxes. Cute. It's not going anywhere, and there's the moat of regulation, which suddenly became a much, much stronger moat, where there are a lot of humans involved in how you get through regulation with those humans and with the connections and so on. But the moat of code is already something that doesn't exist, and then innovation and ideation and reinventing yourself and thinking about the next best thing, when everyone can bring the next best thing to production in a week, suddenly becomes much, much more essential. And that's something you see much more in PMs, that creativity and very, very deep understanding of the users and the problem in order to find the solution, than in engineers, and that's another reason the ratio between PMs and engineers is changing. Excellent. So what I was thinking is that the interview that exists today,

Eyal David: [44:33] is probably going to be very different from the interview a year from now. Probably. And the expectation will be completely different. So maybe for a second we'll talk about how you suggest preparing for that. The second thing I thought about: tell me, how closely do you work in product engineering, with everyone on the team, what does it look like? Very closely, I think. 30 people? Obviously, obviously. So basically what you're saying is that everyone around product is also absorbing this ability, right?

Daniel Marcous: [44:59] So basically the idea is, like, you're going to get much stronger over time, basically, with the existing team. Yes, unequivocally. That's the expectation, and we also try, as a culture, to encourage it, and also to celebrate all these use cases that work and come from all kinds of places in the organization, especially, especially if they're bottom-up, coming from someone's idea: here, I did something like this, come see. Celebrate them and show how good they are and present them at the All Hands and give them a stage. And we also make everything publicly visible, meaning we also have a shared public Slack channel where you tag Cursor and ask it for features, and you can see exactly who did what, and whether it succeeded or not, and how many PMs are active on it, and that pushes people forward to do it.

Eyal David: [45:54] Of course, giving a stage, and measurement, always works. But then my question, OK, I asked it before, is the part from idea to launch or experiment, what does it look like for you?

Daniel Marcous: [46:08] So... and it's probably also changing soon. It changes dramatically depending on the complexity of the feature, and let's also say how much the feature is driven by regulation, or some deterministic calculation, say all kinds of tax calculations, where the testing is much more rigorous. But let's say there are categories of features that I expect PMs or designers to take end to end, and the first stage where they reach an engineer is code review on the PR, which I'm already fine with, and needless to say the PR author didn't write the code. And there are features where I expect it to be at the level of... let's call it some spec, it doesn't have to be called a PRD, I'm not one of those who believe every feature needs a PRD, it's case by case. But some spec, at the level of which I also expect the product person or designer to iterate on it with those same agents so that it's also super technical and can point people to the right places in the code, and why the impact and the risks of these things change. And thank God, agents do that on their own too, so you don't even need to tell them anymore; part of their instructions is to add all those elements. Then it moves to an engineer who needs to get the lay of the land from that very technical spec, and once they give the green light, they throw it back to the agent team to start producing the baseline, and from there they start iterating and testing. You know, in the best-case scenario the first iteration worked. Usually with complex features that doesn't happen on the first iteration, but it's very close, and that baseline saves a dramatic amount of time. And it saves more and more time if you knew how to give it the right context. That's it. Around job interviews, really, you didn't touch on context with me at all, and I think that's the most interesting thing to see. No, maybe it can save a huge amount of time, right? If you know basically... Unequivocally. So there's context in its super-technical sense, of what I feed the LLM and which agent, and every agent gets different context. But let's say if you have agent sets, there's usually some agent that's the orchestrator of all of them, which a lot of the time manages the context, prepares it, and maybe sends some other agent to do research work to gather context. Now, that research work is as effective as what it has seen in the past and the knowledge base it has for understanding the context, plus what you write specifically for this feature. Now, the more sophisticated and complex its knowledge base, the less you need to write for the next feature you give it. And there again comes the matter of the reasoning: reading the reasoning to understand what's missing from its knowledge base, in order to update the knowledge base. Now, the method, the method for building the knowledge base, isn't let's take a week and start writing a knowledge base,

Eyal David: [49:21] but rather giving, not writing the knowledge base. Engineering, I agree. No, I actually meant at the level of the interview you do: catching what context the person gives, or what prompt they write, so to speak, which obviously saves a lot of iterations. Totally. OK, I want us to quickly go through a few tips. I want now, the thing that most offended me is: I now want a team of agents working with me, how do I do it?

Daniel Marcous: [49:54] Choose your favorite platform. OK. And let me caveat for a second that I'll split this in two. I'll split it into people who are already comfortable with code, even if that code is only behind the scenes, and know it's there and have no problem working and opening a terminal and so on, and people who are starting out, for whom it's the first time and maybe they'll use these things only through a UI. For people starting out, I'd recommend slowly easing into the more complicated things, and first crossing that barrier of courage: I do things with vibe coding, I see the code, I look, I see that it works. And the way I most recommend, from personal experience, for people to do it, is if they have kids, vibe code something with your kid. You have to find something, a game, something for coloring. Something you're a domain expert in, that's the point. Something you're a domain expert in. And actually, in the situation with my kid, the part that was fun for me at least, and it was very hard for me to let go, believe me, as a PM, is that I handed him 100% of the hat: he's the PM, and I'm his prompt engineer, OK? He tells me things, and I refine them, and I suggest to him, and I explain to him how I'm refining it, and we write it in English to the tool we're using, and slowly we iterate until we both feel comfortable with it. We didn't say patience is a crazy skill, but OK, yes. Unequivocally, unequivocally. OK, so you gave in to him. So I'm the prompt engineer, and I'm practicing, and I also see what works and what doesn't, on some use case that's fun for me, that I want to do, that I want to invest time in, until I feel much more comfortable jumping to the next stage. The next stage starts being working with more sophisticated tools that can stand up this platform of teams. Style: Claude Code or Cursor. There's also a stop on the way, for those who want it, at Claude Cowork, but the real tools for teams of agents are Claude Code and Cursor. And there I start from the assumption that the expertise is with the agent helping me build the code and not with me. Meaning, I start giving context: this is what I want to build, this is why I want to build it, I'm weighing all kinds of options, tell me what you think. I read in this place on Twitter, I give it the Twitter link; I read in this and that article, I give it the article link, that I see the best practices are such and such, and a lot of people do multi-agents with Awesome Claude Skills and with Paperclip and so on. Should I use this for my use cases? Why yes? Why not? Do a few iterations, get some plan from it, some comparison, ask it questions about the comparison, try to refine until I understand there's some fit between us, and we both agree on a plan forward we're happy with, and then start implementing, and test on real use cases. And I'd do it like I did with Jon-Jon: let's start with a game that's just a bird walking around the world doing nothing, start simple and iterate. Because a lot of the time, building that multi-agent framework and seeing what they say, and seeing that they pass the right context to each other and don't miss things, is much more complicated than building complex features later. So start with the simplest things in the world. Like moving this button five pixels to the right, but see that the context passes correctly and read the reasoning between my agents, between all the agents properly, and see that it knows how to then build me a test that the button moved five pixels to the right, or see that it knows how to update the existing tests, and so on, show that it knows how to spin up a remote environment. And every time I don't know something, ask it, don't be shy; every time something doesn't work, give it the error, every time, and lots and lots of iterations. And really, it's fun, for someone who's a builder and sees these things with their own eyes, and every time throws a prompt and then suddenly gets a new version? It's fun. That's lovely. We'll also, if you share, we'll also put a link in the show notes to... sorry. What I also understand is that you now expect to see an agent in job interviews too, in the end an agent you built. Listen, I have to say that, for example, the last PM I hired, I gave her a use case, a kind of take-home case study, where obviously, I assume, in a hundred percent of cases, and for me it'd be a red flag if not, people use their favorite tool to build the answer to that use case, why I should do this or that, compare, do the market research, and so on, that's a given. But the fact that she went the extra mile and brought me a working app, deployed on Vercel, that I could play with and see the feature she chose out of the two, with lots of extra little things that weren't related to the use case at all, but she said, OK, it makes sense for them to be here. And every time I asked her about some small thing she did there, she knew how to reason about why, and if she reasoned incorrectly about something, I asked her where she got the context, and then she showed me the prompts: oh yes, I consulted with it, I asked it like this, and then I gave it a prompt I like to use, battle testing: try to poke holes in my thesis. Like, I worked, OK, that's the person I want to work with. That's how we propel the organization forward.

Tips for getting started with a team of agents

Eyal David: [55:41] Excellent. OK, so I want to ask, toward the end, for the record, for all time, since you're heading on from here, so you can do two sentences: where do you think, where do you think, I want to say the world of work is going, but I'm looking at April. Tough.

Where the world of work is going, and the new philosophy of product strategy

Daniel Marcous: [56:04] Totally toward something much more builder-oriented, and much more... it's hard for me to find a good sentence for it, so I'll say a sentence that actually has a bad connotation, but I think it's simply going to change: the product strategy that used to be mocked, spray and pray, like I ship lots of things and see what works, and I don't necessarily have some very defined strategy. I just see what people really love and use. I think that's where the world is going, and the faster you acknowledge it and move forward, the more of a gap you'll have over all your competitors, and that's what we're trying to do at April, among other things. And a lot of it is also bringing in all these capabilities we talked about, agents and AI, really inside the product itself: let's reimagine what a tax filing experience is in 2026. Do I even need UX? Interesting question. Yes, until today my answer was 100% yes, it's going to be a terrible experience to ask a person 100 questions in a chat. On the other hand, the American consumer's expectations are starting to change, and changing dramatically, and even if these things are experiments, I want to be the first to put that experiment in front of citizens and users in production. To learn from it; that's how I'll learn the most, and that's how I'll be first for when it really does work.

Eyal David: [57:43] Gorgeous, a great vision. So first of all, to get in touch with you, we'll really put a link to LinkedIn, I understand. Gladly. And write to me if you, like, we want to bring him back, and we'll also talk about the whole human-in-the-loop thing. In general, we touched on it in this type of product, it's super relevant. Possibly, we'll expand on it in the group if you want. Yeah, Daniel, so great that you came. There are already a few challenges in working with accountants in an agile way. I recommend it to anyone who can afford it. That's one side of the equation, but totally. Daniel, so great that you came. Thank you, it was excellent. Thanks, my dear. It was a lot of fun.