I find myself rethinking "minimum". Instead of asking, What's the least we can do to launch? I'm asking, What's the least we can do to make people love this?

Half-baked functionality is not enough in an age where AI accelerates the product development lifecycle—people want experiences that feel intuitive, engaging, and yes, delightful.

Sometimes, it's the smallest things—a clever animation, seamless usability, or a thoughtful touch—that leave a lasting impression. An MDP isn't about perfection; it's about ensuring even the simplest version of a product creates joy. In a world of endless options, delight isn't a bonus; it's a competitive advantage.

One of the most impactful uses of LLM technology lies in content rewriting, which naturally capitalizes on these systems’ robust capabilities for generating and refining text. This application is a logical fit, helping users enhance their content while engaging with a service.

Similar to summarization but incorporating an element of judgment, features like Microsoft Team CoPilot’s call transcript summaries distill extensive discussions into essential bullet points, spotlighting pivotal moments or insights.

The ability to ‘understand’ nuanced language through summarization extends naturally into advanced search functionalities. ServiceNow does this by enabling customer service agents to search tickets for recommended solutions and to dispel jargon used by different agents.

Rather than merely focusing on content creation or manipulation, emerging applications of these systems provide new perspectives and predict outcomes based on accumulated human experiences. The actual value of these applications lies not merely in enhancing efficiency but in augmenting effectiveness, enabling users to make more informed decisions.

The challenges start from the fact that it's never a good time to do a redesign. It's hard to make it a priority. It's difficult to calculate the ROI on it. And if you run your product with A/B testing, every global redesign will tank the metrics in the short term.

The real need for redesigns often comes when you have created a successful product and it has evolved with the market and users over time.

We ship small changes daily, and something major almost every week. Every year, it's almost like a new product. This incremental way of building the product is hugely beneficial, and often necessary — though it unbalances the overall design, and leads to design debt. Each new capability adds stress on the product's existing surfaces for which it was initially designed. Functionality no longer fits in a coherent way. It needs to be rebalanced and rethought.

If your product evolves fast, you should be paying this debt every 2-3 years. The longer you wait and the more successful your product becomes, the more you will have to untangle.

Slowly the user sentiment and perception might start turning negative and you might start looking like a dinosaur incumbent. This leaves an opportunity for some nimbler player to come along and compete in your market. Companies often try to address this with brand refreshes, but if you don’t refresh the product, nothing truly changes about the experience.

While the design debt often happens in small increments, it’s best to be paid in larger sweeps. This goes against the common wisdom in engineering where complete code rewrites are avoided. The difference is that on the engineering side, a modular or incremental way of working can work as the technical implementation is not really visible. Whereas the product experience is holistic and visual. You cannot predict which path the user takes. If you update just one module or view at a time, the overall experience becomes more disjointed. Secondly, if your goal is to reset and rebalance the whole product UI and experience, you have to consider all the needs simultaneously. An incremental approach doesn’t let you do that.

I’ve never seen redesigns successfully executed without the CEO behind it. While design might have a seat at the table generally, they are usually not able to convince everyone around that table. Only the CEO can push through all the excuses and give the latitude to a project touching all of the surfaces the product needs.

The way to get the CEO involved is to tie a design reset into a larger company shift or directional change. For example, if a company is looking at a new product, or major new feature, a redesign project can be a way to imagine how it might look or feel. This can be the justification for why you need to spin up the team (and at the same time, you can make a case for updating the rest of the product experience).

Organizations are often quite stuck in their views and ways of doing things, making them less enthusiastic about something new. When I was at Airbnb, the mobile redesign project was a way to shift the company to become mobile-first. It set the tone and got the message across to the whole company that mobile was happening and that it was happening now. While it looks like an obvious change in hindsight, there were many arguments against it at the time and it took a lot of convincing. Switching to think about mobile meant the design and features had to be rethought to work in that platform.

While Linear is a smaller and younger company, we’re also undergoing a shift. The product vision has widened from a simple issue tracker to a purpose-built system for product development. We are now moving into planning workflows that naturally come before the building or execution phase of building products. This product evolution creates new future needs from the product design, and we have to make space for it.

When you realize that a design reset is needed for your product, how do you actually get started with the project? You start with a standalone team to explore the new concept design and create something the company can rally around.The auto industry has a practice of building “concept cars”, where they explore the next version of the car freely and boldly without considering practicality. A concept car sets the direction, but usually is not expected to land in production because it’s too impractical or costly to manufacture.

