Show HN: Two-way Jira sync in a collaborative spreadsheet and Gantt (visor.us)
Our startup nearly died 2 years ago. We kept losing customers to spreadsheets. And it made us see a problem right under our nose: everyone just wanted flexibility & speed from a spreadsheet. But they have to stay in sync with {Jira / Salesforce / insert SaaS app}.
When we followed this thread, we discovered how broken the integration experience was for flexible products like Airtable, Smartsheet, Monday, and Google Sheets. Their big problem is that they transform external data into their own format. This makes setup harder, since you have to get the mapping just right. And often you can’t sync back.
We took a different path when building Visor. We essentially made a data lake & ETL tool with a front-end. Visor integrates with your Jira instance, reads its schema, helps you import the right data, and lets you work in a flexible spreadsheet* that syncs both ways. There’s also an interactive Gantt & Timeline view.
*Spreadsheet is a generous term for now. Formulas are still on the roadmap. As are many true “spreadsheet” features. But we’re working towards it.
Our roadmap is public, here: https://support.visor.us/visor-roadmap
And for VueJS devs, we eked out more performance from Vue 2 by modifying the core, documented here: https://www.reddit.com/r/vuejs/comments/u6tzv8/how_we_resolv...
For database geeks, you might enjoy learning about the realtime graph DB we built to power the product: https://blog.visor.us/cloudstore-part-1/
I’ve seen so many great companies start out by launching on HN. It’s quite a special personal moment finally to be sharing with you all.
I’m happy to answer questions, take criticism, and generally hear what you think.
56 comments
[ 3.1 ms ] story [ 107 ms ] threadI can see how it'd speed up dev time for my team, I'd be curious to hear how something like that (reactive no-sql frontend for a SQL DB) would work for others outside of Vue.
We haven't really tried CloudStore + other frameworks. That would be a fun experiment to try next. :)
The original reasons people needed to move those spreadsheets into tools like Jira still exist.
I'm glad to see a product like this acknowledge that people want both:
a) The flexibility/speed of navigating spreadsheets
b) Centralizing that data for consumption by other people participating in the overall process
Jira and similar products seem to assume people moved away from spreadsheet because spreadsheets suck. This is not the whole story.
I think this also highlights the major gap in good reporting functionality in these tools. If they made the data easier to work with in-product, the export would be unnecessary. But such a reporting tool would need to be as flexible as Excel.
It seems that no reporting tool is ever flexible enough to do that -- add custom columns to annotate, filter, and contextualize the report. Raw data is rarely "clean" enough and explanatory enough to just be exported into something for external consumption -- either via an exec or even externally to a different company (partner, client, etc.)
Oh absolutely! That ability to “extend” Jira without the overhead usually associated with doing so is definitely the part that caught my eye.
These guys solve the problem where Jira is either positioned facing up (clean) or facing down (messy details) and doing your own translation is usually a complex time consuming and error prone API effort in comparison to live spreadsheet data you can produce (down) or consume (up) any way you like. Similar workflows on Make/Integromat or Zapier also help re-orienting the use case direction if you are allowed to connect them.
One emergent use case is that teams who can’t get all the fields they need added to Jira end up going around it to do their work. (The qa team, for example, may not have leverage to get a whole bunch of checkboxes added that reflect their process). Spreadsheets then become a place where their work happens, and Jira becomes the place they keep up to date to “communicate” with others.
But then the people actually working day-to-day need flexibility. So they end up creating extra spreadsheets off on the side where they work, but those get out-of-date.
During broad pre-build research (even beyond Jira), we found that spreadsheets consistently shadowed the real data in SaaS apps -- ranging from Jira to HR software and everything in between.
It's like taking the concept of materialized views in databases and applying it to all of life's little data pools. The data is what matters, and Jira is a tool for materializing in a certain way. But often, it's just as important to allow to be materialized and managed in a completely different way (spreadsheet views).
I love this and am going to pitch it hard to our product team. Thank you!
So anything that lets me use the Jira data that I'm forced to create, but in effective ways outside of Jira, is a win.
The challenge is that many people working as part of bigger teams can't pick their own tools or really make a change unilaterally. So they need a way to make things work for them as part of a bigger structure.
Similar argument with open sourcing your product. Couldn't your competitors look at your code? Sure they could, but if that's how they're trying to compete, they're going to lose. Plus, their engineers will probably look at your code and think they can do better anyway ;-)
We are a lot more concerned with making customers feel like part of the company’s growth than worrying about competitors.
Our customers love seeing the roadmap. And we are lucky to have an engineering team that really does deliver what’s promised. So we like to show that (hence the public release notes that connect to items on the roadmap).
This gives customers confidence that we really will deliver what we say we will, and they can plan their adoption of the product around it.
The community also really loves seeing their own suggestions make it into the roadmap. The way I see it, we’re all building this together.
At the end of the day, it’s not the best product that will always win. It comes down to community.
On the other hand this is a cursed development methodology. There's an infinite mine of No True Scotsmans about Agile, but really, when you find yourself putting your Agile stories in a Gantt chart and projecting sprints several months out, you are unambiguously rejecting substantive principle and content of Agile as a methodology. At this point it would be much more productive to admit that you're doing waterfall and put some effort into doing it well, instead of farting around with backlog grooming, sprint planning, etc. where the outcomes are all committed before the meeting in a master schedule.
It does seem there are a lot of methodologies being used with the product. And agilefall does seem to be making a comeback. But a fair number just use it as a faster way to plan the sprints and run standup. (Vs in Jira)
The thing about “spreadsheets” is that they seem to be flexible enough to fit all the idiosyncrasies of how different teams work, regardless of methodology. I hope the product can save you time, frustration, and copy/paste drama.
I wouldn’t encourage anyone to buy a tool just to make a single type of chart, even less if it is a for-pay SaaS wedge.
Spreadsheets are over-used and I’m not sure meeting users where they are works in this case. Hasn’t paid off (in my experience) with anything more than additional layers.