I’m serious. Delete the whole thing.

If something in there was actually important, you’ll hear about it again. Real bugs get reported again by the next person who hits them and real customer needs get raised again by the next person who has them.

The rest was junk you were never going to do anyway, no matter how many times you groomed it.

Most teams won’t try it. Everyone will be mad if we delete their half-baked idea from the list. It also looks like proof that the team is thinking ahead and that nothing is being forgotten. The future is queued up and ready.

The backlog mostly looks like job security.

But that’s the problem. The backlog was never an asset, it was a liability of all the crap we thought we had to do. It was a graveyard with a project management interface.

Then AI changed everything. Claude Code showed up and could clear the whole backlog in a weekend.

The Backlog Was Always the Junk Drawer

Walk through the average engineering team’s backlog and you’ll find a museum of things nobody is going to do. There’s a feature request from a customer who churned in 2023, a bug ticket nobody can reproduce, an “improvement” idea from a product manager who left the company, and a research spike that was supposed to inform a decision that ended up getting made six months ago without it.

Then there’s the engineering side of the junk drawer, which is its own ecosystem.

You’ll find the refactor someone proposed two years ago that everyone agreed was important, the library migration that keeps getting bumped because it’s not customer-facing, and the monitoring overhaul that’s been there long enough that nobody remembers what problem it was supposed to solve.

Engineers loved these tickets because they felt productive and serious without requiring anyone to sit in a room arguing with product about priorities. Product loved them right back, because keeping engineers busy meant nobody had to make a hard call about what actually mattered.

That was the whole point of the backlog. It was the place where decisions went to be deferred indefinitely.

The Real Reason Teams Hid in the Backlog

Strategic roadmaps are hard. They force executives to disagree with each other in the open, push product to tell engineering why something didn’t make the cut, and force engineering to push back when product is wrong. They require choosing winners and losers, naming what won’t get done, and standing behind the choice when your competitor ships the feature you decided not to do.

Backlog grooming requires none of that. A team can spend a 90-minute meeting refining estimates on tickets that will never ship and walk out feeling like they accomplished something. The whole exercise lets the team look busy and serious without anyone having to make the call about whether they’re building the right product in the first place.

That’s the path of least resistance for any team that doesn’t want to fight about priorities. It’s also the reason most engineering orgs feel busy and frustrated at the same time. Everyone is moving, but nobody can point to what mattered.

My favorite backlog grooming was always deleting the whole thing... until AI showed up.

AI Burned Down the Hiding Place

Claude Code can chew through a well-defined backlog at a pace that would have seemed absurd two years ago. Even the engineering wish list, the refactors and migrations and monitoring improvements, can be knocked out at speed when AI knows the codebase well enough.

Which means the activity of “working through the backlog” has lost its cover.

You can’t claim the team is heads-down on important work when the same work could be done by AI in a long weekend. You can’t justify a quarter on cleanup when cleanup is what AI is best at. Execution stopped being the constraint, which means execution stopped being a place anyone can hide.

For teams that are good at strategy, this is a gift. They get less wasted effort, more focus on outcomes, and more time on the conversations that actually move the business. For teams that have been deferring strategy for years, it’s terrifying. There’s nothing left to do except the thing they’ve been avoiding.

The New Problem Nobody Is Ready For

This is where I want to be honest. Killing the backlog is the easy part of the story. The harder part is what comes after.

When a team is producing two or five times the volume of code, review becomes the bottleneck. PRs pile up faster than humans can read them. Most of the code looks fine on the surface, but somewhere in the diff is a subtle bug, a wrong abstraction, or a solution that solves the problem you described instead of the problem the user actually has. You can’t tell which PRs have those issues without careful review, and careful review at AI speed is exhausting.

The shape of engineering work shifts too. Engineers who used to write code now spend their days editing code that AI wrote, which is a different muscle, and most engineers were never trained for it. Senior engineers who used to mentor junior engineers through code reviews are now reviewing the AI’s code while the junior engineer waits to be told whether to accept it. Junior engineers themselves are stuck in a strange limbo where they’re supposed to be learning the craft, but the craft is increasingly being done before they touch it.

Then there’s the architectural challenge that everyone is trying to figure out. AI is great at building what you asked for. It’s not great at maintaining the conventions of your codebase, the principles your team has agreed on, or the long-term shape of the system. If your review process isn’t catching those things, your codebase is getting messier in ways that won’t show up for a year, and by then the cleanup will be enormous.

Most teams are not set up for any of this.

They cleared their backlog and high-fived. They didn’t notice that the work they had been doing was the easy part of engineering, and the work they’re left with is the part they were never very good at.

Product Thinking Is the Whole Job Now

The Product Driven thesis is that engineers who think like owners outperform engineers who wait for tickets, that engineering teams need vision, focus, clarity, ownership, and courage more than they need process, and that the bottleneck in most software orgs has never been technical skill. It’s been product thinking.

This is the thing I think about constantly at Full Scale. The engineers our customers value most aren’t the fastest builders. They’re the ones who can sit in a planning meeting and ask whether the team is solving the right problem. That skill was always valuable. Now it’s the price of entry.

For most of the last decade, you could ignore that argument. You could keep your team busy on tickets, ship features that didn’t matter, and call it engineering. The backlog gave you cover for not doing the hard work of figuring out what to build.

That cover is gone. AI handles the ticket work. The only thing left for engineering teams to do is the work that AI can’t do, the work that requires judgment, taste, customer empathy, and the willingness to say “we shouldn’t build this.” Which is to say, the work that’s left is exactly the argument of Product Driven.

The teams that build that muscle right now are going to win the next decade. The teams that don’t will look back in a year wondering why their AI-cleared backlog produced nothing of value, while a smaller team somewhere else used the same tools to build something customers actually wanted.

The Backlog Was a Treaty

The backlog was a peace treaty between product and engineering. Both sides agreed not to have the hard conversations as long as everyone stayed busy. That treaty is over now.

Now the only work left is the work everyone has been avoiding.

The hard conversations are the only ones left.

P.S. You can grab a free copy of Product Driven. The whole book is about how to build engineering teams that can have the hard conversations.

“AI can write all the code.”

How much can you trust AI is the real question.

No matter where code comes from, you’re still responsible for it.

The AI didn’t sign your customer agreement. The AI doesn’t carry the SOC 2 attestation. The AI doesn’t get paged at 3am. The AI doesn’t get fired when production crashes.

You did. Your team did. Your company did.

That accountability hasn’t moved. You can’t point the finger at AI when things don’t go perfect.

AI deleted your production database? Sorry, it’s your fault.

No matter how good the AI models get, that won’t change.

Which means the rule is simple:

AI can write 100% of your code, but humans still have to review 100% of it, because humans are still 100% responsible for it.

You can’t dodge accountability.

Microsoft just published new research that turns this from a philosophical argument into a real one.

What Microsoft’s DELEGATE-52 just showed us

DELEGATE-52 is a benchmark Microsoft Research just released. It simulates long delegated workflows across 52 professional domains: code, databases, financial statements, music notation.

Think about your long chats with AI. You change things. You change them back. Over time, a long context of edits piles up.

That’s exactly what DELEGATE-52 was built to measure.

The test setup is deceptively simple. Give a model a document. Ask it to make a structural edit, the “forward” edit. Then ask it to undo that edit, the “backward” edit. Chain those round trips together. After 20 interactions, compare what you have to what you started with.

If the model is doing its job, you end up where you started.

Except it didn’t!

Across 19 models tested, the average degradation was about 50% of the original content. The frontier tier (Gemini 3.1 Pro, Claude 4.6 Opus, GPT-5.4) corrupted roughly 25% of content by the end of long workflows. Only one domain consistently cleared a 98% fidelity threshold across the frontier: Python code. Most everything else slipped, and natural-language and niche domains failed badly.

The headline number is bad enough. The detail of the failure is worse.

Weak models, the paper found, fail by deletion. Things go missing. That’s noticeable. You can spot it in a diff.

Frontier models fail by plausible rewriting. The shape of the content stays the same. The vocabulary stays the same. The output looks like what came before. But the substance has drifted. Subtly, defensibly, in ways that survive a normal review.

Read that again, because it’s the whole argument.

The better the model, the more dangerous the corruption, because the corruption looks like it isn’t there.

“I read the diff and it looks fine.”

That’s how most engineering teams review AI code today. It’s also the exact review this kind of corruption is built to slip past.

Two findings that should reset how you evaluate AI tools

Buried in the paper are two more results that matter at least as much as the corruption rate.

#1 Two prompts can’t predict twenty

Microsoft was explicit: short prompt sessions tell you nothing about how the model behaves in a long session. If your team’s “we tested it and it worked” story is built on a few prompts and a thumbs-up, that story doesn’t hold up.

The model that looked great in the demo is the same one that loses 25% of the document by the 20th prompt.

#2 Even Claude Code can’t save you

The kind of agentic loop Claude Code runs didn’t improve DELEGATE-52 scores. The problem is in the model itself, not the wrapper around it.

Want another piece of evidence?

Look at Chroma’s “context rot” research, which tested 18 frontier models and found that every one of them degrades as input context grows, well before the advertised window fills up.

Chroma found that three things go wrong at once.

Models pay attention to the start and end of context but skim the middle. As context grows, they have exponentially more pairs of words to track, so focus dilutes. And similar-looking content actively misleads the model.

None of these are bugs. They’re how the AI models work.

Two independent research efforts came to the same conclusion:

Output quality drops as sessions get longer and context gets wider. The models can’t tell. Reviewers usually can’t either.

And nowhere does this hit harder than on real, large codebases.

The prototype trap

The research confirms what we keep reading about on LinkedIn and social media.

People rave about the amazing prototype they built over a weekend. At the same time, enterprise software architects are not impressed with AI.

The research is showing that both things can be right at the same time.

The prototype thing people rave about is real. You describe an app, AI builds it in 30 minutes, the demo works. Anyone who says otherwise hasn’t tried it.

Then point the same AI at your actual codebase. 200,000 lines of legacy Python. Fifteen internal frameworks. Business logic that took ten years to get right.

The wheels come off. The architects were right.

Bigger codebases trigger context rot immediately. Enterprise sessions are never one-shot, so corruption compounds. And the failures hide better in 200 files than in 5. A 5% silent corruption rate across an enterprise repo is invisible until production breaks.

The numbers map this directly. Python on simple workflows: 98% fidelity. Most other domains over long sessions: 25-50% degradation.

“If AI built that demo in 30 minutes, imagine what it’ll do for our platform.”

That’s the trap. The demo tells one story. The first production incident tells another.

How to use AI you can’t trust

If humans are responsible for the code, the engineering moves are obvious. The goal isn’t using less AI. It’s using AI in a way humans can actually review.

