You Built It. Nobody Used It. Here's Why.
When you have an idea for building a new product, what comes to your mind first? In most cases, new products arise because founders want to solve existing problems and make life easier — whether that's with tools, automation, or anything else you can name.
But what is the "actual" problem? And what makes you think people really need your product? Creating a good product should be based on something that potential customers really need. Today, let's learn about a framework called Jobs to Be Done, developed by Clayton Christensen and Bob Moesta, to help you figure out the best approach to creating a product that people really need.
Let's imagine a developer named Mr. Kagama. One Sunday morning, he decided he wanted to add a new feature to his mobile app. His application helps people read more e-books and audiobooks, and he has run it for one year. He decided to add AI agents that could help users find what to read next based on their interests, and that could summarize a book. Mr. Kagama added this feature because he thought it would attract more users and make his existing ones happy. He spent three months developing it. Once it was done, five months went by with no significant change in user behaviour, and the feature wasn't used by even 20% of his users. The conclusion? The feature failed, and time and money were spent on a failure.
So why did this happen to Mr. Kagama? It comes down to how he identified his users' needs before deciding anything. The Jobs to Be Done framework helps you understand why users want to buy your product, so you don't have to waste time guessing at the possibilities. Instead, it helps you weigh those possibilities the right way.
What is the JTBD Framework?
You're reading this article right now on your phone, so ask yourself: why did you buy that phone? Maybe you bought it to take good pictures with your friends, listen to your favorite album, chat with family and friends, or track your steps every day. Those are the "jobs" of your phone, and if it does those jobs well, as you expected, the product is a success. That's how the JTBD framework helps you understand the decisions people make about your product.
Take a look at the timeline above. It maps out the journey a person goes through whenever they decide to buy something — the process of making progress, step by step.
It begins with the First Thought: the moment the idea of a change first pops into someone's head ("maybe there's a better way to do this"). From there they drift into Passive Looking, where they're not actively searching yet, but they start noticing options around them. Something then pushes them into Active Looking, where they research and compare seriously (that's the stick figure with the binoculars). Next is Deciding, the confusing part where they weigh everything and finally make a choice. That's the "???" moment. After that comes Consuming, where they actually use the product, and finally Satisfaction, where they find out whether the product did the "job" they hired it for.
Along the way you'll see Events (Event 1, Event 2, and the Buying moment itself). These are the key triggers that push a person from one stage to the next, including the moment they finally hand over their money.
Notice the two big arrows, too. "Going in" is the momentum that carries a person forward toward the purchase. "Looking back & satisfaction" is what happens afterward: once they've experienced the product, they look back and judge whether it truly solved their problem.
This entire timeline is what JTBD helps you understand. Mr. Kagama's mistake was jumping straight to building, without ever asking where his users were on this timeline or what "job" they were really trying to get done.
Back to Mr. Kagama. Once he realized his new feature had failed, he didn't want to waste more time or money on the same result. He learned JTBD and started asking his existing users, "Do you need a feature like AI agents to summarize your e-books?" It turned out that the majority of his users didn't need that feature, but he also discovered that more than half of the people he surveyed wanted different voice options for the audiobook version. He understood the real demand, and he updated the feature with confidence. The result? People actually started using it — especially the deep, cinematic narrator voice, which became everyone's favorite.
Now, before we decide anything for our product, let's make sure we apply this framework to help us identify what our customers are really trying to get done: the real "job" they're hiring our product for. When you build around that, you're no longer guessing. You're building something people genuinely need.
