Product Builders

The Making of a Product Builder

I wrote about The Age of Product Builders last year. Now I’m seeing the term “product builder” used in discussions about the collapsing of the product stack (design, engineering, strategy) in the age of AI. That made me think about my own journey, and how I became a Product Builder. As I took the stroll down memory lane, I uncovered insights about my path, learnings, and what it means to be a Product Builder today.

Creativity thrives inside boundaries

I started in design when I was in a band in high school. We needed t-shirt designs, posters, logos. Nobody else was interested, so I did it. I always loved creativity and making things ever since I was a kid. So why not?

One of the early design specialities I fell in love with was t-shirt design. Even after my band split up in college, I continued to work on t-shirt designs. I tried to get clients and projects while posting on a site called Emptees. It was like Dribbble, but for t-shirt designs. You could post, like, comment, and vote to capture the coveted “Tee of the Day” award.

T-shirt design was where I developed an understanding of context and constraints.

While the design begins on a computer screen, it is ultimately born on a physical object. When you’re designing t-shirts, you need to understand constraints like ink colors, fabrics, and how it will look on different shirt sizes. I even worked in a printing shop, taking design files and separating the layers in Photoshop so they could be printed. This gave me insight into how something looks connects to how something works—the context.

I learned that constraints breed creativity. And to live in those constraints and understand them, you need to know the context. You need to respect the medium of creation. Seeing other designers create diverse and unique designs on the same canvas, the t-shirt, was a true expression of creativity.

Clarity emerges through compression

Another area of design I focused on was logos and branding. This type of work required an entirely different way of thinking.

Branding requires a deep understanding of the meaning you’re trying to communicate. It’s a simple expression of a complex idea. You’re compressing the values, principles, and emotions of an entity—company, product, band—into a symbolic visual representation. In order to achieve this outcome, you have to strip away everything until there’s nothing left but the core essence. It’s an exercise in addition by subtraction.

Creating logos forced me to find the essence of ideas. It helped me understand that making something simple is difficult. Simplicity is earned through ruthless reduction.

Or, as Antoine de Saint-Exupéry said:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

From the visual to the functional

Outside of a killer Geocities page featuring wolves, palm trees, and calypso music, making custom MySpace pages was my first entry into the world of web development and code. I once thought this was a unique experience, but later found out several engineers started their coding journey with MySpace. Who knew?

I made several custom MySpace pages for bands. I was in a band, knew other bands, and making them was gross (more on that in a minute), so getting work was easy. I charged a flat fee and knew the time involved to make one. And I got faster with each project.

Now let me tell you about MySpace code: it was absolutely chaotic. It was all table-based HTML layouts, which predates the widespread use of CSS for layouts and styling. This is how HTML emails still work, and is largely why I can’t even look at or work on HTML emails.

But I also learned how to take a fixed design and turn it into a working webpage. I learned to bridge art and implementation. Product clarity lives at the intersection of form and function. Like the t-shirt designs, I learned how context and constraints affect the final product. In this case, translating an idea from one state to another—the form to the function.

Building modular, reusable systems

I eventually graduated from MySpace pages into standard websites. I learned how to use CSS for layouts and JavaScript for interactions. I learned WordPress and found a niche building blogs for wedding photographers. This was mainly because one of my clients kept referring me to their photographer friends.

As I finished college and started my first jobs, I worked on both websites and web applications. I created large-scale CSS architectures that made me think about systems, not screens. Creating reusable components turned design into an ecosystem of creation. To do so required an understanding of patterns. And patterns are a form of leverage. Once you find one, you reproduce at a faster rate and increase your efficiency. The more I learned about modular design, the more I increased my efficiency and rate of production.

Patterns show up everywhere. They’re in design, code, and any place where inputs and outputs occur. That applies to people, teams, and organizations, too!

The culture of creation

As I made my way through companies and products, I found myself in leadership roles and leading teams. I led designers, user interface (front-end) engineers, and then cross-functional product teams of designers, engineers, and strategists. My natural inclination—refined through years of deliberate practice—for organization and efficiency placed me in positions to have influence on the process.