Tip #1: keep sessions short enough that a human can still hold the diff in their head. DELEGATE-52’s whole point is that long sessions accumulate plausible-looking corruption. If your agent ran a long session and produced a 2,000-line diff, no human is going to actually review that, no matter what the PR comment says. Cap session length. Commit and restart aggressively. Treat each agent session like a one-off contractor job, not a long-running employee.

Tip #2: narrow the context, don’t widen it. Repo-wide context windows feel like progress. They’re the exact thing that triggers context rot. For most edits the model only needs the file, the interfaces it touches, and the relevant test. That’s 2-10K tokens, not 200K. Build that into your tooling. The model won’t do it on its own.

Tip #3: verify by execution, not by reading. This is the move that actually catches plausible corruption. Tests, type checks, property checks, integration checks. Those are the only review steps that aren’t fooled by output that looks right. If your CI doesn’t catch what an LLM silently changes, your reviewers won’t either. The model produces exactly the kind of change designed to slip past visual review.

Tip #4: you can’t generate more AI code than you can review. This is the one that actually matters. Either grow review capacity, narrow where AI is allowed to work, or slow how fast AI code enters your repo. Anything else just defers the risk to a future incident.

The bottom line

The marketing pitch for AI coding tools is “AI writes code for you.”

Anyone who’s actually used AI knows the real version: AI writes the code for you, and you spend all day making sure it actually works.

DELEGATE-52 is not an interesting benchmark. It’s evidence in the case against trusting code you did not personally read, did not personally test, and did not personally vouch for.

The teams that get this in 2026 will ship faster with AI than the teams that don’t. They’ll spend less time hunting plausible-looking bugs that no human introduced. And a lot less time explaining to a customer why something they thought was reviewed wasn’t, really.

Your AI assistant is a really productive intern.

Don’t ship its code without reading it.

You’re the one whose name is on it.

Further reading

• LLMs Corrupt Your Documents When You Delegate (arXiv:2604.15597)

• DELEGATE-52 code and dataset

• Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma Research)

Even the CTOs panicking on Slack about AI replacing engineers are only half right. AI is replacing a kind of work, but the work it’s replacing is the engineering. What it’s bringing back is something we used to do twenty-five years ago and somewhere along the way forgot how to do

What We Actually Did 25 Years Ago

When I started my career, my job title was software developer. Not engineer. Developer. I have long been confused by the difference as the terms seemed interchangeable. Now, the difference is more obvious than ever. Let me explain why.

Back then, I sat down with customers, asked them what would make their job easier, and tried to build it. Simple, right?

In 2001, that meant going where they actually worked. I sat in a medical lab studying how they checked in lab specimens, flew around the country meeting with ticket brokers, and walked car dealership lots learning how cars actually got sold.

I spent countless hours on the phone with customers learning about their problems.

Avoiding customers wasn’t an option. We had to “develop” the solutions to their problems. That meant listening to them.

Development was the whole job. I’d talk to the customer, write the code, ship it, and rebuild it when I got it wrong. There was no spec sitting in a queue and no PM translating what the customer needed.

The tools were built for that kind of work. We had rapid application development (RAD), and tools like Visual Basic that let you drag a button onto a form, double-click it, and write the logic right there. The whole stack was designed to compress the loop between “I think I know what they need” and “let me show them and find out.” It was definitely RAD!

We weren’t over-engineering anything. We were figuring out what the right answer was by building, showing, learning, and rebuilding. The early agile manifesto came out of this exact world: customer collaboration over contract negotiation, working software over documentation, responding to change over following a plan.

How Engineering Took Over

Then the tech boom happened. Companies got bigger, teams got bigger, compliance showed up, specialization showed up, and the way the industry decided to scale was to break the job apart.

The customer conversation got peeled off and given to product managers, the roadmap went to product owners, project managers ran the schedule, business analysts wrote the specs, QA tested at the end, DevOps ran the infrastructure, UX designers owned the experience, and architects drew diagrams that nobody actually read.

By the time the coding work landed on an engineer’s desk, every interesting decision had already been made by someone else.

That’s an assembly line.

Tickets came in one end, code came out the other, and the person writing the code had no idea who the customer was or why the feature mattered. We renamed it engineering because that’s what it had become, a careful, formal, documented process for converting requirements into code.

None of the supporting roles around the engineer are bad on their own, but the engineer in the middle of that pipeline loses the thing that made the work matter to them.

They stop seeing customers, they stop owning outcomes, and they focus on moving tickets across a kanban board. Most engineering teams I see today are running this exact playbook and wondering why their people don’t act like owners.

They don’t even know who the customer is or how their work impacts them.

What AI Is Actually Doing

AI is the best rapid application development tool ever built. It is really RAD!

It compresses the loop between idea and working software in a way that Visual Basic could only dream about. Claude Code can take a half-formed thought and have a working prototype in front of a customer during the customer call itself! The boring engineering work, the typing and the scaffolding and the wiring between systems, is exactly what AI does well.

This is why the panic about AI replacing developers is misreading the moment.

We aren’t in a moment where developers are getting replaced. We are in a moment where the engineering assembly line is getting replaced. The question every engineering leader has to answer right now is whether they are running an assembly line or a development team.

You do call it the “dev” team, right?!?

The 80/20 Just Flipped

When I started, a software developer spent maybe 20% of their time writing requirements, talking to customers, and validating their work. The other 80% was engineering itself, the typing, searching Stack Overflow, debugging, and wrestling with frameworks. The engineering part was still very time consuming.

That ratio has flipped. As a software developer today, we spend 80% of our time figuring out what to build, writing requirements clear enough for an AI to act on, and validating what comes back. The 20% is engineering, and most of that is reviewing the code that Claude Code wrote.

Reviewing the output of AI is now a massive part of the job.

Claude Code is the software engineer now. I’m managing it. What I’m doing now is a hybrid of product owner, software architect, and QA, three jobs that the industry spent the last twenty years pushing apart and treating as separate functions. AI has collapsed them back into one role, and that role is software developer.

In my opinion, it is also way more fun and you can better see how your work matters to the customers who use it.

The reality of this is much messier than what I’ve described.

Customer-facing work is its own kind of messy and confusing nightmare (at times), and plenty of strong engineers want nothing to do with it. Not every developer on your team is going to thrive on a sales call, and the reality is that not every developer needs to.

The answer is somewhere in the middle. A few people on the team will love being close to customers, and you should let them run with it. The rest are going to need the customer’s voice piped in to them, and that’s where the leader’s job comes in.

If your developers can’t all be on the call, you have to be.

You sit on the customer calls, read the support tickets, watch the demos, and then keep repeating what you heard until the customer’s voice is loud enough in the team’s head that it shapes the work even when no customer is in the room. That isn’t optional anymore. The team can’t navigate the new 80/20 ratio without it.

If we can write code 5x faster, we need product requirements 5x faster.

Or you need software developers who intuitively understand the customers and the business problems.

The Retraining Problem

If any of this resonates, your leadership team is going to be living with these questions:

How do we retrain our engineers to be software developers?

How do we create more product owners on a team that has been organized around tickets for two decades?

Engineers haven’t lost product thinking. Many never had the chance to learn it. We hid them from the customer behind a stack of PMs and BAs for twenty years and never showed them what product thinking even looked like. Now we have to expose them to the customer fast, because the teams that figure this out first are going to ship circles around the ones still defending the line.

Every engineering leader we talk to right now is saying the same thing. They can process the backlog faster than ever, and the real bottleneck is figuring out what to build next. There’s a severe lack of skilled product managers and product owners in the industry to answer that.

The solution is to go back to where we were twenty-five years ago, when we had more software developers who thought like product owners themselves.

That’s the question I wrote Product Driven to answer. The book is built around five pillars: vision, focus, clarity, ownership, and courage. Two of them, Focus and Clarity, are what your team needs most right now. Focus is saying no to work that isn’t connected to a real customer outcome. Clarity is making sure every developer knows why and who, even when they aren’t on the call. Without those, the new role doesn’t work.

I’d rather you read it than not, so I’m giving it away for free on my website. Grab a copy if you want the framework for how to actually do this with your team.

The industry spent two decades turning developers into engineers. Luckily us old timers remember what it was like to be a software developer.

Software development is back, baby!!!

Here’s what’s worth saying out loud. AI isn’t replacing engineering jobs. It’s replacing engineering tasks. That distinction matters, and most leaders are fumbling it.

The easier parts of the job are getting automated. That isn’t new. Software engineers have been automating other people’s work for forty years. Now AI is automating ours. Writing code has always been the easy part. Knowing what to write has always been the hard part. AI is great at the first one. It is nowhere near the second.

A Task Is Not a Job

A task is a unit of work handed to you. A job is ownership of an outcome.

If your job is “close these tickets,” AI can already do that. Claude Code reads the spec, writes the code, opens the PR, passes the tests. If the requirements are detailed enough, AI is faster and cheaper than a human engineer will ever be.

If your job is “make checkout convert better,” or “keep our infrastructure costs from bleeding us dry,” AI is a tool you wield. Not a replacement. Those are outcomes, not tickets. Outcomes require judgment, context, trade-offs, and conversations with people who are not engineers.

The uncomfortable part: if your team has been run like a ticket factory, AI is exposing that. Not because AI is magic. Because the job was defined too narrowly to begin with.

Writing Code Was Always the Easy Part

In 1986, Fred Brooks wrote an essay called “No Silver Bullet.” It’s one of the most important things ever written about software engineering, and it lives inside his book “The Mythical Man-Month,” which you should read if you haven’t.

Brooks drew a line between two kinds of complexity in software. Accidental complexity is the stuff that’s hard because of our tools, our languages, and our platforms: the typing, the scaffolding, the glue between systems. Essential complexity is the stuff that’s hard because the problem itself is hard: figuring out what the software should do, specifying it correctly, and understanding the people who will use it.

Brooks argued that productivity tools would keep attacking the accidental side and would never put a dent in the essential side. He was right about compilers, IDEs, frameworks, ORMs, serverless, and no-code. Each wave was supposed to replace engineers. Each wave made the job bigger, not smaller. More software got written, and someone still had to decide what it should do.

AI is the same thing, just bigger. It absorbs the accidental complexity in one enormous gulp: syntax, scaffolding, boilerplate, glue, first-draft implementations. None of that is where software engineering was ever actually hard.

I built VinSolutions and Stackify from nothing. The parts I remember are not the parts where I was typing. They were the parts where I was trying to figure out what a car dealer actually needed at 11pm on a Tuesday. Or what a developer using Stackify cared about when their production app went down. The code wasn’t the mountain. The users were.

That is the shift every engineer has to make now. Stop thinking about the code and start thinking about the people who will live with it. What are they trying to accomplish? What would make their life easier tomorrow? Where is the thing they put up with every day because nobody bothered to fix it? Step out of the editor. Go find the real problem. The real problems are not inside your repo. They are inside your users’ days.

