Re:Work | How AI is reshaping the way we work

Re:Work #1 The changing role of product managers

Between conversations at the AWS Product Innovators Symposium and examples shared by product leaders, one thing feels increasingly clear: AI is compressing many traditional PM workflows, pushing the role further “up the stack.”

The shift

Tasks that used to take weeks such as user research synthesis, competitive analysis, drafting PRDs, and even early prototypes can now be done in hours with AI tools.

That doesn’t eliminate the PM role. It changes where the value sits.

As solution generation becomes easier, the hardest and most valuable work becomes defining the right problems.

What I’m seeing

• More emphasis on problem framing rather than solution specification.
• PMs defining goals, constraints, and evaluation criteria instead of writing highly detailed specs.
• Product Managers increasingly building early prototypes themselves before handing work to engineering for production.

What we should do

PMs should spend less time documenting solutions and more time clarifying intent.

That means developing stronger skills in:

• Problem definition
• Decision framing
• Evaluation design
• Stakeholder alignment.

AI can generate many possible solutions. The real leverage comes from choosing the right direction.

Question

For Product Managers experimenting with AI tools: where has your workflow changed the most?

Re:Work #2 The engineer role is shifting

Between sessions with engineers and conversations with teams experimenting with agentic development, one idea came up repeatedly: coding itself is rapidly becoming commoditized.

The shift

With AI development tools generating large amounts of code automatically, the engineer’s role is moving away from writing individual functions and toward designing systems that autonomous agents can execute.

The center of gravity is shifting from coding to architecture and verification.

What I’m seeing

• Engineers spending more time on system architecture and agent workflows.
• Structured specification writing that agents use to implement code.
• Increased focus on evaluation frameworks, testing loops, and guardrails.
• Developers supervising autonomous agents that can produce large amounts of code continuously.

One team described their workflow simply: Write specs during the day. Let agents execute overnight.

What we should do

Engineering teams should start investing in:

• Clear system specifications
• Strong testing and evaluation infrastructure
• Observability and guardrails for AI-driven systems.

In an AI-assisted development environment, the hardest problem isn’t generating code. It’s verifying that systems behave correctly.

Question

For engineers experimenting with AI coding tools: what part of your workflow has changed the most so far?

Re:Work #3 The rise of agentic architecture

We’re starting to see common design patterns emerge for AI-native systems. Between demos and technical sessions, one thing felt clear: agentic architecture is beginning to develop its own playbook.

The shift

Just as microservices became a defining architecture pattern for cloud-native systems, AI systems are developing new patterns for coordinating models, agents, and workflows.

These patterns focus less on static logic and more on structured reasoning processes.

What I’m seeing

Several recurring design patterns appeared across teams:

• Prompt chaining: breaking complex tasks into smaller steps
• Reflection loops: agents reviewing and improving their own outputs
• Multi-agent orchestration: planner agents coordinating specialist agents
• Resource optimization: routing tasks across different models
• Guardrails: validation layers and boundaries around agent actions

These patterns help make AI systems more reliable, controllable, and scalable.

What we should do

Teams building AI products should think less about individual prompts and more about system design for agents.

That includes:

• Clear workflows
• Evaluation loops
• Structured reasoning steps
• Well-defined boundaries for autonomous behavior.

The architecture of AI systems may soon matter more than the models themselves.

Question

What architectural patterns have you found most useful when building AI-powered systems?

Re:Work #4 Why durable truths matter right now more than ever

I’ve been thinking about the idea of durable truths. Between the pace of change we’re all experiencing, shifting roles, and constant signals about what’s coming next, one thing feels increasingly clear: while the future is uncertain, not everything is.

The shift

We’re operating in a moment where it feels impossible to keep up. There’s a constant pull to stay ahead, paired with a real sense of anxiety about how work is changing. That combination can quickly lead to feeling overwhelmed or even paralysis. And despite what you might hear, no one can reliably predict what’s coming next.

What I’m seeing

I’m seeing more teams struggle with the pressure to react to every new trend, often without clarity on what actually matters.

I’m also seeing how quickly uncertainty can slow decision-making, even in high-performing organizations.

At the same time, the teams that seem to move with confidence aren’t guessing more accurately, they’re anchoring themselves in what they know won’t change.

What we should do

Instead of trying to predict the future, we should spend more time defining our durable truths, the things that will remain constant for our business and industry.

A few that stand out to me:

• Speed matters.
• Understanding and clearly defining the problem is more important, and often harder, than building the solution.
• Trust compounds over time and is difficult to rebuild once lost.
• The innovation flywheel will continue to accelerate, and falling behind makes catching up exponentially harder.
• Culture becomes the bottleneck, not the technology.

These aren’t trends. They’re fundamentals. And they’re far more reliable anchors than any prediction.

Question

What are the durable truths that guide how you build and operate?

Re:Work #5 The death of traditional roadmaps

Between shifting priorities, faster build cycles, and constant new information, one thing feels increasingly clear: the way we’ve been planning work no longer matches the reality of how work gets done.

The shift

Roadmaps were designed for a world with more certainty. You could define priorities upfront, align teams, and execute against a relatively stable plan. That world doesn’t really exist anymore.

Today, the half-life of information is shorter. What we learn this quarter can quickly invalidate what we planned last quarter. The risk isn’t just building the wrong thing, it’s committing too early to decisions we don’t yet have enough context to make.

What I’m seeing

I’m seeing roadmaps become more about signaling alignment than driving actual outcomes. 
I’m seeing teams spend significant time defending plans instead of updating them.
I’m also seeing the most effective teams treat roadmaps as living artifacts, not fixed commitments.

What we should do

Instead of treating roadmaps as promises, we should treat them as hypotheses.

That means:

• Anchoring on problems and outcomes, not just features and timelines.
• Creating space to adjust as we learn, not just as plans fail.
• Measuring progress by what we’ve learned and changed, not just what we’ve shipped.

The goal isn’t to eliminate planning. It’s to make planning more honest, more flexible, and more connected to reality.

Question

How are you evolving the way you plan in a world where priorities don’t sit still?

Re:Work #6 Operating in continuous beta

Between faster feedback loops, evolving customer expectations, and constant iteration, one thing feels increasingly clear: finished is no longer a stable state.

The shift

We used to think of work in phases: build, launch, stabilize. Now, products, strategies, and even org structures are in a constant state of evolution.

That creates tension. Many teams still seek certainty and closure, while the environment demands adaptability and ongoing change.

What I’m seeing

I’m seeing teams struggle with the discomfort of never being “done.”
I’m seeing more frequent releases, but not always better learning.
I’m also seeing high-performing teams embrace iteration as a core capability, not a temporary phase.

What we should do

We need to normalize operating in continuous beta.

That means:

• Designing for iteration from the start, not as an afterthought.
• Shifting from perfection to progress.
• Building feedback loops that actually inform decisions, not just validate them.

Continuous beta is not about being unfinished. It’s about being responsive.

Question

Where are you still operating as if things should feel “final” when they no longer are?