Talk to Users and Make Decisions in Just 5 Days🖐️:What’s a Sprint? (Part 1)

Written by BACKND Product Manger Sunny, 3 July 2025

It’s like an old friend who suddenly looks stylish after a new haircut and a fresh outfit. Our BACKND team made this dramatic transformation in just 5 days!

Same product, completely different first impression!

If you’ve worked on a team project, you’ll understand; coming up with ideas, deciding what to build, and getting team-wide alignment takes way more time and energy than actually building something. But what if all of that, including talking to real users and making confident decisions, could happen in just 5 days? It did for us! With the help of Jake Knapp’s Sprint methodology.

This article is the first part of a two-part series on Sprints.

In this post, we’ll share why our team chose this methodology and how we studied it together. We've even included the exact discussion prompts we used and some of the most heated debates we had along the way. (Yes! That’s how we spar at BACKND 🥊) We’ll reveal our full workshop journey and results in Part 2!

If you’re considering a book club for Sprint or planning your own workshop, this post is especially for you.

Why Did We Choose a Sprint?

First, a quick intro: BACKND is a backend service for game developers. In the early days, our main users were indie teams without server engineers. But over time, our user base has grown. Now, even publishers and mid-to-large-sized studios rely on BACKND.

And yet… our landing page hadn’t changed in years. It was still speaking to our earliest users, even though the product had evolved. In other words, our first impression was stuck in the past.

Conversations with our designer made the problem clear. At the same time, the whole team was eager to try out a new framework, not just to improve the visuals, but to rethink the experience strategically. That’s how we landed on the idea of running a Sprint.

But hold on, this isn't the Agile sprint you might be thinking of. The Sprint we’re talking about is a totally different concept.

Wait, What is a Sprint?

You might’ve heard the word sprint in the context of Scrum. But the Sprint introduced by Jake Knapp in his book is something entirely different.

You build a prototype and gather real user feedback. The important of this methodology is all in just five focused days. This method is strict about focus. It even sets rules about limiting screen time, checking emails, and choosing snack-friendly foods to minimize distractions!

Here’s a quick comparison:

This sprint method was a perfect fit for the situation we were facing.

We needed to shift our target audience, which meant we couldn’t rely on A/B testing with our existing users. We also had to 'quickly' identify what kind of messaging would work, and more importantly, why. Most of all, the fact that we could run real experiments with almost no development resources, using just design-driven prototypes?

It wasn’t just a good match—this project and Sprint were made for each other.

Book Club, But Debate It Intense 💥

To prepare for our Sprint, we assembled an Avengers-level team and ran a six-week book club on Sprint. The book is structured clearly by day: Prep → Monday → Tuesday → Wednesday → Thursday → Friday. It was natural to read one chapter per week and bring it out for discussion.

Each one-hour session followed this flow:

1. One person gave a summary of that week’s chapter
2. Everyone shared the points that stood out to them
3. Then we jumped into a discussion based on topics we had prepared

These topics were key to making the study sessions meaningful. Rather than just sharing impressions, we pushed each other to think critically such as how does this apply to our team and product? The more controversial the topic, the hotter the debates got.

Here are two of the most intense discussions we had.

i) “If we can’t follow the rules perfectly, should we even try not to”

One of the biggest challenges of a Sprint is that it requires five full days of focus, and the decision-makers have to be fully involved. That’s a big challenge for most teams.

We discussed practical adjustments, like “Let’s go as no-code as possible since our developers are already overloaded.” But alongside that we voiced a real concern: that in trying to make the method fit our current reality, we might unintentionally reduce it to a superficial version that misses the point entirely.

Some raised sharp questions like, “The company encourages a study culture and expects performance like in the book, but doesn’t really create the environment to support it.” Others countered, “Isn’t it on us to create that environment, too?”

Throughout the study, we kept circling back to the same questions: What does it really mean to apply a methodology? How much can we bend the rules without losing the point? Where do we draw the line between adapting and compromising?

ii) “How important is appearance in a B2B product?”