What Survives, What Doesn’t

What AI is absorbing:

• Boilerplate, scaffolding, glue code

• First-draft implementations from a clear spec

• Rote test writing

• Tier-one bug triage

• Internal tools, admin panels, most CRUD

What it isn’t touching:

• Problem framing and product judgment

• Technical trade-offs under real constraints

• Understanding the customer well enough to build the right thing

• Communicating with people who are not engineers

• Owning an outcome end to end

The honest version of this conversation is: if you built a team around ticket throughput, a chunk of those engineers are exposed. That isn’t an AI problem. It’s a management problem that AI is making visible.

What Engineers Should Actually Do

1. Start asking why. Ownership and understanding both start with that one question. Why are we doing this? Who is it for? What happens if we don’t? If you’re writing code before you can answer those questions, you’re doing what AI does. The engineer AI cannot replace is the one who refuses to start until the problem is clear.

2. Own an outcome, not a backlog. Pick a number that matters to the business, whether that’s conversion rate, activation, build time, or churn, and tie your week to moving it. If you can’t show a number moved, don’t count the work. Tickets closed is not an outcome.

3. Ship end-to-end, not to the PR. Your job is not done when the merge goes through. It is done when the customer sees value. Watch your feature land in production, read the support tickets it generates, and find one user who will tell you what they actually do with it. That last step is where almost everyone quits, and it’s where the job now lives.

4. Review AI’s code with more rigor than you’d review a junior’s PR. The most dangerous engineer on your team right now is the one who can’t tell when Claude handed them subtly wrong code. Reading code used to be a useful skill. Now it is the critical one. If you can’t explain why every line is there, you don’t own it, and you shouldn’t be merging it.

5. Use AI to buy yourself time for judgment, not more tickets. The trap is using AI to close Jira cards faster. The play is using the hours you save to talk to users, understand the product, and push back on bad requirements. If your throughput went up but nothing else about your work changed, you’re doing it wrong.

What Engineering Leaders Should Actually Do

1. Actually do your one-on-ones. You might not enjoy them. Do them anyway. One-on-ones matter more now than they did three years ago, not less. This is where you hear how AI is actually changing the day-to-day for your engineers, where they feel exposed, and what they think their job is becoming. It is also where you reconnect each engineer to the bigger picture: why the work matters and how it fits into what the company is trying to build.

2. Ditch the vanity metrics. The old velocity signals (commits, PRs merged, story points, team velocity) were always game-able, and AI makes them trivially game-able. What matters now is the impact of the work, not the volume of it. What outcomes for your users can you track instead? Pick one your team can actually move, and make that the new north star.

3. Put every engineer on a support rotation. Two hours a week reading real customer tickets will change what your team builds more than any kickoff meeting ever has. If you can’t run a real rotation, forward the top five support tickets to the team channel every Monday. Engineers who never see the damage their software causes will never fix it.

4. Protect your team’s focus. AI made code cheap. It did not make attention cheap. If your engineers are still context-switching across ten competing priorities, you have not adjusted to the new world yet. The highest-leverage move a leader makes now is cutting the list in half. Focus is a leadership job, not one you can delegate to your team.

5. Invest in clarity before velocity. AI will write the wrong code faster than any human ever could. If the problem is fuzzy, the speed multiplier works against you. Get the brief crisp before a single line is written: what are you solving, who is it for, what is in scope, what is out. Product clarity, scope clarity, and technical clarity are the real unlocks now, not more AI tooling.

6. Stop shielding engineers from product. You do not need every engineer in every messy stakeholder meeting where nobody makes a decision. What they do need is to see the roadmap and understand why each choice on it got made the way it did. The old version of engineering leadership buffered engineers from product ambiguity, and it produced exactly the kind of engineer AI can now replace. The goal isn’t more meetings for your team, it is more understanding of the product.

The Real Question

The panic is real, but it’s aimed at the wrong thing. AI is doing what every abstraction before it has done. It’s pushing the work up. Engineers whose jobs were defined as “execute tickets” are in a bad spot. Engineers whose jobs were defined as “solve business problems” just got the biggest leverage boost of their careers.

It has never been more fun to build software, if that is what you are focused on. The fun is in building for users, not writing code for yourself.

Here is the big question...

Are your engineers doing their job, or only the tasks you assigned them?

Your team needs goals, not just tasks.

Most people are still catching up.

If you feel like the tools keep shifting under your feet, you’re not imagining it. They are. And understanding where we’ve been helps make sense of where we actually are right now.

Generation One: Asking AI for Help

The first wave started simply. ChatGPT dropped, and suddenly engineers had a smarter, faster version of Stack Overflow.

You’d paste in a function you were stuck on. Ask how to write a regex. Get a snippet, copy it into your editor, and carry on. The workflow didn’t change. AI was a research tool. A really good one, but still just a tool you consulted and then left.

The core question in this generation was still: “How do I build this?” You had the problem. You had the plan. You just needed help with the syntax.

It was genuinely useful. But the engineer was still doing 100% of the thinking and 100% of the writing. AI was somewhere between a documentation search and a rubber duck.

Generation Two: AI Inside the Editor

Then AI moved into the IDE itself, and the experience changed.

GitHub Copilot showed up and started finishing your thoughts as you typed. Cursor went further. You could highlight a block of code, describe what you wanted changed, and watch it happen in place. The AI had access to your entire codebase, not just the snippet you pasted. That context made it dramatically more capable.

This felt like a real unlock. The suggestions weren’t just snippets anymore. They were whole functions, whole files, built with awareness of what was already around them.

But the model was still the same: you were in the driver’s seat. The AI was a copilot in the literal sense. Your hands were on the wheel. You made every decision. AI helped you execute faster, but it wasn’t doing the thinking. You were.

Generation Three: Ditching the IDE (And the Old Mindset)

Then Claude Code showed up, and something more fundamental shifted.

The change wasn’t just that you moved from the IDE to the command line. It was that the entire way you thought about the work changed.

In Generations One and Two, the question was always some version of “how do I build this?” You knew what you wanted. You were using AI to help you write it.

Claude Code made that question irrelevant. You stopped asking how. You started focusing on the goals.

Describe the feature. Describe the problem. Tell the agent what you’re trying to accomplish and let it figure out the implementation. That sounds like a small shift. It isn’t. It removes the engineer from the implementation loop and puts them into a direction and review role instead.

You’re not writing code anymore. You’re describing problems clearly enough that AI can solve them, then reviewing what comes back with enough judgment to catch when something is technically correct but completely wrong for the actual use case.

That’s a different job. It requires a different kind of thinking. And the engineers who made this transition well weren’t necessarily the fastest coders. They were the ones who understood the problem deeply before they touched anything.

Generation Four: Managing the Agents

This is where we are right now, and it’s moved faster than most people expected.

We’ve gone from IDE to CLI to something that looks more like product management than software development. You’re not in the code at all. You’re managing a team of agents working in parallel.

The latest version of Cursor rebuilt its entire interface from scratch around agent orchestration. It still lets you edit code directly when you need to, but the primary model is now dispatching and managing agents, not writing line by line. Claude Code sits at the other end of the spectrum: no IDE at all, just you and the agent at the command line. Tools like Vibe Kanban wrap Claude Code in a visual interface that lets you juggle multiple agent tasks the way a project manager runs a sprint board. You write the requirements. You review the plan. You assign the work. The agents build it.

Think about what that actually means on a real sprint. You have five tasks in flight at once. One agent is building a new API endpoint. Another is refactoring a module you flagged last week. A third is writing the tests for a feature that shipped yesterday. You’re not blocked waiting for one thing to finish before the next one starts. You’re reviewing, redirecting, and feeding the next requirement into the queue. The throughput doesn’t look like one developer anymore. It looks like a small team.

The Next Layer: Agents That Talk to Each Other

What’s coming next, and what some teams are already doing, is chaining agents together into automated workflows that run without a human in the loop at all.

The idea is straightforward. Instead of a person reviewing every output before the next step starts, you wire agents together so the output of one becomes the input of the next. A feature agent builds the code. A testing agent automatically runs against it and flags failures. A security agent scans for vulnerabilities. If everything passes, a deployment agent ships it to staging.

You review the results at the end, not at every step.

This is already happening. Teams using Claude Code with custom tooling are building pipelines where a single requirement kicks off a sequence of agents that build, test, scan, and document the feature before a human ever looks at it. The engineer’s job becomes setting up the workflow, validating the output at the end, and handling the exceptions that fall out of the automated process.

It’s the difference between managing a team and managing a factory. The bottleneck shifts entirely to the front of the process: the clarity of the requirements going in and the judgment of the person reviewing what comes out.

What Software Engineering Looks Like from Here

The role didn’t disappear. It transformed.

The engineers who are doing well right now are spending roughly 80% of their time on three things:

1. Writing requirements. Clear enough that an agent can execute them without guessing. This is harder than it sounds. Vague requirements produce confident, plausible, completely wrong output.

2. Architecture and judgment calls. Build vs. buy, when to slow down vs. ship, how components connect, what the security surface looks like. These decisions still require a human who understands the system.

3. Validating output. AI is confident whether it understood the problem or not. Someone has to know enough about the big picture to catch it when the code is clean but the logic is wrong.

The 20% that’s left is still technical. You still need to recognize bad patterns. You still need to understand what’s happening under the hood. But the bottleneck isn’t implementation speed anymore. It’s clarity of thinking going in.

If you can’t describe what you’re building, why it matters, and what success looks like, it doesn’t matter how many agents you’re running. You’ll produce faster garbage. If you can describe the problem with precision, AI makes you an order of magnitude more productive.

And that’s always been true. AI just made it a lot more obvious.

This Is a Product Driven World

Everything that makes an engineer effective in this generation comes back to product thinking.

Understanding the user. Understanding the outcome. Being able to articulate what needs to happen before a single line of code gets written. Asking why before asking how. Owning the result, not just the ticket.

The engineers who asked those questions before AI were already better than average. Now they’re the ones who can direct agents effectively, catch the mistakes, and build things that actually solve the problem instead of just satisfying the prompt.

This is what the Product Driven model was built for. Not just a philosophy, but a practical framework for how engineering teams think and work when they’re at their best.

If you want to get your team thinking this way, and ready for what’s coming next, the full playbook is in my book. Product Driven is available now as a free digital copy or audiobook at fullscale.io/product-driven.

The engineers who thrive in this generation won’t be the ones who learned to code the fastest.

They’ll be the ones who learned to think like owners.

Do we still test for coding skills? Do we need different technical screens? Is the traditional interview dead?

