As the AI revolution took off, I increasingly found myself having more and more conversations about continuous discovery with my product team. These tended to turn into debates about whether it was worth it to keep doing continuous discovery or even whether we should put additional resources into research projects.
Despite their popularity, neither of these approaches worked that well for us. So, we pivoted and decided to try something completely new — weekly research sprints.
Since implementing them, it’s been a real game changer for us. Let me tell you how.
The AI revolution completely changed what was possible for tech products and made development easier than ever before. This has upended the previous product world, as lean teams with relatively little experience can now release solutions that used to require extensive engineering, UX, and PM support.
In short, it’s a product bloodbath out there.
My company found ourselves attempting to enter a brand new product segment, while also pivoting our whole business model to thrive in the new AI era. We needed to stay on top of things, and we needed to learn a lot. Fast.
To help with this, we implemented weekly interviews and other continuous discovery activities. Although the continuous stream of insights was very helpful, it wasn’t enough to keep up with our needs.
We also did research projects, but the time from concept to research report was too long.
Don’t get me wrong, both methods worked and were extremely helpful — we just needed more.
At some point, it dawned on us that if our developers could work in weekly development sprints and get a ton of things done, couldn’t we (PMs and UX designers) do the same?
We decided to commit to getting through one robust research project every week.
This might sound similar to continuous interviewing, but there a were few key differences:
Here’s how the process looked.
We always defined a research question for the next research sprint. Sometimes it was a specific one, such as “understand what name best fits our best answer type,” and other times it was a broader one, such as “learn what it means for students that notes are useful.”
The goal wasn’t just to get a couple of insights, but to get to a true knowledge bomb.
We then scheduled between five and eight interviews for the following week, depending on our capacity and the ambiguity of the research question. Sometimes we combined an interview and usability testing in a single session.
In practice, this meant we had three days to get the insights we needed, as the process was structured like:
Although the process caused us to work under pressure, it created a sense of urgency that pushed us to really make it work and optimize along the way.
While extremely useful, these weekly research sprints turned out to be much more expensive than we initially anticipated.
The first reason for this was the recruitment challenge. Recruiting so many users in such a quick period of time wasn’t feasible for us. Eventually, we decided to partner with an external agency that specializes in it.
Secondly, we simply couldn’t keep up with the research from a capacity perspective. To add insult to injury, there was approximately an eight hour time zone difference between us and our users. We resolved both issues by partnering with a freelance researcher who worked in the local timezone.
After a couple of months of working with such a process, we decided to stick to it for the long term. We started to understand our users ten times better than ever before.
Whenever we had a doubt or hypothesis, we rapidly tested it instead of guessing. However, that came at a cost. The need to hire an external agency, bring on an extra researcher, and spend so much additional time soon added up.
We can probably lower that in the long run by hiring an extra full-time employee and optimizing the process further. We’ll definitely experiment with that in the future, but as of today, it’s still quite an expensive endeavor for us worth a couple of hires.
Now, the real question: Should you embrace the weekly research projects?
In short, yes, but only if you can act on insights as you get them. Research only makes sense if it leads to action, and the insight you get today might be obsolete in a couple of weeks.
We act in pivot mode, working extremely fast and deciding priorities on the go, so the regular influx of insights works well with our process. But if your roadmap is already fixed for the next quarter, then there’s no point researching under such pressure.
I’d say start with continuous interviewing — just one interview a week. Then, assess if you’re able to process more insights.
Ideally, you’d scale it slowly — from one to two, then from two to three, and so on. In our case, we didn’t have time for that, so we went all in. It was more chaotic and thus more expensive, but in the end, we believe we got a good return on investment.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Alicia Littleton talks about the importance of empathy and flexibility in the workplace when team members go through life changes.
Daric Snyder talks about developing supportive, user-friendly healthcare software that layers on top of traditional health records systems.
Monique Piras shares how she helped redesign the feature brief and product requirements template and quarterly planning process.
Digital product leader Aditya Raju talks about the importance of meeting users in the healthcare ecosystem where they are.
Learn more →
