Are you kidding me right now?

This isn't television. Sit up straight. Turn that phone around.

Preferred color scheme

Character: Product

Mood: Expressive

Flavor: House

Interface sounds

Red light

Derek Wood Technical Product Designer

Los Angeles, CA + Remote (213) 400 6366 · derekthomaswood.com derekthomaswood@gmail.com | linkedin.com/in/derekthomaswood

Hi, I'm Derek.

Working in agencies, I kept seeing the same problem: designers didn't understand the medium they were designing for, devs chose to avoid learning basic visual fundamentals, and the whole team spent three times the energy for outcomes that didn't measure up. More meetings weren't going to fix it. If your designers are mad because the devs used 18px instead of 16px, there's a bigger systems problem.

I got a little obsessed with that problem. I'd seen companies that practiced pair programming, and it felt natural that design, development, and product should work that closely too. What would eventually get called the product trio made complete sense to me. I tried integrating those workflows into the teams I was on, but it's hard to change habits once everyone settles into their corners. Eventually I thought: there should be a school that teaches the whole thing together from the beginning.

So I built one. I designed the curriculum, programmed the platform, built the business and the systems behind it, and spent years working through real problems with hundreds of designers and developers. The thesis was pretty simple: the work gets better when we're one team instead of “designers” and “coders” handing things back and forth.

I kept doing product work in parallel: a green-field real estate platform where the forms, legal machinery, seller education, messaging, and the actual product all had to be figured out together; a financial education company with its experience scattered across a bunch of disconnected tools; accessibility R&D; interactive products and internal systems. The surface problem changes every time. The deeper work is figuring out what's actually going on, what matters, who needs what, and how all of those pieces should work together.

I research the problem, work through the IA and flows, design the interface, prototype in code (and these days, with AI), and get it into a form where we can test what we thought we knew. We can always flip through Mobbin and find some nice UI flourishes. The bigger gains come from getting the system right: the goals, the information, the workflows, the decisions, and the way the team works together.

I've spent about 15 years learning this product design stuff in pretty obsessive detail. I don't need to be the person doing every part. I want to understand the parts well enough to help everyone do their best work. Give me the messy problem, the people who understand different pieces of it, a whiteboard, Figma, some code — whatever we need to make the idea real enough to test, measure, and refine. My job is to make sure everybody has what they need to succeed, we're learning from each other, and we're actually getting closer to the goal.

Thanks for reading.

Derek Thomas Wood