How monday.com Turned a Competitor's Surprise Launch into a New Operating System

Daniel Lereya, Chief Product and Technology Officer at monday.com, takes host Lenny Rachitsky back to a time when the team was around 30 people. They shipped constantly and shared long weekly updates, and they felt good about their execution. Then one morning they saw that a main competitor had launched 30 new column types for its boards, the table-like heart of the product. monday.com had five, and Lereya was personally coding the sixth, with each one taking about four months.

The founders, Lereya and a few tech leads left the office to talk it through. The painful realization was that when they asked what the most meaningful thing they had done in the last three months was, there was no single answer. Lereya says admitting this was hard after working so intensely. Yet the team chose to treat the rival's move as "a gift" because it showed that something they had assumed impossible could be done.

Rachitsky compares this to the four-minute mile, where one person breaking the barrier unlocked everyone else. He also notes how many companies instead deny that a competitor's move matters, as with early reactions to the iPhone. Lereya's advice is to know your competition, use it to your advantage and believe in yourself enough to set ambitious goals.

Adding 25 columns at four months each was out of reach for a small team, so monday.com set the goal of 25 columns in a single month. They reached 30 columns within about a month and a half. Lereya says the goal worked because it removed the option of simply working harder. The team had to step back and ask what a column actually is.

That question led them to define the capabilities every column needs, such as export to Excel, filtering and sorting, and to build shared infrastructure for them. A tech lead built that structure, and the team ran a one-day hackathon where each developer built one column in a day. Two weeks later the columns were in production, a drop from four months to one day. Lereya says the team then repeated the drill for dashboards, widgets and automations.

Lereya stresses the difference between fake speed and real speed. Fake speed skips stages or lowers quality, while real speed comes from doing the right things and cutting work you tend to invent when solving a problem. A target like shaving a month off a four-month project, he says, simply sounds like a demand for longer hours. A goal that can't be met by sleeping in the office forces the whole team to think differently.

For Lereya, a great PM is relentless until the impact is real and validated. A PM's first job is to create shared understanding of the problem, the opportunity and how the team will know it moved the needle, rather than to define a solution. Spending more time in the problem space also cuts down debate about solutions, since everyone knows the result will be tested in real life. Sometimes the biggest impact is not a new feature but making existing value easier to find or connecting it better to go-to-market.

He names a clear warning sign: teams that talk about "enhancing" or "extending value" without saying what will change for users and how they will see it. A real goal forces questions about audience size and whether the work will reach enough people. Rachitsky sums it up as working backwards from a metric tied to growth rather than shipping whatever the sales team asks for.

Lereya gives a recent example with AI blocks, a no-code way to add AI actions to existing workflows. The team had good customer feedback, but the daily numbers showed only a few thousand of 250,000 paying accounts were using them. The blocker was a terms-of-service change planned for the next quarter. The team decided to do it now, working with legal, and within two weeks it was open to 98% of customers.

Lereya recommends an exercise: each quarter, imagine how the product and company will be better for customers, then work backwards. Promises of better security, performance or fewer bugs are not enough, he says, because the team must constantly build value that is pivotal for customers. He likes to ask people what they are most proud of from the last three months, and if that takes a long time to answer, they are not focused.

At company level, he writes a slide at the yearly kickoff describing what will be different for customers in a year, and next year's presentation starts with that slide to check progress. Today the builders organization covers about 700 people in engineering, product management and design. At team level, early on, every team member wrote highlights for a biweekly company update, which made people reflect on whether they had a high-impact two weeks.

Lereya shares scale numbers: monday.com recently crossed $1 billion in ARR and serves 250,000 customers across more than 200 business verticals, most of them non-technical. When he joined about eight and a half years ago, the company was called Pulse, with around $4 million in ARR and 30 to 40 people. Today it has about 2,500 employees. Rachitsky adds that behind the simple-looking product, even rocket and shipbuilding teams manage their work in tools like it.

His most counterintuitive lesson is transparency. Before going public, monday.com showed dashboards of paying accounts, churn and signups in the office, and even interview candidates saw them. Family members who work in tech told him this was a mistake that would demoralize people. Lereya argues the opposite: for the right people it creates deep partnership, and he recalls the loneliness of holding information as a leader, which he calls "the dark side of the moon."

He says transparency spreads the work of spotting problems. People noticed conversion issues and other challenges because they could see the data, so the company wants "everyone's brains in the challenge" rather than one centralized brain with many working hands. Even as a public company, monday.com has found ways to share what it can, and product managers sign 10b5 plans for automatic stock sales so they can see the data without trading on it.

Lereya says the internal Monday Morning app has a part for all employees and a confidential part by role. For a young startup, he says, the start is easy: build a daily numbers dashboard in about an hour and put a TV on the wall. Early on, their office dashboard even played sound effects, such as a Simpsons clip, for new paying accounts. He says it changed conversations because everyone knew what mattered.

Lereya says monday.com likes to take bold risks, not for their own sake. Users were building CRMs and dev-cycle tools on top of the platform, so the company decided to become a multi-product company, though its go-to-market was still that of a project management tool. Rather than launch one product quietly and double down if it worked, it announced five products at the same moment.