A secret I've learned is that when you tell people a design is a "concept" or "conceptual" it makes it less likely that the idea is attacked from whatever perspective they hold or problems they see with it. The concept is not perceived as real, but something that can be entertained. By bringing leaders or even teams along with the concept iterations, it starts to solidify the new direction in their mind, eventually becoming more and more familiar. That's the power of visual design.

The key design skill is less about beautiful all-encompassing Figma documentation with all the kinds of journey maps and personas, or mastering a “process”. It’s about being so keenly situationally aware of what unknowns are in front of you so you can pick out what tools or design activities target them precisely.

It's not helpful to think of design as process of discovering, defining, ideating and delivering (or whatever version of those double diamond steps you prefer) because following those steps often does not get you closer to a solution.

A lot of people see software as a list of features, hardware as a list of specs. But when you think about how much time we spend with these things, maybe they just aren’t that utilitarian. We think of buildings not just as volumes of conditioned air — but also as something architected, as something that can have a profound effect on how you feel, something that can have value in itself (historical buildings and such).

as I’ve wrestled with writing this, it’s clear that many just don’t see the problem, as they assume a cheap button is nearly as good as a proper dial. They’ll openly admit a dial is indeed better but a cheap button is “good enough” and that a dial is “just too expensive.” That actually may be true! There are cases when using a push button is the right choice. But not always. We need to understand when to try a bit harder. Yes, you’re spending a tiny bit more on hardware, but you’re creating a product that is usually much easier to use, reduces returns, and builds your brand which improves sales. Is this positive outcome a given? Of course not, nothing is guaranteed but we need to stop pretending there is NO COST to cheaping out on buttons.

The dial changes the frequency with a simple twist. The push button device “Deconstructs” the twist dial into two up/down buttons. Each press increments the frequency a tiny amount. This means a twist is replaced with many button presses. Again, they are ‘functionally equivalent’ but the expression and ease of use are quite different.

“Adding a feature” is never free. Always start with the user’s problems first. If pressed into using one of these four abuses, make sure to fully appreciate its impact, the friction it creates, and what you can do to work around it.  Adding a feature shouldn’t also “add a problem.”

As a professional UX Designer, I want devices to offer more. But UX Design isn’t about cramming everything into your product in the vague Hail Mary hope it’ll ship a few more units. That’s the sales team speaking, not the user. It’s the wrong motivation and creates monsters.

However the most controversial step I’ll be taking is removing a few of the functions. This usually gets pushback from most product managers as for them “features == sales”. The problem with this thinking is that it assumes a) all features are used and b) extra features has no negative impact.

You need to make your case for what the problem or opportunity is—most often validated with at least directional data and/or research insights—and why your specific solution could work. You need to ensure it weaves into broader company initiatives as well as goals for your team and org. And you need a plan to get your product out there in a timely manner along with ways you'll further learn and validate your approach. An executive team won't be thrilled to hear you want to spend a year building something based solely on a hunch.

People hire services not just based on what they can do but how it makes them feel. Quality has a direct relationship to that. Quality products can take your users from "I'm merely using this thing to accomplish a task" to "this is something I love using and I'm telling everyone I know about it."

To maintain a shared, company-wide understanding of the company's specific stance is on quality, how does quality get rewarded, celebrated and prioritized? Is there a process in place for delaying a release and having a retro when the quality bar slips? Who decides when quality has slipped? Who's accountable for addressing it?

What does quality mean to them? How does it tie into the career ladder, promotions and prioritization frameworks? Do they focus more on execution speed over quality?

Is quality baked into the normal product development process, or is it often relegated to low priority "polish" tickets that pile up.

Do different roles (like engineering, product, design) have different motivations for getting their work done? This, again, ladders up to what the org thinks about quality.

Liberal use of "MVP" or "it's just an experiment". Does the team use those terms to skirt around typical quality standards and ship something subpar? Does everything worked on, even experiments, demand the same care as a more mainstream release that goes out to all users? That's a slippery slope because it's all too easy to simply ramp up that experiment to 100% of your users if it performs well, without addressing quality issues that were neglected prior to shipping to that initial set of users. No one wants a slice of cake that is just a piece of the bottom layer. You need to have a taste of each layer with each bite, including the icing. So even if it’s not your entire vision, it has all the right pieces involved. Ditch the term MVP and use SLC (Simple, Lovable, Complete).

I’m not saying designers, PMs and engineers should be holding up their projects for months to “get it right”. I'm saying that teams should be working in a way where everything is considered and there's a framework for identifying, discussing and prioritizing quality-related issues so that quality is a bit less of a sisyphian task.

Does your team have the skills and incentives to identify and adequately fix those issues? Does the organization continually reinforce and celebrate work that ladders up to quality, craft and great design?