You Signed Up to Build Something
You got into this because you wanted to build something. Maybe you called yourself a product manager, maybe a tech lead, maybe you just said yes when someone needed someone to own it. For product managers, Marty Cagan crystallised what it actually means: the most important non-executive position in the building, with CEO-level accountability and zero CEO-level authority.
You own the outcome. You control none of the inputs.
That's not unique to PMs. Anyone who's been responsible for a product without controlling the people who build it knows the feeling. Your power is entirely influence, trust, and insight, applied across a team you don't manage, toward goals set by people above you, through processes designed by people who've never done your job.
That's not a bug in the system. That's the system. And the smart, adaptable, genuinely committed people who survive it do so by becoming very good at navigating complicated environments: stakeholder maps, roadmap negotiations, sprint ceremonies, prioritisation frameworks. The whole apparatus of corporate product work.
The skills are real. The exhaustion is real, and here's the part that matters: surviving that environment built genuine skills, and some habits that will work against you the moment the context changes.
The context that's worth paying attention to isn't the AI-pressure environment, the one where your manager's manager is asking why the team isn't moving faster with all these new tools. That's just the old rules with a new deadline.
The environment worth talking about is different. A single person with the right instincts and the right tools can now do what used to require a team, a budget, and eighteen months of runway. That gap is real, it's open right now, and most of the people best positioned to walk through it are too exhausted from the day job to see it.
Two types of hard
Not all hard problems are the same kind of hard. Dave Snowden's Cynefin framework draws a distinction that's worth internalising: some problems are complicated, and some are complex. These aren't degrees of difficulty: they're different categories that require entirely different approaches.
Source: Cynefin framework, Wikipedia (CC)
A complicated problem is one where the answer is knowable. It requires expertise, rigour, and careful analysis, but given enough skill and information you can work it out. Building a bridge is complicated. Running a clinical trial is complicated. Optimising a mature product roadmap is complicated.
A complex problem is one where the answer isn't knowable in advance, it emerges through action. You can't analyse your way to it because the variables are interdependent and shifting. You have to probe, observe what happens, and respond. Building a new market is complex. Finding product-market fit is complex. Deciding what to build when nobody has built it before is complex.
Corporate product work is almost entirely complicated. The customers exist, the market is known, the technology is established. Your job is to optimise: find the best path through a known space, balance competing constraints, ship incrementally better versions of a working product.
The frameworks you learned were designed for this. They work. And they will actively get in the way the moment the problem shifts from complicated to complex.
The Christensen mirror
Clayton Christensen spent his career studying why good companies fail. His central observation was that the tools, processes, and capabilities that make a company successful in a stable market actively prevent it from responding when the market changes. It's not incompetence. It's the wrong capability, applied to the wrong problem.
The same pattern applies to you personally.
A roadmap assumes you know what to build. A stakeholder review assumes there are stakeholders. A sprint ceremony assumes the problem is stable enough to plan around. Apply these to a complex problem and they don't just slow you down: they shape what you're able to see. You stop noticing the signals that don't fit the process.
Kodak had more photographic expertise than anyone on the planet when digital killed film. They saw it coming. They invented the digital camera. They optimised their way right past the moment to act on it, because the organisation was built to do one thing extremely well: film. If you carry the corporate operating model into unknowable complex territory, you'll work just as hard and meet the same fate.
What needs to stay and what needs to go
The skills that transfer: pattern recognition, prioritisation under pressure, knowing what good looks like across design, engineering, and business. The ability to hold a system in your head. The commercial instinct that tells you whether something is worth building at all. These are hard-won and they matter more than ever when you're operating without a team around you.
The habits that need unlearning: consensus-seeking before you have anything worth showing. Roadmaps that project certainty you don't have. The reflex to manage up before you've validated anything. The habit of treating process as progress.
In complex territory, you move first and learn from what you find. You don't seek permission to probe. You probe, and you show the result. The speed of the loop is the thing. Every ceremony that sits between you and the next test is friction you can't afford.
The instinct to explore was there before the system trained it out of you. It's why you chose this work in the first place.
The tools that followed the dysfunction
The product tools that defined the last decade didn't succeed because they solved the right problem. They succeeded because the problem was undefined enough that comprehensive-looking software felt like the answer. If nobody can agree on what a product manager actually does, a tool that covers everything (every view, every field, every ceremony) looks like the right tool. But if the filing is elaborate enough, questioning it feels like admitting you don't understand the job.
What the alternative looks like is simpler than the category would have you believe: strategy and delivery in the same view, fast on input, visible on output. A tool that reflects your thinking back as structure while you're still thinking, not after you've filed it away.
ProductBrain was built for exactly this: the thinking work, without the performance of planning.
The path
The gatekeeping, the budget dependencies, the eighteen-month roadmaps, they still exist. What changed is that you no longer need them. LLMs collapsed the cost of execution. Tools that don't demand the performance of planning give you the thinking without the theatre. The dependency on the apparatus was always the constraint. Now it's a choice.
The complex space rewards exactly what the corporate environment spent years discouraging: curiosity, speed of judgment, the ability to see what others miss, and the commercial sense to know which problem is worth the building. If that's why you got into this, now is the time.
You don't need to unlearn everything. You need to know which tools to put down, and pick up ones built for the terrain you're actually in.
The person who makes that crossing with their real skills intact arrives somewhere most people in this field never reach. That's not a consolation. That's the upside.
Related reading: Kano and the Innovator's Dilemma Are the Same Thing: how Christensen's disruption model and Kano's satisfaction framework combine into an operating model for knowing what to build and when. The Fifth Door Is Still Work: the technical breadth required to ship a real product with AI.