In most organizations, you plan first, then build, but what if we plan to build first and design later?

Welcome back to Part 2 of the conversation with Ken Wilkins. In Part 1, we heard how Ken's software team navigated FDA regulations and the tension of needing approval without getting timely feedback. But Part 2 digs into something even more fundamental: what makes a design process actually work?

Ken explains how software's quick prototyping cycles create a unique advantage: you can build something, see how it works, and then loop that learning back to improve your original design. His team transformed a narrow fix-this-one-thing directive into a sustainable framework that would make future work easier. Instead of creating one-off patches, they built a general solution the FDA could approve once and apply to similar problems going forward. But this only worked because they had a project manager who listened when they said "we need to change the scope."

Here's the catch: this kind of bidirectional design process—where what you learn during implementation can actually reshape the design—isn't the norm. In many organizations, whether you're dealing with FDA regulations, donor requirements, or just organizational bureaucracy, the design gets locked in early and you're stuck with it. Ken talks about what he sees as the gold standard: processes that people actually want to follow because they make work easier, not harder.

If you've ever felt like your team is doing good work and then awkwardly jamming it into a process after the fact, or wondered why it's so hard to shift direction even when everyone can see a better path forward, this episode is for you.