Why We’re Rewiring How We Build Product

By: Gavin Wills, SVP, Engineering

Part 1 of 2.

The job of building software is changing faster than the workflows we use to do it.

AI can draft a feature, write the tests, review the diff, and sketch the UI in the time it used to take to schedule the kickoff. Meanwhile, most product teams are still running playbooks designed for a world where typing code was the bottleneck. Sprint ceremonies. Linear handoffs. Product writes the spec, Engineering builds it, QA validates it, and weeks go by.

Those workflows aren’t wrong. They’re just increasingly out of step with the work itself. And the cost of running an outdated process on top of a fundamentally changed job is one we’d rather not keep paying.

So we changed how we work.

We started planning this shift back in April, spent two months gradually migrating the workflow over, and as of now, we’re fully on the new process. Our first release under it shipped last week.

There’s a deeper motivation here than speed. NVIDIA’s Jensen Huang has argued that traditional technical intelligence, the coding and problem-solving kind, is becoming a commodity as AI advances. The people who matter most, in his view, sit at the intersection of technical acumen, human empathy, and the ability to see around corners: anticipating problems before they surface, using wisdom and intuition rather than just analysis. This put words on something I’d been circling for months. A large part of this change is about moving everyone toward that intersection. Our developers get room to build skills beyond writing code: product sense, client empathy, judgment. Our Product team gets the technical footing to build. Nobody stays in their lane, because the lanes were drawn for a different era.

The bet: we’ve moved from sprint-based, handoff-driven development to an AI-assisted, Kanban-based continuous flow, with Product and Engineering jointly owning feature delivery.

What’s actually changed

• Sprints → Kanban / continuous flow. Work moves when it’s ready, not when the ceremony says so. Smaller, more frequent releases.
• Sequential handoffs → a shared delivery zone, where either function can pick up work between spec and ship. Product still owns problem definition, success metrics, and stakeholder comms. Engineering still owns architecture, security, and code quality. UX/UI implementation, feature delivery, and happy-path logic are now shared work.
• Product gets hands on the code. With AI assistance, our Product team is upskilling into feature branches, Git workflows, front-end prototyping, and CI/CD awareness, building UX components and happy-path logic directly, with Engineering pairing alongside.
• UAT shifts. Product can’t independently validate work they helped build, so UAT execution moves to internal stakeholders. Accountability doesn’t move: Product retains ownership and sign-off.
• QA’s remit changes. Less scripted validation, more exploratory testing. And a genuinely new frontier: as we build AI-powered products, QA is moving into model evaluation and benchmarking, testing systems that don’t behave the same way twice.
• AI in the loop across the workflow: discovery, prototyping, coding, review, and QA.

What we hope to gain

• Speed. Shorter idea-to-production cycles. Smaller, safer releases.
• Fewer handoffs. Less coordination tax, more time on the actual problem.
• Quality. AI-assisted review and test generation catching what humans skim past.
• Room to be strategic. With AI absorbing more of the mechanical work, we expect to reclaim time for the things that always get squeezed: planning, architecture, deeper discovery, and deliberate upskilling, both in AI fluency and in the craft of building product.
• A more technical Product team, closer to the build, faster to iterate.

What we’re worried about

• Cognitive load. Faster doesn’t mean easier. AI-assisted development compresses the cycle, which means more decisions per hour, more context-switching, more reviewing of code you didn’t write. The pace itself is a risk. Burnout looks different when the bottleneck is your attention, not your typing.
• Confidently wrong code. AI is fluent, and fluency hides errors.
• Review as the new bottleneck. If AI writes faster than humans can review, what breaks first?
• Product moving into code. How steep is the learning curve, and where do the seams need extra care?
• Skill atrophy. When AI does the generating, the muscles you stop using fade. Our main mitigation is treating review as the new core skill: the scarce ability now is judgment, not typing, and we’re building the habit of reviewing AI output critically rather than just accepting it. Beyond that, we genuinely don’t know how to solve this yet. It’s the worry we’ll report on most carefully in Part 2.
• Kanban needs different discipline, not less. Sprints gave us rhythm for free. Continuous flow means we have to build it ourselves.
• Measuring real impact, not vibes. Faster-feeling isn’t the same as faster.

We don’t have clean answers yet. That’s part of why we’re writing this down.

Coming in Part 2

The honest retrospective, once we’ve lived with this long enough for the numbers to mean something: what worked, what didn’t, what surprised us, including the numbers that don’t flatter us.

If you’ve already made this jump, I’d genuinely like to hear what you learned the hard way.

See how you can partner with OpinionRoute and bring AI into your research operations. Contact us.