Article’s core thesis: Software that sits between two existing systems and collapses time-to-value from hours to seconds wins. Any line you read in the article should be acted upon only after considering the fact that time to value is the primary metric that we should work on.
I recently wrote an article titled “Translators 2.0” where my point is that you need to have low time-to-value and provide that value as quickly as possible. I give an example of an Excel plugin where you just click a single shortcut and you get all the Excel formula dependencies. That was huge for us at PWC.
Okay, so you’ve got the premise that value should be easily accessible and it should be quick as fuck.
Then I investigated the nature of these types of things, and the idea there was that software’s that act as translators can do a lot for us. Software’s within their own boundaries do very well, but there is a gap left between one system and another, communication between one software and another, communication between software and a human. These things are where quality suffers, where the user suffers.
And this is where translators can emerge. The Excel plugin I talked about before basically translates whatever Excel complexity was there and shows it to a user, telling them how it works. It translates that complexity into simplicity.
Then there can be data translators like, for example, you are using some form application and you need to load that data into your CRM. You can do it manually or you can use a translator that does it for you, and you can see the value emerge real-time.Another glaze I had for this idea was that since we are being translators, that means we are sitting between two things that already exist and have traction. If you are creating an Excel plugin, then that means you are sitting between humans who use it a lot and between Excel which, of course, has a lot of traction. Or you are translating between a CRM software and a form application. Both of them have a user base and that means they have experienced the troubles. It’s a very narrowed-down market, so ICP formation is also easier.
Basically, having a translator as the main idea reduces a lot of work.It tells you where to look and the next step naturally becomes to go out there and pick a software which you want to translate for, because the translation either happens software-to-human or software-to-software.Or, of course, it can happen from human to software, but I think it would have a lot of edge cases, so I don’t know.
Yeah, you gotta pick a software. The conditions for software should be:
- It should have a user base that is big enough
- The software should be kind of stable and not trying to appease any user base (it should have incentive to be a generalized platform like Excel has the responsibility to be a spreadsheet app, not a hyper-specialized formula audit application for valuation analysts)
- It should be a product that is helping winners win, and our plug-in helps winners win even faster and easier.
- And people are willing to put money into that software.
An example of this can be After Effects, where the software is used by people to create high-quality media products. Since that area entails a lot of possibilities, After Effects cannot possibly serve every feature demand, so there is a thriving market for plugins. Since editors themselves make a lot of money or creative agencies make a lot of money, they are okay with spending some money on plugins. Also, of course, After Effects has a huge user base.
Once you have selected a software, I want you to scour each and every post or piece of discourse you can find about it online (especially anything that has anything to do with developer tools).
Go check Reddit, go check Twitter. Go check any public forums, go check anything that I’m missing out on here.
You will see people complaining about a lot of things. You have to size up the problems and understand which one might have a huge user base behind it. Then you have to analyze if these guys would pay after you have a few competitors. You have to evaluate which one to serve.
I’ll talk more about that Excel plugin because I think it was genuinely something incredible.
Excel has its primary unit as a cell, and the value it generates is because of the interaction between cells. Of course, there are going to be some users who are very complicated use cases, and they would have a lot of complicated interaction between cells. The normal tools that are baked into Excel are not able to show it without confusing the user.
So, to check a complicated formula, you would have to invest a lot more time than to check a normal formula. So like time to value was a lot higher. But this plugin collapsed it into a single instant.
I think that is a core component of what makes a translator really good that it detects something that is taking a lot of time to value and collapses it into an instant.
to quote claude “Your Excel plugin wasn’t just “showing dependencies” – it was collapsing 30+ minutes of manual tracing into 1 second. That’s a 1,800x time collapse.”
And all of this shall happen w no to low setup and minimal external information needed, basically something seld sufficient
Claude Reaction:
The Research Protocol
Here’s how I’d actually execute this:
1. Platform Selection First
Pick software that passes your filters:
- Large, stable user base
- Generalized platform (won’t build your solution themselves)
- Used by people/companies with budget
- High-stakes workflows (winners winning)
Let’s say you pick Figma as an example. Now the real work starts.
2. Discourse Mapping (where to look)
Reddit:
- r/FigmaDesign
- r/webdev (Figma complaints in context)
- r/frontend
- r/UI_Design
- Search:
site:reddit.com figma "I wish" OR "annoying" OR "tedious" OR "manually"
Twitter/X:
- Search:
figma (pain OR annoying OR tedious OR "wish it" OR "why doesn't") -filter:replies - Follow hashtags: #figma #figmadesign #productdesign
- Monitor complaints from design influencers (they surface widespread pain)
Public Forums:
- Figma Community Forum (official)
- Designer News
- Hacker News:
site:news.ycombinator.com figma - IndieHackers (people building Figma tools)
Other Sources:
- YouTube comments on Figma tutorials (people ask “how do I…” when stuck)
- Product Hunt (existing Figma tools—see what’s getting traction)
- GitHub Issues on popular Figma plugins
- Slack/Discord communities (DesignerHangout, etc.)
- Figma plugin marketplace reviews (complaints = opportunities)
3. The Analysis Framework
When you find complaints, categorize them:
A. Frequency Signal
- How many unique people mention this?
- Is it recent or old? (Old + persistent = real pain)
- Does it appear across multiple platforms?
B. Intensity Signal
- “This is annoying” vs “This costs me 3 hours every week”
- Do people describe workarounds? (Complexity of workaround = intensity of pain)
- Are they asking for solutions or just venting?
C. Willingness to Pay Signal
- Are these complaints from freelancers or agencies/companies?
- Do people mention budget in the context? (“We’d pay for…”)
- Are existing paid solutions getting mentioned positively?
D. Competitive Landscape
- Does a solution already exist?
- If yes, what are people complaining about in that solution?
- Can you do it 10x faster/simpler? (Your “low time-to-value” principle)
4. The Sizing Question
This is the hardest part. You need to estimate:
Total addressable pain:
- How many people use the software? (Figma = millions)
- What % hit this specific problem? (Need to estimate)
- How often? (Daily pain > monthly pain)
Example math:
- Figma has ~4M users
- Let’s say 10% are in agencies/companies (400K)
- If 5% of those hit your specific pain point weekly (20K)
- And 10% would pay $20/month (2K potential customers)
- TAM = $40K MRR = $480K ARR
Reality check: Are there already competitors? If yes, how many users do they have? (Check their reviews, social media followers, any public metrics)
5. The “Would They Pay?” Test
Before building anything, you need proof:
Signals that people will pay:
- “I would pay for this” comments
- Existing paid tools in adjacent space are successful
- The pain costs more than your price (time = money)
- Companies/agencies complaining (not hobbyists)
Red flags:
- Only students/hobbyists complaining
- Workaround takes 30 seconds
- Feature requests directed at main platform (they might just build it)
- Pain is in learning curve, not recurring workflow
6. Competitive Analysis
Find existing solutions:
- Search:
figma to [whatever] tool - Figma plugin marketplace
- Product Hunt:
figma - Google:
figma [pain point] solution