In last post, I went on a walk that sparked a whole chain of ideas.
The sun was shining, the air was crisp, and I stumbled across a dome-shaped playground structure that got me thinking about my summerhouse project. I wrote about it. I let it sit. Then I did the only thing that felt natural: I opened my laptop and didn’t design the thing.
No, really—I could’ve just opened CAD, spent 15 minutes sketching a dome concept, and called it a day. But where’s the fun in that?
Instead, I got an idea:
What if I built a dome generator?
Like… an actual tool that could generate the structure for me and export the necessary data points. That way, I could play with forms, scale, and proportions on the fly. And maybe even learn something along the way.
And of course—obviously—I figured I’d nail it on the first try.
I mean, how hard could it be?
The Eternal Trap of “Getting It Right the First Time”
As someone who’s worked in product development for years, I know better.
Like, I really know better.
Still, I fell into the trap I warn others about:
Trying to get it right at the first shot.
I knew this wasn’t realistic. I knew how this would go. But somewhere in my overconfident brain, I still believed: This time, maybe I’ll just crush it in one go.
I didn’t.
Not even close.
The first iteration of my dome generator was so far off the mark it almost became an entirely different tool. But that’s where the story starts—not ends.
Because product development is not about getting it right the first time.
It’s about having the curiosity to keep going after it goes wrong.
A Flashback to My Product Dev Roots
This whole process reminded me of a professor who left a deep impression on me: Kalevi Ekman.
Kalevi once gave a lecture that I still remember clearly. With his signature dry sarcasm, he told us:
“In product development, you should always get it right the first time.”
He didn’t mean it, of course.
The sarcasm was the point.
Because product development is not about precision at the start. It’s about process.
You begin with an idea (often a messy one), then slowly evolve it into a concept. That concept evolves into something testable. That testable thing becomes a product. And the whole thing keeps going—shifting, adapting, refining.
You don’t start with something finished.
You start with something alive.
Starting with Nothing (and a Bit of Excitement)
So, back to the dome generator.
The first attempt? Pretty bad. It wasn’t just “not what I had in mind”—it didn’t make much sense at all. But I kept going.
And here’s what I realized, again:
I wasn’t even sure what I really wanted.
This is common, whether you’re building software, hardware, or even shaping a team (more on that in another post someday). You often don’t have a complete picture when you begin.
But that’s okay.
You don’t need the full map to take the first step.
The Real Development Begins
So I iterated.
I restructured the logic.
Rethought the rendering.
Added basic coordinate scaling.
Switched up the visualization approach.
Realized I needed export functionality.
Started from scratch. Again.
And again.
About ten iterations in, something started to form.
It still wasn’t what I envisioned—but now it was getting closer. And, more importantly, I was learning.
That’s the thing: development doesn’t mean you’re building something perfect. It means you’re building something real—one small improvement at a time.
It’s a Lot Like Team Development, Too
Side note: this process reminded me of how I’ve approached building teams in the past.
You can’t plan the perfect team dynamic upfront. You have to start somewhere. You try things. You test boundaries. You learn what works (and what really, really doesn’t). And then you adapt.
Team development is product development.
The product just happens to be human relationships, communication patterns, and shared goals.
But that’s a whole different story.
The Dome Generator Keeps Morphing
So… how many iterations did it take before the generator started working like I imagined?
Probably twenty. Maybe more.
Some of those iterations were major logic changes. Others were just UI tweaks or “how-do-I-make-this-make-sense” adjustments. But each step revealed something new:
- I discovered I needed a different structure to the code logic.
- I added features I didn’t even know I wanted at the beginning.
- I played with visuals just to test how far I could take it.
- I accidentally created something weird—and got an idea for something totally different.
(Yes, that might become its own post later.)
That’s product development.
You build, break, rebuild.
You get excited. You hit walls. You create sparks you didn’t expect.
You realize your idea wasn’t complete—and that’s when it becomes interesting.
Kudos to the Community That Taught Me
While I was debugging one particularly frustrating issue, I found myself thinking about the Design Factory community—ADF—where I really learned what product development is.
That place was more than a classroom. It was a mindset.
A space to test things, share ideas, get feedback, and grow them into something more.
Without that experience, I’d probably still be stuck thinking everything has to be polished before it’s real.
So if this post reaches any fellow ADF souls—thank you. You taught me that unfinished things are often the best kind of starting point.
Iteration Is More Than a Process—It’s a Perspective
Sometimes in the middle of iteration #13 or 14, you realize something:
You’re not just building a tool—you’re reshaping your thinking.
I began this project with a technical challenge: generate a dome.
I ended up with new insights on visual logic, algorithmic structure, UI interaction, and even how I think about form and geometry.
Even better? It reminded me why I love this stuff.
Not the “finish line.” The figuring-it-out.
Also… I Have Four Kids
Let’s not forget: this wasn’t some weeklong sprint with a clear block of time. I have four kids.
This project happened in small chunks—late evenings, early mornings, stolen pockets of focus. The fact that anything came out of it at all is a small miracle.
But that’s another reminder: you don’t need a perfect environment to make progress.
You just need to start.
Even when you’re tired. Even when it’s messy. Especially when it’s messy.
So, Is the Generator Ready?
Absolutely not.
It’s working. It exports some data. It renders structures. It plays nice (mostly). <- click to see yourself
But it’s not finished. I still need to test the export files more. Fine-tune the math. Check edge cases. Maybe build a cleaner UI. Maybe do nothing for a while.
And that’s okay.
Because I’m not chasing ready.
I’m chasing real.
Final Thoughts (And a Quiet Thank You)
This little dome generator taught me more than I expected.
Not because it’s revolutionary, but because it reminded me of how product development really works:
- You don’t start with the answer.
- You start with a spark.
- You shape the spark through feedback, frustration, and fun.
- You let it evolve.
- And sometimes, you find something totally different than what you thought you wanted.
So if you’re building something right now—whether it’s a tool, a team, a habit, or a blog—here’s your reminder:
You don’t have to get it right the first time.
You just have to keep going.
And if you’re curious to play around with the generator, go ahead.
It’s in the LAB now.
Let me know if something breaks. Or sparks something new in you.
That’s what it’s for.