Scoping Cutting

# Scoping & Cutting - All Guest Insights

*15 guests, 19 mentions*

---

## Anton Osika
*Anton Osika*

> "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."

**Insight:** Shift the focus from 'Minimum Viable Product' to 'Minimum Lovable Product' to ensure the initial release resonates emotionally with users.

**Tactical advice:**
- Aim for 'lovability' rather than just 'viability' in early versions
- Iterate from Minimum Lovable to Absolutely Lovable

*Timestamp: 00:00:31*


## Crystal W
*Crystal W*

> "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."

**Insight:** Use manual 'Wizard of Oz' testing to validate product value propositions before investing in engineering resources.

**Tactical advice:**
- Use WhatsApp groups to manually simulate automated features
- Test onboarding flows using simple in-app message overlays on existing screens
- Use Typeform for quick feature validation like personality quizzes

*Timestamp: 00:14:46*


## Daniel Lereya
*Daniel Lereya*

> "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."

**Insight:** Setting hard time-boxes (traps) forces teams to prioritize the core value and prevents 'death by a thousand cuts' from over-engineering.

**Tactical advice:**
- Set a fixed deadline (e.g., 3 weeks) and cut scope to fit the time rather than extending the date
- Use external events like earnings calls as 'traps' to force product delivery

*Timestamp: 00:53:48*


## Dharmesh Shah
*Dharmesh Shah*

> "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"

**Insight:** To fight product entropy, enforce a 'one-in, one-out' rule for features to keep complexity constant.

**Tactical advice:**
- Evaluate the 'third-order' cost of a feature: the dimensional complexity it adds to every future decision and chart.

*Timestamp: 00:41:00*


## Eeke de Milliano
*Eeke de Milliano*

> "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."

**Insight:** An MVP should be a functional, end-to-end version of a smaller value proposition, not an incomplete piece of a larger one.

**Tactical advice:**
- Identify the smallest 'slice' that allows a customer to complete a valuable task
- Ensure the MVP is a standalone functional product (the 'scooter') rather than a component (the 'axle')

*Timestamp: 00:47:34*


## Eric Ries
*Eric Ries*

> "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?"

**Insight:** An MVP is a validation tool for a specific hypothesis, not just a low-quality version of a product.

**Tactical advice:**
- Identify the core hypothesis first
- Determine the most efficient way to get validation
- Contain the liability of making a mistake

*Timestamp: 00:28:22*

---

> "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."

**Insight:** Founders consistently overestimate what is 'minimum' for an MVP; aggressive cutting is required to reach a true baseline.

**Tactical advice:**
- List all features