An architect learning to start before she knows everything

Before product, I was an architect. On a healthcare project, I designed a cath lab for a cardiac unit: the walls, the floors, how the team moves around the table. Then the machines arrived, and I saw how much rides on them too. The design of the cath lab equipment makes or breaks the medical staff's experience, and in turn the patient's. My room would serve one hospital; the same machines serve labs everywhere. I wanted to work on that layer as well.

Dezeen reported in late 2025 that recruiters are seeing architects and designers move into UX (Dezeen). The skills travel well: thinking about how people move through a space is close to thinking about how they move through a product.

Architecture school is five years, and architectural design is only one of about ten subjects. We also learned construction, materials, building services like ventilation and water, structures, environmental science, interior and landscape design, and the rules of the city. All of it is core curriculum, before you ever put work out into the world. You learn where columns go so the interiors work, and how the space around a building shapes the experience inside it.

That's why product management pulls me. An architect is expected to know how a design looks and feels, and also how it gets built, how it breathes, and whether it's compliant. In software, that means the database, the front end, the back end, the integrations, and the marketing and sales around the product. I want to see all of it.

My two-year master's didn't give me that kind of depth, and for a while I held that against it. But five years and two years aren't the same thing. Software also moves differently. In architecture, a new technology might be one new chapter in a semester. In software, with AI, something changes almost every week.

So the architect in me wants to learn everything before starting, and I'm letting go of that. Architects need a qualifying exam and a license, because when a building fails, it can hurt people. Most software isn't like that, and the cost of starting early is low.

There's a limit: as Marty Cagan puts it, a prototype you build fast is not a product. A product still needs reliability, security, and the boring work that makes it safe to depend on (SVPG). For me, starting early means learning early, not shipping something half-checked.

My rule now: even if all I have is an ambiguous objective and some basic context, I start. Research and the first prototype fill in the rest. When I'm building something customer-facing, I start once I know 60–70% of what goes into it, and learn the rest on the way, from people who know the field better and from AI tools that can now draft, code, and test with me.

I'm not fully there yet. At work, I've held back on calls I had already done the research for, and waited longer than I needed to. Now that I know the team, I'd make them sooner. I'd like to work in a higher-stakes field like healthcare technology someday, where waiting to understand every constraint really matters. Until then, I'm learning to be less hesitant, and to start.