Prototyping for User Validation

20 years of building software taught me this: 1 killer prototype > 10 PowerPoints. Everyone talks about validating ideas. Nobody explains how to prototype fast without burning a week. Here’s the simplest way to build a prototype without burning a sprint: 1. Map the core flow Not the whole product. Just the path from “start” → “success.” Most teams overbuild here and drown. 2. Wire real behavior Fake buttons and placeholder data hide the problems. Move real data. Trigger real state changes. 3. Run the flow like a user Click every button. Fill every field. Refresh the page. Try to break it. This is where the real requirements show up. 4. Fix the first 5 issues You’re building direction, not perfection. A prototype only needs to work once end-to-end. 5. Put it in front of someone Stakeholders. Users. Your team. A working flow sparks better decisions than any deck. And here’s where Anything Max came in handy: Instead of wiring everything myself, I described the flow, and Max built the UI, the routes, the logic, the DB model, the emails, and the tests. Then it did the part nobody wants to do: - Opened the app in a real browser - Logged in - Clicked through the flow - Found what broke - Fixed it - Ran it again If you want faster validation without blowing up your roadmap, use tools that help you prototype, not plan. I put together a guide on building a working prototype using Anything. Comment "Anything" and I'll send it over.

Prototyping is how ideas turn into evidence. It surface hidden assumptions, generate better stakeholder conversations, test specific hypotheses, reveal unforeseen interactions, and give you a concrete artifact to evaluate before code or tooling locks you in. Use low fidelity sketches and storyboards when you need speed and divergent thinking. They help teams externalize ideas, reason about user goals, and map flows before pixels appear. They are deliberately rough to avoid premature polish. Move to click through wireframes in Figma when the question is structure and navigation. Validate information architecture, menu depth, labeling, and path efficiency while changes are still cheap. When the feel of interaction matters, use interactive digital prototypes to evaluate micro interactions, timing, and visual polish. Treat them as validation instruments, not trophies. Plan change criteria up front so attachment to a pretty artifact does not silence real feedback. Some questions require real performance and materials. Coded prototypes and functional hardware mockups tell you about latency, reliability, durability, ergonomics, and safety. In medical devices and other regulated domains, high fidelity functional and contextual testing is expected for Human Factors validation. Not every question lives on screens. Experience prototyping and bodystorming put bodies in space to surface constraints that lab tasks miss. Acting out a shared autonomous ride with props reveals comfort, cue timing, and social norms. Wearing a telehealth mockup for a week exposes stigma, routine friction, and alert patterns that actually fit domestic life. Before building intelligence, simulate it. Wizard of Oz studies let a hidden human drive system responses while participants believe the system is autonomous. You learn vocabulary, trust dynamics, acceptable latency, and recovery strategies without heavy engineering. AI of Oz replaces the human with a large language model so you can study conversational realism early. Manage risks like model bias, hallucinations, and outages with guardrails and logging so findings remain trustworthy. Strategic prototypes also matter. Provotypes and research through design artifacts challenge assumptions, surface values, and force early conversations about privacy, power, and trade offs that slides tend to dodge.

Stop trying to perfect features before development. Most junior product managers fall into two traps: analysis paralysis or rushing straight into development without validation. Both are expensive mistakes. After years of working with teams, there are actually two gates you need to think about, not one. Gate 1: Validation → Is it worth building? This is about de-risking the why and what, not the how. You need evidence that users want this solution, but you'll never get 100% confidence. I assess based on cost risk, technical complexity, user impact, and business implications. For a high-risk feature? 60% confidence might be enough to move forward. For lower stakes? Even 50-50 could work. Gate 2: Specification → Is it defined enough for developers to start? They need to understand what they're building without guessing. That means clear user flows, data requirements, and integration points. But you don't need pixel-perfect designs or every edge case solved upfront. The key is collaboration. On my team at Product Institute, developers and I go back and forth off prototypes as we build. That's what keeps us agile. You're not ready when developers ask the same clarifying questions repeatedly, or debate fundamental assumptions instead of implementation details. How do you balance definition with speed in your team?