Here’s the uncomfortable answer: if your hiring process is in trouble right now, AI didn’t break it. It was already broken.

The Engineer’s Job Is Shifting

Let me tell you what I’m actually watching happen on engineering teams.

The daily work is changing fast. Engineers are spending less time writing code from scratch and more time doing something harder: writing clear requirements, describing intent, reviewing what AI produces, and figuring out when the output is wrong.

That last part matters more than people realize. AI is confident. It will produce something plausible-looking whether it understood the problem or not. The engineer sitting in the loop has to know enough about the big picture to catch it when the output is technically correct but completely wrong for the use case.

The engineers thriving in this environment aren’t the ones who can recall the right algorithm under pressure. They’re the ones who can look at a problem from the user’s perspective, articulate what needs to happen, and hand that off in a way that produces something useful. They understand what they’re building and why before they start.

That’s product thinking. It’s always been the highest-leverage skill in software engineering. AI just made it impossible to fake.

Product Thinking Is the Skill That’s Rising to the Top

To use AI well, an engineer has to understand the big picture.

If you don’t know what problem you’re solving or why it matters, you can’t write a good prompt, you can’t review the output critically, and you can’t catch it when something’s gone sideways. You also can’t push back when the requirements are unclear or the scope is wrong. You’re just a relay for bad instructions.

This is what separates engineers who make AI a force multiplier from engineers who use it to produce faster garbage.

The engineers who asked “why are we building this?” before writing a single line of code are the ones who are dangerous in the best way right now. They always were. They’re the engineers who feel ownership over the product, not just the ticket. AI just made that quality more visible, and more valuable, than it’s ever been before.

If your team is full of people who wait to be told what to build, AI is going to accelerate your problems, not solve them. If your team is full of people who understand the users and the outcomes, AI is going to make them three times as productive.

So how has this changed how we hire engineers?

We Stopped Coding Challenges Years Ago

At Full Scale, we receive hundreds of job applications a month for software engineers. That makes it nearly impossible to give each person multiple rounds of interviews.

So like many companies, we used to rely on multiple choice and online coding tests to help weed out applicants so we could focus on the best ones.

Then we realized we were making a few major mistakes.

1. The best software engineers aren’t going to do your stupid test.

2. Those tests are super easy to cheat on with AI.

3. They don’t even test what really matters.

They tell you almost nothing about how someone actually thinks. How they handle ambiguity. Whether they ask good questions before diving in. Whether they understand what they’re building and why it matters.

The companies that designed their entire hiring process around coding challenges were never finding the best engineers. They were finding the engineers who were best at coding challenges. Those are not the same people.

Interview for How People Think

Instead, we interview for judgment and curiosity.

We give candidates a real problem with context and constraints and some missing pieces. Not a whiteboard algorithm. Not a timed code screen. A genuine, open-ended problem that requires them to think.

Then we watch what they do with it.

Do they ask clarifying questions before they start, or do they just charge in? Can they explain their reasoning to someone non-technical? When they hit an edge case, do they flag it or paper over it? Do they have opinions about what matters most, or are they waiting to be told?

Those conversations tell you everything. You can see in one honest discussion whether someone thinks like an owner or like a ticket-taker. And it’s fast. You don’t need four rounds of technical screens to find out if someone has good judgment. You need one real conversation.

This approach also scales. Junior engineers can show you how they approach a new problem even before they have years of experience. Senior engineers can show you how they think about tradeoffs, not just solutions. The format works at every level in a way that algorithm screens simply don’t.

You can ask the same question to a junior engineer, senior engineer, or CTO and their clarifying questions and concerns show you the level they are at!

The Best Skills Were Never on the Coding Test Anyway

Here’s the thing nobody talks about in the “AI is forcing us to rethink hiring” conversation.

The skills that make a great senior engineer, a great tech lead, a great architect, were never tested by coding challenges in the first place.

And now? When AI is writing 90% of the code, testing someone’s ability to recall a sorting algorithm under a time limit isn’t just unhelpful. It’s almost completely irrelevant.

Engineers still need to recognize good and bad patterns in the code that comes out. That matters. But the real bottleneck isn’t coding speed anymore. It’s the quality of the requirements going in. If you can’t describe what you need with precision and context, it doesn’t matter how fast you can write code. You’re going to build the wrong thing quickly.

That takes product thinking. And you can’t test for it with a LeetCode problem.

The skills that actually separate good engineers from great ones at scale: software architecture, security, managing a team under pressure, build-vs-buy calls with incomplete information, knowing when to slow down and when to ship, communicating risk to a non-technical executive, knowing what good looks like and having the courage to say when it isn’t.

When people say AI is forcing them to rethink their interview process, what I actually hear is: they were hiring for engineers who could turn requirements into code.

That was always a low bar. Now you need engineers who can turn business problems into requirements and then into code. That’s a different job. And you can’t screen for it with an algorithm test.

You have to interview for product thinking.

If you want to build a team that actually thinks this way, I wrote the playbook for it. Product Driven is about exactly this problem: how to close the gap between engineers who execute tickets and engineers who understand the product well enough to own outcomes. That’s what makes a team AI-ready. Not the tools they use. The way they think.

Even more exciting, my book is now available for free. Head to fullscale.io/product-driven
to get your digital copy or audiobook

Good hiring was never about finding someone who could write the code. It was always about finding someone who understood the problem well enough to know what code to write.

AI just made that distinction impossible to ignore.

You scale meetings.
You scale process.
You scale compliance.

Most big companies do this and call it “maturity.” But let’s be honest—what they’re really doing is building a machine that turns creative engineers into ticket takers.

I sat down with David Mitchell, CTO of the Americas at VML (yes, the 30,000-person global creative agency), to talk about how they’ve scaled creative engineering—not just engineering—across thousands of developers working on massive projects for brands like Wendy’s and United Airlines.

And yeah, they’re doing a few things most big orgs just flat out get wrong.

What Big Companies Get Wrong

❌ They confuse structure with progress.

You add product managers, project managers, scrum masters, release managers, QA managers…
And now your best engineers can’t even ship a button without six approvals and a Jira ticket that’s older than your intern.

The more layers you add, the more disconnected teams become from the actual product. What started as “alignment” becomes red tape.

❌ They remove all creative responsibility from engineers.

Engineers become implementers.
Not builders. Not thinkers. Just order takers with a keyboard.

They’re handed specs and told to execute. No room for opinions. No room for ideas. No context on why they’re doing it. That’s not engineering. It’s typing.

❌ They focus on outputs instead of outcomes.

Your dashboards are full of velocity, story points, sprint burndown charts... but no one knows if what got shipped even mattered.

Activity ≠ Impact.
If you don’t tie engineering work back to real results, you’re just keeping people busy. Not productive.

What Great Companies Get Right

✅ They build small teams with ownership.

VML doesn’t throw headcount at problems—they build 5–7 person teams with full ownership.
That team ships the code.
Owns the quality.
Talks to stakeholders.
Knows the business problem they’re solving.

Ownership isn’t a slogan. It’s built into the structure.

✅ They teach engineers to speak in product language.

Every couple months, team leads write short updates—not to check a box, but to sharpen their voice.

Can you explain the why behind the code?
Can you describe real progress in plain English?

If not, you’re not just failing at communication—you’re failing at leadership.

✅ They use Journey-Driven Development—not process worship.

VML doesn’t obsess over funnel metrics or force “API-first” down your throat.
They start with actual human behavior—the journey your user is on—and work backward from there.

Design. Sketch. Ship. Get feedback. Repeat.
Process supports product—not the other way around.

🚩 How to Know You’re Getting It Wrong

• Your best engineers don’t talk in meetings anymore

• You’re spending more time estimating tickets than building

• Teams don’t know if what they shipped is actually being used

• People are busy, but no one knows what actually got better last sprint

If any of that feels familiar, it’s not just “growing pains.”
It’s a signal that creativity is dying inside your engineering org.

What to Do About It

Don’t blow everything up.

Start small:

• Build smaller, autonomous pods with cross-functional ownership

• Let engineers talk directly to stakeholders—skip the game of telephone

• Prioritize value shipped over stories completed

• Make space for experimentation (VML even funds sci-fi-style prototypes just to stretch the team’s imagination)

And above all—stop optimizing for velocity.
Start optimizing for insight.

Creative engineering doesn’t die because people stop caring.
It dies because the system stops rewarding them for thinking.

Let your teams think again.

It’s the moment someone says:
“It’s done.”

But it’s not in production.
There’s no test coverage.
The edge cases aren’t handled.
And the PM doesn’t agree on what “done” even means.

So… what’s really “done” here?

This is one of the biggest killers of engineering velocity—and most teams don’t even see it happening.

Shipping ≠ Finishing

Most teams confuse output with outcomes.

They ship the ticket.
Close the Jira.
Merge the PR.

And think the job is done.

But if the customer doesn’t get value—if the team doesn’t share a definition of success—you’re not done. You’re just in limbo.

We see it all the time:

• Features that technically work but don’t solve the user’s problem

• Tickets closed while bugs pile up in QA

• Endless handoffs between engineers, PMs, and designers who were never on the same page

That’s not progress. That’s churn.

Why Teams Get Stuck at 90%

Here’s the painful truth:
The last 10% of the work feels like 90% of the effort.

You’re debugging edge cases.
Chasing down feedback.
Fixing what was “done” last sprint.

And it all stems from one root issue:
Lack of shared understanding.

In the early days, I used to think docs were just nice-to-haves. Something you did after the code was written.

But I’ve learned the opposite is true:

Documentation isn’t a record of what was built.
It’s a tool for aligning everyone before you start.

Context Is the New Developer Multiplier

In this week’s podcast, Seth Rosenbauer nailed it:

“AI can write the code. But it can’t explain what problem the code is supposed to solve.”

Tools are getting better.
But alignment is getting harder.

Distributed teams.
Compressed timelines.
Fewer PMs. More AI-generated output.

The only thing that scales with this complexity?
Clear, contextual documentation.

Not a Notion doc that no one reads.
Not a requirements dump.

We’re talking about living docs:

• Framed around the why behind each feature

• Owned by the team

• Evolving as things change

Because when everyone shares the same map, finishing the work gets a whole lot easier.

How to Build Shared Understanding Before You Build Software

Here’s what works:

✅ Start with problems, not tickets.
Before you open Jira, write down what problem this is solving. What’s the user trying to do? Why now?

✅ Get buy-in on definitions.
What does “done” actually mean for this feature? What’s the success criteria? Agree before the build.

✅ Write for your future self.
If you come back in 6 months, will you know what this code was for? Your docs should make that obvious.

✅ Make docs part of the process, not a task.
The best teams I’ve worked with don’t “do docs”—they build shared context as they go. It’s embedded, not extra.

Don’t Let the Last 10% Derail the Sprint