I cared enough about the process to say and do something about it. If I saw a better way, I called it out and suggested a new process. And I got better and better at seeing these opportunities for improvement. So I kept suggesting until I realized I see things other people don’t immediately see. That’s when my superpower began to emerge. Your superpower is the thing you do really well and comes “easy” to you, but confounds other people.

So I extended my superpower beyond the craft of design and code into the system of creation—the process, structure, and environment of teams. Teams are living systems with inputs, outputs, and feedback loops. There are patterns to uncover and complexities to decipher. A great process is an enabler, not an inhibitor. The right system cultivates an environment for people to do their best work.

The Product Builder

When I was at Figma’s Config conference in 2024, multiple people asked me:

Are you a designer?

I bumbled my way through a response:

I started in design and learned engineering and then layered in strategy and leading teams. Now I’m a CPO, but I still design and code…

You get the point. Rambling nonsense.

So who am I?

I am a Product Builder. I understand how things look, how they work, and what they mean. I create and translate value to affect positive outcomes. I build, create, and craft experiences through the medium of software.

Each part of my journey was a layer, not a linear path. My skills compounded and learned from one another, like lifelong friends with a symbiotic connection—from constraint to compression; from coherence to scale; from systems to adaptation. Together, they formed my mindset as a Product Builder. Because building great products requires fluency in design, engineering, and strategy.

Designers who learn how things feel.

Engineers who learn how things work.

Strategists who learn how things connect.

The translation—the connective tissue between disciplines—is what makes a Product Builder. And in a world of rapidly advancing AI blurring the lines between disciplines, you must move forward as a holistic thinker, builder, and craftsperson.

You must be a Product Builder.

There are three key pillars for the Product Builder, and five Product Senses.

Let’s start with the three pillars:

1. Strategic Clarity: Knowing what to build.
2. Continuous Craft: Making it better.
3. Execution Fluency: Bringing it to life.

(This idea lives in the 🦉Clarity Codex of the Claritorium.)

Strategic Clarity

For most of my early work experience, I didn’t think much about what I was making. It was all about creation and execution. I was practicing and refining the craft of making. As I moved into product work and building SaaS, I quickly discovered that wouldn’t work. You can make something great, but you either:

1. Don’t solve a valuable enough problem.
2. Or you don’t have a means to sell it.

And AI isn’t solving this problem yet. You can vibe code software to your heart’s content, but knowing what to vibe code is a critical step in the process. And it’s not the only step, either.

Great ideas are rooted in nuanced human problems. They need to be cultivated, developed, and mixed in with rich human experiences. Even as you read these words, you’re processing information and layering it with your lived experience. It’s a process of continuous consumption. AI still relies on the intentional input of information. That’s why AI is a great thinking partner when connected to the right context, and working with the right human counterpoint: you!

Strategic Clarity is the ability to connect meaning to motion—to understand not just what to build, but why it matters.

Perception allows you to sense and answer what’s really happening here? Paying attention, asking questions, and validating assumptions fine-tune your judgment.

Prioritization guides you to leverage points and to answer what’s worth doing right now? If everything is a priority, nothing is. You identify the most impactful work and commit.

Principles let you apply judgment consistently and answer what is the outcome? Knowing where you’re trying to go helps you decide the right next step. A principled decision is grounded in an eternal truth.

My team started using AI agents to assign individual issues to work on independently. I spent a lot of time drafting issues, assigning the work to AI agents, and then continuously refining the outputs filtered through my own product intuition, taste, and judgment.

“But you’re not writing the code!”

That’s true! But we’ve always increased the layers of abstraction to make programming easier—from binary machine code to high-level programming languages to frameworks to autonomous agents. Yes, we’re not typing out the code. But in my nearly two decades of coding, I’ve not once written out ones and zeroes, either. Does that mean I’m not a real programmer because I don’t manage memory assignments in the CPU? The abstraction has always been there. The abstraction layer now is natural language in the form of prompts.

Working with AI agents is still an exercise in product knowledge. Left to their own devices and limited input (context), they’ll change the wrong thing in the wrong ways. AI won’t work on the right thing without you. They still require oversight. And you, a Product Builder, need to provide that oversight. Use the time you’re saving not writing the code yourself to define the problem, shape the solution, and refine the output. You choose what to work on.

