What's New

monday.com ships more than 10 new features every month — but until 2022, they lived in a dozen different places. A blog post here, a tooltip there, an internal email, the bottom of a sales deck. Users couldn't see what was new without going hunting, and most never did.

The signal came from three directions at once. Support tickets kept asking variations of "is there a place where you list new features?" User interviews surfaced the same question, framed as wasted productivity — power users wanted to keep up but had nowhere to look. And sales calls hit the same wall: prospects asking "what have you shipped recently?" while AEs scrambled to remember.

The brief was clear: build the place that should have existed all along.

I led design end-to-end — not just for the page, but for the publishing system behind it. I worked with one PM, a PMM partner, and a developer. PMM owned content strategy and editorial tone; PM owned scope and the cross-team rollout; I designed the page, the contributor experience, and the guidelines each department would follow to publish their own updates. Once the system was live, I stayed on as the final editorial reviewer — every announcement crossed my desk before it shipped.

We started by reading every "what's new" support ticket and quoting them back to the team. Then I ran a short round of interviews with power users to understand what they actually wanted from a release feed: chronological? Filterable? By product area? By release type? The answer was "yes to all of it" — so the design had to accommodate both scanning and digging.

The first prototypes tested how to hold a high volume of content without becoming a wall of text. A pure chronological feed drowned the bigger announcements in noise. A curated-only carousel left out 90% of what shipped. The pattern that worked was a hybrid: a featured strip at the top for the announcements we wanted everyone to see, then a chronological feed below it with filters by product area, so users could choose between "show me the highlights" and "show me everything."

Once the page worked, the harder problem started: how do you get a dozen teams to keep it alive? Asking each team to ping me every release would have made me the bottleneck within a month. Instead, I built contributor guidelines — a short document per department covering tone, length, image specs, what counts as an announcement versus a quiet ship, and how to submit. With guidelines in place, teams drafted on their own; I stayed in the loop as the editorial reviewer, but the day-to-day publishing moved from "Maya makes it" to "Maya approves it."

The contributor guidelines were the unglamorous half of this project — and the reason it kept working after I moved on. Each team got the same template: a one-sentence headline, a one-paragraph description, a hero image at a fixed aspect ratio, a "type" tag (feature, improvement, fix), and a target product area. Anything outside the template got returned.

The constraint sounded harsh but it's what made the page feel coherent — every announcement read like it belonged to the same product, not the team that wrote it. The review queue became my main interface with the system: a stream of drafts, edited where needed, sent back when off-template, approved when ready.

The page shipped as monday.com's first dedicated home for product announcements — a single URL the product team, marketing, and sales could all point to. Teams across the company moved from one-off launch emails to self-publishing on a shared cadence, and the release page became the default link in feature-launch threads.

The hardest part of this project wasn't the page — it was getting other teams to trust the system enough to use it. Templates feel restrictive when you're the one filling them in; the work was in showing the constraint paid off in the final result.

The win wasn't a beautiful release feed. It was that other teams stopped asking me to build them one of their own.