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.

Per-seat pricing only works when your users are human. But when agents become the primary users of software, that model collapses.

Executives aren't evaluating software against software anymore. They're comparing the combined costs of software licenses plus labor against pure outcome-based solutions. Think customer support (per resolved ticket vs. per agent + seat), marketing (per campaign vs. headcount), sales (per qualified lead vs. rep). That's your pricing umbrella—the upper limit enterprises will pay before switching entirely to AI.

enterprises are used to deterministic outcomes and fixed annual costs. Usage-based pricing makes budgeting harder. But individual leaders seeing 10x efficiency gains won't wait for procurement to catch up. Savvy managers will find ways around traditional buying processes.

This feels like a generational reset of how businesses operate. Zero upfront costs, pay only for outcomes—that's not just a pricing model. That's the future of business.

The winning strategy in my books? Give the platform away for free. Let your agents read and write to existing systems through unstructured data—emails, calls, documents. Once you handle enough workflows, you become the new system of record.

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.

Building something valuable is no longer about validating a novel idea as fast as possible. Instead, the modern MVP exercise is about building a version of an idea that is different from and better than what exists today. Most of us aren’t building for a net-new market. Rather, we’re finding opportunities to improve existing categories. We need an MVP concept that helps founders and product leaders iterate on their early ideas to compete in an existing market.

It’s not good enough to be first with an idea. You have to out-execute from day 1.

The MVP as a practice of building a hacky product as quickly and cheaply as possible to validate the product does no longer work. Many product categories are already saturated with a variety of alternatives, and to truly test the viability of any new idea you need to build something that is substantially better.

Airbnb wanted to build a service that relied on people being comfortable spending the night at a stranger’s house. When they started in 2009, it wasn’t obvious if people were ready for this. Today, it’s obvious that it works, so they wouldn’t need to validate the idea. A similar analogy works for Lyft when they started exploring ridesharing as a concept.

Today, the MVP is no longer about validating a novel idea as quickly as possible. Rather, its aim is to create a compelling product that draws in the early users in order to gather feedback that you then use to sharpen the product into the best version of many.

If you look at successful companies that have IPO'd in the recent years–Zoom, Slack, TikTok, Snowflake, Robinhood–you see examples not of novel ideas, but of these highly-refined ideas.Since many of us are building in a crowded market, the bar for a competitive, public-ready MVP is much higher than the MVP for a novel idea, since users have options. To get to this high bar, we have to spend more time refining the initial version.

The original MVP idea can still work if you’re in the fortunate position of creating a wholly new category of product or work with new technology platforms, but that becomes rarer and rarer as time goes on.

Let’s jump over the regular startup journey that you might take today when building a new product:You start with the idea on how you want to improve on existing products in a category.You build your first prototype.You iterate with your vision and based on feedback from early users.You get an inkling of product market fit and traction.Optional: You start fundraising (with demonstrable traction).Optional: You scale your team, improve the product, and go to market.

In today’s landscape, you’re likely competing against many other products. To win, you have to build a product that provides more value to your users than your competition does.To be able to do this with limited resources, you must scope down your audience (and thus your ambitions) as much as possible to make competing easier, and aim to solve the problems of specific people.

When we started Linear, our vision was to become the standard of how software is built. This is not really something you can expect to do during your early startup journey, let alone in an MVP. But you should demonstrate you have the ability to achieve your bigger vision via your early bets. We chose to do this by focusing on IC’s at small startups. We started with the smallest atomic unit of work they actually needed help with: issue tracking.

We knew we wanted our product to demonstrate three values:It should be as fast as possible (local data storage, no page reloads, available offline).It should be modern (keyboard shortcuts, command menu, contextual menus).It should be multiplayer (real-time sync and teammates presence).

Remember, you’re likely not building a revolutionary or novel product. You’re unlikely to go viral with your announcement, so you need a network of people who understand the “why” behind your product to help spread the word to drive people to sign up. Any product category has many people who are frustrated with the existing tools or ways of working. Ideally you find and are able to reach out to those people.

