Scope-by-Time Traps
Box work by a fixed deadline, cut scope to fit, and ship early enough that the feedback is 'this is premature'
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 93%
Set a fixed time box (a 'trap') for a piece of work — three weeks, or an external commitment like the next earnings call — and cut scope to hit it rather than extending time. Getting real users on it fast beats polishing, because more time creates more invented assumptions. The ideal early feedback is 'this is premature, we need more' — that proves you shipped focused rather than over-built.
Origin
Daniel Lereya's practice at monday.com, which he connects to Ryan Singer's Shape Up appetite-over-deadline method (from Basecamp) after Lenny raises it — though Lereya says he wasn't previously familiar with Shape Up.
Core principles
- 01Scope work by time, not by effort — commit the deadline up front and cut scope to fit
- 02More time creates more questions, complications, and invented assumptions about what users need
- 03The scary moment of putting real work in front of users is exactly the moment worth forcing
- 04'Wow, what an amazing product' is bad feedback for an early release — it means you built too much
- 05A deadline removes theoretical discussions and forces the team onto the core of the value
How to run it
- 1
Set the trap: a fixed deadline
Commit to a fixed window before starting — e.g. 'we have three weeks,' or an external anchor like 'we announce this at the next earnings call.' The deadline is the constraint; scope flexes.
Pro tip An external commitment (earnings, a customer date) sharpens focus more than an internal one because it's non-negotiable.
Watch out Watch the bottom-up planning dynamic: people turn 'what can go wrong?' into a sport, get fear-driven, and pile on content until the thing would ship in two years.
- 2
Cut scope to the core of the value
When the work won't fit the box, cut scope — don't extend time. Ask 'what can we ship to this earnings?' and let that reframe the whole conversation onto the essential value.
Pro tip The reframe from 'ship everything' to 'ship the core by the date' is what removes the theoretical debates.
Watch out Adding to every corner of the product is 'death by a thousand cuts' — each area gets more than it needs.
- 3
Ship early to real users, even if premature
Release the first alpha/version to real users even when every instinct says wait. Take customer feedback in context — sometimes you deliberately learn only from paying users who get real value.
Pro tip For enterprise products where you 'have every reason to wait,' shipping the premature alpha and getting precise gap feedback is a win worth praising the team for.
Watch out Not every customer feedback point is the one that drives the best product — separate the wheat from the chaff (paying users are a strong signal of real value).
- 4
Read the feedback as a build-quantity signal
Interpret the response: if the feedback is 'this is premature, we need this and this,' you shipped focused. If it's 'what an amazing product,' you probably over-built and under-focused. Then keep iterating on the real gaps.
Pro tip People complaining is a sign they care — no complaints can mean they don't care about what you built.
Watch out Don't stop at version one — continue iterating according to the feedback; the trap starts the loop, it doesn't end it.
In the wild
Building a new enterprise work-management offering (managing tens of thousands of employees and thousands of projects), monday.com had every enterprise reason to wait for comprehensive value. Instead they used a deadline trap and shipped an early alpha to big customers.
→ Customers responded 'this is premature, we need more comprehensive value' but specified exactly what — feedback Lereya calls priceless, and he told the teams 'well done' for shipping rather than polishing for three more weeks.
Common mistakes
Chasing 'just three more weeks' for a better product
Believing one, two, or three more weeks will yield a materially better product is, in Lereya's experience, 'not true' — the extra time mostly generates invented assumptions and complications, not value.
Treating universal praise as success
If early users say 'what an amazing product,' it likely means you built too much and the product isn't focused enough — the death-by-a-thousand-cuts trap of over-adding to every corner.
Is it for you?
Best for
Product teams that repeatedly overrun on features and redesigns (the six-months-on-a-landing-page problem) and need to force focus and fast learning
Not ideal for
Work where a premature release causes real harm (safety-critical, regulated, or trust-destroying first impressions) and scope genuinely cannot be cut
From the transcript
“put preps for themselves that is cop by time and not by effort”
“many times using like the setting traps mechanism of saying listen we have three weeks let's think about it and scope it by time it…”
“we really love the fact of this is not a good product”
“let's say now as a public company we say listen we are working on something we want to announce it on the next earning and…”
“when you build a lot of features this can be like you know the death by thousand cuts”
From the episode
Inside monday.com’s transformation: radical transparency, impact over output, and their path to $1B ARR
Daniel Lereya (Chief Product and Technology Officer)