Yazan Sehwail and the trouble with finished software

A welcome message ought to be a small thing. A few words, a button, perhaps a nudge toward the useful part of a new application. For Yazan Sehwail, the irritating detail was how much work it could take to put one there. The message might be simple. The queue of engineering work behind it could be anything but.

That gap became the premise of Userpilot, the company he co-founded with Thabet Gharabah. Sehwail had spent years making software and had become interested in a less ceremonial moment: what happened after it arrived. A release could be complete while the customer was still standing at the entrance, wondering which door to try.

Today, the Austin-based founder is carrying that question into AI. Building more software, more quickly, gives teams more to explain and more behavior to understand. His career has kept circling the same awkward possibility: a product can work perfectly well and still fail to become useful to the person paying for it.

From Ramallah to the other side of the brief

Sehwail grew up in Ramallah and attended Friends High School before taking a full academic scholarship to Hamilton College in New York. His studies combined mathematics, computer science and economics. His public education history lists Hamilton from 2009 to 2013. It is an apt combination for someone whose business sits between what software can do and what people consider worth doing.

He returned to Palestine after college. An early attempt at a Groupon-style application failed. InnerChip, started in 2013, proved more durable: an enterprise software business whose clients included BMW. He led it for almost five years. This was work done against somebody else’s requirements, with all the practical exposure that entails.

The distinction matters to his story. A software agency sees the negotiations behind a finished interface: who requests the change, who implements it, and how long everyone waits. Userpilot grew out of that experience of making relatively small changes expensive. The eventual product idea had the unglamorous advantage of being attached to an irritation he already understood.

The purchase before the product

In 2020, Sehwail recalled signing Userpilot’s first contract before an alpha version was ready. More than 200 teams subsequently used the closed beta; he put the public launch at the beginning of 2019. Customer conversations preceded the code.

There is a particular discipline in asking someone to commit before the demonstration is polished. The conversation has to survive without the distracting pleasure of a working button. What matters is the problem, the person who has it, and whether solving it deserves a place in a budget.

Sehwail also described retiring a heavily used feature because customers struggled with its configuration. “The data can lie sometimes!” was his verdict. The remark is less a dismissal of measurement than a warning about what a measurement can conceal. A click may register enthusiasm, confusion, or another attempt to make the thing behave.

“The data can lie sometimes!”

Yazan Sehwail, 2020

A small release with an expensive lesson

His writing about soft launches supplies a more concrete mishap. Userpilot introduced autofill for attribute identifiers, intending to spare customers tedious typing. The new functionality unexpectedly crashed the database. The team withdrew it and restored the previous version.

Only around 20 percent of users had received the change. That limited release gave the team room to reverse course. Sehwail used the episode to explain why he preferred testing functionality in use before arranging a large announcement around it.

A launch party is a curious place to discover that a shortcut has taken the scenic route. The quieter release had preserved an option that publicity tends to make uncomfortable: admitting the improvement needed more work. In his telling, the rescue was operational rather than theatrical. Put the old version back, examine what happened, try again.

The useful moment arrives late

By 2021, Sehwail was taking his ideas about activation and experimentation into product podcasts. With ProductLed, he discussed A/B testing, gaining a team’s support for experiments, identifying an initial moment of value, and handling products with several use cases. On Let’s Talk Product, the conversation stretched from first understanding to later feature adoption.

That sequence gives his work a longer horizon than the introductory tour. Someone may understand the main purpose of a product while remaining unaware of another function that would make next week’s work easier. Getting through the opening screen leaves plenty of the relationship ahead.

It also changes the founder’s task. An onboarding system has to make choices about relevance, timing and restraint. Every additional prompt competes with the work the customer came to do. Software that introduces itself too enthusiastically can resemble a host who insists on explaining the furniture before letting a guest sit down.

A sales call can belong in the picture

In June 2024, his conversation with Vincent Jong followed Userpilot’s expansion from a focused offering toward a suite. The discussion covered how free trials and demonstrations could serve different customers, how sales teams fit alongside a product-led approach, and how existing accounts might discover more of the product.

This is a revealing complication for a founder associated with self-directed product experiences. A more complicated purchase may need a human conversation. The practical question becomes how much assistance a particular customer needs, rather than whether the company can remain loyal to a single fashionable sales doctrine.

It is easy to admire a frictionless buying journey in the abstract. It is harder to design one for a buyer with several colleagues, unfamiliar requirements and a deadline. Sehwail’s discussion leaves room for those people. The same attention to context that shapes an in-app prompt can also shape the invitation to book a call.

The etiquette of a well-timed suggestion

His public examples of feature discovery are deliberately ordinary. Slack might suggest scheduling a message when someone is writing outside working hours. HubSpot might surface templates when repeated text is being pasted into an email. In both cases, the action already underway supplies a reason to care.

“Feature adoption is all about timing and context,” he wrote. The observation helps explain what he is looking for in user behavior: the point at which a suggestion can save effort. A feature announcement has the company’s calendar behind it. A useful prompt has the customer’s task in front of it.

There is a modest social intelligence in that distinction. People rarely enjoy being interrupted merely because someone has something new to say. They are more receptive when the interruption helps them finish. Sehwail’s examples treat the interface as a participant in that exchange, capable of having either good manners or very poor timing.

When the user sends an agent

His October 2026 writing turns toward a customer who may no longer visit the interface at all. An agent might prepare a weekly report on someone’s behalf. Fewer human sessions would then be compatible with continued value. Counting the agent’s tool calls alone would also miss whether the job actually succeeded.

Sehwail sets out two connected directions: Lia, Userpilot’s product adoption agent, and Userpilot Headless, intended to make its data and tools available to customers’ own agents. He describes further investigation, prepared fixes and review as ambitions for the system. The destination includes checking whether a change helped after release.

This is where his original question becomes more demanding. If the work moves out of sight, the evidence of success must follow it. A busy interface was always an imperfect proxy for a satisfied customer. An absent customer makes the distinction harder to ignore.

For a founder, that is an uncomfortable form of continuity. The original problem survives each new technical possibility. Faster development changes the volume of work; agents change who performs it. Neither automatically explains whether the person at the end received something useful. Sehwail’s newer plans are an attempt to make that explanation part of the work itself.

Someone still needs to see what happened

Sehwail has separately argued that enterprise software will continue to need interfaces beyond chat. In his account, people move toward supervision: setting policies, approving work, monitoring activity and intervening. They need comparison, history and control. A conversation that scrolls away is an awkward place to keep all of that visible.

That position adds a useful tension to his ambitions for agents. More autonomous execution creates a fresh design problem for the people responsible for the result. The screen has another job to learn. It must help someone understand what was done and decide whether the next step makes sense.

There is also a question of attention. A person checking automated work has limited time, just as a new customer learning a product does. An interface can overwhelm either of them with information that is technically available and practically unhelpful. The design challenge is to bring the relevant evidence forward at a moment when someone can act on it. That makes supervision a close relative of onboarding: both require a system to understand what the person needs to do next, and to give them enough context to proceed.

The line back to the troublesome welcome message is unusually straight. Sehwail began with the cost of helping someone take a useful action inside software. He is now working on how teams understand and improve actions performed around it, sometimes by machines. The definition of a user is getting more complicated. The obligation to be useful remains stubbornly familiar.