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.

inside look at how Perplexity builds product—which to me feels like what the future of product development will look like for many companies:AI-first: They’ve been asking AI questions about every step of the company-building process, including “How do I launch a product?” Employees are encouraged to ask AI before bothering colleagues.Organized like slime mold: They optimize for minimizing coordination costs by parallelizing as much of each project as possible.Small teams: Their typical team is two to three people. Their AI-generated (highly rated) podcast was built and is run by just one person.Few managers: They hire self-driven ICs and actively avoid hiring people who are strongest at guiding other people’s work.A prediction for the future: Johnny said, “If I had to guess, technical PMs or engineers with product taste will become the most valuable people at a company over time.”

Typical projects we work on only have one or two people on it. The hardest projects have three or four people, max. For example, our podcast is built by one person end to end. He’s a brand designer, but he does audio engineering and he’s doing all kinds of research to figure out how to build the most interactive and interesting podcast. I don’t think a PM has stepped into that process at any point.

We leverage product management most when there’s a really difficult decision that branches into many directions, and for more involved projects.

The hardest, and most important, part of the PM’s job is having taste around use cases. With AI, there are way too many possible use cases that you could work on. So the PM has to step in and make a branching qualitative decision based on the data, user research, and so on.

a big problem with AI is how you prioritize between more productivity-based use cases versus the engaging chatbot-type use cases.

we look foremost for flexibility and initiative. The ability to build constructively in a limited-resource environment (potentially having to wear several hats) is the most important to us.

We look for strong ICs with clear quantitative impacts on users rather than within their company. If I see the terms “Agile expert” or “scrum master” in the resume, it’s probably not going to be a great fit.

My goal is to structure teams around minimizing “coordination headwind,” as described by Alex Komoroske in this deck on seeing organizations as slime mold. The rough idea is that coordination costs (caused by uncertainty and disagreements) increase with scale, and adding managers doesn’t improve things. People’s incentives become misaligned. People tend to lie to their manager, who lies to their manager. And if you want to talk to someone in another part of the org, you have to go up two levels and down two levels, asking everyone along the way.

Instead, what you want to do is keep the overall goals aligned, and parallelize projects that point toward this goal by sharing reusable guides and processes.

Perplexity has existed for less than two years, and things are changing so quickly in AI that it’s hard to commit beyond that. We create quarterly plans. Within quarters, we try to keep plans stable within a product roadmap. The roadmap has a few large projects that everyone is aware of, along with small tasks that we shift around as priorities change.

Each week we have a kickoff meeting where everyone sets high-level expectations for their week. We have a culture of setting 75% weekly goals: everyone identifies their top priority for the week and tries to hit 75% of that by the end of the week. Just a few bullet points to make sure priorities are clear during the week.

All objectives are measurable, either in terms of quantifiable thresholds or Boolean “was X completed or not.” Our objectives are very aggressive, and often at the end of the quarter we only end up completing 70% in one direction or another. The remaining 30% helps identify gaps in prioritization and staffing.

At the beginning of each project, there is a quick kickoff for alignment, and afterward, iteration occurs in an asynchronous fashion, without constraints or review processes. When individuals feel ready for feedback on designs, implementation, or final product, they share it in Slack, and other members of the team give honest and constructive feedback. Iteration happens organically as needed, and the product doesn’t get launched until it gains internal traction via dogfooding.

all teams share common top-level metrics while A/B testing within their layer of the stack. Because the product can shift so quickly, we want to avoid political issues where anyone’s identity is bound to any given component of the product.

We’ve found that when teams don’t have a PM, team members take on the PM responsibilities, like adjusting scope, making user-facing decisions, and trusting their own taste.

What’s your primary tool for task management, and bug tracking?Linear. For AI products, the line between tasks, bugs, and projects becomes blurred, but we’ve found many concepts in Linear, like Leads, Triage, Sizing, etc., to be extremely important. A favorite feature of mine is auto-archiving—if a task hasn’t been mentioned in a while, chances are it’s not actually important.The primary tool we use to store sources of truth like roadmaps and milestone planning is Notion. We use Notion during development for design docs and RFCs, and afterward for documentation, postmortems, and historical records. Putting thoughts on paper (documenting chain-of-thought) leads to much clearer decision-making, and makes it easier to align async and avoid meetings.Unwrap.ai is a tool we’ve also recently introduced to consolidate, document, and quantify qualitative feedback. Because of the nature of AI, many issues are not always deterministic enough to classify as bugs. Unwrap groups individual pieces of feedback into more concrete themes and areas of improvement.

High-level objectives and directions come top-down, but a large amount of new ideas are floated bottom-up. We believe strongly that engineering and design should have ownership over ideas and details, especially for an AI product where the constraints are not known until ideas are turned into code and mock-ups.

Big challenges today revolve around scaling from our current size to the next level, both on the hiring side and in execution and planning. We don’t want to lose our core identity of working in a very flat and collaborative environment. Even small decisions, like how to organize Slack and Linear, can be tough to scale. Trying to stay transparent and scale the number of channels and projects without causing notifications to explode is something we’re currently trying to figure out.

