JTBD analysis: switching from VS Code to Cursor
Last week, I explored the journey of a developer (Sam) who switched from VS Code to Cursor using journey mapping, a useful technique for revealing key touchpoints users go through before adopting a product. In this article, I take a deeper look into Sam’s decision to adopt Cursor through a jobs to be done switch analysis.
IDEs are deeply ingrained in a developer’s workflow, making them difficult to replace once they are setup. Relearning a new tool is a significant time investment, which is why understanding the motivations behind this switch is important.
TL;DR
What surprised me about Sam is that the decision to adopt Cursor was not pain-driven. In fact, there was no issue with his VS Code workflow. The switch was triggered by an ML influencer on Linkedin and the fear of falling behind in productivity. When there is no clear problem or pain for developers, influencers can create demand through FOMO. This also applies to influencing developers who are not early adopters.
When Sam saw that Cursor was the same exact copy of VS Code, meaning the learning curve was essentially zero, the switch became a no-brainer. If Cursor had not been the same as VS Code, Sam would not have switched.
Contrary to my expectations, Sam didn’t dive into the AI features right away. He first imported his VS code configurations, and simply just wanted to continue coding to see if the transition would be seamless.
Shortly after, he encountered a usability issue where he couldn’t right-click to jump to a class definition, a feature he was accustomed to in VS Code. This almost made him abandon the tool. That’s why usability testing key tasks is so important for frequently used dev tools like an IDE.
Part I: What is the JTBD switch framework?
The jobs to be done switch framework helps us understand why users switch from one product to another. It does so by identifying the underlying task or job that they need to accomplish and the forces that influence this behavioral change.
push: the pain of their current situation that triggers them to look for a solution.
pull: the benefits of using the new solution (e.g how life would be better).
anxiety: concerns and questions that prevent adoption.
inertia: resistance or hesitation in switching to the new solution (e.g habit).
The decision to switch happens when the push (pain of current situation) and the pull (benefits of the new solution) outweigh the switching costs. If we want to acquire and activate more users, we need to amplify the push and pull forces while addressing or reducing the switching costs.
Part II: Applying the framework to Sam
Push: fear of falling behind in productivity
Sam didn’t have any frustrations with VS Code. The push wasn’t about a specific problem with his IDE, but rather a fear of falling behind. AI advancements created an underlying pressure for him to want to keep pace and stay competitive. He described that developers will become more like ‘AI orchestrators.’ Sam felt that Cursor could position him for greater productivity and career security.
“You don't want to miss the train. If everyone else is using it and you aren't, it's bad for you. You can see what people are able to do with code generation these days. If you do things only by yourself, you are two, five, or ten times less productive.”
Pull: Cursor is the same as VS Code, but smarter
Sam could not emphasize enough that what drew him to Cursor was that it was the same as VS Code, meaning he didn’t need to learn a new tool. In fact, he didn’t even realize this benefit until after installation. This shows that the pain of switching IDEs is high for developers.
“I felt happy discovering the IDE was exactly VS Code, like wow I don't have to learn a new tool. It’s boring changing IDEs.”
He also found that using Cursor was better than copy and pasting from ChatGPT and that it automated mundane tasks like refactoring and renaming variables. It became worth switching when Sam saw that Cursor saved time, offered better code quality, and a sense of security knowing he (probably) won’t fall behind peers who are also using it.
If he had to describe Cursor to his peers, he would say:
“It's cool, if you're using VS Code, just try it because it will be a smarter copy of it.”
Inertia: Comfort of using VS Code
The habit of using VS Code was a strong barrier, but it wasn’t an issue because Cursor is essentially the same. The transition was seamless, as all he had to do was import his VS Code configurations. For many other dev tools, the learning curve is a constant challenge to adoption.
Anxiety: Usability and privacy concerns
Sam quickly encountered an issue where he was not able to right click to jump to class declarations, a feature he was accustomed to in VS Code. For a moment, he considered abandoning Cursor altogether. This highlights how seemingly 'small' issues can cause significant frustration in IDEs, potentially leading to churn.
“I was working on something and wanted to check a class definition and I couldn't. Simple things like that are really important. I would have dropped it if I couldn't figure out.”
Cursor addressed another barrier to adoption by giving Sam the option to disable AI training early in the onboarding. This proactive approach helped ease concerns about data privacy and control. Offering this choice reassured Sam, making the switch to Cursor smoother. This is a great example of how identifying and addressing user concerns upfront can help overcome potential adoption barriers.
Usability concerns, especially early on, can become the reason developers return to their old tools. Cursor overcame these hurdles because the overall promise of productivity and familiarity was strong enough to outweigh the initial anxiety.
Usability testing is the best way to uncover onboarding issues, allowing companies to address them early in the user journey.
Part III: Applying the learnings to marketing, growth and product
Since Sam was driven by the fear of falling behind, it’s possible that he might have switched to Cursor earlier had he seen how productive other developers were with it. It might be worth looking into creating awareness around hidden inefficiencies, showing developers that they might not be as productive as they think with VS Code or similar tools.
Integrating Cursor more visibly into developers' workflows when copying and pasting code from ChatGPT could be another strategic entry point. Find places where developers would go during this workflow. Learn what help they may need and be that source of help.
He also didn’t realize that Cursor is the same as VS Code until after installation. A low friction sandbox environment where developers can test Cursor without commitment could also help.
In theory, if Cursor highlighted its productivity benefits, demonstrated real workflows in action, and emphasized the minimal learning curve, Sam might have adopted it sooner.
I would recommend conducting usability tests on key tasks for developers who are new to your product to identify any onboarding issues.
Thanks for reading! 🧡
This is a great post Shili! I didn't know cursor worked for the most part like VS Code, I have to try it out.
For code generation i've basically been copy/pasting from the LLM output to VS Code. I've found that copilot doesn't give me as good quality code (though I do like that it integrates with the files).
Also ++ on the privacy concerns. When using cloud based LLMs I always go to the configuration page and turn off any of the options that could make my data public. So making it part of the onboarding process makes a ton of sense. I feel like that should be up front and center from the start of the user journey.