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.

Some build fast but never seem to deliver what matters.

Others move slower—but consistently land the work that has real impact.

The difference isn’t velocity.

It’s feedback.

Or more specifically, how many layers of feedback that developer actively uses.

Most teams only think about feedback at the top: customer feedback, feature usage, stakeholder input.

But the best developers I’ve worked with? They’re collecting feedback constantly—from the inside out.

It’s a layered system. And if your team isn’t using it, you’re probably shipping code that misses the mark.

Let’s walk through what that system actually looks like.

Layer 1: Internal Review — Your Own Thinking

Before code reviews, before QA, before you push the commit… there’s the first and most powerful feedback loop:

Your own brain.

Ashley Davis, my guest on this week’s Product Driven Podcast, calls it “personal feedback loops.” That moment where you step back from your code and ask:

• Am I solving the right problem?

• Is there a simpler way to do this?

• What trade-offs am I making?

• What did I not do, and why?

It’s a kind of self-review that mirrors test-driven development—except it’s about thinking, not tests.

And it’s massively underrated.

Every good developer I’ve ever worked with has some form of this reflex.

They pause. They reframe. They gut-check before handing it off.

You can teach this. But only if you name it.

Layer 2: Peer Feedback — Fast and Frictionless

Here’s where most teams stop: peer reviews, code comments, maybe a Slack convo after standup.

But ask yourself:

• Are peer reviews helping engineers make better decisions?

• Or just checking for syntax and spacing?

True peer feedback means surfacing assumptions. It means having the courage to say, “Are we sure this is the best way to do this?”

It’s not about nitpicking. It’s about building a culture where better thinking gets multiplied.

Make it lightweight. Make it normal. Make it continuous.

Layer 3: Stakeholder Feedback — Are We Still on Track?

Ashley said it best: “You can spend hours or days coding in the wrong direction.”

That happens when developers lock in too early—without checking with the PM, designer, or team lead.

At Full Scale, we’ve seen teams burn weeks on misunderstood features simply because nobody paused to ask: Are we still aligned?

This isn’t about waiting for sign-off. It’s about developers taking ownership for the outcome.

The best engineers don’t just ship what’s in the ticket. They ask if the ticket still makes sense.

Layer 4: User Feedback — Did It Work?

This is the top of the ladder. The place most teams claim to care about… but rarely reach.

It’s not enough to ship the feature.

• Did the user notice?

• Did it solve their problem?

• Did anything actually get better?

If you don’t know, you’re not done.

And if your engineers never get visibility into that feedback, they’ll never improve their instincts for what matters.

Ashley pointed out how many developers work in a vacuum today—especially in remote environments. That used to happen gradually as companies scaled.

Now it happens from day one.

And that disconnection? It’s killing motivation, slowing progress, and leading to more waste than most CTOs want to admit.

How to Build the Feedback Ladder Into Your Team

• Start with questions. Encourage developers to gut-check their own work before review.

• Normalize mid-flight feedback. Don’t wait for sprint review—ask for feedback on direction early and often.

• Break the wall between engineering and users. Share customer insights with the dev team regularly. Let them see the impact (or lack of it).

• Reward curiosity. When someone asks, “Are we sure this is the right thing?”, celebrate that. It’s not dissent—it’s ownership.

Great developers don’t just code faster.

They climb the feedback ladder—every day.

If your team is stuck, burned out, or off track, don’t just ask them to move faster.

Ask them what kind of feedback they’re using.

Then go one layer deeper.

🎧 To hear my full conversation with Ashley Davis—author of The Feedback Driven Developer—and learn how to make feedback loops part of your development culture, check out this week’s Product Driven podcast.

You’ll never think about “product-led” the same way again.

But what I’ve learned—from building products, funding startups, and interviewing founders like John Rush—is that real product-led growth doesn’t start with features.

It starts with the founder.

The truth?
You don’t need a breakthrough feature.
You need a breakthrough alignment between your product and your worldview.

And if you get that right, you don’t need funding, a sales team, or a massive marketing engine to grow.

Let me explain.

John Rush Has Built 25 Startups—Without Raising Capital

When I talked with John on Product Driven, he shared something that stopped me cold:

“I only build products that are 100% aligned with how I think.”

That’s not about ego.
It’s about leverage.

Because when you build something that matches how you think, how you work, and what you wish existed in the world…

• You know the problem intimately
  
  

• You use your own product every day
  
  

• You spot friction faster than any PM or customer report ever could
  
  

And that’s where the growth comes from—not from features, but from fluency.

Why “Product-Led” Gets Misunderstood

