On February 26, 2026, Block announced it was cutting more than 4,000 jobs, representing over 40% of its workforce, as it reorganized around AI. The impact was concentrated in product, engineering, and design.
I was at a work offsite when the news hit. People left conference rooms and were just gone. I didn’t have time to say goodbye to my team.
My team had gone from five people to me. The work was still there. My reaction was basically: oh shit. How do I move forward?
The adrenaline fueled a lot of activity. There was a push within the company for non-engineers to become builders, and I threw myself into figuring out how. I needed agents, a knowledge base, a second brain. A second me.
Actually, I needed five me’s.
And for a while, it seemed like it was working. By April, I had written product requirements documents for 46 finance and accounting priorities. Most involved journal automation; others covered tax transfer pricing, software capitalization, and bank account reconciliation. We started working through them.
By June, I was having mini panic attacks before the standups I was supposed to lead. I had agents preparing agendas and pulling together meeting notes, but I didn’t understand the work well enough to know which questions to ask.
What I’ve learned since then has implications for both me and the company.
I still have to do the work of being a good product manager. AI gives me much more capacity to investigate, build, and learn. But I have to develop the understanding required to own the outcome.
And if a company expects that transition to happen quickly, especially after dramatically reducing capacity, it has work to do too. People need support figuring out how the tools change their jobs, how to use them effectively, and what value they’re actually creating.
I could produce more than I understood
What I hadn’t appreciated was how much discovery I had already done myself on the first few problems we started working on. I understood those problems before moving to a fully agentic workflow. That understanding carried forward and masked the issues for another couple of months.
When we got into journal-entry estimation, I didn’t have that same foundation.
I kept trying to solve the problem with more program-management automation. But an agenda could make sense to me the night before and then not make sense the next morning. It didn’t give me enough understanding to drive the conversation.
Eventually, I got the subject-matter experts, the engineers, and everyone who knew the requirements into a room and had them talk it out. That was effective. It also reinforced the feeling that I had become a proxy, coordinating between people, agents, and documents without understanding enough of the substance myself.
That was the limit I hadn’t accounted for when I was trying to make five me’s.
Before automating the process, understand the system
One of the more useful examples of what AI actually enabled came from that same accounting work.
We were looking at journal automation for a part of the business with a particularly complicated data-ingestion and warehousing setup. Initially, we expected to automate the manual work the team was doing, using an approach that had worked elsewhere.
But the data behaved differently. The timing was different. Delivery was different. In some cases, it wasn’t clear whether we could get the data when we needed it.
So we stepped back and mapped the complete pipeline: where the data originated, what happened to it, what was being reconciled automatically, what people were doing manually, and when each part ran.
Building that picture meant understanding work across five to eight teams and checking that the picture was correct with the people involved.
Once we had it, I could see options we hadn’t started with. Reordering jobs might get some of the actual data in on time, reduce the need for estimates, and let us focus on the difficult reconciliation problems. We might not need to build ML for some of the work we had initially expected would require estimation.
None of those changes had been implemented. I hadn’t decided on the approach yet. That decision was mine to make.
But I had a much better understanding of the decision in front of me. We had started by asking how to automate the existing manual work. Now I could question which parts of that work needed to exist at all.
The difference is the breadth of discovery
Previously, I would have met with each team, had them walk me through their part, gone back to distill it, and shared it with them again. I would have needed help finding the right tables and either done the analysis myself or asked someone else to do it. Getting answers would have taken multiple meetings.
Across the number of projects we were trying to deliver within a quarter, that level of discovery wouldn’t have been feasible in the time available.
Agents made more of it possible. I could investigate more paths, get to dependencies and risks faster, and bring specific questions to the people who could resolve them. Teams in Australia or India could respond while I was offline, and the work could keep moving.
The judgment was still mine. But I could get to the point where that judgment was useful much faster.
That is good product management. It would have been good product management before any of these tools existed.
It also feels central to becoming an AI-native company. Automating every existing procedure can create an enormous amount of activity. You still have to understand the system well enough to decide which procedures should change or disappear.
For me, making the findings become my understanding means I still need to write. I need to create artifacts, visuals, and diagrams. I need to explain things to other people, share directly, and work through their questions. I need that generative friction.
And I need to ship the thing.
Owning the whole thing
One of the coolest opportunities that came out of being an early adopter was building an internal document-review application.
It brings together source documents, summaries, and key topics, with a chatbot that lets users ask questions across multiple documents.
I’m the product manager, the builder, and the program manager. I’m doing the design work too.
As I built the chatbot, the requirements developed along with my understanding. Initially, it answered questions about one document. That was pretty limited, so we added multiple documents. Then we ran into limits on how much information we could send in a request, which meant learning about retrieval, context chunking, and how to get the right material into an answer.
Each step exposed something else I needed to understand.
The application has now been used repeatedly and extended each time. It’s critical work, it has real users, and it’s highly visible internally. The part that matters most to me is that I own the whole thing. I can go from an idea to a working product, learn what it takes to make it function, and keep improving it.
That ability also changes how I work with engineering. I can get much further into design and prototyping before bringing an engineer in. Building forces me to work through requirements. I’m bringing something more concrete, with more of the thinking already worked through.
The company has a job here too
Taking more of an idea through the product loop myself means learning how to do work that used to belong to several different roles.
And we weren’t learning these tools with our old capacity intact. Part of my day went into figuring out how to connect agents, preserve context, and make workflows function, while also absorbing the work of a team.
Some experimentation is necessary. I’m curious, and I enjoy it. But spending half my day getting the tools to work together takes time away from the product I own.
Companies can provide useful defaults: shared skills, templates, knowledge repositories, suggested workflows, examples, and office hours. Understanding how people actually use the tools creates opportunities to build something useful once and improve it for everyone.
There also needs to be thought about the roles themselves. If PMs are expected to become builders, what support helps them make that transition? If managers become player-coaches, what does that mean for their work and career growth?
AI tooling is tooling. Like data and ML tooling before it, it needs intentional development, operating practices, clear goals, and some way to understand the value it produces. That support would let people spend more attention on doing their jobs well.
Faster loops, same responsibility
Where I’ve landed personally is that I’m probably about twice as productive as I was before all this happened.
I can work across more projects, do broader discovery, and build prototypes that previously required more people and coordination. Two or three projects in parallel feels possible. Five runs into the limits of how much context I can understand and retain.
The biggest benefit is speeding up the product loop: identify a customer problem, form a hypothesis, design an experiment and a solution, build it, test it, learn, and repeat.
I still need to understand the customer need, the jobs to be done, and why we’re building something. I’m still responsible for the user experience and for delivering customer and business value. I can’t outsource that responsibility to five versions of myself.
Taste and instinct still come from experience building things, shipping them, and seeing what happens.
So I don’t think much has changed about what it means to be a good product manager. What has changed is how much I can do as one and what a company needs to provide to help people work that way.
We’re going to spend years figuring out what that makes possible and how the roles should evolve.
And that is exciting. I’m curious about a lot of things, and now I can build far more of them. I can follow an idea further, get something into people’s hands faster, and learn from it.