Internally there were many concerns about confusing users, hurting conversion, marketing, sales navigation and pricing, and there was a lot of friction. Looking back, Lereya says some products succeeded, with monday sales CRM growing faster than monday itself did at the same stage. Others were folded back into the main product. The move changed both how people inside saw what they were building and the competitive landscape outside.

He frames not taking bold risks as a risk in itself, because people prefer inertia and incremental gains. Doing leaps means letting go of things that were successful in the past. A mental model that helped was remembering that when they had 20,000 paying customers, most potential customers of the platform were not yet customers. Rachitsky ties this to his Airbnb experience, where teams shipped many experiments and still wondered what was exciting.

Lereya believes more time rarely makes a better product. Wanting to hear "what an amazing product" is, he says, bad feedback to seek early, and shipping to real users is scary because they may call it lousy. He urges teams to get to production fast and to set "traps," meaning deadlines that scope work by time rather than effort. More time, he says, creates more questions, assumptions and invented requirements.

A recent example is the company's enterprise work management offering, built for tens of thousands of employees and thousands of projects. The team released an early alpha to customers and heard that it was premature and needed more comprehensive value. Lereya told them well done, because that feedback is priceless. Rachitsky clarifies the idea as a set time box in which scope is cut if the deadline is at risk, and links it to Ryan Singer's Shape Up method, which Lereya hadn't heard of.

monday.com also applies traps at company level, for example picking something to announce at the next earnings call. Bottom-up planning tends to turn into a sport of listing what could go wrong, adding scope for protection until the project would take two years. A deadline shifts the conversation to the core of the value and removes theoretical debate. Lereya adds that you must keep iterating after the first version rather than leave it as it is.

Lereya warns that not every piece of customer feedback leads to the best product. In the early days monday.com did not offer a free trial, partly because it wanted feedback only from people who cared enough to pay. In his view, paying is the best proxy for getting real value, and it helped the team separate useful signal from noise.

Rachitsky adds a related point from Captions CEO Gaurav Misra: if nobody complains about a product, it may mean nobody cares. He also describes the common experience of a landing page redesign that balloons into six months, when a three-week commitment would have been enough. The shared conclusion is that setting the time limit upfront and doing as much as possible within it is hard but effective.

Asked what he wishes he had known before taking the role, Lereya says his role has changed dozens of times as the company grew, so it is like working at dozens of different companies. His biggest strength early on was mastering every detail and keeping everything in his head. As the company grew, doing the same thing created damage. He says the advice he would give himself is not to be afraid to let go of what he thinks are superpowers, and he admits he often did it too late.

A concrete signal came in a leadership quarterly business review. Lereya left feeling he had explained everything articulately, but a colleague said he hadn't understood anything and asked for the bottom line. The colleague wanted only the three most meaningful things Lereya was dealing with. Rachitsky connects this to the shift from pitching leaders to being pitched, and the need to learn to delegate and give feedback.

Lereya is open about self-doubt. The founder Roy once said he would not have interviewed himself for a job running a company with a market cap around $10 billion and 2,500 employees, and Lereya says he has asked whether someone more experienced should lead. A talk with a colleague reminded him that as someone who helped build it, no one could do it like he could. He copes by imagining how he wants to look back on the next six months, running, and bouncing back the next day. Rachitsky adds that most people are imposters in a role they have never done before, and that is fine.

Lereya describes a crisis in which customer success told him tickets about board performance were spiking. Eight years ago a board might have five columns and 100 rows, while today customers use hundreds of columns and tens of thousands of rows. The team first shared the graph with everyone and worked hard to improve things, but the problem returned, including a third time. He says monday.com believes performance is the number one feature.

On the third occurrence he decided to think differently. A few of the most talented engineers were taken off feature work and asked to solve the problem while thinking about 100x scale. The result is monday DB, an underlying data infrastructure built over about three years, with a first version released around one and a half years ago. Lereya says it is what makes monday.com an enterprise-grade platform today.

His lesson is that strategic work sometimes has to rest on intuition rather than on past data or a measurable goal, and that you should turn a problem into a competitive edge rather than a patch. Rachitsky notes that many of his own crisis stories involve databases reaching capacity, and compares infrastructure to Brian Johnson's point that the first goal is not to die. Lereya adds that reliable, fast products change how people use them.

In the AI corner, Lereya tells how he had a knee injury while preparing for a marathon and loaded his MRI disc into ChatGPT to get a line-by-line explanation before seeing a doctor. When he asked about skiing, ChatGPT gave recommendations, while the doctor said he didn't know because he never skis. Lereya says the experience shows both the power of the technology and the need to productize it so others can benefit. Rachitsky mentions a New York Times story comparing doctors, doctors with ChatGPT and ChatGPT alone.

At work, Lereya used AI to get a full picture of what competitors were doing on AI pricing in about two hours, something he says would normally involve analysts and product managers. He values being able to keep digging without the tool getting bored or annoyed. In closing, he says the culture and people at monday.com are what drive everything, and that he used to take culture for granted before scaling made it so clear.

In the lightning round, he recommends *No Rules Rules* by Netflix and *Nonviolent Communication*, which changed how he and co-founder Roy talk. He also names Formula 1: Drive to Survive and Google Photos, and gives "stay positive" as a motto. He says his army experience, where he commanded a large group, taught him about building a sense of purpose and belonging in teams.