A lot of startup founders hear “product-led” and think it means:

• Ship fast

• Add more features

• Let the product “sell itself”

But that’s not how it works in real life.

In real life, most bootstrapped products are scrappy.
They’re opinionated.
They’re built around a very specific user, with a very specific pain.

That’s where product-led growth shines—not because the product is shiny, but because it’s sharp.

Feature-Rich ≠ Growth-Ready

John said something else that stuck with me:

“People think they need 10 features to get one user. But you can get 100 users with one feature—if it’s the right one.”

And he’s right.

I’ve seen teams overbuild because they didn’t trust the simplicity of a clear problem.
I’ve seen founders waste 6 months on v2 when v0.5 was already working.

Product-led growth isn’t about volume.
It’s about velocity—of understanding, of adoption, of value.

And that velocity only happens when your product feels inevitable to the person it’s built for.

The Real Playbook: Start With Founder Fit

✅ Don’t build “for the market.” Build for your past self.
If you’ve lived the problem, you’ll spot details no competitor can copy.

✅ Simplify until the value is obvious.
One clear outcome beats ten vague features.

✅ Make it impossible to use wrong.
John designs his products so they almost force the right action. That’s not UX magic—it’s alignment with what the user already believes.

✅ Trust small signals.
Before you build “the full version,” build the one that solves one small job for your dream user. Then stack from there.

If you’re overbuilding…

If you’re second-guessing your roadmap…

If you’ve ever thought “maybe we just need more features”...

Take a step back.

You don’t need more.
You need sharper.

That’s the lesson I’m taking from builders like John.
And it’s the approach we’re using at Full Scale Ventures, too.

🎧 We broke this down in the latest episode of Product Driven—including how John thinks about stacking tiny products into a self-funding growth engine.
👉 Go listen to the full episode here.

You’ll never think about “product-led” the same way again.

That’s what I’ve learned as we’ve started introducing GenAI tools across our teams.

Because it’s not just about the tech.
It’s about the tone.

If you’re leading a team right now and wondering why AI adoption feels slow, scattered, or forced—this might be why:

Your team doesn’t need another platform.
They need a signal.

They need to know it’s safe to try, explore, and fail without looking dumb.
They need to see it’s okay to not “get it” the first time.

They need to see you using it.

So what does it look like in practice? What does it mean to lead a team that’s actually ready for this shift?

Let’s break it down.

What AI-Ready Leaders Do Differently

I got to sit down with Senad Santic on the Product Driven podcast to talk about how real teams are building toward AI maturity. He’s seen it firsthand at TestChimp—and his advice wasn’t about tools. It was about trust.

Here’s what I’ve learned—from my own teams and from leaders like Senad:

✅ You Normalize Experimentation

Senad’s team didn’t start with a top-down plan. They started with bottom-up curiosity.

They encouraged developers to try things. To share their prompts. To show wins.

The habit mattered more than the outcome. And that’s what drove momentum.

Try this: Start a “Prompt of the Week” Slack thread. One person shares how they used an AI tool to make their work easier or faster. Everyone learns. No pressure.

✅ You Show Use Cases By Role

You don’t need a whitepaper. You need real examples.

Like:

• A developer using Claude to explain a legacy codebase

• A QA lead using GenAI to write variations of test cases

• A PM using ChatGPT to summarize customer call transcripts

The more your team sees themselves in the possibilities, the faster they adopt.

✅ You Build Rituals That Support Curiosity

Rituals create safety. And teams need safety to explore.

Try this:

• Add a “What did you try with AI this sprint?” question to retros

• Host monthly internal demos where team members share their AI workflows

• Let one person per week teach a new shortcut or tool

Curiosity spreads fastest when it’s visible and valued.

✅ You Connect It to Real Problems

This isn’t about looking innovative. This is about solving real problems:

• Long onboarding times

• Manual QA

• Tedious documentation

• Slow estimates

The AI-ready leader doesn’t pitch a vision of the future. They ask, "Where are we spending time that doesn’t require human brilliance?"

Then they invite the team to find a better way.

The Old Model Won’t Work Here

Top-down AI rollouts won’t work.
Waiting for your team to magically “get on board” won’t work.
Hiring one person to “own AI” won’t work.

This isn’t just a tooling shift.
It’s a leadership shift.

Because being an AI-ready team doesn’t mean everyone’s a prompt engineer.

It means your team knows:

• What AI is and isn’t good at

• When to trust it—and when to question it

• How to improve the way they work because of it

And that starts with you.

The AI-Ready Leader Thinks in Systems—Not Tools

Senad put it best:

“People want a button. But what they need is a mindset.”

You don’t need to be an AI expert. But you do need to create a system that rewards exploration, shares wins, and builds confidence in what’s possible.

You don’t start with use cases. You start by shifting the culture.

If your team is waiting on permission, they won’t move. If your team is afraid to experiment, they won’t grow.

The AI-ready leader’s job is to reduce fear and increase feedback. To make "try something weird with AI" a normal part of how the team works.

And that shift starts with you.

If you're leading an engineering org right now, here’s the question I’d ask:

What signal are you sending?

Are you showing up curious, exploratory, open?
Are you letting your team see you learn—not just lead?

Because that’s what builds readiness.
That’s what builds buy-in.
And that’s what will separate the teams who lag behind… from the ones who leap forward.

🎧 We unpacked this in depth on the Product Driven podcast with Senad Santic from TestChimp—especially the cultural side of AI readiness most leaders miss.

👉 Listen to the full conversation here

But you can feel it.
The edge is gone.
The curiosity starts to fade.
The strongest people on your team—the ones who used to push back, challenge ideas, and raise the bar—go quiet.

They’re still productive.
They still ship code.
But something’s missing.

And by the time you notice it?
They’re halfway out the door.

This is one of the hardest things about leading technical teams.
You don’t lose your best engineers in a moment.
You lose them in pieces.

And the cause usually isn’t money or burnout or office perks.
It’s a quiet breakdown in the three things that matter most:

✅ Mastery
✅ Autonomy
✅ Purpose

When those go missing, people don’t escalate.
They disengage.

What Keeps Top Engineers Engaged (It’s Not Just the Work)

This is something I talked through with John Durrant on the Product Driven podcast.

He said it best:

"Culture isn’t a vibe—it’s a system. It’s the invisible structure that either reinforces motivation or drains it."

And the core of that structure?
The space to grow, lead, and believe in what you’re building.

Let’s break it down:

1. Mastery: “Am I getting better here?”

The best engineers want to get better.
They’re not looking for comfort.
They want challenge.
They want stretch.
They want to be around people who push them.

When that stops?
So does the engagement.

You don’t need to send them to a conference every quarter.
But you do need to:

• Give them visibility into the bigger picture

• Let them lead problems, not just solve assigned tickets

• Create room for learning in the work, not just outside it

2. Autonomy: “Do I have space to lead—or am I just executing?”

Engineers don’t burn out from too much work.
They burn out from meaningless work.

From constantly waiting for requirements.
From never getting input into the roadmap.
From fixing things they know shouldn’t exist—over and over.

High-performers want to own outcomes.
Not be stuck in reactive mode.

Autonomy doesn’t mean letting go of standards.
It means giving your team a real voice in what’s being built—and why.

John shared how his team embedded this mindset into everyday practice:

"We don’t need more process. We need more trust. And we need to let teams make small bets, safely."

3. Purpose: “Does this matter—and to who?”

Even the most technical engineers want their work to mean something.
They want to know:

• Who’s using this?

• What problem are we solving?

• Are we making anything better for someone?

When purpose is missing, even well-written code feels hollow.

If your demos are just updates and no one’s talking about real user feedback or outcomes—purpose is slipping.

You can bring it back by:

• Sharing support tickets in standup

• Bringing PMs and engineers together earlier

• Celebrating impact, not just output

This is how you turn “I did my job” into “I’m proud of what we did.”

Culture Isn’t a One-Off. It’s a Loop.

You can’t solve this with an all-hands and a values slide.
You build it through repetition.
Through rituals.
Through leadership behaviors that reinforce Mastery, Autonomy, and Purpose every week.

The teams that retain top talent don’t wait until people are checked out.
They design for motivation before it fades.

And they build a culture that isn’t just positive—but motivating.

If you’ve ever felt that shift in energy from your best engineers—
If you’ve ever asked, “Why aren’t they stepping up like they used to?”
If you’ve ever wished someone told you earlier what was missing…

This is it.
This is what’s missing.

Mastery.
Autonomy.
Purpose.

And as a leader, you don’t have to create it all yourself.
But you do have to protect it.

🎧 We dug deep into this in the latest episode of Product Driven, where I sat down with John Durrant to talk about what makes great engineering cultures—and what slowly breaks them down.

👉 Listen to the full conversation here

Product Driven engineers speak up when something doesn’t make sense—because ownership includes the courage to challenge, not just comply.

This lesson helps engineers understand when and how to raise questions about direction, strategy, or technical decisions—without undermining collaboration or trust. Challenging the plan is part of ownin…

Read more