Once you have a bunch of people on your waitlist, you need to invite the right users at each stage of your iteration. You want to invite people who are likely to be happy with the limited set of features you’ve built so far. Otherwise, they’ll churn straight away and you’ll learn nothing.

To recap:Narrow down your initial audience and build for them: Figure out who you're building the product for and make the target audience as small as possible before expanding.Build and leverage your waitlist: The waitlist is the grinding stone with which you can sharpen your idea into something truly valuable that will succeed at market, so use it effectively.Trust your gut and validate demand with your users: Talk, talk, talk to your users and find out how invested in the product they are (and if they’d be willing to pay)

complexity can make it difficult for both domain novices and experts alike to learn how to use the interface. LLMs can help reduce this barrier by being leveraged to prove assistance to the user if they’re trying to accomplish something, but don’t exactly know how to navigate the interface.The user could tell the program what they’re trying to do via a text or voice interface, or perhaps, the program may be able to infer the user’s intent or goals based on what actions they’ve taken so far.Modern GUI apps are slowly starting to add in more features for assisting users with navigating the space of available commands and actions via command palettes; popularised in software iA Writer and Superhuman.

for executing a sequence of tasks as part of a complex workflow, LLM powered interfaces afford a richer opportunity for learning and using complex software.The program could walk them through the task they’re trying to accomplish by highlighting and selecting the interface elements in the correct order to accomplish the task, along with explanations provided.

Expert interfaces that take advantage of LLMs may end up looking like they currently do - again, complex tasks require complex interfaces. However, it may be easier and faster for users to learn how to use these interfaces thanks to built-in LLM-powered assistants. This will help them to get into flow faster, improving their productivity and feeling of satisfaction when using this complex software.

unlike Clippy, these new types of assistant would be able to act on the interface directly. These actions will be made in accordance to the goals of the person using them, but each discrete action taken by the assistant on the interface will not be done according to explicit human actions - the goals are directed by he human user, but the steps to achieve those goals are unknown to the user, which is why they’re engaging with the assistant in the first place

With iA Writer 7 you can manually mark ChatGPT’s contributions as AI text. AI text is greyed out. This allows you to separate and control what you borrow and what you type. By splitting what you type and what you pasted, you can make sure that you speak your mind with your voice, rhythm and tone.

As a dialog partner AI makes you think more and write better. As ghost writer it takes over and you lose your voice. Yet, sometimes it helps to paste its replies and notes. And if you want to use that information, you rewrite it to make it our own. So far, in traditional apps we are not able to easily see what we wrote and what we pasted from AI. iA Writer lets you discern your words from what you borrowed as you write on top of it. As you type over the AI generated text you can see it becoming your own. We found that in most cases, and with the exception of some generic pronouns and common verbs like “to have” and “to be”, most texts profit from a full rewrite.

we believe that using AI for writing will likely become as common as using dishwashers, spellcheckers, and pocket calculators. The question is: How will it be used? Like spell checkers, dishwashers, chess computers and pocket calculators, writing with AI will be tied to varying rules in different settings.

We suggest using AI’s ability to replace thinking not for ourselves but for writing in dialogue. Don’t use it as a ghost writer. Because why should anyone bother to read what you didn’t write? Use it as a writing companion. It comes with a ChatUI, so ask it questions and let it ask you questions about what you write. Use it to think better, don’t become a vegetable.

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?

The reason startups are so counterintuitive is that they're so different from most people's other experiences. No one knows what it's like except those who've done it. Which is why YC partners should usually have been founders themselves.

the essence of what happens at YC is to figure out which problems matter most, then cook up ideas for solving them — ideally at a resolution of a week or less — and then try those ideas and measure how well they worked. The focus is on action, with measurable, near-term results.

A small improvement in navigational ability can make you a lot faster, because it has a double effect: the path is shorter, and you can travel faster along it when you're more certain it's the right one. That's where a lot of YC's value lies, in helping founders get an extra increment of focus that lets them move faster. And since moving fast is the essence of a startup, YC in effect makes startups more startup-like.Speed defines startups. Focus enables speed. YC improves focus.

However good you are, good colleagues make you better. Indeed, very ambitious people probably need colleagues more than anyone else, because they're so starved for them in everyday life.