If your team’s velocity drops after “delivery,” that’s a sign.

You don’t have a code problem.
You don’t have a QA problem.
You have a clarity problem.

Fix that, and the work doesn’t just ship—it sticks.

If your team’s “done” keeps turning into rework, then you’ll want to hear the full conversation I had with Seth Rosenbauer.

We got into how AI is exposing the cracks in product communication, why most docs fail, and what it really takes to build software that ships and succeeds.

🎧 Listen to the full episode on Product Driven—wherever you get your podcasts.

Write the best code. Architect the system. Solve the hardest problems.

But it didn’t take long to realize that none of that was enough.

The reality?

The job of a great engineering leader comes down to one skill that almost no one talks about. And certainly no one teaches.

Translation.

The Real Language Barrier in Software Companies

If you’ve worked in or around software engineering, you’ve seen this play out.

Engineers speak in technical detail—frameworks, architecture, systems.

Executives speak in outcomes—revenue, timelines, growth.

Both sides are intelligent. Both are essential. But most of the time, they’re not speaking the same language.

I’ve seen engineers who can explain why a system needs to be re-architected—but the business only hears “delays and cost.”

I’ve seen executives lay out ambitious market goals—but the engineering team only hears “impossible expectations.”

And so the two groups orbit each other, frustrated.

Executives think engineers don’t “get the business.”

Engineers think executives don’t “get the technology.”

The result? Misalignment. Slow innovation. And teams that feel stuck.

Why Engineers Struggle to Say “No”

In the latest episode of Product Driven, Karell Ste-Marie of The Serious CTO and I dug into something most people won’t admit: a lot of software engineers struggle to say no.

The profession tends to attract introverts. They don’t want to rock the boat, push back, or look incompetent. So they say yes—sometimes even when they know the ask is unrealistic.

That creates a dangerous cycle:

• Engineers say yes to everything.

• Executives assume everything can be done.

• Deadlines get set that can’t be hit.

• Trust breaks down when the delivery doesn’t match the promise.

And it all stems from the same problem: the languages aren’t translating.

Why This Matters More Than Technical Skill

Most engineers spend the first decade of their career heads-down in code. They live in the world of technical problems.

But here’s the uncomfortable truth:
You can be the most brilliant coder on the planet and still fail as a leader.

Because at some point, the job stops being about code. It becomes about outcomes. About money. About making sure the business actually survives.

As Karell put it—if the company doesn’t make money, you don’t get a salary. It’s that simple.

That’s a language many engineers aren’t taught to speak.

The CTO as Translator

The best CTOs I know are the ones who can sit in a boardroom with executives and make the business case clear…
…and then walk into the engineering room and translate that vision into technical priorities the team can actually execute.

It’s a dual fluency:

Understanding the business well enough to make trade-offs.

Understanding the technology well enough to know what’s realistic.

Most importantly, it’s being able to speak both languages in a way each side understands.

That’s what makes the role so difficult.

And that’s what defines the leaders who actually move companies forward.

Why This Skill Rarely Gets Taught

You don’t learn this skill in computer science class.

You don’t pick it up from Agile training.

And you won’t find it in most management books.

You learn it the hard way—by being thrown into the fire.

That’s why so many CTOs become CTOs the same way Karell and I did: by starting their own companies. Overnight, you’re forced to become fluent in both worlds. You can’t hide in the code anymore.

You’re selling, pitching, raising money, talking to customers—and still leading the engineering team.

It’s trial by fire. And it teaches you fast.

Why Companies Fail Without Translators

Think about it: a company can’t exist without a product. And that product can’t exist without engineers.

But if the engineers don’t understand the business, they’ll keep building things that don’t move the needle.

And if the business doesn’t understand the engineers, they’ll keep setting goals that can’t be achieved.

Without translation, both sides lose.

Engineers feel invisible, like mushrooms in the basement.

Executives feel frustrated, like nothing gets done.

And customers feel neglected, because the company isn’t innovating.

Translation isn’t just a soft skill. It’s survival.

What This Means for You

If you’re a technical leader, here’s the uncomfortable but empowering truth:

Your job is to be the bridge.

You may be the only one in your company who can do it. You might be the only one who can sit down with engineers and executives and actually make both sides feel heard.

That’s not a burden. That’s the definition of your value.

It’s the skill that makes or breaks great engineering leaders.

And even if no one taught it to you, you can start practicing it every day:

• Ask engineers to explain their work in business terms.

• Push executives to ground their goals in reality.

• Translate. Over and over again. Until both sides understand.

Because when that happens? That’s when companies innovate.

Want to hear the full conversation I had with Karell Ste-Marie of The Serious CTO—including our own mistakes and lessons from becoming CTOs—check out the latest episode of the Product Driven Podcast.

That should feel like a gift for product teams.

But often, it turns into a trap.

Because speed without judgment doesn’t get you to value faster.
It just helps you ship the wrong thing sooner.

For years, we told founders and product teams to focus on the MVP.
Build version one. Get something out there. Learn.

But that mindset doesn’t hold up anymore—at least not the way most people practice it.

Here’s what I mean…

The old MVP game was about building fast. Now it’s about validating faster.

When Jerel Velarde, one of our PMs at Full Scale, started building one of our internal tools, he wasn’t focused on shipping a “working” product. He wasn’t obsessing over what v1 would look like. He wasn’t even asking engineers to start coding.

He was trying to validate—in a single day—whether the idea was worth building at all.

He called the approach prompt prototyping.
No sprints. No engineering backlog. No long planning meetings.

Just fast UX flows, real interface mockups, AI-generated scaffolding, and enough interaction to see how users respond.

Not to impress anyone.
To kill the bad ideas before they made it into the roadmap.

Because let’s be honest...

Most MVPs don’t get validated.
They get released.
And then ignored.
And then buried in backlogs while your team wonders what to build next.

If AI can build anything, your job is knowing what not to build.

This is the real shift.

AI raised the floor for building, but it also raised the ceiling for what teams are expected to deliver.

The teams who win won’t be the ones who can ship code faster.
It’ll be the ones who validate faster and have the conviction to say:
"This is the right bet. Let’s go."

And the courage to say:
"We thought this mattered. It doesn’t. Kill it."

The MVP mindset we inherited was often about launching something minimal.
But we didn’t always ask if that minimal thing would prove anything useful.

Prompt prototyping flips that.

You build just enough to answer the next most important question:
Does this idea matter?

The job of a product team isn’t to build a product. It’s to reduce risk.

In early-stage companies, your biggest risk isn’t how long it takes to build.

It’s building the wrong thing.

It’s wasting 3 sprints chasing a feature no one wants.
It’s launching a tool that looks good but doesn’t solve the core pain.
It’s investing engineering time on the wrong bet—because nobody tested it first.

In that world, every unnecessary commit is a cost.
Every unvalidated idea that makes it past planning is a liability.

Jerel told a story about a hackathon project where, instead of handing a Figma link to engineering, he handed over an actual code repo. He had already validated the UX, the need, and the flow—before the engineering team wrote a line of backend code.

That’s where product leadership lives now.

In the bets you kill.
Not just the ones you launch.

If you’re still shipping “just to see what happens,” you’re playing the wrong game.

I’ve been in that position.

Thinking we were validating when we were just deploying.
Believing shipping meant learning.
Believing progress meant movement.

But when you ship a product no one uses, it’s not feedback.
It’s silence.

And silence is expensive.

The better strategy now?

Use AI, use your own hands, use whatever it takes—to build something testable fast enough that you don’t waste another week guessing.

You don’t need a dev team to validate every idea.
You need better product judgment and faster loops to confirm you’re building the right thing.

Build to validate. Not to launch.

You don’t need a working MVP to test the idea.
You need a way to learn quickly enough to stop wasting time on things that don’t matter.

AI changed the game.
It didn’t remove product risk.
It amplified it.

So stop focusing on the “minimum viable product.”
Start asking:
What’s the minimum test that proves this idea deserves to live?

That’s how product teams earn their next sprint.

And that’s how engineering stops being the bottleneck—because you're only building what matters.

Want to hear how we’re doing this in real time at Full Scale?

Check out my full conversation with Jerel on the latest episode of the Product Driven Podcast. We go deep into prompt prototyping, PM-engineer workflows, and why the new rules of product management demand a very different kind of leadership.

👉 Listen to the episode now on YouTube or on your podcast player.

So why does everything still feel... off?

One team’s building the future.

Another’s fixing the past.

A third is off-road entirely, convinced their thing is the most important.

You get on a call and realize:
Everyone heard the same plan—
But no one walked away with the same understanding.

Welcome to the post-strategy chaos stage.

The Myth of the “Clear Plan”

Most companies think their problem is strategy.
It’s not.

Everyone has some strategy.
The problem is no one knows how to execute it together once things start moving.

At zero to one, this isn’t a problem. You’re in the room. You feel the signals.
But once you’ve got more than a few teams, those instincts break.

You assume your message made it downstream.
It didn’t.

You assume your teams are aligned.
They’re not.

What you’ve got instead is something Randy Silver described perfectly in our conversation:

“Autonomous teams doing whatever they want—without guardrails, communication, or shared goals.”

That’s not autonomy.
That’s anarchy.
And it happens all the time.

Where It All Starts to Break

You can usually trace the breakdown to one of three dysfunctions:

1. The Bottleneck Org
The founder or exec team is still making every decision.
No one else can move without permission. Execution slows. Teams disengage. And any innovation has to fight its way up the food chain before it ever gets built.

2. The Lord of the Flies Org
You gave teams autonomy—but forgot to give them alignment.
Now every team is optimizing for what’s best for them, not for the product. Priorities compete. Strategies fragment. And no one sees the whole picture.

3. The Vacuum Org
No top-down clarity. No bottom-up ownership.
Just aimless execution. Work gets done, but no one’s sure why—or if it matters.

If you’re nodding your head, you’re not alone.
You’re not broken.
You’re scaling.

But unless you fix it, your best people will burn out building the wrong thing faster.

What Strategy Actually Needs to Work

Here’s the shift that hit me in this conversation with Randy:
Vision is not enough.
You also need:

• A clear diagnosis (Where are we, really?)

• A guiding policy (Where are we trying to go?)

• Coherent action (How will we get there, together?)

Most teams get maybe one of those. Two, if they’re lucky.

But without all three? You can’t prioritize. You can’t scale decision-making.
And you definitely can’t trust your teams to think like owners.

Autonomy Requires Structure

If you're aiming for true team autonomy, here's what it actually requires:

• Clarity of purpose

• Transparent communication

• Mutual accountability

• Aligned incentives

Autonomy isn't freedom to go rogue.
It's freedom within a shared strategy.

You want your teams to build like entrepreneurs?
Give them the constraints a real entrepreneur has:
A mission. A customer. A clear goal. And responsibility for the outcome.

