Nazli Danis Learned to Scale the Machine. Now She Wants to Fix the Factory Floor.

On her first day at Deel, Nazli Danis felt as if someone had promoted her from a local league straight into the Champions League. She was the company's first product hire. The assignment in front of her was less glamorous than the metaphor: an Employer of Record product operating as a two-person, sub-$10,000-a-month prototype on Google Sheets. For months, she worried the invitation had been an administrative error. Surely someone would notice the fluke and send her back down.

Four and a half years later, Danis left a very different machine. Deel's EOR product had become a multi-hundred-million-dollar business. The spreadsheet had acquired teams, systems, controls, and all the difficult exceptions that appear when a service starts employing people across borders at scale. Danis had risen from product manager to group product manager. At her farewell Zoom, more than 40 colleagues appeared, including people she had not worked with in years.

Someone asked what she was proudest of building. Revenue would have been the tidy answer. Product people adore a curve that bends upward and to the right. Danis chose the less chartable thing.

“The team. A thousand times, the team.”Nazli Danis on leaving Deel

That answer is a key to her career. Danis talks about products as systems, but she talks about growth as an environment people enter. Deel surrounded her with enough high-agency colleagues that her internal refrain gradually changed. “That's impossible” gave way to “everything is a solvable problem.” Each solved problem became evidence for the next one. Confidence compounded until convention looked more like a suggestion.

An art historian enters the spreadsheet

There is no standard corridor from the Brooklyn Museum to payroll infrastructure. Danis found one anyway. At Barnard College, she studied art history and architecture, served as vice president of the Barnard-Columbia Architecture Society, and took internships in editorial and curatorial work. Her early career moved through design and product roles at Kairos, the Venture For America fellowship, and later Pensa Systems, where machine learning and computer vision met the practical problem of retail inventory.

The medium changed. The organizing instinct remained. Architecture asks how people move through a structure, where friction accumulates, which constraints deserve respect, and which can be redesigned. Product management asks versions of the same questions, then adds deadlines, databases, and a meeting that should have been an email.

Danis describes her work with a sentence that carries traces of both worlds: “I create digital products that solve tough problems artfully.” She has also declared an obsession with “11-star” experiences, the deliberately unreasonable exercise of imagining a service so considered that five stars feels stingy. In enterprise software, where a tolerable form can count as a triumph, the phrase lands as both ambition and mischief.

She practiced the 0-to-1 habit outside work, too. In 2016, when bots were fashionable and GPT was still far from ordinary conversation, she co-created Emile. The SMS assistant nudged people to sleep earlier so they could use their free time with more intention. It stayed operational without becoming a commercial phenomenon. Danis seems fond of that honest outcome. A product may fail to conquer a market and still teach its maker how to notice, build, and ship.

Her other side projects are gloriously unnecessary: a hot sauce brand made with her father, furniture designed for her home, and experiments around making Instagram collections more navigable. She calls them “side quests with high production quality.” The phrase suggests a person who regards polish as play and play as a legitimate form of practice.

Everything after the handshake

Paloma began with a scar the founding team shared. Danis met co-founders Alex Avnit and Kaiwen Song at Deel. Danis and Avnit had worked on EOR as it grew; Song had built billing and payments infrastructure. They knew what a clean sales presentation concealed. After a customer signs, contracts develop unusual clauses. Pricing experiments collide with finance systems. Service consumption lives in another tool. Customer success remembers a promise that billing never heard about. Growth leaks out through missing context.

The first public Paloma product gathered contracts, communications, service usage, and account history into a shared post-sales record. It flagged expansion opportunities, renewal moments, usage changes, and churn risks. It translated complex commercial terms into billing instructions. A natural-language interface promised relief to salespeople who had ever assembled an exotic deal and then received a message from Finance beginning with “quick question.”

Danis launched it with an affectionate nod to the “resilient AF salespeople” who always find a way to get a deal over the line. The product idea carried her familiar pattern: respect the operator who already understands the mess, then give that person better leverage. Paloma offered free revenue audits to companies that suspected upsells were hiding or churn signals were arriving too late.

“Over time, your default mindset moves from ‘that's impossible / I can't do it’ to ‘everything is a solvable problem.’”Nazli Danis

The factory changes the brief

By 2026, Paloma's public face had changed. The company now describes itself as a digital transformation partner for real-economy businesses, especially manufacturing companies. Billing remains part of its operating memory, but the canvas is wider: inventory, logistics costs, compliance checks, production data, handwritten shift reports, WhatsApp orders, aging records, ERPs, inboxes, and the unofficial spreadsheets holding the peace between them.

The shift reads less like a rejection of the first product than a move closer to the underlying problem. Context was scattered in revenue teams. Context is also scattered across a factory, except some of it arrives on paper and some sits with the veteran operator who knows why Tuesday's number always needs an adjustment.

This is a revealing destination for someone trained to look at buildings. Factories are compositions of movement, memory, and constraint before they are collections of machines. The formal process may say one thing while the practiced route across the floor says another. A worker takes three extra steps because a screen lives on the wrong wall. A supervisor keeps a private worksheet because the official report cannot express an exception. Those details resemble minor inconveniences from a distance. At operating scale, they become the business.

Paloma's stated process begins with an operational diagnostic. Its team shadows the customer's team and maps the process from end to end. Next comes a trial engagement, deliberately narrow enough to prove value without requiring a giant commitment. Continued work expands into other workflows, carrying forward the operational context gathered along the way.

There is a practical humility in that sequence. The operations team already knows where the work hurts. Paloma's job is to turn that knowledge into technical leverage. A compliance checker across 15 languages, an equipment-effectiveness tracker from shop-floor data, or a cleanup system for 850,000 inconsistent records is useful because it fits the actual exception-riddled workflow.

The company's trust language is equally concrete. Answers should display their sources and calculations. Actions should leave an audit trail. Customers should choose the points where a human approves the next step. If logistics costs rose 12 percent, the system needs to show the arithmetic rather than deliver a beautifully phrased shrug.

That insistence also puts a boundary around the fashionable idea of an AI copilot. Fluency earns attention; traceability earns permission. In a business where an incorrect calculation can travel into inventory decisions, customer promises, or the general ledger, a plausible sentence has little value by itself. The useful interface is the one that lets an experienced operator inspect the path, correct the premise, and teach the system what the business means by right.

The useful thing to steal

Danis once wrote a hiring brief for a product-operations leader at Deel. She wanted someone who thought “dashboard” was a love language, harbored a personal vendetta against systemic inefficiency, could break a complicated problem into executable pieces, and accepted that herding cats occasionally belongs in the job description. Under the jokes sits her operating doctrine.

Start with the system, not the feature. Find the metric that tells the truth. Give ownership to people who can follow a problem across departmental borders. Stay close enough to the work to discover the rule nobody documented. Build with enough care that the user feels understood, even when the user is reconciling invoices or cleaning a record created before the engineer was born.

Her story also offers a useful correction to the mythology of confidence. Danis did not arrive at Deel feeling inevitable. She arrived worried she had slipped through. The high-agency operator emerged through repetition, honest standards, and an environment where difficult problems were treated as puzzles with owners. The person who later left to found an AI company was assembled in public, one solvable problem at a time.

Now the setting is less polished than a San Francisco product demo. A factory floor contains noise, legacy systems, physical constraints, and people with no patience for a chatbot that cannot account for Wednesday. It is an excellent place to test whether an 11-star experience can wear steel-toed boots.