When your product team skips user research (and just builds fast with AI)... 🤡 AI lets you ship in days, not weeks. But without user research, speed just gets you to the wrong place faster. A product leader was about to ship a feature last week. AI-assisted code. Cloud deployment ready. Built in 3 days. Then someone from customer success flagged something: "This solves a problem our users stopped complaining about 6 months ago." One conversation. Saved weeks of wasted effort. We can build faster than ever. AI tools, cloud code, vibe coding—the speed is real. But speed without direction is just efficient wandering. The real question isn't "Can we ship this?" It's "Should we?" That's where user research becomes non-negotiable. Here are 5 ways to quickly validate ideas before you ship: 1. Run a 5-second test on your concept (does it communicate what you think it does?) 2. Send a quick survey to your target segment (10 questions max) 3. Do 3-5 unmoderated usability tests on a prototype 4. Interview 5 users who match your ICP (even 15-min calls work) 5. Card sort your information architecture before building navigation None of these take weeks. Most can be done in days. Tools like Lyssna make this even faster. You can recruit from 690K+ vetted participants, run moderated or unmoderated tests, and get results before your sprint ends. Speed is a competitive advantage. But only when you're building the right thing. What's your go-to method for quick validation? PS. Save this for the next time you're tempted to ship something fast without validating it first. Future you will thank you.

I posted this image last month and a lot of people asked for a breakdown — not the theory, but how each stage actually works in a real project. Here’s the reminder this visual was meant to give: Understand → Ideate → Test → Implement is not a straight line. It’s a loop. You return to previous stages every time new data proves you wrong. Example from my own work: I was designing a dashboard for a SaaS product. The UI looked polished and was already “ready for handoff,” until usability testing showed that 4 out of 6 users couldn’t correctly interpret the main metric. So we had to loop back: → Understand: clarify user mental model → Ideate: restructure hierarchy + labels → Test: validate again with a quick prototype → Implement: only then ship the updated version The design didn’t change visually — the clarity did. Task success rate went from 42% to 91%. That’s real UX. Not a clean slide with arrows — but constant informed rewinding. A few things people underestimate in real projects: • “Understand” is not only interviews — it’s business goals, constraints, and success criteria • “Ideate” is not Dribbble-style wireframes — it’s structured problem solving • “Test” is not just moderated sessions — analytics, heatmaps, and field feedback count too • “Implement” doesn’t end at handoff — onboarding, content, states, and accessibility are still design The process doesn’t fail. What fails is expecting it to work in one direction. What is your take on this? #uxdesign #productdesign #designprocess #userexperience #uxresearch #uidesign #uxworkflow #designthinking #uxstrategy #usabilitytesting #saasdesign #uxcasestudy

Most dashboards don’t fail because of bad data or bad charts. They fail because they were built too early. Someone asks for “a dashboard.” The team opens the BI tool. SQL gets written. Charts get polished. And only at the end does anyone ask the uncomfortable question: “Wait… what decision is this supposed to support?” That’s why prototyping is non-negotiable if you want dashboards that actually get used. Prototyping forces the hard thinking before the build: → What questions are we really trying to answer? → Who is this for, and what do they need to decide? → Which metrics matter, and which ones are just noise? → What level of detail is useful vs overwhelming? A simple low-fidelity prototype (even boxes and labels) does two critical things: 1 — It exposes vague thinking immediately. 2 — It lets stakeholders react to structure and logic, not colors and charts. By the time you open your BI tool, 80% of the decisions should already be made. That’s exactly why I put together this practical, no-nonsense cheatsheet for dashboard discovery and prototyping. It’s a repeatable framework to gather clean, complete dashboard requirements — without endless meetings, vague requests, or dashboards that get ignored. The guide walks you through: – Running focused user interviews – Defining business questions first – Aligning on metrics and breakdowns – Mapping data sources – Translating all of that into a clear, stakeholder-friendly layout If your dashboards aren’t getting used, don’t add more charts. Prototype better → https://lnkd.in/dxyFYdUy

