Prototype Iteration Cycles

A CAD section view in real life! This was an over-molded 3D printed bottle prototype that we did for Emulait several years ago. Here's a few things we learned when building these samples: Thin silicone is difficult to prototype - no joke. It's extremely challenging (read expensive) when outsourcing, as most shops want to cut aluminum tools due to the thin wall. Some of the areas have 0.6mm wall section, and it was a complex over-mold to begin with due to the stiffening/threaded ring. So we had to learn how to vacuum cast in our shop using disposable PLA tools in order to have the ability to fail-fast and iterate rapidly. Layer lines are not a big deal on functional prototypes. We used aluminum tooling once the function was approved. Waterclear SLA is possible, I used my vendor in China to build these parts. They sanded and spray-coated the SLA parts with SLA resin to give them a glassy sheen. Formlabs 3D printers are incredible for highly accurate, watertight parts. Over the life of the program, I printed hundreds of rings in my office, with precision fit into the mold. Rapid prototyping means iterating quickly. Don't waste your quick turn parts with multi-week design feedback loops. Quickly design, quickly build, and adjust. Some people say "ready, fire, aim" is a metaphor for sloppy design practice, but I'm convinced in early concept development there's no better way than getting hands-on with hardware, early. in this design, we argued whether we were doing over-molding or insert molding. It's a tough argument with no winner. RLP, Rapid Liquid Print is doing some thin-wall silicone prints, which we tried for this program, but they couldn't do sub-millimeter wall sections. Many shops quoted these prototypes but nobody is doing silicone samples with FDM (PLA) molds. I'm shocked. It is by FAR the cheapest and fastest way to get functional parts in my hand. Multiple durometers, multiple colors, etc. All possible. The only real tradeoff is the mold surface finish. But I'm actually considering offering this as a standalone service. It's so fast. I can design and print a mold in one day, and cast parts the next day, all for a fraction of the cost of a traditional aluminum tool. Call me if you're looking for complex silicone parts. I'll help you out. #prototyping

As a product leader, I’ve spent years refining product development cycles — from ideation to launch. But AI is forcing all of us to rethink the how. Recently, I’ve been diving into how AI can enhance prototyping, and tools like blot.new or V0.dev have genuinely impressed me. What have I learned? 🔹 Instead of static designs in Figma → we’re using blot.new to turn those into working UIs It accepts plain-text prompts and instantly scaffolds React components styled with Tailwind CSS. The UI output is clean, componentized, and ready to plug into a real product. 🔹 Product managers can write functional prompts directly No need to wait for handoffs. A PM can now write something like: “A form with email/password input and a login button, responsive for mobile” …and blot.new returns the actual code and live UI preview within seconds. 🔹 A/B tests without code deployments We can test variations of user flows or UI layouts directly in blot.new, collect early feedback, and refine before it ever hits the dev backlog. What this changes: ✅ PMs and designers are now more hands-on with execution ✅ Engineers spend less time on throwaway prototypes ✅ Idea-to-feedback loops are dramatically shorter This shift has been energizing. And we’re just scratching the surface. Curious if others are doing the same. How are you integrating AI into your product workflow? #ProductLeadership #AIinProduct #PromptDrivenDevelopment #PrototypingWithAI #blotnew #TailwindCSS #React #RapidIteration #LeanProduct

🚀 Level up your prototyping workflow: How to share multiple versions of your vibe-coded prototype Working on a complex prototype and need to show stakeholders different variations? Or running A/B tests with users? Here's a game-changer I just set up for our team: The problem: You're iterating on a prototype but need to keep the "stable" version accessible while testing new ideas. Or you want to run user research comparing two approaches. The solution: Deploy each Git branch to its own unique URL. Now our prototypes live at: main → primary "stable" prototype URL variant-a → /variant-a/ variant-b → /variant-b/ Why this matters for designers: ✅ Stakeholder reviews. Use the Github desktop app to switch between versions — "Here's the current version, and here's what we're exploring" ✅ User research — Run proper A/B tests with different participants seeing different URLs ✅ Iteration without fear — Experiment on a branch without breaking what's already working ✅ Documentation — Each variation has a permanent, shareable link The setup takes minutes using GitHub Actions. Once configured, every time you push changes to a branch, it automatically deploys to its own URL. This setup works particularly well at companies with security restrictions on teams that already use Github. Showing always beats telling. If you're a designer working with code-based prototypes, this workflow is a must-have. Happy to share the technical setup if anyone's interested! Also curious — what tools or workflows have changed how you share work with stakeholders?

