Learning to Explore as a Systematic Designer
How a systems-obsessed designer learned to thrive in startup chaos. From rigid frameworks to "vibe traveling" through product uncertainty. It's messier than I expected.
Anyone who has worked with me can validate that I advocate for good frameworks and systems to make processes smoother. There's a reason I thrived leading Design System initiatives, spent countless hours decoding design processes, and find it easy to reuse frameworks for everything. Even my first article was about process systematization for designers.
I'm a systems thinker by nature. Having control over expected results has allowed me to refine my craft over the years. But as the saying goes, "what got you here won't get you to the next level."
So how did a creature of habit like me switch from predictive environments to the uncertainty of early-stage startups? To make it even more challenging, a startup working on AI-native products? This is how.
The type A designer
I like planning. My activities go into my calendar, I use various systems to access my digital content easily, and my travel plans are all documented in Notion. It's an investment of time, but it is incredibly worth it when I need to remember, access, or do something that could get lost in a sea of context. It's like paying it forward to my future self.
This, however, has sparked debates in the past with my type B friends, who are more free spirits who go where the wind blows. Let's take traveling, for example. They schedule their trips in a blink of an eye and do activities spontaneously without much structure. So, whenever I explain my approach to traveling, they're usually horrified by how much time I spend on it.
But what happens when life gets in the way and I'm forced to go with the flow? I've let myself wander more freely, discover local gems just based on how good the food smells when I pass them, or ask the tour guide for recommendations on which coffee shop I should visit next.
For someone used to having everything structured, it might seem like a wild idea to do "vibe traveling," but as with anything in life, having a bit of both creates a good balance. Just enough structure to have the key elements in a safe spot, while embracing the act of exploring that will undoubtedly make some of the best anecdotes you'll share with your friends afterwards.
Coming back to design, when I worked at software development agencies, I was used to having structure: a PM to take care of the logistics, a PO that owned the roadmap, a highly detailed PRD after a few days of product discovery, etc. You get the gist. The problem space and the solution of the MVP might be unknown, but the operating systems in place were more or less predictable, and I liked that.
Until I dared myself to step into the unknown of startup life.
Exploring vs Exploiting
Over dozens and dozens of projects, I found myself gravitating more towards 0 to 1 products. I thrived in dealing with ambiguity and discovering the opportunities amidst the unknowns. It was exhilarating. Challenging. And when it worked? Incredibly rewarding. Still, I had a safety net of operating processes to rely on and a certain level of predictability of how things would unfold at a high level.
I couldn't explain why the MVPs felt different from most other projects where I had to scale and optimize until recently, when I read about explore vs. exploit modes in an interview with Granola's co-founder and CEO, Chris Pedregal.
Exploit is like your type A friend during a trip. Structured, systematic, and optimizing to make the most out of every day before the returning flight.
Explore is, on the other hand, like your type B friend. Adventurous, willing to make mistakes, and enjoying one day at a time.
Based on these descriptions, you might think I had to become an explorer to fit into my new reality. But as with most things, it depends.
Depending on the context, one approach might generate better outcomes than the other. Exploring is about venturing into unknown territory and generating new possibilities, a synonym of pre-PMF products, and figuring out how to make them stick. Exploitation is about optimizing, scaling, and operationalizing what already works; hence, it becomes the driving force after PMF.
Two very different mindsets for two different scenarios.
So now I'm technically both. I'm more open to wearing many hats, experimenting outside of my traditional toolkit, and skipping a process diagram in favor of shipping fast.
At the same time, I'm certain that there will come a time when some things will require a framework or a system to scale. At some point, another designer will have to rely on solid foundations to maintain cohesion while still shipping fast. Quoting Dan Mall on a recent Auto Layout walkthrough, "You systematize afterwards, once you know the things that need to be a system."
To enjoy the best of both worlds, I had to adopt a new strategy and make trade-offs as I learned the nuances of exploring.
The principles of an explorer
Although I was already enjoying the discovery of new ideas, I hadn't fully experienced startup life until last year, let alone the craziness of building AI products. What comes next are the hard lessons I came to understand through a lot of iteration, keeping a growth mindset, and being curious about how things can evolve. The overarching principle is explore → iterate → exploit.
1. Adaptive systems over rigid frameworks
I'll be the first to admit that it's tempting to create structure right after joining if you're used to it. However, reusing old patterns before even knowing if you'll have to pivot your entire business in 6 months is a dangerous trap. Instead, I'm focusing on building minimal viable structures that evolve as the product grows, adapting to pre-PMF startups that need flexibility over predictability.
Daily practices:
Systematize only when it's needed. Just enough documentation until patterns emerge organically.
Document, reflect, and learn. Lightweight personal decision logs to capture learnings and inform yearly retrospectives.
2. Entrepreneurial product intuition
Designing an MVP is one thing. Becoming a founding designer in the age of AI? That's a whole different story. To design at an early stage, you have to shift from a traditional design mindset to entrepreneurial product thinking, which is an ongoing practice of immersing yourself in product and customer data to confidently prioritize your bets.
Daily practices:
Find signal through the noise. Actively monitor user feedback, market pulse, and competitor news to spot trends and outliers.
Build strong product sense. Dive into identifying emerging opportunities that others haven't pointed out to make decisions despite the ambiguity.
3. Exploration beyond traditional boundaries
Shaping a product during its early phases requires full-stack problem-solving. This is demonstrated by technical curiosity, business insight, and a willingness to collaborate across various fields, regardless of job title. This is the stage to do some ad-hoc data analysis, influence GTM, or leverage prompt engineering to shape new solutions. The lines are blurring fast, making expanding our impact as product builders easier than ever.
Daily practices:
Curiosity to do unsolicited exploration. Proactively run experiments and get involved in conversations across disciplines, acquiring new perspectives to inform better design decisions.
Thrive in autonomy with high agency. Discover problems independently, proposing solutions and taking ownership of their outcomes to drive the vision forward.
Parting thoughts
In the last couple of years, I have travelled a few times without having an actual plan other than where I'm staying and my return ticket. It has created unique experiences in ways I didn't expect, so I'm striving for just enough planning these days. Like my traveling habits, I've embraced a dynamic role and processes that are hard to put into words, but have expanded my impact and accelerated my growth exponentially.
My past self would probably be in disbelief at seeing my current way of working, and that's okay. It was a different chapter of my career that required a different mindset than the one I've come to develop over the last two years. Truth be told, startup life isn't for everyone, but if you're willing to jump on this kind of exploration, you're in for quite the adventure.
Shortcuts
Some leaders are not a good fit for 0 to 1 products, explained by Shreyas Doshi
Don't trust the (design) process, by Jenny Wen to remind us all what truly matters
How to Build a Truly Useful AI Product, an insightful essay by Chris Pedregal
Designing the future of Cursor, a Dive Club interview with Ryo Lu
The ultimate guide to the founding designer role, by Tom Scott and Ivy Mukherjee.
It's always more fun to learn with others than doing it alone, so don't hesitate to reach out on Twitter if you want to continue the conversation. If this article has been helpful, share it with a friend!
Over and out,
Laura ✌️