The author emphasizes the importance of a product’s appearance, because it's often the very first touchpoint with potential customers. But BACKND is a B2B service, and our users are developers. In this context, visual polish often takes a back seat to more practical concerns like documentation quality, system reliability, incident response, and technical compatibility.

So, is appearance really as important for BACKND as the author suggests? What if our target shifts toward larger organizations; how might that change the expectations around design and presentation? And if we’re speaking to global customers, not just those in our captive marekt, what should “good appearance” even look like?

These questions led to some of our deepest discussions. Even one hour barely felt like enough.

“In B2B, functionality and reliability matter far more. As long as the visuals meet basic standards, that should be enough.”

“But even the most well-built feature is useless if no one knows it exists. The landing page is how you put it out into the world.”

We also dove into other questions, like: 1) Who exactly are we targeting? 2) What are the pros and cons of visual sketching as a way to communicate ideas? And 3) how do you convince your team to block out five full days?

Conversations like these helped us think beyond the book and reflect on what really fits our team.

We’re sharing some of the actual discussion topics we used.

Rather than just exchanging impressions, we focused on topics that invited critical thinking and multiple perspectives, more like a balanced debate than a book club.
If you base your study sessions on topics like these, your discussions will be much richer and more engaging.

1. Does appearance really matter? How important is visual polish in a technically-focused B2B service like BACKND?
2. The author’s obsession with productivity: how did that land with you? The author is deeply obsessed with optimizing productivity: testing whether coffee in the morning or tea in the afternoon yields better results, and tracking everything meticulously. This level of self-experimentation is probably what led to the creation of the Sprint framework in the first place. How did his mindset come across to you? Have you ever tried your own productivity routines or discovered an environment that really helped you get into deep focus?
3. 5 full days + decision-makers: is that realistic? The Sprint method assumes full-time participation from multiple team members, and decision-makers for five consecutive days (which can be a tough ask in many organizations). How might we adapt this ideal process to fit real-world constraints? Is there a way to stay true to the core benefits of Sprint without strictly following the book?
4. How do we define the target user? On Day 1 of the Sprint, you should clearly define your target. Blue Bottle focused on new customers, not their loyal ones. Savioke targeted hotel guests, not hotel managers. So when improving a landing page, who should your target be? Small teams vs. large teams? If large, who’s the key decision-maker? Domestic Vs. Global? And what happens when values clash between these groups?
5. Is sketching a fair way to express ideas? At Amazon, they have a principle of expressing ideas in 'written narrative form' rather than visuals. The reason is visual styles and skill levels vary widely from person to person, which can lead to unintended bias or confusion. But Sprint emphasizes sketching ideas. Could visual skill unfairly influence which idea gets chosen? What are the risks and benefits of sketch-based communication? How can we make sketching more inclusive? And as a reviewer, how do we stay fair when judging visuals?
6. Is a rapid-experiment culture right for our team? The same matter is emphasized by Sprint, Hacking Growth, and The Right. Agile testing with minimal resources. Sprint falls into the same category. Have you ever experienced a situation where this kind of fast, lightweight testing really paid off? If so, let’s share.
7. Interview vs. Data: what persuades you more? User interviews are a classic research method, but they’re often criticized for not representing the full user base.
   What do you see as the strengths and weaknesses of interviews vs. data-driven analysis? How can the two approaches complement each other? And which one feels more convincing to you personally?

Ready to step into the teal World! — now it’s time to act.

Through this study, we got to understand the logic behind the Sprint methodology as a Tool. We debated when it’s most effective, and what conditions need to be in place to make it work.
Now it’s time to close the book and step into the real world. Will this method work in our team, for our product? Can we really test customer response and make confident decisions, all in just five days?

Subscribe us for Part 2, where we share how it all played out in practice! 🙌

In the next post,
we’ll walk you through how we prepped for the real Sprint workshop, and share the intense but short five-day journey in full detail.

And here’s a little spoiler...

We uncovered a lot of unexpected insights! And honestly, it was kind of thrilling. 😉

© 2025 AFI, INC. All Rights Reserved. All Pictures cannot be copied without permission.