Imagine spending months building a product, only to hear crickets at launch. 😱 Before coding, ask yourself: “𝘏𝘢𝘷𝘦 𝘐 𝘢𝘤𝘵𝘶𝘢𝘭𝘭𝘺 𝘷𝘢𝘭𝘪𝘥𝘢𝘵𝘦𝘥 𝘵𝘩𝘢𝘵 𝘱𝘦𝘰𝘱𝘭𝘦 𝘸𝘢𝘯𝘵 𝘵𝘩𝘪𝘴?” I once stopped a founder who wanted us to develop his product from diving into development too soon: “𝘎𝘰 𝘨𝘦𝘵 𝘱𝘳𝘰𝘰𝘧 𝘧𝘪𝘳𝘴𝘵.” So, instead of us jumping directly into coding, He tested the idea with a 𝗹𝗮𝗻𝗱𝗶𝗻𝗴 𝗽𝗮𝗴𝗲 & 𝗿𝗲𝗮𝗹 𝗰𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻𝘀 and discovered critical tweaks that saved months of effort. 🔥 𝟲 𝗪𝗮𝘆𝘀 𝘁𝗼 𝗩𝗮𝗹𝗶𝗱𝗮𝘁𝗲 𝗮𝗻 𝗠𝗩𝗣 𝗘𝗮𝗿𝗹𝘆: ✅ 𝗧𝗮𝗹𝗸 𝘁𝗼 𝗣𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝗨𝘀𝗲𝗿𝘀 - Skip assumptions. Five real conversations reveal more than weeks of guesswork. ✅ 𝗟𝗮𝗻𝗱𝗶𝗻𝗴 𝗣𝗮𝗴𝗲 𝗧𝗲𝘀𝘁 – Create a simple page & see if people sign up. Buffer’s founder validated demand this way! ✅ 𝗗𝗲𝗺𝗼 𝗩𝗶𝗱𝗲𝗼 𝗼𝗿 𝗣𝗿𝗼𝘁𝗼𝘁𝘆𝗽𝗲 – Show value before building. Dropbox’s MVP was just a 3-min video—75K signups followed! ✅ “𝗪𝗶𝘇𝗮𝗿𝗱 𝗼𝗳 𝗢𝘇” 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 – Manually deliver the service while users think it’s automated. If they love it, build later. ✅ 𝗧𝗲𝘀𝘁 𝗪𝗶𝗹𝗹𝗶𝗻𝗴𝗻𝗲𝘀𝘀 𝘁𝗼 𝗣𝗮𝘆 – Pre-orders, deposits, or dummy “Buy Now” buttons reveal real demand. ✅ 𝗠𝗮𝗿𝗸𝗲𝘁 𝗥𝗲𝘀𝗲𝗮𝗿𝗰𝗵 & 𝗖𝗼𝗺𝗽𝗲𝘁𝗶𝘁𝗼𝗿 𝗜𝗻𝘀𝗶𝗴𝗵𝘁 – If people actively seek solutions but remain unsatisfied, you’ve found a gap. 🎯 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲: Set a validation benchmark. Example: “20%+ 𝘴𝘪𝘨𝘯-𝘶𝘱𝘴 𝘰𝘯 𝘮𝘺 𝘭𝘢𝘯𝘥𝘪𝘯𝘨 𝘱𝘢𝘨𝘦 = 𝘨𝘳𝘦𝘦𝘯 𝘭𝘪𝘨𝘩𝘵 𝘵𝘰 𝘱𝘳𝘰𝘤𝘦𝘦𝘥.” 𝗙𝗼𝘂𝗻𝗱𝗲𝗿𝘀 – 𝗵𝗼𝘄 𝗱𝗼 𝘆𝗼𝘂 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲 𝘆𝗼𝘂𝗿 𝗠𝗩𝗣 𝘂𝗽𝗳𝗿𝗼𝗻𝘁?  Share your best hacks! Your tip could save someone from building something nobody wants. 💡🚀