Agile Hardware Highlight: Astranis Space Technologies (SF, 🇺🇸) Three lessons on agile hardware engineering from Astranis—a company building small, geostationary satellites, and a Flow customer, with a scrappy, iterative approach that’s anything but traditional. 1. Scoping & Iterative Hardware Engineering The biggest mistake teams make is assuming they know how to execute on something they’ve never done before. Today, Astranis builds complex geostationary satellites, a notoriously challenging domain. But they didn’t start there. Their first cubesat, built for Y Combinator’s Demo Day, came together in just three weeks. The “cleanroom”? PVC pipes and shower curtains. Later, to test their software-defined radio technology, Astranis launched LEO satellites. These early missions helped them iterate on full mission profiles, get more reps for the team from each launch, and steadily progress to a more challenging higher orbit. If your team hasn’t done it before, it’s the same as doing it for the first time. Which is why optimising for cycle speed is so important. 2. No Systems Engineers—Because Everyone Is a Systems Engineer Every engineer owns the systems they work on. Every engineer is responsible not just for their component but for how it integrates into the larger system. This approach helps eliminate silos. Instead of handing off requirements without context, teams collaborate cross-functionally, enabling faster decisions and fewer disconnects. Ownership is a practice, not just a lofty principle. And it’s a big part of how Astranis moves quickly while building reliable systems. 3. Hardware-in-the-Loop Testing (HITL) To iterate faster and reduce risk, Astranis brings testing in-house. They’ve built facilities like thermal vacuum chambers and ion thruster testing setups, simulating space conditions in real time. This hands-on approach, known as hardware-in-the-loop testing (HITL), accelerates iteration cycles while uncovering and addressing potential issues early. Faster progress, higher reliability, and lower costs. The team is crushing it, and we’re excited to see what’s next. Astranis is proving that iterative hardware development is a competitive advantage, culminating in the recent successful commissioning of four new satellites currently on their way to GEO.

You're still designing like coding costs a fortune. That's why your ideas always arrive too late. 🧠 What if our design process was… backwards? For years, our craft was built around one fear: building the wrong thing is expensive. So we stacked layer after layer of protection: functional docs, PRDs, detailed specs, pixel-perfect Figma files, reviews, committees, validations — all before a single line of code was written. That made sense when: shipping a prototype took 3 weeks, spinning up a dev team was costly, every iteration was a mini-project. But with Claude, Figma AI, Lovable & co, reality has shifted: a clickable version "good enough to test" can take 30 minutes, not 3 weeks. In that world, the old process "think → specify → design → build" is becoming a bottleneck. The role flips: From 🔒 "block construction until everything is validated" To 🎯 "build fast, then use design to shape, fix, and refine." So what does this new workflow look like? 1️⃣ Start with a problem, not a document One clear sentence is enough as a brief. Ex: "Designers struggle to get honest feedback on their portfolio from peers." 2️⃣ Build the roughest version first With Lovable, Claude Code or any other tool, generate a functional prototype — even an ugly one. Not a beautiful Figma. Something real and clickable. 3️⃣ Actually use it Test it yourself, break it, feel where it gets stuck. You no longer guess the friction — you live it. 4️⃣ Design after, not before This is where UX design reclaims its full value: fix what blocks, simplify what overwhelms, add clarity, consistency, hierarchy. 5️⃣ Show the product, not the spec Instead of a 20-page doc, send a link: "Try it, tell me what's confusing." Feedback is grounded in something real, not hypotheses. 6️⃣ Iterate at the speed of conversation Got feedback? Adjust in minutes, not at the next sprint. Iterate on something concrete, multiple times a day if needed. 7️⃣ Document after the fact Documentation becomes the trace of what exists, not a prediction of what might exist. It comes once the experience has been proven. This shift doesn't mean "stop thinking." Quite the opposite: you think at every step — grounded in real feedback, user tests, and data — rather than long theoretical debates. The real shift, for designers and PMs, is accepting that: value is no longer in producing docs, but in taste, judgment, and the ability to iterate fast on something real. 📎 Free resource I packed this process into a ready-to-use prompt. Paste it into Claude, Lovable or Cursor — and you'll have a functional prototype in 30 minutes. https://lnkd.in/dse5WQYB No Figma. No PRD. Just something clickable in 30 minutes. If this post made you think — save it. 🔖 In 6 months, you'll wonder why you didn't apply it sooner. #claude #lovable #workflow

Think You Can “Get It Right” Fast? Think Again. Do you have a physical product idea and think you can get it right quickly? Wrong. We all want things fast — especially in a world of AI and instant everything. But as much as I wish it weren’t true, physical product development takes time. If you want a great product, it takes more time. One of the biggest miscalculations in product development is underestimating the time it takes to iterate. The first prototype isn’t the product — it’s the starting point. Each round reveals new information about materials, performance, manufacturability, or user experience. Those discoveries require new samples, new tooling, and new tests. Unlike software, iteration in hardware and apparel isn’t instantaneous. Every change has a cost and a lead time. Skipping steps often leads to products that look right but fail in use. If you’re bringing a new product to market: Plan for numerous prototype rounds before production. Build structured feedback loops with users, labs, and factories. Expect every improvement to add both time and insight. Prototypes aren’t delays — they’re data. And the better your data before launch, the stronger your product after it.

