The Weekly Marketable Feature
Every engineer ships one feature per week that a user would pay or show up just for
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
Instead of measuring engineering by activity or by large multi-week epics, set the standard that every engineer must ship one 'marketable' feature per week — a feature novel enough that a user would come to or subscribe to the app purely for it. This forces radical scope-cutting, generates high volume of shots-on-goal, and lets the team double down only on the ones users actually adopt.
Origin
Gaurav Misra's operating model at Captions, informed by his years running design engineering at Snap where small teams shipped rapid prototypes into production.
Core principles
- 01A 'marketable' feature is one you can show users who will then come to or pay for the app just for it — not table-stakes work like text justify-alignment
- 02Ship MVPs, not complete features; the first week's version is deliberately incomplete
- 03High volume of weekly releases surfaces which directions actually work
- 04Double down only on features that show traction; let the rest die
- 05User complaints after shipping are the signal of what to build next week
How to run it
- 1
Define the marketable bar
For each proposed feature, ask: is this novel enough that a user would come to the app or subscribe purely for this? If it is obvious table-stakes functionality every competitor already has, it does not qualify.
Pro tip Contrast 'justify alignment in a word processor' (nobody switches apps for it) with something nobody else has done (people jump over missing basics to try it).
- 2
Reslice to the MVP core
Take the design and cut relentlessly until removing anything more would make it useless. Ship that irreducible core within the week.
Watch out Accept that the shipped version will be visibly incomplete and will draw complaints — that is by design.
- 3
Ship weekly across the whole team
Hold every engineer to one marketable feature per week, producing a large volume of features and directions.
Watch out Do not compromise quality to hit the deadline — cut scope instead (see Cut Scope Not Quality).
- 4
Read adoption and complaints
Watch which features users actually use despite their rough edges, and collect the specific complaints. Complaints reveal both product-market fit and the exact next week's work.
Pro tip People complaining is a strong PMF signal — they care enough to complain. Silence is the bad outcome.
- 5
Double down or kill
Expand the features showing traction into fuller products; abandon the ones nobody engaged with.
Pro tip Shipping all the complained-about fixes the very next week makes users feel the team is hyper-responsive.
In the wild
Misra describes building an 'add an image to your video' feature. A designer would naturally spec background removal, hue/saturation, cloud/drive import. They cut all of it down to a native camera-roll picker that drops the image straight into the video with no UI. If that core is not useful, nothing built on top of it would be either.
→ The stripped core ships in one week; user complaints then dictate which of the cut features (e.g. background removal) to add next.
Common mistakes
Treating the weekly feature as a finished product
The point is an MVP that exposes real user reaction, not a polished release. Trying to ship complete features breaks the weekly cadence.
Marketing table-stakes work
Shipping obvious features nobody switches apps for wastes the cadence — the feature must be genuinely novel to earn attention.
Is it for you?
Best for
AI-era startup engineering teams that need to stay above the noise by constantly shipping novel, attention-grabbing capabilities
Not ideal for
Mature products, regulated/safety-critical software, or infrastructure-heavy work where weekly user-facing novelty is neither possible nor desirable
From the transcript
“our engineering goal is every engineer should ship a marketable product every week”
“it's a product that you can show to users and the user might subscribe or pay for the app just for that”
“we take the design and we cut cut cut until we can really say that it's going to be useless if we cut anymore”
“if things are going well people will use it despite all the problems that it might have and now people will complain and we'll have…”
“things that start to work we double down on those things build more”
From the episode
How to win in the AI era: Ship a feature every week, embrace technical debt, ruthlessly cut scope, and create magic your competitors can't copy
Gaurav Misra (CEO and co-founder of Captions)