Describe things that someone can explain to someone else, or you'll miss out on word-of-mouth growth. Imagine you wandered into some party and met an investor/donor/customer named Emily. Even if you're the most persuasive person ever and she walks away from the conversation energized and excited, your time is wasted because Emily can't explain to her coworkers/friends/legislative-body what specifically she's excited about.

If Emily is a potential customer and all she heard was nothing-language, then you've gained no information. She might be interested! But that interest might only be in something she's imagined — not what you're actually making.

Nothing-language is describing your product as "an investigation into how we generate dispersed intimacy, signify alliance, and physical representations of our digital coordination praxis"1 instead of saying you're an investment fund. If you're going to "revolutionize", "create the operating system for", "build at the intersection between", "empower", "democratize", "individually flourish", or "be interdisciplinary", the universe should pause, rewind, and let you explain again. It's kind and wants you to succeed.

Be boring. Say you're "plaid for messaging apps" or "a figma plugin that generates svg icons from gpt-3" or "chrome extension that adds cmd-k to every website".

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)

Imagine, for example, that you were thinking of starting Netflix back when it was founded in 1997. How would content providers, distribution channels, and competitors respond? How soon would technology develop to open a hidden door and let you distribute online instead of by mail? Or consider Dropbox in 2007. Dozens of cloud storage companies had been started before. What mistakes had they made? How would incumbents like Amazon and Google respond? How would new platforms like mobile affect you?

When you’re starting out, it’s impossible to completely map out the idea maze. But there are some places you can look for help: History. If your idea has been tried before (and almost all good ideas have), you should figure out what the previous attempts did right and wrong. A lot of this knowledge exists only in the brains of practitioners, which is one of many reasons why “stealth mode” is a bad idea. The benefits of learning about the maze generally far outweigh the risks of having your idea stolen. Analogy. You can also build the maze by analogy to similar businesses. If you are building a “peer economy” company it can be useful to look at what Airbnb did right. If you are building a marketplace you should understand eBay’s beginnings. Etc.

Muse as a brand and a product represented something aspirational. People want to be deeper thinkers, to be more strategic, and to use cool, status-quo challenging software made by small passionate teams. These kinds of aspirations are easier to indulge in times of plenty. But once you're getting laid off from your high-paying tech job, or struggling to raise your next financing round, or scrambling to protect your kids' college fund from runaway inflation and uncertain markets... I guess you don't have time to be excited about cool demos on Twitter and thoughtful podcasts on product design.

I’d speculate that another factor is the half-life of cool new productivity software. Evernote, Slack, Notion, Roam, Craft, and many others seem to get pretty far on community excitement for their first few years. After that, I think you have to be left with software that serves a deep and hard-to-replace purpose in people’s lives. Muse got there for a few thousand people, but the economics of prosumer software means that just isn’t enough. You need tens of thousands, hundreds of thousands, to make the cost of development sustainable.

We envisioned Muse as the perfect combination of the freeform elements of a whiteboard, the structured text-heavy style of Notion or Google Docs, and the sense of place you get from a “virtual office” ala group chat. As a way to asynchronously trade ideas and inspiration, sketch out project ideas, and explore possibilities, the multiplayer Muse experience is, in my honest opinion, unparalleled for small creative teams working remotely.

But friction began almost immediately. The team lead or organizer was usually the one bringing Muse to the team, and they were already a fan of its approach. But the other team members are generally a little annoyed to have to learn any new tool, and Muse’s steeper learning curve only made that worse. Those team members would push the problem back to the team lead, treating them as customer support (rather than contacting us directly for help). The team lead often felt like too much of the burden of pushing Muse adoption was on their shoulders. This was in addition to the obvious product gaps, like: no support for the web or Windows; minimal or no integration with other key tools like Notion and Google Docs; and no permissions or support for multiple workspaces. Had we raised $10M back during the cash party of 2020–2021, we could have hired the 15+ person team that would have been necessary to build all of that. But with only seven people (we had added two more people to the team in 2021–2022), it just wasn’t feasible.

We neither focused on a particular vertical (academics, designers, authors...) or a narrow use case (PDF reading/annotation, collaborative whiteboarding, design sketching...). That meant we were always spread pretty thin in terms of feature development, and marketing was difficult even over and above the problem of explaining canvas software and digital thinking tools.

being general-purpose was in its blood from birth. Part of it was maker's hubris: don't we always dream of general-purpose tools that will be everything to everyone? And part of it was that it's truly the case that Muse excels at the ability to combine together so many different related knowledge tasks and media types into a single, minimal, powerful canvas. Not sure what I would do differently here, even with the benefit of hindsight.

Muse built a lot of its reputation on being principled, but we were maybe too cautious to do the mercenary things that help you succeed. A good example here is asking users for ratings; I felt like this was not to user benefit and distracting when the user is trying to use your app. Our App Store rating was on the low side (~3.9 stars) for most of our existence. When we finally added the standard prompt-for-rating dialog, it instantly shot up to ~4.7 stars. This was a small example of being too principled about doing good for the user, and not thinking about what would benefit our business.

