All people

Guest · monday.com

Daniel Lereya

Chief Product and Technology Officer at monday.com

1 source16 tips

Where to hear and read about Daniel Lereya1 episode or test

Lenny's PodcastInside monday.com’s transformation: Radical transparency, impact over output, & the path to $1B ARR
In short

Daniel Lereya is Chief Product and Technology Officer at monday.com, which he joined at about 40 people and helped take past $1B ARR. The thing most worth learning from him is to judge teams by the change they bring customers, and to set goals that working harder cannot reach.

We received a gift from our competitors. They showed us that it's possible.

Inside monday.com’s transformation: Radical transparency, impact over output, & the path to $1B ARR

Daniel Lereya: the story and the lessons

1How Daniel Lereya and monday.com learned they were moving too slowly

  • Lereya joined monday.com at about 40 people and grew with it. The product was called Pulse and the team was 30 to 40 people. monday.com grew from about $4M to over $1B ARR in eight and a half years, and now has 250,000 customers and 2,500 employees.

    Customers span more than 200 business verticals, from airplane and cruise ship builders to real estate, construction and finance. Most are not tech companies.

  • He was coding the sixth column type when a rival shipped 30. A competitor launched 30 new board columns while monday.com had five, and each of its own had taken about four months. Boards are the heart of the product, and each column type is a data type inside a board.

    The team of about 30 felt good about its execution and its weekly update was always long and packed. The launch showed that all that shipping had not transformed the product.

  • Lereya could not name one meaningful thing built in three months. Asked for the most meaningful thing the team had done in three months, there was no specific answer. He calls that a focus problem.

    Founders Roy and Ian, Lereya, tech lead Tal and a few others went offsite to rethink how they worked. Admitting the hard work had not transformed the product was painful because people had put their hearts into it.

  • He treated the competitor's launch as a gift. A rival's success removes the excuse that something is impossible, so only the question of how was left.

    He compares it to the four-minute mile: once someone does it, others start to follow. He calls it the biggest favor you can ask for.

2How Lereya used an impossible goal to ship 30 columns

  • Lereya set a goal the team could not hit by working harder. The goal was 25 columns in one month, against four months per column before. The team delivered 30 in about six weeks.

    His test for a good goal: you cannot reach it even if you sleep in the office. Meeting a goal they did not know how to hit made the team feel invincible.

  • The goal forced the team to define what a column is. Each column must export to Excel, filter and sort. Tal built shared infrastructure so each developer was left with only the product questions.

    Lereya built a column overnight to test it. In a one-day hackathon each developer built one column, and the work reached production two weeks later.

  • Lereya separates real speed from fake speed. Fake speed skips stages or lowers quality. Real speed means working only on what moves the needle and dropping the extra work teams invent.

    Cutting four months to three sounds to people like a call for longer hours, which is why he frames it this way.

  • He repeated the drill and still sets goals he cannot prove possible. The same approach was applied to dashboards, widgets and automations.

    Today the team applies it to things it has not seen others do.

3Lereya's rules for judging teams on impact, not output

  • Lereya has product managers define the problem and the metric, not the solution. The PM owns a shared understanding of what would help customers and how the team will know the needle moved. Teams spend more time on the problem before choosing a solution.

    Solution debates shrink because everything is tested in real life. He says much of what he built was never used the way he thought.

  • He spots weak goals by the words enhance, augment and extend value. A goal that never says what changes for users signals a team not focused on impact. A committed goal forces questions such as whether the target audience is big enough.

    The whole team, not just product managers, succeeds or fails on customer value, because people love building and lose track of why they started.

  • Every team posts daily numbers that keep it honest. Each team writes a daily update that an internal system called Big Brain posts to Slack for discussion. Lereya says to live by your numbers.

    He enjoys seeing teams ask why a metric jumped.

  • Daily numbers showed AI blocks reached few accounts, so he pulled a fix forward. Only a few thousand of 250,000 paying accounts used AI blocks. A terms-of-service change planned for next quarter was done in two weeks, opening AI to 98% of customers.

    AI blocks are no-code AI actions inside existing workflows, and 70% of customers are non-tech. The team tracked discoverability, adoption and retention.

  • Lereya knows the biggest impact is sometimes not a new feature. It can come from better go-to-market links or from helping customers learn and reach what was already built.

  • He checks impact on a fixed rhythm, not when a rival moves. Every quarter he imagines how customers will be better off a quarter ahead, then works backward. He asks teams and people what they are proudest of from the last three months.

    Better security, performance and fewer bugs are not enough on their own. A slow answer shows weak focus, and the cadence can be a quarter, a month or two weeks.

  • A yearly kickoff slide states what will change for customers. Next year's kickoff opens with that slide. In the early days every team member also wrote highlights every two weeks, and the company shared them.

    Readers of those updates judged the period a good or bad two weeks, with a lot of impact or not enough.

