The 4-6 Week Research Cycle Was Built for Quarterly Shipping. Now What?
Filippos Protogeridis
•
June 2, 2026
•
“Let’s simply ship and learn.”
I hear this every week from people on our product team and product leaders I talk to across the industry. Why wait 4-6 weeks to run a research cycle when we can use AI to prototype the flow today or ship an experiment this sprint? What used to take weeks can now happen in days, sometimes hours. If AI is making us 10x faster, why should we not ship 10x as much?
As the head of product, I find myself pushing back on this more and more. The instinct isn’t wrong. But it’s incomplete.
When we move this fast, we often just build more wrong things with more confidence. We’ve quietly taken evidence out of our decision-making process and started hoping the market will correct us later.
Askable gives you the platform, the participants, and the researchers to get there quickly.
Let's chatThe question isn’t whether teams value evidence. Most do. The harder problem is whether the way they work gives evidence anywhere to live.
This tension predates AI. Frameworks like dual-track agile, where discovery and delivery run in parallel rather than in sequence, and continuous discovery were built because practitioners already knew the serial model (design, research, build, ship) was breaking down under delivery pressure. Teresa Torres, whose work on continuous discovery has shaped how many modern product teams operate, has argued for years that the goal isn’t more research but making customer contact a regular habit rather than a scheduled event.
What AI has done is speed up one side of the system so much that a manageable problem has become a structural one.
The serial model assumes a team can pause, learn, decide and then build. In most real product environments that’s not what happens. Teams learn, decide, and build at the same time, in Slack threads, Notion docs, Figma files, Cursor prompts, Claude conversations, and quick product reviews squeezed in between meetings.
For example:
None of these moments feel like major strategic decisions on their own. But without a shared foundation of customer insight underneath them, there’s nothing keeping them aligned. Each one looks like agility. Taken together, they can become drift.
Get a sneak peek into the product, and everything Askable can do for you.
Contact salesThis is far from theoretical; I faced this tension first hand recently when my team completely revamped our app’s onboarding experience.
In the past, it would have taken us months to do this work: weeks of discovery and data analysis, followed by content and design work, testing with a research panel of users, and then finally launching as an experience. This time, with AI reducing the design and development cycle drastically, we were able to ship in just a few weeks.
However, when we did launch, it didn’t perform. And we had little to no insight as to why the new flow wasn’t working. So we started testing. From the first session it was obvious we had introduced significant friction early on in the flow, and our communication and value proposition wasn’t landing despite our best efforts.
The quality would have been there if we had just slowed down a little bit and gathered evidence for our assumptions or validated our solution prior to launching.
The obvious response to an evidence velocity problem is to make research faster: Quicker set-up, shorter sessions, AI-enabled synthesis. That instinct isn’t wrong, but it misidentifies the problem. Speed isn’t what’s missing. Continuity is. Fast research without traceability—without being able to follow a finding back to a real person, a real session, a real moment—doesn’t build on itself. Each cycle produces an answer and then resets, leaving no foundation for a decision that comes six days later inside a Figma file or a Claude conversation. The gap doesn’t close; it just fills with something else.
That something else, for most teams under pressure, has become LLM tools that pull from public patterns, broad product assumptions, and whatever context gets pasted into a prompt. The outputs are well-written and often plausible, which is precisely the problem. A 2026 randomized trial published in npj Digital Medicine found that misleading AI explanations significantly reduced decision accuracy, while correct AI explanations made no measurable difference compared to no explanation at all. Wrong answers that sounded confident did more damage than right answers did good.
The domain is medical, but the pattern will be familiar to anyone who has watched a product team talk itself into a bad decision using a well-formatted AI summary. A polished “finding” removes the friction that usually forces a team to ask harder questions. Once that friction is gone, it’s difficult to notice what you’ve stopped asking.
Teams have always moved faster than they’d like. What’s changed is that tools now available for filling the evidence gap produce output that feels like evidence without being traceable to any of it. The confidence is real; the foundation isn’t.
The alternative isn’t a slower system or a return to the 4-6 week cycle as the primary unit of learning. That cycle still has a place. There will always be questions that require depth, space and dedicated exploration. Rushing them produces worse decisions, not faster ones. But treating the research cycle as the only mechanism for building conviction is what created the gap in the first place. An evidence layer doesn’t replace that work. It fills the space around it, so that the dozens of smaller decisions made between deep research cycles have something real to draw from rather than defaulting to assumption or AI synthesis.
Smaller bets, reversible decisions, and faster feedback loops (like those that utilize AI moderation) all reduce the cost of being wrong. They are useful. But they don’t tell you whether you’re heading in the right direction — they just find it cheaper to find out you weren’t.
For that, you need evidence that was gathered from real people, in real sessions, and can be traced back when someone asks why the team believed what it believed. That evidence needs to be available at the speed decisions are actually being made, which means it can’t only arrive in a report after the meeting has already ended.
The question product teams are now facing isn’t how to do research faster. It’s whether the evidence system they’re working with was designed for how they actually work… or for a version of product development that AI has already made obsolete.
.jpg)
.svg)
.png)
.png)