That’s how you scale ownership without losing your grip on direction.

How to Know If You’re Already There

Ask yourself:

• Are teams working toward the same definition of success, or just closing tickets?

• Do roadmaps overlap and contradict across teams?

• Is anyone responsible for integrating the bigger picture?

• When you say the strategy out loud, do you actually believe your teams could explain it the same way?

If not, you’re probably already living in the jungle.
Everyone’s got a spear. No one’s got a map.

In this week’s episode of Product Driven, I sat down with product and leadership consultant Randy Silver to talk about exactly this problem.
How companies lose their way at scale—and what it really takes to lead them back.

🎧 Get the full episode on the Product Driven podcast.

On average, developers waste 20% of their time every single week.

That’s a full day lost. Every. Week.
Not because the team isn’t talented. Not because they aren’t working hard.

They’re losing it to friction.

Unclear requirements.
Slow build pipelines.
Broken tests.
Poor documentation.
Meetings that slice up the day until there’s no focus time left.

I hate to break it to you, but leaders who think AI is going to magically fix this are fooling themselves.

If your team is already drowning in wasted time, AI doesn’t save you.
It just helps you paddle faster in the wrong direction.

The 20% Tax You Don’t See

Laura Tacho, CTO at DX, shared research that developers waste 20% of their time on inefficiencies and poor processes. That’s the average. Some teams are worse.

It’s not “beer fridges and ping pong tables” bad.
It’s organizational bad.

• Waiting for clarity because requirements are half-baked or keep shifting.

• Waiting for feedback because tests take forever or PRs sit in review limbo.

• Waiting for decisions because the business context is missing and everything stalls until the next meeting.

Every wait creates drift. Every drift costs time. Multiply that across a team of 20 engineers and you’re losing a month of productivity every sprint.

And the more layers you add — more handoffs, more shit shielding, more meetings — the harder it becomes for developers to actually get momentum.

Focus Time Is the Scarce Resource

Most leaders talk about velocity. Few talk about focus.

But developer productivity is deeply tied to whether an engineer gets long, uninterrupted stretches of focus time.

When every day is chopped up with status calls, Slack pings, and shifting priorities, developers aren’t coding. They’re context switching.

The cost isn’t just hours lost. It’s energy. Cognitive load. Momentum.

Think about the last time you were in flow and someone tapped you on the shoulder. (Or the Slack ding went off). It takes 15–30 minutes to get back. Now imagine that happening five times a day. That’s the reality of most engineering teams.

And when developers can’t find time to think deeply, they can’t solve problems creatively. They end up stuck in reactive mode. Shipping tasks, not outcomes.

AI Won’t Save You

Here’s the belief I hear a lot right now:
“AI is going to fix developer productivity.”

It won’t. Not if you’re already losing that 20%.

AI can autocomplete code.
It can generate tests.
It can even draft documentation.

But if your developers don’t know what problem they’re solving, or they can’t get through a single hour without interruption, AI just adds more noise.

AI multiplies speed, not clarity.

That’s why the companies seeing the biggest gains from AI are the ones that already solved the fundamentals of developer experience:

• Fast pipelines.

• Clear requirements.

• Lightweight processes.

• Documentation people can actually find.

• Leadership that protects focus time.

They don’t waste 20% of their week.
So when they layer in AI, the benefits compound.

But if you’re still struggling with friction, AI just accelerates the waste.

The Leadership Lesson

I used to think my job as a CTO was protecting my team from business chaos.
Keep them in the code. Keep them focused.

But shielding developers from context is the opposite of leadership.

When engineers don’t know the why behind the work, every decision gets delayed. They can’t move without a meeting, a ticket, or a manager’s approval.

That’s where the 20% loss comes from.
That’s why focus evaporates.

Leadership isn’t about shielding.
It’s about clarity.

Clarity fuels progress.
Clarity turns wasted time into forward motion.
Clarity is what keeps your team moving even when you’re not in the room.

Questions for Leaders

If you’re serious about developer productivity, forget the hype cycle for a moment.
Don’t ask, “How will AI transform my engineering team?”

Ask this instead:

• Where is my team losing that 20% every week?

• Am I creating focus time or crushing it?

• Do my engineers know the why, or are they just waiting for the next ticket?

Fix that first.
Because the real productivity problem isn’t solved by AI.

It’s solved by leaders who remove friction, protect focus, and give their teams the clarity to keep going without getting stuck at every turn.

This article scratches the surface of a much deeper discussion I had with Laura Tacho, CTO of DX. We broke down what developer experience really means, why AI helps some teams and hurts others, and how leaders can stop wasting 20% of their team’s time.

Catch the full episode of Product Driven to hear it all.

I learned this the hard way.

I’ve run teams where execution interviews produced fast coders who stalled the moment the spec was fuzzy.

Momentum looked high. Progress wasn’t.

The problem wasn’t talent. It was how we filtered for it. We were testing fluency, not judgment. And judgment is the differentiator in the AI era.

Interviewing devs has to shift

Execution interviews are designed for stable problems. But, product work is not stable.

The dev’s real job is navigating ambiguity, balancing trade-offs, collaborating across disciplines, and staying anchored to user outcomes. You won’t see that in a timed coding puzzle. You will see it in how someone frames a messy problem and asks better questions.

As building gets cheaper and faster, the bottleneck shifts from “Can we code it?” to “What should we build and why?” Interviewing has to shift with that.

What to test instead

Knowing is cheap. Choosing is expensive.

It’s silly to quiz candidates on trivia they’d Google—or ask AI—to answer. What matters now is whether they can architect a path through uncertainty, identify risks, and define what success looks like for the user.

If you want product thinkers, stop testing for memorized solutions and start testing for how someone reasons when the answer isn’t obvious.

The Product-Thinking Interview Approach

At Full Scale, we use this step-by-step pattern in one 60–75 minute session.

You can do it without slides or a whiteboard trick. You just need a realistic, fuzzy scenario and a rubric that rewards signal over slickness (and you can steal ours).

0) Set the scene (2 min)

Give a short, imperfect brief:

A lot of first-time users bounce on step 2 of signup. We don’t know why. You’ve got one sprint to improve activation.

This mirrors reality: partial data, competing priorities, unclear constraints.

The point is to watch how they create clarity. Ambiguity compounds and kills momentum. Great candidates reduce it fast.

1) Questions before answers (8–10 min)

Invite the candidate to ask anything.

They get points for: user empathy, metrics curiosity, success definition, edge cases that matter.

They get dinged for: jumping to architecture, optimizing before understanding, asking for perfect specs.

2) Define success & constraints (5 min)

Ask:

What outcome would prove we made the right trade-offs?

Look for crisp, outcome-first language, not feature lists. Great candidates propose a measurable bet and call out what they’ll not do to protect it.

3) Make it messier (10 min)

Introduce a constraint:

Design has limited capacity.

Or

Legal requires email verification.

See how they rebalance scope, sequence, and risk. Product thinkers narrate the trade-off and its user impact.

4) Propose a first slice (10 min)

Ask for a scrappy, testable plan:

What’s your smallest shippable to learn fast?

Look for simplification, not heroics. Bonus if they design an instrumentation plan to validate the bet.

5) Collaborators & communication (5 min)

Ask:

Who do you pull in and when?

You want cross-functional awareness and the ability to narrate intent so decisions propagate. Speed of vision beats speed of code.

6) Risks & safeguards (5 min)

Ask:

What could backfire for the user?

Strong answers surface user harm, adoption friction, and platform risks, and propose mitigations. Leaders make the caution explicit.

7) Reflection (3 min)

Ask:

What did you learn as we talked?

You’re testing coachability and metacognition. Can they adjust their plan as reality shifts?

The scorecard

Rate 1–5 on each axis:

• Curiosity & Questions: depth, sequencing, signal-seeking

• User Orientation: talks about impact, not only implementation

• Trade-off Clarity: names what’s in, what’s out, and why

• Outcome Definition: proposes a measurable bet, not outputs

• Systems Thinking: navigates constraints without thrash

• Collaboration: knows who to involve and how decisions spread

• Judgment Under Ambiguity: simplifies the path forward

• Ownership Signals: says “I’d own X,” not “I’d wait for a ticket”

Anti-signals: speed-running a solution, arguing frameworks instead of outcomes, fear of saying “it depends,” or asking zero questions before proposing work.

Questions worth stealing

Use a few of these, then be quiet and listen.

• “What would you change about a product you use every day—and why?” You’ll hear how they notice friction, frame the user, and reason about impact.

• “What won’t you do in the first sprint, and why?” Forces visible trade-offs.

• “If you were the PM, would we even build this?” Permission to think upstream.

• “Where could this backfire for the user?” Makes caution explicit and builds judgment.

• “How will you know you’re wrong quickly?” Tests learning speed over certainty.

How to adapt your loop for AI

Your goal isn’t to “catch” tool use. It’s to reveal thinking.

• Don’t penalize Google/AI for facts. Penalize shallow reasoning. It’s silly to quiz someone on what they’d look up on the job anyway.

• Reward transparency. If they use a tool, ask what prompts they’d try and how they’d validate the output. You’re testing what questions they ask, not rote recall.

• Keep the scenario anchored to users and trade-offs. That’s where product thinking shows up.

Calibrate the bar with culture

Hiring for product thinking without building for it is a fast path to churn. If you only reward speed, you’ll interview for judgment and then smother it. Create an environment that teaches, supports, and requires thinking: narrate trade-offs, assign real ownership, and celebrate people who protect outcomes—not just output.

Start small:

• Change one interview question this week. Swap trivia for judgment.

• Give a stretch problem to an engineer and back them while they learn.

• Say out loud what you’re not doing—and why. Make boundaries visible.

These tiny moves send a loud signal about what matters on your team. And people copy what gets rewarded.

The bottom line

The job has changed. Your interviews should, too.

Hire for how they think—especially when the answer isn’t obvious.

Then build an environment where that thinking survives.

If you want to go deeper on what this looks like in the age of AI, I unpack more in this week’s conversation on Product Driven: Why We Still Need Software Engineers in the Age of AI with Brian Jenney. Tune in for the full discussion on how to hire for judgment—and grow it once they’re on your team.

I learned this the hard way: 2 a.m., phone buzzing, production fire.

“I thought Bryan owned that…”

I’d delegated, but the work still boomeranged back to me.

That’s the Invisible Ownership Trap—when responsibility changes hands on paper, but the real weight never leaves your shoulders. If ownership isn’t visible, it isn’t real – and your team feels the pressure without the power.

Real delegation isn’t a checklist item.

It’s a system you design on purpose.

After working with dozens of CTOs at Full Scale, (and cleaning up my own late-night messes), I’ve boiled that system down to five non-negotiable hurdles. Clear them, and you can finally log off without checking Slack “just in case.”

