When I leave a feature out of the MVP.
How I weigh value, cost and complexity before adding something to a first release.
A first release needs a clear reason to exist. Every extra feature asks for design time, development time, and another decision from the person using it.
Start with the job people came to do.
On YAL, the central job was finding and booking a trip. The surrounding experience needed to support that: choosing travellers, coordinating with organisers, and sharing the documents needed for a trip.
That gave us a useful way to review new ideas. Did this feature help someone complete a booking or take part in their trip? Or were we starting to build a different product?
Keep the value. Change the scope.
An in-app travel photo feed was one idea we left out of the first release. People already had places to share their photos. Building another feed would have added work without being essential to booking a trip.
Instead, travellers could add their past trips and generate a branded image to share on Instagram. We kept the opportunity for self-expression and discovery, with a smaller implementation.
- Keep following organisers, because their new trips matter to travellers.
- Leave traveller-to-traveller following out of the first release.
- Use a trip group for coordination instead of adding one-to-one messaging.
Make the trade-off visible.
Leaving something out is still a product decision. I want the client and development team to understand what value we are preserving, what complexity we are avoiding, and what would make us revisit the decision.
This was a scope decision informed by competitor analysis and team discussions. We did not run user testing on this work, so I would not describe it as a validated preference.