I love programming. I always have. And I’m a huge believer in the process itself as the key to insights and clarity. No pain, no gain. You can’t prompt insights—you experience them. But what if the craft now sits on a new abstraction layer? Maybe that’s okay. Because writing the same React component for the 100th time feels less valuable than talking with a customer, brainstorming with a designer, or improving a product experience. And what if those human experiences catalyze into reality faster with the help of AI? Even if you only love to write code, you still can. Strategic Clarity is a Product Builder’s compass to know where to focus their energy. AI is an accelerant for thinking and creating, not a replacement.

Critical thinking, creativity, and craft have never been more important.

Perception helps you see what’s possible with AI agents in programming (and other areas).

Priorities help you decide which tasks to delegate to AI and which to take yourself.

Principles help you maintain taste and accountability in every output.

The Product Builder’s job is orchestration by way of intuition. Your intuition creates Strategic Clarity and highlights exactly the right thing to focus on right now.

Continuous Craft

There’s a crossing guard at the nearby elementary school my kids attend. She’s been a crossing guard there for over 17 years. That depth of experience shows when you watch her operate the intersection while greeting each parent and child by name. She’ll even get after drivers who don’t obey the rules of the road—of her intersection. Because she cares.

Her work as a crossing guard is a craft.

Craft as a term is often conflated with the notion you must partake in something grandiose to have a craft: an artist, a programmer, a musician. But craft isn’t defined by what you make. It’s defined by how deeply you care about making something. That something can be paintings or software or, yes, safety in transportation for school kids.

Continuous Craft is performing a function repeatedly with care, purpose, and an insatiable desire to make it better each time.

Observation helps you notice the subtle signs and nuances others miss.

Iteration helps you make small, intentional changes that compound over time.

Dedication helps you sustain care through consistency and discipline.

Continuous Craft is the heartbeat of a Product Builder. It’s how you keep improving across the spectrum of the craft:

1. Design Craft is how things feel at the aesthetic and emotional level.
2. Code Craft is how things work at the structural level.
3. Systems Craft is how things connect at the strategic level.
4. Writing Craft is how things make sense at the linguistic level.
5. Leadership Craft is how people move together at the social level.

As a Product Builder, you should invest time and energy into improving across the craft spectrum with these practices. Understand design, code, and how systems work; deepen thinking through writing; move effectively with others through leadership in the work.

When I was prompting AI coding agents to work on issues, I was reviewing each output to make it better. I was reviewing the look and feel (Design Craft), evaluating the code structure (Code Craft), and shaping my response into words (Writing Craft). Even though I wasn’t making the changes myself, I was using the same raw materials as part of the craft. That’s the key. Working with AI is another process to leverage against the same inputs and outputs. The expression of the craft evolves, but the fundamentals stay the same.

Execution Fluency

I sat on a video call with two senior engineers to discuss the state of a project. We looked at the tasks broken down by individual scopes of work. I asked them questions and they discussed where they felt the work was—what was done, what wasn’t, and what unknowns still exist. Nobody was writing code. We weren’t making any real progress on the call. Yet, in that moment, they learned something: they were a lot further than they thought.

We identified one scope of work that grew and added additional work we could move to another scope and deprioritize. Another scope was mostly done, with just some nice-to-haves on the list. We were just talking. But we all came out of the call relieved, full of energy, and with a surge of confidence to deliver.

Taking a challenging project full of unknowns and executing in small, focused tasks is an impactful skill. The best engineers I work with think in isolated scopes of work. They see the map of all the work, and then they carefully draw lines around independent pieces. Doing so reduces the surface area of work, increases iteration speed, and drives faster progress. But the real, hard-earned skill is knowing how to deliver and ship the work on time (or early!).

Execution Fluency is the art of translation, converting clarity into craft into creation.

Rhythm establishes the cadence of work so the team moves in sync. You create space for deep work and creativity.

Translation connects the strategic context to the execution steps to deliver real impact. You create shared understanding and alignment.

Orchestration creates the right balance of pacing to modify the rhythm based on where the work stands. You make sure the system is in tune with its environment.

