Ideating in the Engine Room: Why Product Strategy Requires Architectural Friction
Product management has a distance problem. Features look trivial on a roadmap. "User Dashboard" is three words until it hits real architecture — and then you find out exactly how hard it can be.
The friction of reality
I've been using Cursor differently lately. Not just as an IDE, but as a reality check. Instead of writing a spec in a doc somewhere, I sit in the codebase and try to build the thing myself — duct tape and all.
When you actually try to connect a Next.js App Router frontend to a Payload CMS backend, you stop drawing boxes on a diagram. You hit the Auth Wall. You live inside infinite redirect loops caused by mishandled HTTP-only cookies. You find out that a "simple" user preference toggle isn't a new UI component — it's a database migration in Supabase, a stateful architecture shift, and a spike in technical debt you weren't planning for.
The spec looked fine. The codebase had opinions.
What happens when you feel it
There's a rewiring that happens when you get your hands dirty in an autonomous workflow. You develop what I'd call cynical empathy for engineering reality. When you've felt the pain of a deployment collision, or wrestled with an LLM hallucinating legacy code, you become a different kind of product person. A better one.
Three things shift:
You scope harder. You stop requesting the nice-to-have polish in V1 because you know what it costs — not in story points, in real architectural stability. You default to the leanest possible iteration because you've seen what happens when you don't.
You think in trade-offs, not just value. Features stop being evaluated purely on user impact. You start asking what the time-to-market cost is, and what this does to the architecture six months from now. You get faster at recognizing when the right call is a manual workaround instead of a build.
You stop hallucinating roadmaps. The same way you ground an LLM in the actual codebase to stop it making things up, stepping into the engine room stops you from building strategy on assumptions. The friction is the correction.
Strategy has terrain
Product strategy isn't a line on a whiteboard. A vector has to move through real space. If you want to build things that actually ship, you have to feel the friction of the stack — understand why the system pushes back, and respect what the architecture is telling you. That's when the strategy becomes real.