Practical Handbook for Product Developers – First Steps: Idea, Validation, MVP – Fake it ‘till You make it
An MVP isn’t about building less — it’s about learning fast by making users believe the value exists before fully automating it.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
📚 Previous on this series
⏩ Section 1 - First steps: Idea, Validation, MVP
1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP
2️⃣ Chapter 2 – Simple Solutions First
2️⃣ Chapter 3 – Fake it ‘till You make it → You’re here.
3️⃣ Chapter 4 – Validating the problem/opportunity vs validating the solution → Coming next week!
🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.
🔎 Scenario / Pain Point
In the rush to ship, many startup teams fall into the trap of over-building early. They design for scale before they have one user, set up full production infrastructure before they’ve confirmed the core value, and build features that only make sense “when we reach 10K users”. Meanwhile, the rest of the business is experimenting, iterating, learning — and the engineering team is stuck trying to perfect architecture.
The core mistake here is confusing product with project. A project is “build this spec, then ship”. A product is “deliver one slice of value, learn, then evolve”. When you treat an MVP like a full release, you end up with a large, slow, expensive version that validates nothing.
Instead, what an MVP needs is to validate the solution, not just the idea. And if you build everything as if you already have full automation, you lose speed. You lose learning. That’s where the principle of “Fake it till you Make it” comes in: build what users see, but you might handle the value delivery manually or semi-automatically behind the scenes. Think “Wizard of Oz” architecture or “Concierge MVP” where you simulate the final product with human operations.
With a 30-60 day window to launch a viable MVP, you cannot wait to build perfect systems. Your architecture must be evolutionary: start with a walking skeleton and enable real learning before you scale. Build simple, see what works, then evolve. If you don’t, you risk being slow because you over-engineered before you even had clarity.
⚡ Why it matters
When you shift to this mindset, you free your team from the tyranny of “perfect first”. You align with speed, feedback and learning. Here’s why the principle is critical:
Research & tech spikes speed things up. Instead of choosing a new framework on day one and rewriting later, experiment quickly to see what works — then scale. Otherwise you invest time in tech decisions you may never use.
Prioritize features for learning, not completeness. With a list of IN vs OUT items you guarantee that, if time becomes the blocker, you have done the value delivery first. If you wait too long on secondary features, you ship no value.
Keep a list of non-must features anyway. Just because they’re out now doesn’t mean you forget them. Documenting the OUT list allows future scope decisions to reference it rather than start from scratch.
Features must themselves be “MVP versions”. A feature isn’t finished when it’s built; it’s finished when it validates the problem. If you only need two operations, don’t build a full suite of six. Simplify.
Build to learn, not to perfect. An architecture that evolves wins over one that’s built for all possible use-cases. Evolutionary architecture + walking skeleton = start small, adapt often.
🛠️ How we solve it
Here are practical steps to apply “Fake it until you make it” within your MVP:
Create your walking skeleton. Build a thin vertical slice of functionality that works end-to-end: UI ➝ business logic ➝ backend ➝ deploy. Even if manual behind the scenes, the slice must deliver real value to a user.
Adopt an evolutionary architecture mindset. Don’t build the entire platform up front. Start small, code by the team, evolve as real data justifies it.
Identify your core feature and map manual delivery. Pick the one feature that validates your solution. If automation takes too long, deliver manually for now and mark “automate later”.
Classify all other features into must-have vs nice-to-have. If you have more than 5 must-haves, revisit: tie each back to your core problem. For example: do you really need your own login system or can you reuse one?
Use “Fake it” experiments like fake-doors, concierge or manual-first delivery. Add a “Pay now” button for a feature that doesn’t exist yet, manually onboard users, manually generate results. Learn their behaviour before coding full stack.
Document scope clearly: IN / OUT with reasons. You’ll avoid endless debates and keep the team aligned. When stakeholders push “just one more feature”, you refer to the documented list and explain trade-offs.
Always ask: is this a one-way door or a two-way door decision? If reversible, act now. If irreversible, delay until you have data. Engineering in MVP mode thrives on reversible decisions.
⚖️ Trade-offs
Too minimal ➝ you’ll refactor later; acceptable if you learn quickly.
Too elaborate ➝ you get stuck in build-mode and learn nothing; dangerous.
Manual delivery (fake) is fast, but if you don’t automate or evolve, you risk poor scalability or user experience.
Evolutionary architecture requires discipline, else you accumulate technical debt because you didn’t set boundaries.
Simulations are valid, but must still deliver user value — fake for speed, not for deception.
🚀 Next Steps (tomorrow morning)
Highlight 3 major technical assumptions your team is making (e.g., “we will need multi-tenant DB”, “we need custom workflow engine”, “we need full AI pipeline”). Decide which are one-way vs two-way doors.
Define one thin slice: pick a single user flow that delivers value now, automate none or very little, deliver manually if needed. Map what parts are manual vs automated.
Write your IN / OUT feature list: mark clearly what must be done for launch and what you’ll purposely exclude. Publish the list to the team and stakeholders for alignment.
📎 Primary Resources
Fake Doors MVP — Tomer Sharon (Medium)
16 Techniques to Validate & Improve Your MVP — mobileLIVE blog
What is a Minimum Viable Product? – Ironhack blog
What is one feature you’re simulating manually right now — and why?
Reply to this email: I’d love to hear how you’re “faking it” to learn faster.