4Why monday.com shares every number with everyone

  • Lereya wants everyone's brain on the problem, not just a central one. Before going public, monday.com shared every bit of information with employees. He says it builds a sense of deep partnership rather than demoralizing people.

    Family members in tech warned him that open numbers would demoralize the team when things went south. He found the opposite for the right people.

  • He says leaders who hold back bad news carry it alone. He calls that position the dark side of the moon: knowing something heavy while the office feels happy.

    The aim is radical transparency about everything, so the whole team works on each challenge together.

  • A young startup can begin sharing numbers in about an hour. Early on, daily company numbers covered paying accounts, upgrades and downgrades. Everyone sees what leadership cares about, so the KPIs focus the whole team.

    Dashboards even showed churn and signups to interview candidates, and employees spotted problems such as a conversion drop. There is also relief in not deciding each time what can be shared.

  • The first office TV played a Homer Simpson clip for new paying accounts. The goals dashboard had programmed sounds: a Homer Simpson million-dollar clip for a new paying account and a tick for a new signup.

    The first $1 million month and a record day of new paying accounts were celebrated by everyone, not only founders.

  • Going public changed the format of sharing, not the commitment. Bankers and lawyers said an all-financials dashboard at the building entrance no longer made sense. The company kept the principle and built an internal app with an all-staff part and a role-based confidential part.

    Product managers sign 10b5 stock-sale plans so they can still see the data. The logistics are heavy and worth it.

5The bold bets Lereya backed: five products at once and Monday DB

  • monday.com launched five products at once to become multi-product. Customers were already building CRMs and dev-cycle software on the platform while go-to-market still sold project management. Monday CRM grew faster than the core product did at the same stage.

    Launching all at once avoided a misleading verdict on a single product. Some products were later folded back into the main product, but the move changed how the company and its competitors saw it.

  • Lereya accepted heavy internal friction for the multi-product move. Staff worried about confused users, lower conversion, several go-to-markets, sales navigation and pricing. He calls it very hard but is still happy with it.

    His line: not taking bold risks is itself a risk.

  • He reminds the team that most future customers are not yet customers. At 20,000 paying customers, the team used this to accept changes that cut into current success.

    People tend to want inertia and incremental value, and leaps require giving up part of the success you already have.

  • He pulled top engineers off features to build Monday DB. Repeated board performance tickets showed boards had grown from about five columns and 100 rows to hundreds of columns and tens of thousands of rows. On the third recurrence he chose to rethink the architecture.

    Monday DB was designed for 100x scale and its first version shipped about a year and a half before the episode. He calls performance the number one feature and says to act on strategic intuition even without past data.

6How Lereya ships: timeboxes, early releases and paid feedback

  • Lereya scopes work by time and cuts scope to hit the deadline. With a set period such as three weeks, the team cuts to the core of the value. Even as a public company, they choose what to announce at the next earnings.

    Bottom-up planning becomes a sport of what can go wrong, and fear-driven teams add content until it ships in two years.

  • He treats 'too early' feedback as a win. An alpha of the enterprise work management offering was called premature, and Lereya answered well done, because that was the feedback they wanted.

    Hearing what an amazing product on a first version is bad feedback, since it means the team built too much. After the first version, the team keeps iterating on feedback.

  • He argues more time rarely makes a product better. More time adds questions, complications and assumptions about what users need. Teams invent needs for good reasons, such as wanting people to like the product.

    Putting work in front of real people is scary because they may call it lousy.

  • monday.com had no free trial so feedback came from payers. Paying is the best proxy for real value, which separated wheat from chaff. Not every customer's feedback should steer the product.

    A landing page redo can drag on for six months, and committing to three weeks up front avoids that.

7How Lereya's leadership had to change as monday.com scaled

  • Lereya's biggest strength became damage as the company grew. His role changed dozens of times, like working at dozens of different companies. Knowing every detail helped when the company was small and hurt when it got bigger.

    He says he let go of this too late. The signs came from feedback, coaching and trial and error.

  • A colleague told him he had explained everything and they understood nothing. After an early leadership QBR, a colleague wanted only the three most meaningful things Lereya was facing.

    He first resisted, then accepted that the requirements had changed. His rule now is to give others the bottom line.

  • He treats self-doubt as normal and keeps habits that reset him. He often asked whether someone with more experience should lead this phase. Roy noted he might not hire himself to run a public company worth about $10 billion with 2,500 employees.

    Lereya asks what he wants to say he learned over the next six months, and runs and does non-work things to get back to his center.

  • He leads through culture, shared purpose and positivity. His army unit experience taught him to build teams with purpose and belonging. He gives people No Rules Rules after explaining monday.com's culture.

    After he and Roy read Nonviolent Communication, they changed how they talk: state observed facts without judgment, then say how you feel. Staying positive does not mean ignoring problems, it means asking how to make the situation better.

  • He uses ChatGPT to cut days of research to hours. In about two hours he got a full view of competitors' pricing for the AI offering. He also uses it for extensive topics such as a competitor's history.

    After a knee injury he put his MRI results into ChatGPT for a line by line explanation before seeing his doctor. His lesson for monday.com is that the hard part is productizing the technology so people can use it.