Growing the team slowly was a delight. At several previous ventures, I've onboard people in the hiring-is-job-one environment of a growth startup. At Muse, we started with three founders and then hired roughly one person per year. This was absolutely fantastic for being able to really take our time to find the perfect person for the role, and then for that person to have tons of time to onboard and find their footing on the team before anyone new showed up. The resulting team was the best I've ever worked on, with minimal deadweight or emotional baggage.

ultimately your product does have to have some web presence. My biggest regret is not building a simple share-to-web function early on, which could have created some virality and a great deal of utility for users as well.

In terms of development speed, quality of the resulting product, hardware integration, and a million other things: native app development wins.

After decades working in product development, being on the marketing/brand/growth/storytelling side was a huge personal challenge for me. But I feel like I managed to grow into the role and find my own approach (podcasting, demo videos, etc) to create a beacon to attract potential customers to our product.

when it comes time for an individual or a team to sit down and sketch out the beginnings of a new business, a new book, a new piece of art—this almost never happens at a computer. Or if it does, it’s a cobbled-together collection of tools like Google Docs and Zoom which aren’t really made for this critical part of the creative lifecycle.

any given business will find a small number of highly-effective channels, and the rest don't matter. For Heroku, that was attending developer conferences and getting blog posts on Hacker News. For another business it might be YouTube influencer sponsorships and print ads in a niche magazine. So I set about systematically testing many channels.

The most powerful thing a product can do is give its user a premise.1 A premise is the foundational belief that shapes a user’s behavior. A premise can normalize actions that people otherwise might not take, held back by some existing norm

AirBnb. The premise: It’s ok to stay in strangers’ homes.

the idea of staying in strangers’ homes for short stays was doubted even by the founders. Crashing in someone’s spare room wasn’t unheard of, but it might be seen as weird, taboo, or even dangerous.

Bumble. The premise: It’s ok for women to ask men out.

The best way to follow through on a premise is to make it the core feature of the app. Bumble did, requiring that women make the first move on the app. A woman would be presented with a list of her matches and would have to make the first "move" before men could reply. This of course became a powerful differentiating feature and marketing hook.

Substack. The premise: It’s ok to charge for your writing.

Substack's premise aimed to normalize the hardest part of internet writing: getting paid. They aimed to show that independent authors could succeed at making a living (and subscription models aligned with this ethos). In doing so, Substack also made the less-hard parts of internet writing even easier. You could start a newsletter and keep it free until you felt confident about going paid. This not only normalized the end goal but also lowered the barrier to getting started.

A premise is valuable not only for “products,” but also for experiences.As I recently shouted, people still underestimate the power of giving a social event a premise. Hackathons, housewarmings, happy hours and the like are hangouts with a narrative. They have a good premise — a specific context that makes it more comfortable to do something that can be hard: socialize. (Side note: some of the best tv series and films are built on great premises.)

Premises work best on end consumers, prosumers, small business freelancers, and the like. Many two-sided marketplaces serving two of these stakeholder groups tend to have a good premise. For example, Kickstarter's premise for the creator might be: It’s ok to ask for money before you've built a product.

There are four signs your idea has legs:People pay you money: Several people start to pay for your product, ideally people you don’t have a direct connection toContinued usage: People continue to use your prototype product, even if it’s hackyStrong emotion: You’re hearing hatred for the incumbents (i.e. pain) or a deep and strong emotional reaction to your idea (i.e. pull)Cold inbound interest: You’re seeing cold inbound interest in your product

Every prosumer collaboration product, including Figma, Notion, Coda, Airtable, Miro, and Slack, spent three to four years wandering in the dark until they stumbled on something that clicked.

Of course, you shouldn’t discriminate, but when we say belonging, it has to be more than just inclusion. It has to actually be the proactive manifestation of meeting people, creating connections in friendships. And Jony Ive said, “Well, you need to reframe it. It’s not just about belonging, it’s about human connection and belonging.”And that was, I think, a really big unlock. The next thing Jony Ive said is he created this book for me, a book of his ideas, and the book was called “Beyond Where and When,” and he basically said that Airbnb should shift from beyond where and when to who and what?Who are you and what do you want in your life? And that was a part of the inspiration behind Airbnb categories, that we wanted people to come to Airbnb without a destination in mind and that we could categorize properties not just by location but by what makes them unique, and that really influenced Airbnb categories and some of the stuff we’re doing now.

I think when you're starting a company, it's really useful to ask the question, why now? And this is like, pretty cliche for startup stuff, so if you've heard of it already, apologies, but I do think it's a really useful framework. And that question of why now? Can be societal. Maybe there's some new cultural trend, perhaps it's regulatory. Some law has been passed or appealed. I like the technological version. And for us we saw drones in 2012 and WebGL as few technologies that were happening where because these technologies were happening, new possibilities were suddenly there.

But we're like, why would you do anything in photo editing if you're not on the phone? And so we felt like we were kind of building the wrong place and then eventually sort of shifted our attention to design, which I had been a design internet flipboard and that helped kind of help me realize what would be possible there.

And I would just say don't just go for an idea because it's kind of working. Go for an idea that you really care about because even if it doesn't work, you'll still learn from it and you'll still have one.