I was wondering if I could have a personal app to organize my activities and track the time I’ve spent on each of them. I began thinking about how it would be, and as time passed, I attempted to add more new features to this program.
I was excited, until I realized I had no idea why I was building it. Many developers fall into the trap of adding cool-sounding features without verifying the real need. I did the same, but fortunately I paused to apply the Jobs to be Done (JTBD) framework. That one question – “what job is a user hiring this feature to do?” – changed everything.
In this post, I’ll share the decision-making journey that saved me weeks of wasted work by focusing on the user’s actual job rather than just adding another checkbox.
The Jobs to be Done Mindset
“Customers don’t buy products — they hire them to solve problems.”
The Jobs to be Done framework starts with a simple shift: people buy products to make progress on a goal, not to collect features. As legendary marketer Theodore Levitt put it, “People don’t want to buy a quarter‑inch drill. They want a quarter‑inch hole!”. In other words, the job (making a hole) is the fundamental unit of analysis, not the user’s demographics. Applying JTBD means uncovering the core goal behind a feature request. Instead of asking “who wants this?”, we ask “what is the user really trying to accomplish?”
By clarifying the true job, we avoid building anything that doesn’t advance it. This approach was originally championed by Clayton Christensen and refined by Tony Ulwick’s Outcome-Driven Innovation, which emphasizes quantifying and prioritizing real customer needs. As Ulwick notes, if a proposed product or feature “does not get the core job done better and/or more cheaply, then the next two efforts are a waste of time.”.
Understanding JTBD changed my perspective: features aren’t valuable on their own — only if they help users get a job done. With that in mind, I took a step back from my impulse to code and tried to see through the user’s eyes.
My Close Call with Feature Creep
Working on my latest personal project, I had a brainwave: adding an advanced analytics dashboard could impress people when I put the project on my GitHub profile. It was technically ambitious and I had the skills to build it, so I almost jumped into development. Then I remembered why I wanted to create it! The Jobs to be Done principle says: “It is tempting to say ‘yes’ to every stakeholder priority, but this sets a precedent for adding ‘just one more feature’.”. I realized I’d slipped into saying “yes” to the stakeholder (myself) without evidence.
Instead of coding first, I asked myself: what job is this dashboard meant to do for the user? I tried to remember the NEED moment. I discovered its real job was making quick decisions from data, not poring over charts. My fancy feature would not help me get my core job done better or faster. It would just add complexity.
At that point, I chose not to build the dashboard as originally planned. By focusing on the job – streamlining decision-making – I realized a simple summary widget (instead of a full dashboard) would serve me better. In practice, this meant I saved days of work on a feature that, in retrospect, would have been useless.
Applying the Jobs to be Done Framework: Steps I Took
Putting the JTBD framework into action involved a few key steps:
- Identify the User’s Job: frame the problem as a job story. Instead of “add feature X,” ask, “When [situation], I want [motivation], so I can [desired outcome].” This shifts focus to the context and goal.
- Validate User Motivation: Talk with actual users and watch how they use the product, or sit and write down what exactly you need if you are the user. By digging into why they/you did things, uncover the real motivation behind their/your actions.
- Question the Assumptions: Test every idea against the job. If a feature doesn’t clearly help achieve the job, it is reconsidered. I asked, “Will this truly solve my problem, or is it just a distraction?”
- Prioritize the Core Job: Align discussions around the one core job you have identified. As strategists note, defining and addressing the core functional job ensures all efforts build on that foundation. Ulwick’s insight helps here: it reminds you to invest in features that address unmet needs before anything is built.
- Lean on Evidence, Not Hype: Resisted even tech hype. It’s easy to chase trending solutions, especially in hot fields like AI. As one AI expert puts it, AI is “exciting, powerful, and game-changing”, but without a clear job, any AI feature risks being just window dressing. Make sure to tie every idea back to a user’s job, not to buzzwords.
Key Takeaways
- Start with the Job, Not the Solution: Always ask “what job is the user hiring this for?” before writing code. The job, not the feature, is the goal.
- Use Job Stories: Frame requirements as When [situation], I want [motivation], so I can [outcome]. This keeps you grounded in user needs rather than neat technical ideas.
- Validate Early: Talk to users or use any data to confirm their actual goal. Don’t rely on assumptions or say “yes” to every feature request.
- Avoid “Feature Creep”: Saying yes to every idea sets a dangerous precedent. As Brian de Haaff warns, doing so leads to endless “just one more feature” additions. Instead, use a strategy to keep focus on what truly matters.
- Build Only What Matters: If a planned feature doesn’t clearly improve the core job, stop and rethink. Pursuing anything else is likely wasted effort. For example, teams often treat a product as an “impulse buy” and pile on flashy features without any idea of the impact. Jobs to be Done forces us to avoid that trap.
- Connect to Bigger Trends: Even when exploring hot technologies (like AI), tie everything back to the job. Remember that AI may be “exciting”, but it still needs a why. Use JTBD to turn tech possibilities into genuine user value.
By thinking in terms of jobs rather than features, I not only saved myself from building something useless, but I also strengthened the link between technology and strategy. The JTBD mindset is now part of my toolkit for every project.
As I stressed in my earlier writing on why AI is important, it all begins with why. JTBD provides that why — ensuring that what we build truly answers a human need, not just a technical itch.
I’m Reza Ghaderipour, and I share my insights about Technology and Strategy.
Let’s talk!
Sources: Real-world JTBD frameworks and expert insights informed this process, helping bridge the gap between strategy and practical product development.