What happens when a bug comes in from a customer or a stakeholder requests a small change? Do you break focus on a project to switch context and work on it? Or do you understand the importance of rhythm and focus and adaptability? That’s what you do as a Product Builder when you operate with high Execution Fluency. You work in rhythm, translate context, and choreograph the work to manage the natural ebbs and flows.

A Product Builder’s work is always in motion.

Product Senses

I was mentoring a senior engineer who felt like they stalled out. They weren’t learning anything new. So they, almost reactively, suggested learning TypeScript.

“Sure, you could, but why don’t you learn more about design?” I said.

It’s a common misconception. If you want to be a better engineer, learning more technologies is not the only way to do it. I’d even argue it’s not the best way. You should expand your thinking, learn about other disciplines, and bring those insights back into your work. Learning about design not only helps your direct engineering skills, it improves how you work with designers and highlights patterns. You diversify your knowledge.

Just like you have five senses to understand the nature of experiences, you must develop the Product Senses to understand the nature of making great products. Product Sense is another term making its rounds because taste is the hot topic of AI. I agree with the idea that judgement, intuition, taste—knowing why something works—is an attribute of great Product Builders. So let’s expand that concept with Product Senses (plural) to deconstruct the practices you can apply.

The five Product Senses are:

1. Design Sense: How things should feel.
2. Technical Sense: How things should work.
3. Strategic Sense: Why things matter.
4. Empathy Sense: Who things are for.
5. Delivery Sense: How things ship.

Design Sense

Design Sense is knowing how things should feel. It’s understanding visual aesthetics, colors, spacing, layout, hierarchy, and all of the principles of design.

The most common design advice I give engineers is you can never add too much whitespace. When an engineer “designs” something, everything is squished together. But nothing in the real world is designed that way. Look around. Notice how objects are spaced intentionally and in relation to the other objects around them. The beauty of design is that you can learn it anywhere if you choose to pay attention. If you like how something looks, ask yourself why. In that understanding is where Design Sense grows.

To develop a Design Sense: Train your eye by noticing what moves you and then ask why.

Technical Sense

Technical Sense is knowing how things should work. While design is also about how things work, it’s about the technical behavior underpinning all things. It’s the layers.

Saying “I’m not technical” is a common mantra of non-technical designers and product managers. But understanding something technically is not only knowing how to code. You need a sense for technical concepts.

To develop a Technical Sense: Trace how things work until you can improve them.

Strategic Sense

Strategic Sense is knowing why things matter. You connect the individual task to the larger context it derives from—the meaning.

One of the most powerful side-effects of knowing the meaning behind your work is the possibilities it opens up. When you know the context, you make better decisions because your fidelity of understanding increases.

To develop a Strategic Sense: Zoom out until the system makes sense, and then act on the leverage points you find.

Empathy Sense

Empathy Sense is knowing who things are for. If you’re making anything, you’re making it for someone, even if for yourself.

Your goal is to understand the person on the other side of the screen. If you’re an engineer, becoming a Product Builder means talking to users and learning about their pain points.

To develop an Empathy Sense: Get close enough to feel what others experience, and stay curious about everything.

Delivery Sense

Delivery Sense is knowing how things ship. You know how value can be delivered in small iterations. You see the lines of the work.

Whether you’re creating a product strategy or designing product improvements or building a feature, you understand how to break down the work. There’s always a next step you can deliver on your way to the larger project.

To develop a Delivery Sense: Find the lines of the work where independent value can be delivered, tested, and refined.

Practice is Progress

The art of building is about practice. You put in the reps to improve your output. It’s a simple equation of energy expenditure. But here’s the secret: effort shrinks as leverage grows. When you understand the fundamentals as a Product Builder, you spot more opportunities to make a bigger impact with less work. You solve the problem with the fewest changes.

Design Sense builds taste and intuition, reducing time spent iterating blindly.

Technical Sense deepens understanding of constraints, enabling smarter decisions.

Strategic Sense identifies the highest leverage points to increase impact.

Empathy Sense connects to a user’s reality, creating valuable solutions to problems.

Delivery Sense breaks the work down and releases it in small iterations.

Product Builders create leverage to solve complex problems in elegant ways. And in the words of Archimedes:

Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.