The Architect Is Really a Hybrid PM
Recruiters read four years of technical titles and file it under "not product." Here is the project that argues otherwise, decision by decision.
In 2022 I traded a Technical Product Manager title for Director of Architecture and Digital Services. On paper, I left product. In practice, the product decisions got bigger.
Recruiters read the last four years of my resume and file it under "not product." I understand the instinct. Titles are the only compression they have. But the first big decision in that architecture seat was replacing a legacy ERP-bound storefront with a composable commerce platform serving 8 brands, and I have yet to find the line in that project where architecture ended and product began.
Walk through it with me.
Platform selection is product strategy in a technical costume
The stack we chose reads like an architecture diagram: VTEX for commerce, Akeneo for product information, Workato for orchestration. The decision underneath it was not technical. It was deciding where our differentiation lives.
We bought commerce capability. We bought product-data management. We kept one thing for ourselves: the integration layer that connects those platforms to our legacy systems, our warehouses, and our partners. That is the layer my team designed, built, and owns, and it is the layer that has driven $5M in net new revenue since launch.
That is a build-versus-buy portfolio call. A CTO can make it. So can a PM. The question that decides it is not "which platform has better APIs." It is "which problems should we stop solving ourselves, and which problem is the business." Every product leader I respect has made that exact call about their own roadmap.
An architecture serving 8 brands is a roadmap problem
One architecture, 8 distinct brands. The technical design was genuinely hard. It was also the smaller half of the job.
The larger half: which brand migrates first. Which workflows earn a rebuild and which get lifted as-is. Which brands can share a catalog and which cannot, because their customers use the same words to mean different products. What the branch counter needs at 6am on a Tuesday, which is not what the brand's marketing lead asked for in the requirements workshop.
Getting 8 of them onto one platform is stakeholder prioritization with a Visio file attached.
Swap "brand" for "customer segment" and this is the sequencing work every platform PM does. Each brand had its own P&L owner, its own habits, its own reasons the shared architecture should bend its way.
A data model is an opinion about the customer
Centralizing product information across 8 brands in a PIM sounds like plumbing. The actual decisions: what is a product record. Which attributes matter enough to govern. What "clean" means when two supplier feeds disagree about the same SKU.
Those are customer questions. In B2B distribution, the product record is the product page, the search result, and half of every support call. We deployed AI to extract and clean specifications at a scale no data team could match manually, but the model of what a product IS came first, and that model is a product decision. Get it wrong and no amount of clean data saves the experience built on top of it.
APIs are products with paying customers
The Workato middleware layer exposes our legacy databases and applications to the commerce platform and to external integration partners. The external part matters. Partner-facing endpoints have adopters, documentation, versioning pressure, and revenue attached. The $5M integration effort ran through this layer.
An interface that outside parties build against is a product by any definition that survives contact with reality. Someone has to decide what it exposes, what it promises, and what it will never promise. That someone is doing product management, whatever their badge says.
The only real difference is the feedback loop
A feature PM ships weekly and learns weekly. Architecture pays back in years, and the switching costs are brutal, which is why the decisions deserve more product rigor, not less. Architecture is product management with a longer feedback loop and higher stakes per decision.
That is why I spent the architecture years running the same loop I learned in a decade of PM roles at Apptio, Numerify, and Rexel: start with the buyer, the workflow, and the P&L, then let the technical design serve the answer. It is also why the team I ran in that Director seat included product managers and designers alongside engineers. The org chart called it architecture. The operating system was product.
What to do with this
If you are hiring for a transformation, do not screen out the operators whose titles went technical. Ask one question instead: who is your customer?
If the answer is a system, you have an architect. If the answer is a person with a workflow and a number attached, you have a product manager who learned to draw the diagrams too. In my experience, the second kind is the one whose platforms make money.