oldwinter Scoping & Cutting
Category: Product Management
Source: https://refoundai.com/lenny-skills/s/scoping-cutting
Scoping & Cutting | Refound AI
Lenny Skills Database SKILLS PLAYBOOKS GUESTS ABOUT SKILLS PLAYBOOKS GUESTS ABOUT Product Management 15 guests | 19 insights
Scoping & Cutting Scoping is the art of fitting ambitious ideas into finite time. The best product teams don't estimate how long features will take - they set a fixed time budget and design solutions that fit within it. Aggressive cutting isn't about settling for less; it's about finding the smallest slice that delivers real value.
Download Claude Skill
Read Guide
The Guide 6 key steps synthesized from 15 experts.
1 Set an appetite, not an estimate Instead of asking 'how long will this take?' ask 'how much time are we willing to spend on this?' This flips the dynamic. With a fixed time budget (an 'appetite'), you design a version of the solution that fits. This forces creative constraint and prevents scope from expanding indefinitely.
Featured guest perspectives
"We instead have appetites. And our appetite for any individual feature is no more than six weeks. Essentially that's our budget we're willing to spend. I'm only willing to spend six weeks in any feature. So we have to figure out the simplest, most effective version of that to get that done within six weeks."
— Jason Fried "We're going to go the other way around and we're going to say, what is the maximum amount of time we're willing to go before we actually finish something? How do we come up with a idea that's going to work in the amount of time that the business is interested in spending?"
— Ryan Singer 2 Build the scooter, not the axle An MVP should be a functional, end-to-end version of a smaller value proposition - not an incomplete piece of a larger one. If you're building a car, don't build just the wheels and axle. Build a scooter first - a complete, usable product that solves a smaller job. Then iterate to bicycle, motorcycle, and eventually car.
Featured guest perspectives
"Build the scooter, not the axle. So if you're trying to build the minimum viable product for a car, don't build just the wheels and the axle, build the scooter first. And then from there, you build the bicycle, and the motorcycle, and then the car."
— Eeke de Milliano "MVP is simply for whatever the hypothesis is that we're trying to test, what is the most efficient way to get the validation we need about whether a hypothesis is true or not?"
— Eric Ries 3 Cut the list in half, then half again Founders and product teams consistently overestimate what's 'minimum' for an MVP. The first tip is simple: write out all the features you think are necessary, cut the list in half, then cut it in half again. Build that. You'll learn more from shipping something small than from planning something comprehensive.
Featured guest perspectives
"The first tip is, write out the list of features that are necessary in your MVP. Cut it in half and cut it in half again and build that. Honestly, if you just do that, that's really not that bad."
— Eric Ries "We really resist the urge to do the big V1. And I think this is... a lot of times when we're exploring something we will say, okay, well, that's cool, how do we strip away a bunch of stuff and figure out what our core hypothesis is? And then, just ship that thing first as a V1."
— Jackson Shuttleworth 4 Use deadlines as a forcing function Hard time-boxes force teams to prioritize ruthlessly. Set a fixed deadline (like a major event or earnings call) and cut scope to fit the time rather than extending the date. This removes theoretical discussions and focuses energy on what truly matters. A deadline 'trap' is one of the most effective scoping tools.
Featured guest perspectives
"I really love using the deadline trap and it makes you focused... It removes all the theoretical discussions that people have and things like that."
— Daniel Lereya "If we say we're going to give it six weeks and we give it seven or eight or nine or 10, then we're not really giving it six weeks, we're giving it 10, then we don't really have a system... If there's any work that's left over... we're at our time limit, it almost certainly dies."
— Jason Fried 5 Kill projects that aren't on track Maintain the integrity of your time constraints by letting projects 'die' if they can't be completed within their allotted window. This prevents never-ending work and the demoralization of projects that drag on indefinitely. If a project fails to ship in its cycle, return it to the shaping phase to identify what was missed.
Featured guest perspectives
"If a project is not on track to actually finish after the six weeks, we're just going to cancel it and rethink... we're not going to keep reinvesting in something that we don't understand. So, let's take this out of build mode and bring this back into shaping mode."
— Ryan Singer "We added into our product process a notion that we might pivot or cut from stuff that we put on our roadmap because it felt like once it was on the roadmap, it had to be done, and that's just not smart."
— Paige Costello 6 Use Wizard of Oz testing before building Before investing engineering resources, validate your value proposition with manual 'Wizard of Oz' testing. Use WhatsApp groups to simulate automated features, Typeform for quick feature validation, or interns coordinating manually. This lets you test conversion rates and value props without building anything.
Featured guest perspectives
"It's really this Wizard of Oz experience. We don't have to build anything. I coordinated with a bunch of interns and we were able to validate some of the value prop and conversion rates that we would expect in a subscription service."
— Crystal W "The power of having a laughably small MVP for something... In the beginning it was truly, basically, a spreadsheet, and phones, and that was it. Even that... not only had tremendous impact... but also gave us so much information about we actually needed to build that was going to be helpful."
— Zoelle Egner
✗ Common Mistakes
Using estimates as outputs instead of time budgets as inputs - this lets scope expand indefinitelyBuilding components (the axle) instead of complete small products (the scooter)Extending deadlines when projects run over instead of cutting scope to fit the timeAdding 'bells and whistles' to a V1 to ensure it wins - this prevents you from testing the core hypothesisTreating roadmap items as commitments that must be done rather than options that can be cut ✓ Signs You're Doing It Well
Teams instinctively ask 'what can we cut?' rather than 'how long will this take?'You ship complete, usable products within fixed time windows rather than incomplete piecesFailed cycles result in better scoping next time, not demoralized teamsYou can describe the specific hypothesis each MVP is testingProjects either ship on time or get killed and reshaped - nothing drags on indefinitely
All Guest Perspectives
Deep dive into what all 15 guests shared about scoping & cutting.
Anton Osika 1 quote
Listen to episode →
"A lot of jargon that I like to use to emphasize what we should be striving for is building a minimum lovable product and then building a lovable product and then building an absolutely lovable product. So I took that jargon with me in the company name." Tactical: Aim for 'lovability' rather than just 'viability' in early versionsIterate from Minimum Lovable to Absolutely Lovable
View all skills from Anton Osika →
Crystal W 1 quote "It's really this Wizard of Oz experience. We don't have to build anything. I coordinated with a bunch of interns and we were able to validate some of the value prop and conversion rates that we would expect in a subscription service." Tactical: Use WhatsApp groups to manually simulate automated featuresTest onboarding flows using simple in-app message overlays on existing screensUse Typeform for quick feature validation like personality quizzes
View all skills from Crystal W →
Daniel Lereya 1 quote
Listen to episode →
"I really love using the deadline trap and it makes you focused... It removes all the theoretical discussions that people have and things like that." Tactical: Set a fixed deadline (e.g., 3 weeks) and cut scope to fit the time rather than extending the dateUse external events like earnings calls as 'traps' to force product delivery
View all skills from Daniel Lereya →
Dharmesh Shah 1 quote
Listen to episode →
"we had a rule in the HubSpot product... that every time you added what we thought of as a knob or dial, called a feature, you had to take one out somewhere else. That's a net amount of... it just at least forces you to think about it" Tactical: Evaluate the 'third-order' cost of a feature: the dimensional complexity it adds to every future decision and chart.
View all skills from Dharmesh Shah →
Eeke de Milliano 1 quote
Listen to episode →
"Build the scooter, not the axle. So if you're trying to build the minimum viable product for a car, don't build just the wheels and the axle, build the scooter first. And then from there, you build the bicycle, and the motorcycle, and then the car." Tactical: Identify the smallest 'slice' that allows a customer to complete a valuable taskEnsure the MVP is a standalone functional product (the 'scooter') rather than a component (the 'axle')
View all skills from Eeke de Milliano →
Eric Ries 2 quotes
Listen to episode →
"MVP is simply for whatever the hypothesis is that we're trying to test, what is the most efficient way to get the validation we need about whether a hypothesis is true or not?" Tactical: Identify the core hypothesis firstDetermine the most efficient way to get validationContain the liability of making a mistake "The first tip is, write out the list of features that are necessary in your MVP. Cut it in half and cut it in half again and build that. Honestly, if you just do that, that's really not that bad." Tactical: List all features deemed 'necessary'Cut the list in halfCut the remaining list in half again
View all skills from Eric Ries →
Jackson Shuttleworth 1 quote
Listen to episode →
"We really resist the urge to do the big V1. And I think this is, I shared the streak goal example, where, a lot of times when we're exploring something we will say, okay, well, that's cool, how do we strip away a bunch of stuff and figure out what our core hypothesis is? And then, just ship that thing first as a V1." Tactical: Strip away all non-essential features to isolate the core hypothesis.Avoid adding 'bells and whistles' to a V1 just to ensure it wins; test the core mechanic first.
View all skills from Jackson Shuttleworth →
Jason Fried 2 quotes
Listen to episode →
"We instead have appetites. And our appetite for any individual feature is no more than six weeks. Essentially that's our budget we're willing to spend. I'm only willing to spend six weeks in any feature. So we have to figure out the simplest, most effective version of that to get that done within six weeks and get it done by two people." Tactical: Set a hard maximum of six weeks for any feature developmentTreat time as a budget to be spent rather than a deadline to be estimatedLimit team size to two people (one designer, one programmer) to maintain focus "If we say we're going to give it six weeks and we give it seven or eight or nine or 10, then we're not really giving it six weeks, we're giving it 10, then we don't really have a system... If there's any work that's left over that's still on the left side of the hill, meaning we're still pushing it up, we don't know how we're going to do it and we're at our time limit, it almost certainly dies." Tactical: Let projects 'die' if they aren't finished in the cycle to prevent never-ending workOnly grant extensions of a few days if the work is in the final execution phase ('downhill')Avoid the demoralization of long-running projects by enforcing strict cycle ends
View all skills from Jason Fried →
Matt LeMay 1 quote
Listen to episode →
"And they did get it done, and they got it done through subtracting. They streamlined the experience. They took out steps that people were getting stuck on. They made things easier. They did the kinds of things that are rarely celebrated in the way that traditional feature launches were celebrated, but because they had this clear, impactful, specific sense of what success looks like, they were able to take on that work themselves" Tactical: Look for steps in the user journey to remove rather than features to add.Focus on the 'commercial heart' of the business (e.g., the first successful action) when deciding what to cut.
View all skills from Matt LeMay →
Ronny Kohavi 1 quote
Listen to episode →
"Try to decompose your redesign if you can't decompose it to one factor at a time, to a small set of factors at a time. And learn from these smaller changes what works and what doesn't. ... Do them in smaller increments, learn from, it's called OFAT one-factor-at-a-time. Do one factor, learn from it, and adjust." Tactical: Break down complex projects into smaller, testable incrementsUse incremental testing to identify which specific changes in a redesign are actually providing value
View all skills from Ronny Kohavi →
Ryan Singer 3 quotes
Listen to episode →
"We’re going to go the other way around and we’re going to say, what is the maximum amount of time we’re willing to go before we actually finish something? How do we come up with a idea that’s going to work in the amount of time that the business is interested in spending?" Tactical: Set a maximum time limit (e.g., six weeks) for any project to maintain visibility and control.Vary the scope of the solution rather than the deadline to ensure shipping. "The second piece is this work that we call shaping and the shaping work is, how do we actually take this fixed amount of time that we’ve given for ourselves and vary the scope? How do we come up with a idea, some version of this that’s going to work in the amount of time that the business is interested in spending?" Tactical: Wrestle with the problem and solution simultaneously until the idea fits the time box.Identify the 'must-have' moving parts that make the feature valuable and cut the rest. "If a project is not on track to actually finish after the six weeks, we’re just going to cancel it and rethink... we’re not going to keep reinvesting in something that we don’t understand. So, let’s take this out of build mode and bring this back into shaping mode." Tactical: If a project fails to ship, return it to the shaping phase to identify hidden complexities.Avoid 'overtime' debt by treating the end of a cycle as a hard stop for reinvestment decisions.
View all skills from Ryan Singer →
Sander Schulhoff 1 quote
Listen to episode →
"Depending on what the user wants, we might be able to restrict the possible actions of the agent ahead of time, so it can't possibly do anything malicious... CAMEL would look at my prompt... and say, 'Hey, it looks like this prompt doesn't need any permissions other than write and send email.'" Tactical: Implement dynamic permissioning to restrict agent actions to the minimum necessary for a specific taskSeparate 'read' and 'write' permissions to prevent automated data exfiltration
View all skills from Sander Schulhoff →
Vijay 1 quote
Listen to episode →
"Instead of making the estimate an output of planning, you make the time box or an appetite the input, and you say, 'We want to solve X problem and we're willing to invest six weeks solving that problem.'" Tactical: Set a fixed time box (e.g., 6 weeks) for a problem and adjust scope to fitPerform a thought exercise: 'What would we do differently if we only had 4 weeks vs 8 weeks?' to find the efficient frontier of cost and impact
View all skills from Vijay →
Zoelle Egner 1 quote
Listen to episode →
"The power of having a laughably small MVP for something... In the beginning it was truly, basically, a spreadsheet, and phones, and that was it. Even that... not only had tremendous impact... but also gave us so much information about we actually needed to build that was going to be helpful." Tactical: Use existing simple tools (spreadsheets, phones) to validate a concept before building custom softwareFocus on the core utility that provides immediate impactPrune features aggressively to maintain agility as requirements change
View all skills from Zoelle Egner →
Paige Costello 1 quote
Listen to episode →
"We added into our product process a notion that we might pivot or cut from stuff that we put on our roadmap because it felt like once it was on the roadmap, it had to be done, and that's just not smart." Tactical: Formalize a process step where teams can decide to cut or pivot from items already on the roadmap.Encourage iterative shipping and prototyping to validate scope early.
View all skills from Paige Costello →
Install This Skill
Add this skill to Claude Code, Cursor, or any AI coding assistant that supports Agent Skills.
1 Download the skill
Download SKILL.md
2 Add to your project
Create a folder in your project root and add the skill file:
.claude/skills/scoping-cutting/SKILL.md 3 Start using it
Claude will automatically detect and use the skill when relevant. You can also invoke it directly:
Help me with scoping & cutting Related Skills Other Product Management skills you might find useful. 101 guests Defining Product Vision Product vision in media should center on the core content (journalism) enhanced by a user experience... View Skill → → 91 guests Problem Definition Directly experiencing the product as a user or provider reveals fundamental flaws in problem definit... View Skill → → 75 guests Prioritizing Roadmap Growth roadmaps must be sequenced based on the underlying growth model and available resources rathe... View Skill → → 55 guests Setting OKRs & Goals Avoid 'toddler soccer' (everyone chasing the same metric) by detangling goals into specific input me... View Skill → →
AI Transformation Partner
Start Your Journey
SERVICES AI Audit AI Automation AI Training COMPANY About Case Studies Book a Call
© 2026 Refound. All rights reserved.