Practical Handbook for Product Developers – First Steps: Idea, Validation, MVP – Validating the problem/opportunity or the solution?
Are you still in the problem space or you already are in the solution space for your product? Here’s how structuring your discovery can reduce waste and increase your odds of success
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
3️⃣ Chapter 3 – Fake it ‘till You make it
4️⃣ Chapter 4 – Validating the problem/opportunity or the solution? → You’re here.
5️⃣ Chapter 5 – Features prioritization strategies → 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
You’ve got a glimmer of an idea—a tech-startup moment of insight. Maybe you saw a process that drags on, a customer always complaining, a manual workflow that could be digitised. So you dive straight into building. You sketch the UI, pick your tech stack, start writing code. But after weeks or months you realise: users don’t care as much as you thought. Or the value you promised doesn’t land. Why? Because you validated the solution, not the problem.
When you jump to solution-mode too fast, you’re building “just in case” instead of “because.” You assume the underlying problem is big, urgent and unserved. You assume your proposed solution will work. But if those assumptions aren’t true, you’ll have built fast — and failed faster.
The right order is:
Validate that the problem/opportunity exists and is meaningful.
Only then validate if your chosen solution addresses it in a way users will adopt.
For example: if you believe “small business time-tracking is broken” (problem) you validate that first — ask how often they track, what they hate, what they do instead. Once you see urgency, a workaround, willingness to change — then you build “our time-tracking app.” If you built the app first, you risk discovering they’re okay with spreadsheets and don’t care about switching.
The cost of skipping intention is high: you end up locked into technical choices (one-way-doors) before you know you had a market problem. Meanwhile you miss flexible, reversible decisions (two-way-doors) that would have given you speed and cheap learning.
⚡ Why it matters
Getting this order right matters because it dramatically changes your odds of success and the shape of your technical and product decisions.
Reducing waste early. Validating a problem costs far less than developing a full feature set. As one article puts it, one of the top reasons startups fail is “solving problems nobody cares about”.
Keeping your options open. If you validate the solution too early, you may lock in architecture, UI flows and tech stack before you understand usage. Two-way‐door decisions (e.g., UI layout, backend choice) should happen early; one-way‐door decisions (e.g., core database, major business model) should wait for problem/solution validation.
Aligning product, business and tech. Validating the problem means you understand user desire, pain severity and willingness to switch. That clarity helps you choose the right scope, the right features and the right metrics. Then—you build the solution with discipline and speed.
Shaping your business model correctly. If the problem isn’t urgent, your solution may not be paid for or adopted. Validating the problem ensures that when you validate the solution, you’re testing something meaningful—not vanity features.
Making simpler, faster architecture and MVP choices. When the problem is clear, you can build a walking skeleton, adopt evolutionary architecture and keep the scope thin because you’re focused on learning one thing well—not shipping everything poorly.
🛠️ How we solve it
Here’s a practical roadmap you can apply.
1️⃣ Formulate your hypothesis
Write it as a testable statement:
“We believe [user segment] has [problem] that causes [pain], and they are willing to pay/use [solution].”
Make it concrete and falsifiable — if it can’t be disproved, it’s not a hypothesis.
2️⃣ Validate the problem first — fast and cheap
Talk to humans before writing code. Do 5–10 user interviews focused on pain, frequency, and urgency. Avoid showing your solution idea too early — you’ll bias feedback.
Use AI/no-code tools for discovery, some examples:
🧩 Typeform, Google Forms or Fillout for quick surveys.
🌐 Carrd, Webflow, or Framer for simple landing pages.
🤖 Lovable or Bolt.new to quickly create an MVP or “realistic prototype”
📣 Run small ad experiments on Google or Meta to test demand (“Sign up for early access”).
Leverage AI for insight extraction:
Use ChatGPT or Perplexity to summarize user interviews, cluster recurring pain points, and detect language patterns (“What words do users use to describe this problem?”).
Feed transcripts into a vector DB (e.g., Supabase + OpenAI embeddings) to query later.
Measure signals, not opinions. Count how many people click, sign up, or reply “I’d pay for this.” Interest is a better signal than agreement.
Keep everything flexible: at this stage, nothing should require hard technical choices.
3️⃣ Define and validate the solution only once the problem signal is strong
When you have evidence the problem is real and painful, define the smallest possible solution that proves your hypothesis.
Start with one feature. The core capability that directly addresses the pain. Anything else is out.
Prototype with low-code and AI first:
Use Bubble, Glide, or Softr to build the working prototype.
Use Zapier, n8n, or Make for quick process automation behind the scenes.
Use AI code assistants (e.g., Replit AI, GitHub Copilot, v0.dev, Lovable) to generate UI scaffolds or backend templates in minutes.
Simulate or semi-automate when needed (Wizard-of-Oz MVP):
Example: accept user inputs but process them manually in a spreadsheet for early users.
Replace the manual step with code only when it becomes the bottleneck.
For coded parts, keep architecture evolutionary:
Use a single repo and a walking skeleton that runs end-to-end from day one.
Keep layers thin and replaceable — one service, one database.
Automate deployment early (CI/CD) to build confidence while staying lean.
Delay irreversible design choices (one-way doors) until you have user data.
The goal is to validate value, not to build infrastructure.
4️⃣ Keep tech and feature choices reversible
Tag every decision: one-way or two-way door.
One-way: foundational architecture, data model, contracts — delay.
Two-way: landing page copy, component layout, integration provider — decide fast.
Use no/low-code tools deliberately:
Treat them as temporary scaffolding: something to replace later when scale or cost demands.
Or, if they prove stable and cheap to maintain, integrate them safely as part of your long-term system — encapsulated behind APIs, monitored, and versioned like any other component.
Budget their replacement upfront. Assume every no-code component has a future rewrite cost. Document it and track it as technical debt, not surprise.
5️⃣ Document everything
Keep a single, living document (Notion, Linear, Confluence — doesn’t matter) with:
✅ The problem and solution hypotheses.
📊 Metrics and signals that confirm or disprove them.
🚪 Decision logs: what’s in/out, what’s a one-way door, what’s temporary.
This discipline gives you clarity when you revisit assumptions or scale up.
⚖️ Trade-offs
Problem first but no solution build → you may validate pain but miss testing whether your proposed approach actually works. Eventually you still need to build the solution.
Solution too early → you may build great code for a non-problem. The product might be technically perfect but commercially dead.
Manual or simulated delivery → fast and cheap, but must be replaced or scaled later or you risk reputation and user experience issues.
Delaying too many one-way-door decisions → can slow things down if you never decide. Balance is key.
🚀 Next Steps (tomorrow morning)
Write your hypothesis for the problem in one sentence. Share it with your team and commit to validating or refuting it.
List the pain indicators you expect: how often, how urgent, what alternative do users use now. Run a quick survey or landing-page test to measure one indicator by end of week.
Identify one two-way-door decision you can make in the next 48 hours (e.g., landing page design, workflow stub). Decide, implement, learn. Mark all other one-way doors and postpone them until you gather more evidence.
📎 Primary Resources
Sam Dickie — Start with Problem Validation, NOT Solution Validation.
Juan Jesús Velasco — The Importance of Validating Problems Before Building the MVP.
iTonics Innovation Blog — 6 MVP Types for Validating Complex New Products and R&D.
Which assumption about your product are you validating this week — the pain or the approach?
Reply to this email and share your hypothesis. I’ll pick a few for a follow up on a Linkedin post!