Cited from real sources 6 min read Written by Arun Agrahri Updated October 2026

A framework by Dylan Field

Dylan Field's Minimally Awesome Product for Founders

Dylan Field's Minimally Awesome Product is his bar for a first release. An MVP clears when users put up with it. His bar clears when one part of the release is good enough to talk about and the rest shows where the thing is going. Same speed. Higher floor.

Best for: Founders who keep delaying launch and want a first-release bar that ships fast and still gets talked about
Price: Free to read. To apply it to your own situation, Gavel has a free plan; Plus is $19/mo.

The framework

Awesome is a floor, not a finish line

Field learned the launch trade-off from Evan Wallace, who built Figma's rendering engine with him. He still repeats it as a rule of three.

For any new launch you got quality, features, deadline. Choose two.

Field, on the rule his co-founder taught him Watch at 29:35

Most teams drop quality, because quality has no launch date attached to it. Field drops features. Software keeps shipping after launch, so scope is the thing you can add later. A reputation for shoddy work is not.

That leaves a small release with a real bar on it.

I think you have to know when you're introducing a new thing what it's going to take, and then to make that minimally awesome product.

Field, naming the bar at Config Watch at 30:13

Awesome here does not mean finished. It means one part of the release is good enough that a user tells someone else about it. Everything else can be table stakes.

The obvious failure mode is the one Field names himself, before anyone else can.

The lesson is not okay, how do I make the awesome thing? I'm going to sweat every detail and I'm never going to ship.

Field, on the trap inside his own advice Watch at 43:59

He has the receipts for that one. Figma started in August 2012 and made its first money in the summer of 2017. Field's word for the whole run is too long.

Practice

How do you decide what the awesome part is?

Pick the one thing a user would repeat to a colleague. Hold the bar there and let the rest of the release be plain.

Say the differentiator out loud before the sprint.

A month out from launch, FigJam worked and bored everyone who used it. Field took that to his team and the board. They came back with one word: fun.

Run one design sprint against that word.

Figma got about twenty ideas out of that day. Cursor chat came out of it and turned into one of the things people know FigJam for.

Cut the epic to a one or three month cadence.

Field scopes work down until a real user can react inside a quarter. A year-long epic hides the quality question until the answer costs too much.

Spend the quality budget on time to value.

He measures how fast a new user reaches the moment the product exists for. In Figma that is a blank canvas becoming a thing you made with someone else.

Staff a blockers team, not just a features team.

Figma ran a team called blockers that struck adoption problems down one by one. Retention and activation moved on the graph after each fix.

Live on it for a week before the clock starts.

Figma's rule is that a major release survives real daily use inside the company first. A week on it finds the gap between a demo and a tool.

Ship it, then charge for it.

Field's advice on his own delay is blunt: go faster. Get to market and take money. Let the next release carry the scope you cut.

Conditions

When does the higher bar cost you?

The bar assumes you already know the problem is real. Field had that signal long before Figma charged anyone. Designers kept pulling features out of the team. He reads that pull as the cue to double down, not to keep testing.

Works best when

Buyers already own a tool that works and switching is the hard part
You know the problem is real and the open question is whether people move
One visible thing can carry the whole vision for the release
The product is software, so you can add the cut scope back later

Fails when

Nobody has confirmed the problem, so polish tests your taste and not demand
Awesome becomes the reason to sweat every detail and miss the date
The bar sits on a feature most users never reach
The team picks all three of quality, features and deadline

The first row on the left is where the fight is. Garry Tan's launch-jankiest rule says the opposite: put out the roughest thing that delivers value and let reaction decide. For a problem nobody has named yet, he is right. Figma launched into a market that already had Sketch and Illustrator, where a rough build would have proved nothing.

The two bars answer different questions. Eric Ries sizes an MVP by the experiment it runs, so polish that changes no answer is waste. Field is sizing a release that has to win a user off a tool they already like.

Primary sources

Where Field discusses this

Two long conversations. He names the bar on stage at Figma's Config. A 2025 interview covers what holding it costs.

30:13

Timestamp

Dylan Field · Lenny's Podcast

Defining Product Quality and Deadlines

"you have to know when you're introducing a new thing what it's going to take, and then to make that minimally awesome product"

43:27

Timestamp

Dylan Field · Lenny's Podcast

The Importance of Speed and Avoiding Over-Optimization

"it's not enough to have the MVP. You got to have something that's a little bit awesome at least"

27:49

Timestamp

Dylan Field · Lenny's Podcast

The Strategy of 'Making Fun' a Differentiator

"The team was like, what, we're gonna make fun our differentiator? In retrospect it was absolutely the right move."

42:26

Timestamp

Dylan Field · Lenny's Podcast

Prioritizing 'Time to Value' and Removing Blockers

"we literally at some point had a team that was called blockers and they just went and one by one struck them down"

Where experts disagree

Where operators disagree: hold a quality bar, or ship the roughest thing that works?

Dylan Field

argues the MVP bar is not enough on its own. Software keeps shipping after launch, so he cuts features rather than quality and insists one part of a first release be good enough that a user repeats it to someone else, because that part is what carries the vision the release cannot yet deliver.

Garry Tan

says put out the jankiest version that still delivers value and let real reaction decide, on the grounds that fear of launching kills more startups than competition does. Polish before contact with users is time spent on assumptions.

The condition is whether buyers already have something that works. Tan probe answers whether the problem exists, and in a young category a rough build gets a clean read. Figma launched against Sketch and Illustrator, where the open question was not whether designers had the problem but whether they would switch, and a rough build there measures your polish instead of their demand. Field bar is also not permission to keep building: he names the trap himself, that chasing the awesome thing means sweating every detail and never shipping.

Useful? Send it to whoever is about to call a rough build an MVP and ship it.

Want the full playbook?

Get 128 product management frameworks.

34 frameworks 21 rules 65 heuristics & principles 49 operators

From Stewart Butterfield, Ami Vora, Codebase Guidelines, and 46 more. Drop one .md into Claude, Cursor, or ChatGPT. Your AI cites practitioners, not guesses.

See the pack

Instant .md download · One-time purchase · No subscription

Related frameworks

Shipping

Weekly Review

David Allen

Once a week, get every list and project current so your head can let go. An hour or two buys the rest of the week.

Shipping

Habit Stacking

James Clear

Pin a new habit to one you already do every day: after I make my coffee, I will meditate for 60 seconds.

Shipping

Time Blocking

Cal Newport

Run the workday from a schedule, not a to-do list. Give every minute a job in advance, redraw the plan when it breaks, and stop at the shutdown.

Shipping

Levels of AI Autonomy

Amjad Masad

Grade a coding tool by how long it runs before it needs you. Level one is a language server, level five is a thousand agents.

Awesome is a floor, not a finish line

How do you decide what the awesome part is?

Say the differentiator out loud before the sprint.

Run one design sprint against that word.

Cut the epic to a one or three month cadence.

Spend the quality budget on time to value.

Staff a blockers team, not just a features team.

Live on it for a week before the clock starts.

Ship it, then charge for it.

When does the higher bar cost you?

Works best when

Fails when

Where Field discusses this

Where operators disagree: hold a quality bar, or ship the roughest thing that works?

Get 128 product management frameworks.

Know when the next expert lands.