The Promotion Problem
I've built my career as an innovation product manager in big banks instead of big tech. I appreciated the agency they granted over products end-to-end, giving me the ability to think strategically and holistically. I loved the challenge: going from blank page to blue sky. Unfortunately, I've lost sight of that joy with each promotion.
In banking, the reward for excellence is almost always a team to scale your productivity. As there's no track for individual contributors, when your superiors start wondering how they can get more of you, the first answer is usually headcount.
Overnight, you're a manager, and the organization awaits this transfer of excellence. The underlying assumption is that if you're good at something, you'll also be good at teaching it, structuring it, and holding others accountable to it. My past performance reviews prove this is a false assumption.
I was great at the work, but I could not for the life of me build a team that could execute at my level. Some of that was temperament. I have an extremely low tolerance for the time it takes for those to ramp up their skills. Some of it was genuinely a skills issue. Management is a craft that I never invested in developing, unlike product strategy. But most of it is that I have never been asked to codify my expertise, so I had no idea what I was to transfer. My judgment and intuition were spot on, but I could never explain how.
This resulted in a toxic loop of me delegating something → it coming back wrong. → I'd fix it myself rather than take the time to explain why it was wrong, because I optimized for overall efficiency over any specific individual's growth. I burnt out carrying work that I'd handed off, and then reclaimed. On my team, everyone lost. Junior PMs weren't being developed, and I was running at 300% just to keep up with both the strategy and execution.
I've spent the semester building out an application for high-performing ADHDers in collaboration with Claude Code. This moment in tech is one I've been waiting for, as I've always had more ideas than I could execute on. Historically, I've been limited by my own skills or the need to rely on others. That reliance, though, comes with its own overhead, like training, coordination, and long-term management. For someone who wants to operate as a solopreneur, those constraints have always been another layer of friction holding me back. But finally, for the first time, I can meaningfully build production-ready software on my own.
My objective has been to deploy a product-safe pilot by graduation day. Unfortunately, as my app has grown in complexity, I've encountered a different challenge. I was no longer limited in my ability to generate ideas or write code, but by my ability to manage the system I was creating. I quickly lost track of what had been built across both the front and backend. I found Claude adjusting foundational things like the data model and logic without a clear view of the consequences, to the point where I unintentionally altered the product itself.
This made my problem incredibly clear. I need help managing execution. I'm effectively missing a Scrum Master, Delivery Manager, and Project/Program Manager hybrid, who can handle repeatable, execution-oriented tasks and maintain a clear view of what exists, what's in progress, and what comes next.
This also surfaced that execution wasn't my only issue. I had never defined how I actually work. For years, I've relied on instinct and intuition to navigate the product process, and it worked when I operated independently. Things completely broke down the moment I needed to scale my work across other people. I couldn't delegate, because I had never externalized the logic behind my own decisions.
If I wanted to operate as a successful solo founder, I couldn't just move faster. I needed to make my thinking legible so that I could create the right system to manage my execution. To do so, I first had to map my product process, end-to-end.
At first glance, my approach isn't fundamentally different from standard frameworks that move from discover → define → build → launch → learn. In practice, however, these frameworks are optimized for delivery as they assume the problem is already well understood. Instead, these teams focus on getting things shipped.
My process diverges as I never rush to execute. Instead, I'm actively seeking constraints. I view product as a bounded system in which my only objective is to clearly define the edges of the sandbox I'm allowed to play in. I seek to understand what must be true, what cannot be done, and what success actually looks like. Once those constraints are clear, then I can explore solutions within them. With clearly defined boundaries, I can let my thinking run free, pull from other industries, reimagine systems, and push ideas further than I otherwise would. I'm able to act more boldly, and without hesitation, in the cell I've locked myself in.
While typically the product process extends beyond a single release cycle, for this project, I have intentionally focused on the discover → define → build phases. My objective is to launch a production-ready pilot, not to fully operationalize and optimize a live product over time. As a result, the later stages of the lifecycle, including post-launch monitoring, iterating, and long-term growth, have not been mapped here. Instead, my work focuses solely on the parts of the process that define what gets built and ensures it can be delivered successfully. These are also the areas where my expertise is strongest, and where I see the greatest opportunity to codify my thinking and support it with agents.
I focused my product map on two primary phases: THINK and EXECUTE.
The THINK phase is where all the critical, foundational decisions are made. It's where I first discover the problem, determine constraints, explore possible solutions, select a direction, and define scope. This phase relies on judgment to produce the documents, requirements, and flows that encapsulate the product strategy.
The BUILD phase is where this strategy is translated into executable units of work. It includes the planning, development, and deployment process, where work is broken down into epics and tickets, sequenced into sprints and releases, implemented, tested, and ultimately pushed to production. Unlike THINK, this work is largely structured, repeatable, and operational.
In mapping the process, I also noticed that I'm not simply plotting a sequence of steps, but a combination of different work modalities. Each step requires a different mode of thinking, ranging from strategy and discovery to design, execution, development, communication, and monitoring. These modes appear throughout the process rather than existing in isolated stages. For example, communications or user-facing work includes both user interviews and release notes ahead of the product launch.
Representing the process this way allows me to better distinguish between judgment-driven work and structured work. Judgement-driven work includes defining constraints, selecting workflows, and determining the direction for a solution. Structured work includes organizing research, generating requirements, sequencing tasks, and tracking execution.
I believe this distinction is critical as it clarifies which steps of the process can be codified and supported by agents, and which parts must remain human. Agents cannot replace this process, but they can operate within it, while I retain the control and ownership of the decisions that define the product.