Episode #47: Scaling Collaborative Product Design with Rotem Waissman

Rotem Waissman joined Monday.com when it was a five-person startup working from an apartment. She had studied visual communication in Tel Aviv, specializing in what was then called interactive design, and spent a year at a studio partly owned by a professor she admired. When one of Monday.com's founders contacted her, she saw a chance to learn how people build a startup from its earliest stage.

Nine years later, Rotem described an organization of almost 90 people across product design, motion and video, creative and marketing design, brand design, and internal brand work. In this conversation with Dwayne Samuels, she explains how design practice scales without losing curiosity, experimentation, or shared responsibility.

What you'll learn

• How Monday.com balances deep customization with a simple, intuitive interface

• Why a requested feature is not the same thing as an understood user problem

• How qualitative research, internal use, staged releases, and A/B tests fit together

• Why small MVPs reduce the cost of being wrong

• How imposter syndrome helped create wider design participation across the company

Make customization understandable

Monday.com describes its product as a work operating system that helps teams and organizations run their work processes. Its interface is meant to be changed and customized for many kinds of work. That flexibility creates the design team's central challenge: a generic product can fit nobody, but a highly complex product can become difficult to understand.

Rotem said about 70 percent of Monday.com's users were nontechnical. The team therefore had to make robust capabilities feel simple, intuitive, and enjoyable for people with very different jobs. Designers worked in cross-functional teams with product managers, developers, and analysts, each responsible for a particular product area or concept. Their daily work involved talking with users, studying how teams operate, and identifying the needs that connect otherwise different use cases.

The visual layer is part of that experience, not decoration added afterward. Rotem observed that even a small UI change can produce a large difference in how a feature feels and works. UX and UI have to be considered together because layout, presentation, and interaction all affect whether someone can understand the system.

Investigate needs before accepting requests

When users ask for a feature, Rotem's team does not assume the request describes the underlying problem. People often propose the solution they imagine rather than explain what is missing from their work. Monday.com examines requests from several angles. Customer success staff participate in product teams and bring information from daily support conversations. The company also learns through its user community, direct interviews, and research tied to its longer-term product vision.

Before launching something new, teams may show a solution or a small mockup to customers who requested the capability, or interview other users to test whether the direction makes sense. The goal is confidence, not certainty. Rotem repeatedly emphasizes that the team does not already have the answers.

Once an idea is available, the evidence changes. Teams use A/B tests to compare outcomes and learn whether an implementation works as expected. They build through MVPs, release something limited, watch the response, and then add to it. This reduces the time spent perfecting an assumption before real people encounter it.

Stage exposure and learn in public

Monday.com has an unusual advantage: employees use the company's own product. A substantial change can first be released internally so colleagues can try it and comment. Rotem sometimes enjoyed releasing a test without announcing it, then hearing people report what they thought was a bug or unexpected change. The team could observe authentic reactions before widening access.

From there, a feature might go to alpha or beta users, a small customer group, or customers who strongly requested it. This progression creates several opportunities to learn before a broad release. It also supports Rotem's most important lesson: do not become overconfident. A design can feel obvious, absorb many hours of work, and still fail when placed in a new context. The product, the market, and people's expectations continue to change.

Turn uncertainty into shared responsibility

Rotem connects this operating model to her early imposter syndrome. As Monday.com's only designer, she felt anxious about whether she had made the right decision. Instead of hiding the work, she involved developers and other colleagues, explained her thinking, and asked what they thought. That practice helped people across the company feel accountable for design quality.

Designers still own final design decisions, but product managers, engineers, analysts, and customer success staff contribute to the process. Rotem also hired early designers whose work she respected, then learned alongside them. The result was not certainty from one authority. It was a culture where design became a joint effort and a tool for influencing product and business outcomes.

Listen to Episode #47 for Rotem Waissman's account of scaling design, testing customizable products, and learning without false certainty.