Story of the week 49

The Glory of the Solution and the Courage to Ask Questions

This week began with one of those conversations that stays with you longer than you initially expect. I was on the phone with an agility expert—someone who has been helping teams for years, not just build good products, but build them right.

We talked about my plans for the coming year. About ideas, about energy, about opportunities. And, of course, about the new app I want to develop for iOS in 2026: Freeletics for table tennis players—training plans, videos, workouts. A kind of personal coach for recreational and club play. I was enthusiastically talking about it. And then came the sentence that stopped everything.

You speak very clearly about your solution. But what problem does your app actually solve?

Silence. My initial reaction was to laugh, thinking, “Well, that's obvious.” But deep down, I realized: I don't have a precise answer.

A brief jump back: Early 2025

This thought took me back to the beginning of the year. That's when I was first introduced to the basic idea for a table tennis app. I was initially sceptical, not because of the sport itself, but because the market for sports apps is already saturated. However, the team that was forming for this project convinced me. We clarified the collaboration and defined a Freeletics-style table tennis offering as our benchmark: structured training plans with videos, a motivating user experience, and clear instructions for amateur and club players. It felt like a promising approach. And yet, back then, we didn't ask ourselves what specific problem we wanted to solve. Because we assumed we knew.

Back to the present

Back in November 2025, the agility expert's question began to resonate within me. I had to admit that we had fallen in love with the solution without truly understanding the underlying problem. To gain more clarity, I picked up a book that was on my reading pile: Inspired by Marty Cagan. The very first pages made it clear that we had made the typical mistake – starting not in the problem space, but in the solution space. Great.

The Team, the Insight, and a PDF

With this realization, I called the team together and outlined the challenge. We had to acknowledge that mockups and technical implementation steps weren't getting us anywhere at the moment. What we needed was a vision, a clear problem definition, and, above all, the willingness to test our assumptions. The parallels to Freeletics helped us enormously because their success didn't begin with an app, but with a simple PDF. A low-threshold prototype that showed whether people could even work with the concept.

That's precisely what our next step will be: We'll create a PDF that reflects our hypothesis and test it with the target group. If it works, we can build on it. If not, we'll learn and adjust our direction. It now seems likely to me that we'll go through several iterations, and precisely the right thing to do.

Conclusion

This week has once again shown me what good teamwork can look like: open, willing to learn, and courageous enough to question our assumptions. And my personal takeaway is clearer than ever: As a developer, it's not enough to continuously deliver software. It's about continuously discovering the product. This principle forms the very core of agile work. And perhaps it really did take a decade for me to understand it to this extent.