1. Define the Edges

“What am I actually allowed to decide?” is the first question every engineer asks—usually silently.

Spell out what’s locked, what’s flexible, and when they should pull you back in. Clear edges don’t restrict ownership; they enable it.

2. Provide Context, Not Control

Dumping tasks is offloading. Real delegation shares the why.

Describe the problem, the stakes, success metrics, and lurking risks. When people understand purpose, they won’t get stuck on process .

3. Make Ownership Visible

If the org can’t point to a name, no one truly owns it.

Announce the owner aloud, put it in the plan, and make it obvious across teams. Visibility builds confidence and signals belief.

4. Support Without Hovering

Delegation isn’t disappearing. It’s staying just close enough to coach.

Swap answers for questions: What are you optimizing for? What feels stuck? Trust—but verify—without micromanaging.

5. Follow Through, Not Just Follow Up

Ownership doesn’t end when the code ships. It ends when the problem is solved and the learning is shared.

Debrief every launch. What surprised us? What worked? What will we carry forward? That’s “trust but verify” in practice.

Why These Hurdles Matter

When you clear all five, you unlock the ownership flywheel:

Trust → Ownership → Impact → More Trust

Your team stops waiting for permission. They start making better decisions. And you—finally—stop being the bottleneck.

Try This Tomorrow

1. Pick one project and write down its edges and success measures in a single paragraph.

2. Name the owner in public—stand-up, Slack, roadmap doc.

3. Schedule a 15-minute post-launch retro before work even starts.

Do that, and you’re already halfway over the first hurdle.

In this week’s podcast episode, I sat down with engineering leader Brittany Rastsmith to dissect real-world examples of each hurdle in action—plus the subtle signals that tell you delegation is slipping back onto your plate. If you’ve ever woken up to those 2 a.m. alerts, this conversation is your blueprint for sleeping through the night.

Listen here → “Systems that Let CTOs Delegate Ownership—and Still Sleep at Night”

The job title covers everything from enterprise deal-maker to scrappy full-stack hacker, yet an early-stage startup can only afford one hire who also feels the pain of the customer, sees the product end-to-end, and can ship without a backlog full of marching orders .

After two decades building, scaling, and investing in software companies, I’ve learned to look past résumés and whiteboard riddles. Three signals tell me I’ve met a true technical co-founder—not just a coder looking for equity.

1. Owns the Product Vision, Not Just the Architecture

A co-founder has an opinion about what we’re building before we debate how. They can describe the user, the outcome, and where Version 1.0 ends—even if the spec is a napkin. If they can’t, they’re a senior engineer, not my partner.

I dig for product instinct in the conversation:

• Tell me about a feature you killed after talking to customers.

• What metric changed when it shipped?

• Where did the idea come from—sales call, support ticket, or you?

Great engineers light up when they can explain why before they code .

2. Absorbs the Domain at Warp Speed

Startups rarely attack broad consumer markets. More often it’s “lead-gen for florists” or some niche no outsider has mapped. I need a co-founder who can parachute into that vertical, see the workflow friction, and start sketching a solution within weeks.

In vertical SaaS, the business founder supplies the relationships, but the technical partner must “slot in and quickly co-create the product.

I ask them to walk me through another industry they picked up fast. If they can outline the jargon, the incumbent tools, and three obvious bugs in the status quo, they pass.

3. Stretches Every Idea One Notch Further

Early designs are half-baked on purpose.

I want someone who challenges them, not just executes. The bar: you hand them an outline; they hand back a sharper concept than you imagined.

In practice that looks like:

• Turning my rough flow into a user-journey doc overnight.

• Proposing a simpler data model that unlocks v2 features.

• Flagging the one killer metric we’re not instrumenting.

A CTO who “can come in, quickly understand the product, bring ideas, and take them to the next level” is the multiplier .

Red Flags I Won’t Ignore

🚩Needs task breakdowns
If I’m still writing tickets, we’re moving at intern speed

🚩Treats domain as a black box
Vertical SaaS lives or dies on nuance they must absorb

🚩Optimizes code purity before value
Shipping late is fatal. Ugly code that proves value can be refactored

My Four-Question Screening Checklist

1. What user problem should we solve first. Why?

2. How would you validate traction before we write 10k lines of code?

3. Walk me through a time you reshaped a roadmap after new insight.

4. If you owned 50 % of this company, what would you not build?

Candidates who think like owners reveal themselves fast.

Product thinkers show up in how they attack ambiguous problems, not in algorithm trivia.

Putting It Together

A technical co-founder must wear two of the four engineering hats—product and technical—from day one; strategy and operations can wait until we have payroll for a VP . When I find someone who:

• Speaks in user outcomes,

• Learns the industry faster than I can schedule a discovery call, and

• Makes my ideas better on contact,

I write the offer.

Anything less, and I’m just hiring another developer with founder-level risk and none of the upside.

🎧 Want the full back-and-forth on spotting “startup gold” co-founders?

I unpack this topic with Noah Lindner on the latest Product Driven podcast episode, “Technical Co-Founders Are Startup Gold.”

They drift into it.

One day you’re the lead engineer, solving hard problems, earning trust with technical execution. Then suddenly, you’re in budget meetings, hiring sprees, and strategy sessions—wondering when you last wrote a line of code that mattered.

And somewhere along the way, you realize: the job you signed up for isn’t the job you’re doing anymore.

That’s not failure. That’s evolution.

But only if you can name where you are… and where you're going next.

The 4 CTO Archetypes I’ve Seen

When I wrote Product Driven, I started mapping out the types of engineering leaders I kept running into.

Not titles. Not org charts.

Mindsets.

Here’s the framework I came up with:

1. Technical CTO: The deep technologist. You’re the architect. The debugger. The person who makes the system work when no one else can.

2. Operational CTO: The executor. You’re building systems, scaling teams, managing people, solving day-to-day delivery problems.

3. Strategic CTO: The partner to the CEO. You’re thinking about vision, business models, market moves, and aligning tech bets to company goals.

4. Product CTO: The user-first builder. You’re sitting at the intersection of customer pain and engineering possibility.

Every strong CTO has some of these. A few might master two. Maybe three.

But here’s the hill I’ll die on: nobody is all four.

And the real trap? Believing you should be.

Most of Us Start in One Lane

I started technical. Most CTOs I know did too.

You were the best engineer. The most trusted pair of hands. So when the company needed a tech leader, it was you.

But no one told you the job would become less about systems and more about storytelling. Less about code and more about clearing the way for others.

At some point, the job stops being about being the smartest engineer in the room and starts being about building rooms full of engineers who don’t need you in the middle.

That transition wrecks a lot of people. Especially if you don’t see it coming.

Why So Many CTOs Get Stuck

About half of all startup CTOs get replaced by Series B.

Not because they weren’t smart enough.

But because they didn’t evolve fast enough.

Your company grows. The complexity grows. Suddenly you’re leading a 30-person team, your CEO wants to raise a round, and you’re still deep in technical debt cleanup.

You need a roadmap for becoming the kind of CTO your company needs next.

The CTO Levels Framework

On a recent Product Driven episode, I talked with Kathy Keating, co-founder of the CTO Levels framework and author of the book Liquid.

Her model hit me hard. It lays out how CTOs evolve across levels—and how most of us “tap out” at a certain point if we don’t actively grow.

She breaks it down into 4 Sentinels:

• Speed: how fast and lean your team executes

• Shield: your technical architecture, security, and resilience

• Stretch: your ability to keep growing with the business

• Sales: your communication and influence across the company

Every CTO is strong in a few. Few are strong in all.

Sound familiar?

Her work gave language to what I’d felt for years: that our job changes radically as the company scales, and most leaders never get a map for the road ahead.

So…What Kind of CTO Are You Becoming?

Are you defaulting to the thing you’re already good at?

Are you hiding in the work you know how to do?

Or are you stretching into the uncomfortable parts of the role. The ones that feel like you’re faking it, but probably matter most?

You don’t have to be all four archetypes.

You do have to know where you are today. And decide where you need to grow next.

Because the CTO role isn’t static.

It’s a moving target.

The only way to keep up is to evolve on purpose.

🎧 Want the full conversation with Cathy Keating and a deeper breakdown of the CTO Levels framework?

Catch this week’s episode of the Product Driven podcast. We go deep on what makes a strategic tech leader, and how to grow into the one your company needs next.

That’s why Chapter 6 ends with a blunt mandate—build feedback loops, not distance—and why I want to give you a concrete playbook you can use before the congratulatory LinkedIn DMs roll in.

Why Loops Beat Gut Feel

When engineers never hear from customers, they default to assumptions, polish features no one asked for, and watch momentum fade. I’ve lived that drift myself, and the data is clear: job satisfaction plummets when developers can’t see the impact of their work.

More velocity won’t fix the void. Direction and dialogue will.

Even the most introverted coder perks up when they find out a bug fix shaved hours off someone’s workflow. The loop is motivation.

Four Simple Loops You Can Steal Today

1. Share the Tape

Record customer calls and slice out the ten-second clips where users light up—or swear in frustration. Drop those clips in Slack. Engineers absorb tone faster than a bullet-point summary.

2. Let Support Speak

Turn your support channel into a pattern detector, not a dumping ground. A five-minute debrief each sprint on recurring tickets surfaces problems specs never captured.

3. Rotate for Empathy

Once a quarter, put every developer on a lightweight on-call rotation. Nothing sharpens judgment like feeling the PagerDuty ping at 3 a.m. for code you wrote.

4. Involve Engineers Earlier

Invite at least one engineer to the discovery call before stories hit Jira. When they hear the why firsthand, they stress-test assumptions upstream instead of hacking around them downstream.

Pro tip: Start with whichever loop feels least threatening to your culture. Momentum beats a perfect rollout.

Why Today Is the Day to Start

Shipping the book is a milestone for me, but it’s meaningless if leaders don’t apply it.

The same is true for your product. A launch without a loop is just hope wearing a release badge.

Pick one loop above, run it with discipline for 30 days, and let me know what changes.

My bet: defects drop, morale rises, and your roadmap conversations start with insight instead of intuition.

Ready for more?

Grab Product Driven on Amazon.

Then go to productdriven.com/book and submit your order to get a TON of bonuses as the toolkit to implement the book.

Then queue up today’s special launch-day podcast where Craig Ferril and I unpack why great teams ask why before they say yes. We talk introverts, empathy, and the leader’s job in closing the loop. Get the episode here

It took roughly 500 hours of pre‑dawn writing sprints to make sure every sentence earned its place.

This process did more than produce a book. It forced me to confront where my own leadership had drifted and what still wasn’t clear. Each rewrite came with a punch-in-the-gut reminder of how products—and teams—really scale.