When you’ve got a big idea, the hardest question isn’t how to build it. It’s: “Will anyone actually want this?” For non-technical founders, it’s easy to get stuck here. Do you need a prototype? A landing page? Or go straight to an MVP? Here’s a simple way to frame it: • Landing Page → Quickest way to test interest. Share your idea, add a call-to-action, and see if people sign up. • Prototype → Great for showing how the product would work. Perfect for pitching investors, advisors, or early users. • MVP → A slimmed-down version of the product that tests whether people will actually use it in real life. 👉 Examples from billion-dollar startups: • Dropbox → validated demand with just a demo video, no code. • Airbnb → tested demand with a simple website renting out their own apartment. • Uber → started as a one-city, one-ride-type app. • Instagram → grew by focusing only on photo sharing after stripping other features. • Twitter (now X) → began as an internal tool, then took off when showcased at SXSW. Think of it as stepping stones: 1. Landing page = do they care? 2. Prototype = do they get it? 3. MVP = will they stick with it? Validation doesn’t have to feel like gambling with your savings. The right tool gives you clarity, confidence, and proof that you’re solving a problem people are willing to pay for. #NonTechnicalFounders #Startups #SaaS #MVP #Prototyping #ProductValidation

Anyone can have an idea. Few can prove it will sell. One of the biggest roadblocks to product success is a lack of customer validation. It looks like this.  You have an idea > you tell everyone about it > your friends and family confirm it > you build it > no one buys To avoid this, you have to get in front of potential customers.  The traps you want to avoid include: 1. 𝗧𝗵𝗲 𝗘𝗰𝗵𝗼 𝗖𝗵𝗮𝗺𝗯𝗲𝗿  → Only talking to friends and family → Getting polite nods instead of honest feedback → Mistaking encouragement for validation 2. 𝗧𝗵𝗲 𝗣𝗲𝗿𝗳𝗲𝗰𝘁 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗙𝗮𝗹𝗹𝗮𝗰𝘆 → Spending months building in isolation → Adding "just one more feature" → Launch day becomes someday 3. 𝗧𝗵𝗲 𝗦𝘂𝗿𝘃𝗲𝘆 𝗦𝘆𝗻𝗱𝗿𝗼𝗺𝗲 → Trusting what people say they'll do → Focusing on opinions over behaviors → Collecting data that only confirms your bias To start, you have to step away from your own thinking and biased environments. Try this. ✅ 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗮 𝗽𝗿𝗼𝘁𝗼𝘁𝘆𝗽𝗲 → Build the minimum testable version  (can be done in Figma, Bolt, Lovable, etc) → Get it in front of real customers in days, not months → Learn from actual usage, not promises ✅ 𝗧𝗮𝗹𝗸 𝘁𝗼 𝘀𝘁𝗿𝗮𝗻𝗴𝗲𝗿𝘀 → Find potential customers in your target market → Watch their reaction to your prototype → Listen more than you pitch ✅ 𝗠𝗲𝗮𝘀𝘂𝗿𝗲 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝘀 → Track what people actually do → Count sign-ups, not compliments → Look for "true" conversion moments Ideally, you would have someone doing the research and outreach for you. After all, we're all biased toward our own ideas. Ideas are easy to come up with, but validated ideas are what count.  What are your thoughts on validating ideas? Share below. 👇 --- ♻️ Repost if this was helpful ➕ Follow Jason Moccia for more insights on building great products

I ran a fun workshop yesterday on Zero to Build, helping founders validate their business ideas before they build. We covered 3 things any founder or business owner can do to learn whether people want what you’re offering: 1. User & customer interviews: Get out and meet your customers. Ask about their workflows, tools, problems, and ideas. Do 10 of these and you’ll learn infinitely more than you ever could from ChatGPT or Google. 2. Demand tests: Spin up a landing page promoting your idea and the benefits it will bring to users. Focus on benefits, not features. Keep it simple. Test a single hypothesis. Include a call to action to measure engagement and collect data. 3. Prototyping: Prototypes are experimental versions of your offering, increasing in fidelity as you learn. A 1-2 hour prototype might be a landing page or social media post. A 2-5 day prototype could be a Zapier automation. A 1-4 week prototype may be a vibe coded web app. Start small, validate your riskiest hypotheses one-by-one. Then build v1 when you know people want it. Let me know if this is interesting and I’ll share more of what we covered! Thanks Makom @ The Collective for having me and to all the engaged participants.