What's the right number of prototype iterations in MedTech? Hint: the answer is not 1. That's like expecting a hole-in-one on a long distance golf shot. Just ain't gonna happen. Instead, focus your prototype iterations on answering specific questions: ➡️ Prototype 1: Does it work on the bench? Simplified proof-of-concept prototype that addresses key questions related to technical performance. ➡️Prototype 2: Does it work (pre)clinically? Early prototype aimed at collecting data, preclinically (for significant risk devices) or clinically (for non-significant risk devices). ➡️Prototype 3: Will people use it correctly? Usability prototypes (or mockups) aimed at evaluating user interfaces, usability, and possible misuse through human factors studies. ➡️Prototype 4: Does it achieve target COGS? Alpha prototype integrating industrial design and engineering, while designing for production materials and processes. ➡️ Prototype 5: Does it meet the requirements? Beta prototype addressing shortcomings of Alpha, and used for engineering verification testing (before V&V). So, minimum.. 5 prototype iterations. Often many more. Stage these prototype iterations so that each one gains the benefit of the prior. If you isolate these risk factors, your prototypes can be much simpler, faster and more cost effective to design, produce, and test. Prototyping is a mindset -- it's about learning, quickly and effectively. > Identify the right questions to answer > Build simple prototypes focused on the key questions > Run the tests, learn, and iterate. #medtech #medicaldevices #prototyping

The way we build product at Noota has completely transformed: here’s what we learned 👇 I’ve been shipping software every month for the last few years with Noota, and one thing became very clear: 🔥 Our old way of building product didn’t scale with our ambition. - For years, we did what most SaaS teams do: - Collect needs (CEO vision, clients, support, sales) - Turn it into a roadmap - Break into specs & tickets - Design - Dev - QA - Ship - Learn - Rebuild It worked… but it was slow and expensive. The "Fail Fast" was closer to "Fail not Fast so please don't fail" The real problem wasn’t the people or the process, it was the distance between the idea and the reality. ❗Every handoff lost context. ⏳ Every validation came too late. 💸 Every feedback loop arrived after money was already burned. Even Stripe’s Developer says “context switching & misalignment” as a top productivity killer. I believe this is true, we’ve lived it. What changed at Noota In 2025, we started leveraging AI-native tools like Cursor, v0, Claude Code and changed the order of operations. Instead of writing docs, I now prototype on weekends. Here’s our new loop: - Step 1: I prototype in 48–72h Functional demo, fake data, rough UX. - Step 2: We validate on users instantly Not opinions, fast reactions. - Step 3: Designers "extract the essence" (thanks Karina) They polish the experience instead of guessing intent. - Step 4: Engineers take over a running baseline They harden it for performance, architecture, security. - Step 5: QA focuses on edge cases and robustness No more "does the button work?" because that’s already proven. Real numbers from Noota After few months of doing this, here’s what we measured internally: ✅ 5× faster from idea to production ✅ ~40% less rework on engineering cycles ✅ Higher UX acceptance rate (fewer redesign iterations) ✅ Feedback loops shrunk from 2–6 weeks to 72 hours ✅ Developers spend more time on quality than interpretation The biggest win is speed and alignment ! If you want i can share you the precise process + prompts if you want to try it on your own project.

𝐖𝐞 𝐬𝐭𝐨𝐩𝐩𝐞𝐝 𝐰𝐫𝐢𝐭𝐢𝐧𝐠 20-𝐩𝐚𝐠𝐞 𝐏𝐑𝐃𝐬. Now we build prototypes instead — and it’s completely changed how Databricks PMs align on solutions. A product manager’s job is still the same at its core — identify a problem that, if solved, drives adoption or revenue. But what we’ve learned is this: aligning on the problem isn’t the hardest part. Aligning on the solution is. Traditionally, this meant messy slides, slow UX cycles, and static mockups. PMs would test ideas with customers using decks or clickable Figma files that took days (or weeks) to build. Each round of feedback felt like a mini product cycle. With 𝐯𝐢𝐛𝐞 𝐜𝐨𝐝𝐢𝐧𝐠, we’ve flipped that. We now prototype directly to test and iterate live with customers. When customers can use something, not just look at it, the insights are richer, and we can see where expectations diverge from design. We tweak the prototypes between user interviews, learning faster than ever before. Before GenAI, PRDs were 20+ pages long and few people read them. Now we skip them entirely. PMs replace written specs with working prototypes and run “prototype reviews” instead of doc reviews. We’ve even developed a Plan/Build workflow, inspired by Claude Code: 🧠 𝐏𝐥𝐚𝐧 𝐌𝐨𝐝𝐞: use an AI assistant to reason through the design — feeding it jobs-to-be-done, API specs/information architectures, and refining until the assistant truly “gets it.” ( 💡 Pro tip: many on our team use Wispr Flow for voice-to-text — it makes iterating on ideas faster and more natural than typing) ⚡️ 𝐁𝐮𝐢𝐥𝐝 𝐌𝐨𝐝𝐞: prompt your AI assistant to generate *page-by-page* UI prompts for your vibe code tool of choice, switching between modes until the design feels right. Incremental building by page is key here! Most of our prototypes today are UI-only (no backend), but they’re powerful enough to test flows, get real feedback, and lock in what the MVP should be. ➡️ Our next step: connecting to real data — turning prototypes into Databricks Apps customers can actually use. We joke that “no engineers were harmed in the making of this prototype” — but the impact is real. We’re moving from writing about ideas to feeling them. 👋 Would love to hear how other teams are replacing PRDs with prototypes in the comments.