Below are the five lessons that kept resurfacing.

Grab your copy of Product Driven on launch day, this Thursday, and skip the mistakes it took me twenty years to learn.

Lesson 1
Velocity without direction is just faster waste

My earliest drafts read like a typical sprint board: lots of words, no impact.

I could feel myself “shipping pages” instead of solving a reader problem. It echoed the teams I once pushed to “go faster” only to ship features no one used.

What it means for your team:
Look at the last release notes. If you can’t tie each line to a user outcome in 30 seconds, you’re burning calories, not delivering value. Instrument speed after you’ve instrumented purpose. Kill one backlog item this week that isn’t anchored to a customer pain.

Lesson 2
Culture is how it feels to work for you

I wrestled with the word culture for 30 pages—until one sentence survived every edit: “Culture is how it feels to work for you.”

Once that landed, the rest of the chapter practically deleted itself. Theory was replaced with feelings: safety, curiosity, pride.

What it means for your team:
Posters and values docs don’t fix disengagement; micro-moments do. In your next 1:1, ask, “When did it feel risky to speak up?” Then fix that risk. When engineers feel safe challenging a requirement, they protect you from your own blind spots—and bad releases.

Lesson 3
Clarity is the fuel

Every time an editor said, “I’m lost here,” they handed me a mirror. I learned that clarity isn’t decorative; it’s functional.

The book finally clicked when every chapter could be explained to a non-technical founder. That insight became the refrain: “Clarity is the fuel.”

What it means for your team:
Replacing half a stand-up with a Clarity Check will do more for delivery than doubling sprint points. Start by restating the user’s problem, then ask, “What’s still fuzzy?” Make dialogue—not docs—the place where clarity gets built, because questions reveal misalignment faster than Confluence ever will.

Lesson 4
You don’t scale yourself. You scale trust

I used to brag that nothing shipped without my review. Turns out I was scaling exhaustion, not excellence. Writing forced me to crystallize the uncomfortable truth: “You don’t scale yourself. You scale the story, the thinking, and the trust.”

What it means for your team:
Hand a decision to the squad and hand them the context you normally guard. Stay available—then stay out of the pull-request queue. The moment they deliver without your stamp, tell the story of why you trusted them. Your narrative sets the ceiling on their ownership.

Lesson 5
Trust → Ownership → Impact → More Trust —
The Flywheel

While hunting for a unifying diagram, I kept sketching loops. One finally stuck: Trust → Ownership → Impact → More Trust. That became the Ownership Flywheel chapter . Every real story in the book nested inside that loop.

What it means for your team:
Spot the next engineer who crosses lanes to fix a bug “outside their ticket.” Praise the behavior publicly. That single signal tells the group, “Cross-lane ownership is the job.” Each rotation of the flywheel compounds judgment and speed—no heroics required, just system design.

Why the book, and these lessons, had to exist

Most leadership books give you slogans: empower your team, move fast. Useful in theory, useless in Tuesday’s sprint review.

I wrote Product Driven so you can hand a playbook to a staff engineer tomorrow morning and watch them run it. The five foundations—Vision, Focus, Clarity, Ownership, Courage—are the operating system for product-minded teams .

Your move

Pick the lesson that stings the most and ship one tangible change this week.

Then tell me what happened—good, bad, or hilarious.

For the past two decades, engineering leaders have been obsessed with velocity. Ship faster. Automate more. Unblock the team. Move.

But we’re finally reaching a turning point.

Thanks to AI-assisted development, low-code tools, and platform maturity, the bottleneck has started to shift. Engineers aren’t the constraint anymore.

So what is?

The bottleneck is now product clarity.

I see it across nearly every team I work with.

The developers are moving. But they’re building from vague ideas, hand-wavy goals, or half-baked specs. The speed is there—but the direction is off.

And that’s the real problem.

Speed without clarity doesn’t create progress. It creates waste.

In a world where code can be generated, tested, and deployed faster than ever, the constraint moves upstream.

It’s no longer about how fast your engineers can execute. It’s about how well your organization can decide what’s worth building in the first place.

“We realized requirements weren’t just annoying—they were necessary.”

That line stuck with me during my conversation with Chris Rickard, the founder of Userdoc.

He started out like most of us—as a software engineer who hated requirements. But once he ran his own software consultancy, his view flipped.

When you’re responsible for delivering a six-month build for an enterprise client, “we’ll figure it out as we go” doesn’t cut it.

You need shared understanding. You need clarity. You need something more structured than Post-it notes and good intentions.

So he built his own system—first manually, then as software.

Now his whole company is built around this idea: requirements are the connective tissue that hold product vision together as it scales.

It’s not about going back to waterfall.

It’s about building smarter guardrails—especially now that the engineers can move faster than ever.

The Agile Lie: “We Don’t Need Requirements Anymore”

We swung the pendulum hard over the past decade.

Agile told us requirements were overhead. Just start with a user story, write the code, and figure the rest out in standups.

That worked for small teams with short timelines and direct access to users. But when your product spans dozens of features, multiple teams, and months of work?

You can’t “scrum” your way out of ambiguity.

And AI has made this even more dangerous. It can generate code faster—but it can’t tell you if you’re building the right thing.

If your process can’t provide direction, AI just makes the wrong work happen faster.

What Modern Requirements Look Like

Modern requirements aren’t mile-long Word docs. They’re structured, living documents that reflect what the product actually is and why it matters.

They include:

• Who you’re building for (user personas)

• What the user needs to do (user stories)

• How the system needs to behave (functional and non-functional requirements)

• What success looks like (acceptance criteria and business goals)

Chris’s platform, for example, uses AI to transform a spec or vision doc into a full requirements model. It pulls out users, goals, features—even flags what’s missing. Then the human steps in and adds judgment.

It’s not about replacing people. It’s about speeding up the parts that slow them down.

If You’re Still Optimizing for Engineer Velocity, You’re Solving the Wrong Problem

If your biggest issue is “we’re not shipping fast enough,” that’s a red flag.

It probably means:

• Your team doesn’t have clarity on what matters

• Your PMs are spread too thin and writing specs in a panic

• Your engineers are building from vague ideas and constant interruptions

You don’t need to move faster. You need to make better decisions about what to build—and why.

Your Process Has to Evolve Too

When engineers stop being the constraint, your leadership mindset has to evolve.

That means:

• Investing in product clarity as a system, not just a role

• Giving requirements their own tooling, not just buried tickets

• Treating alignment as a deliverable, not just a meeting outcome

Your team’s ability to execute isn’t the problem.

Your process for deciding what to execute is.

🎧 AI moved the bottleneck upstream.

Now it’s your move.

If your team is still building from assumptions, tickets written under pressure, or last-minute planning sessions, you’re setting them up to ship fast—and miss.

It’s time to rethink how you do product clarity. And it starts with how you handle requirements.

To hear how Chris Rickard is tackling this shift with AI, product teams, and evolving processes, check out our full conversation on the Product Driven podcast.

You’ll never look at requirements the same way again.

Get the full episode here.

That’s the conversation I had with Clarence Tan, co-founder and CEO of Boddle Learning—a company that turned educational games into something kids beg their parents to buy.

This wasn’t an overnight success. Clarence and his team started out in what he calls their "mom’s basement phase," piecing together grant money to build their first prototype.

They didn’t have a dev team.

They didn’t have users.

They barely had a product.

But they had one big question:

Can we build learning games that are actually fun to play?

Not "educational" games wrapped in a thin layer of gameplay.

Not worksheets disguised as entertainment.

Real games. That kids want to come back to.

That required something most teams skip:

A ruthless focus on understanding the user.

Why Most Product Teams Build in a Vacuum

Here’s the trap:

Your engineers execute the ticket.

Your PM owns the roadmap.

Your designers polish the flow.

But no one is actually listening to the user.

You start building based on secondhand data, internal assumptions, and what the last customer said in a sales call. Slowly, your team loses touch with the people they’re building for.

And when that happens, even the smartest teams ship things no one wants.

Clarence saw that early.

When he and his co-founder were building contract games for clients, they kept noticing a pattern: kids hated most educational games. They could smell the "learning" from a mile away.

The game mechanics were weak.

The fun was missing.

The outcomes were predictable.

So they flipped the script.

Fun first. Then learning.

It was a gamble. But it worked because they were obsessively close to the user.

Proximity Beats Assumptions Every Time

The most important shift Clarence made wasn’t tactical. It was cultural.

He and his team weren’t just trying to build "what made sense."

They were building what made kids light up.

That meant watching kids play.

Sitting in classrooms.

Running playtests.

Studying reactions.

Asking teachers what broke or worked.

You don’t get that kind of feedback from a Google Form. You get it from being in the room.

Too many teams wait until scale to build a feedback loop. By then, it’s too late. You’ve scaled assumptions. You’ve hardened the wrong patterns.

At Boddle, proximity wasn’t an afterthought. It was the product strategy.

COVID Wasn’t the Break—It Was the Mirror

When COVID hit, Clarence saw an opening. Everyone was scrambling for free resources. So his team sent out messages like:

"We’re offering Boddle free during the pandemic."

(They were free anyway. But the positioning mattered.)

Suddenly, they were on lists of "Top 10 Free Tools for Remote Learning." Then they were on the White House resource list. Then they hit 50,000 users.

That kind of growth exposes cracks fast.

Their servers crashed constantly.

Their onboarding couldn’t keep up.

Their support inbox exploded.

But they survived because the product actually worked. Not technically. Emotionally.

Kids liked it. Teachers used it. Parents recommended it.

Because the team had built with empathy from Day 1.

If They Don’t Use It, It Doesn’t Matter

Here’s what I see too often:

Founders get excited about an idea.

They build fast. They launch big.

And they get silence.

No adoption. No stickiness. No traction.

Why?

Because they never got close enough to the people they were building for.

It doesn’t matter how good your tech is if no one wants to use it.

Clarence didn’t just ship features.

He built around motivation. Around characters kids could identify with. Around learning loops that felt like leveling up, not logging in.

That takes more than wireframes and Jira tickets.

It takes watching your users. Caring about their reactions. And being willing to kill ideas that don’t land.

Are You Close Enough to Feel the Friction?

Every team says they care about the user.

But if your engineers can’t describe your user without reading a persona doc...

If your designers haven’t sat with real feedback in weeks...

If your roadmap is shaped more by internal goals than real pain...

Then you’re too far.

Clarence reminded me of something I learned the hard way at Stackify:

The faster you build, the more dangerous your assumptions become.

Speed without understanding isn’t innovation. It’s waste.

🎧 If you’re scaling a product team, you need this episode.

Clarence breaks down exactly how they built Boddle from prototype to millions of users—and how staying close to the user changed everything.

Listen now on the Product Driven podcast.