Two releases shipped in five months. That was the outcome. But the starting point was an 80-person team that had been working for eight months without senior product leadership, missing launch dates, and losing sight of why the product mattered. Turning that around required more than process fixes. It required reconnecting people to purpose.
Stride was building Career as a Platform (CaaP) – a product designed to guide students through career assessments, learning paths, certification prep, and job placement. It was an ambitious vision. The problem wasn't the vision. The problem was that nobody was driving.
I wrote about this work in more detail as a Delivery Diagnostic case study on Fieldway. Read the full diagnostic and results on fieldway.org.
What Happens When an 80-Person Product Team Has No Senior Product Leadership
I joined Stride in 2022, eight months after the CaaP initiative kicked off. In those eight months, the team had been operating without a senior product leader. What I found was a textbook case of what happens when skilled people lack direction.
Reactive workflows everywhere. Teams were responding to whatever was loudest rather than working from a coherent plan. A bug report from a key stakeholder would derail a sprint. A new feature idea from leadership would land mid-cycle with an implicit "do this now." There was no framework for saying "not yet" to good ideas in service of shipping great ones.
Compressed story development. Stories were being written simultaneously with development – literally at the same time during a Zoom call. It wasn't days or hours before; it was during. Engineers were building from incomplete specifications, making assumptions, then discovering those assumptions were wrong during QA. The rework cycle was brutal.
Missed launch dates. The team had blown through multiple deadlines. Each miss eroded confidence, both internally and with stakeholders. People stopped believing timelines were real, which became a self-fulfilling prophecy. Why push hard for a date nobody expects you to hit?
A team disconnected from purpose. This was the most damaging finding. The CaaP product had a genuinely compelling mission: help students find career paths and get the credentials they need. But eight months of chaos had ground that mission down to a series of Jira tickets. People were completing tasks without understanding how those tasks connected to outcomes for actual students.
Rebuilding Product Development Fundamentals from the Ground Up
My first priority wasn't a roadmap. It was documentation. That sounds unglamorous, and it was. But you can't align 80 people around a plan if nobody agrees on what the product is, who it's for, and what "done" looks like.
I documented the product vision, user personas, success metrics, and key assumptions. Then I shared them widely and invited pushback. This wasn't a top-down decree. It was a conversation, but a structured one with clear outputs. By the end of the first two weeks, the team had a shared understanding of what they were building and why. For many people, it was the first time they'd seen that articulated clearly.
The product development best practices began with a four-day on-site workshop. We worked through defining the vision and mission and getting everybody on the same page, then developed a strategy together. After that, we started moving into the tactics – how to write a user story that an engineer can build from, how to define acceptance criteria, how to break an epic into shippable increments, how to run a sprint review that actually generates useful feedback. These weren't skills the team lacked. They were skills the team had never been given space to practice consistently.
Cross-Functional Alignment Through In-Person Collaboration
One thing I pushed hard for was in-person cross-functional sessions. Stride's team was distributed, and while remote work was the norm, the level of misalignment I was seeing demanded face-to-face time. Not because remote can't work, but because this team specifically needed to rebuild trust and shared context that had eroded over eight months of directionless remote work.
We brought together product managers, designers, engineers, and QA leads for intensive working sessions. These weren't presentations or status updates. They were working meetings where we mapped user journeys together, identified technical constraints early, and made real decisions with all the relevant people in the room.
The impact was immediate. Designers heard directly from engineers about what was technically expensive versus cheap. Engineers understood the user research behind feature priorities. QA leads got involved early enough to influence how features were built, not just how they were tested after the fact.
These sessions also surfaced interpersonal dynamics that were invisible over Slack and Zoom. Two team leads who'd been in quiet conflict for months worked it out over coffee. A designer who'd been frustrated about being excluded from planning got pulled into the process and immediately started contributing insights that improved the product.
Tackling Technical Debt and Engineering Efficiency
The CaaP codebase had accumulated significant technical debt during those eight months. When teams work without clear direction, they accumulate shortcuts. Temporary solutions become permanent. Architectural decisions get made locally without considering system-wide implications. The result was a codebase that was increasingly difficult to work in.
There was also an offshore engineering efficiency problem. A significant portion of the engineering team was offshore, and analysis of the code repository showed that only about 20% of their output was actually useful – the rest was rework, duplicated effort, or code that didn't meet quality standards. This wasn't a talent indictment; it was a system problem. Without clear requirements, consistent processes, or adequate quality gates, even good engineers produce poor results.
I allocated a dedicated percentage of each sprint to technical debt remediation. This is always a negotiation. Stakeholders want features. Engineers want clean code. The right answer is almost never "all features" or "all debt reduction." It's a deliberate balance that shifts based on where you are in the product lifecycle.
We prioritized the debt that was actively slowing the team down. If a particular module was causing bugs every sprint, it went to the top of the list. If a piece of tech debt was ugly but stable, it waited. This pragmatic approach meant engineers saw real improvements in their daily work, which built buy-in for the process, while stakeholders continued to see feature delivery.
Building a 6-Month Product Roadmap with the Right Tool for Each Job
With the team stabilized and fundamentals in place, I built a 6-month roadmap using a deliberately tiered tooling approach:
Miro for brainstorming and discovery. Early-stage ideas, user journey mapping, and collaborative whiteboarding lived in Miro. This was the space for messy, divergent thinking. Nothing in Miro was a commitment. It was a place to explore.
Aha! for strategic planning and prioritization. Once ideas matured past the exploration phase, they moved into Aha! for formal prioritization, timeline planning, and stakeholder communication. This was where the roadmap lived. It connected features to strategic objectives and gave leadership the high-level view they needed.
Jira for day-to-day execution. Sprints, stories, bugs, and daily standups ran through Jira. This was the team's operating system for getting work done.
This three-tier approach prevented a common failure mode: using a single tool for everything and doing nothing well. Jira is great for sprint management but terrible for strategic planning. Miro is great for brainstorming but terrible for tracking commitments. Using each tool for what it does best gave every layer of the organization the right level of detail.
Edtech Product Delivery: Two Releases in Five Months
The team shipped two full releases within my first five months, plus partial completion of a third release's feature set. For context, the team had missed multiple launch dates in the eight months before I arrived.
The first release was deliberately scoped to be achievable. I wanted a win. The team needed to remember what shipping felt like. We picked a set of features that were high-value and well-understood, with minimal technical risk. It shipped on time.
The second release was more ambitious. It included features from the CaaP vision that had been on the roadmap since before I joined but had never been close to shippable. By this point, the team's velocity had stabilized, sprint commitments were being met consistently, and the planning process was mature enough to handle the complexity.
What changed wasn't the team's talent. These were skilled people from the start. What changed was the environment they were working in. Clear priorities instead of reactive chaos. Defined processes instead of ad-hoc decisions. Connection to purpose instead of disconnected task completion.
What Product Leadership Turnarounds Actually Require
I've seen variations of this pattern at multiple organizations. A talented team struggles not because of individual capability but because of structural and leadership gaps. Fixing it requires work on several levels simultaneously:
Process. You need basics in place: story development timelines, sprint cadences, definition of done, review and feedback loops. These aren't bureaucracy. They're the infrastructure that lets talented people do their best work.
Purpose. People need to understand why their work matters. Not in an abstract mission-statement way, but concretely. This story you're building? Here's the student it helps. Here's the outcome it produces. This connection gets lost easily in large teams, and it's the leader's job to maintain it.
Protection. The product leader's job is partly to be a shield. When stakeholders want to change priorities mid-sprint, someone has to hold the line. When leadership wants a timeline that isn't realistic, someone has to push back with data. Without that protection, teams burn out and output quality drops.
Patience. Turnarounds don't happen overnight. The first month at Stride, things actually got slower as I introduced new processes. That's normal. You're adding structure to chaos, and there's a transition cost. The payoff comes in months two through five, when the team hits its stride (no pun intended) and starts delivering at a pace that compounds.
FAQ: Product Team Turnarounds and Leadership
How quickly can a struggling product team be turned around?
In my experience, you can start seeing tangible improvements within 4-6 weeks if you focus on fundamentals first. At Stride, we shipped our first on-time release within the first few months. But a full turnaround, where the new ways of working are self-sustaining, typically takes 4-6 months. The mistake is expecting instant results. Teams need time to build new habits and rebuild trust in the process.
What are the signs that a product team needs senior product leadership?
Missed deadlines are the obvious symptom, but the earlier warning signs are more subtle: stories that arrive to engineering incomplete, sprints that change scope mid-cycle, stakeholder requests that bypass the planning process, and a team that can describe what they're building but not why. If you're seeing these patterns, the team likely needs a product leader, not just a project manager.
Should you fix process or people first when rescuing a stalled software project?
Process, almost always. In most turnaround situations I've encountered, the people are capable. They've just been set up to fail by missing structures and unclear direction. Fix the environment first. Give people clear priorities, consistent processes, and connection to purpose. If individual performance issues remain after the structural problems are solved, then you address those. But don't jump to "we need to replace people" before you've given them a functional system to work within.
Related Case Studies
- Enterprise Agile Transformation for 120,000 Consultants at a Big Four Firm – A different scale of organizational transformation, this time implementing Atlassian tools across a global enterprise.
- Machine Translation at CoinDesk: Automating Multilingual News for Global Growth – A product-led growth initiative where technical strategy and editorial needs had to align, similar to the cross-functional challenges at Stride.