Hacker News new | ask | show | jobs
Give Notion the Superpowers of Google Sheets (notion2sheets.com)
31 points by leanzubrezki 1726 days ago
2 comments

This looks really cool, though I'm only half getting it. We use notion a bit, I spend a lot of time in Google sheets.

I'm a bit ashamed to admit, but I don't really understand how I would use this.

I've looked at your youtube channel, can I suggest you do a walkthrough with voice of your best customer use case and make it clear why this is of value?

I think you may be onto something, but I'm just missing that last bit of connection to make me go "I NEED THIS!!"

Also, your pricing is confusing. As someone who has run a company with confusing pricing before, this is a HUGE issue. You really need to simplify it. For our company, our costs were complicated and annoying because we had large service costs, (map data) and free accounts with tons of use could easily bankrupt us. Your cost structure shouldn't be challenging like that, so you should be able to simplify the pricing.

Things like 24 synced cells sounds incredibly small if I'm basically sharing my spreadsheet with notion. But maybe this is clearer when the user has a better idea of how they'd use your tool.

I always like pricing where I'm reluctant to pay, but feel I'll get so much value, that I don't really have a choice.

With your pricing at $15/month for 24 synced cells, I feel like I'm being asked to pay for a lot, and not getting much in return.

Thanks for the feedback, I really appreciate you taking the time to write.

I totally understand your comments around pricing, the product first started just being your databases in sync, then I added the chance of having Sheets to Notion connections with synced columns, later on recurring tasks to schedule page creations and just a couple of weeks ago synced cells and the ability to connect a cell value with a block in Notion.

Pricing is HARD and it definitely requires some iterations, it is something I struggled with. I started with the limit based approach, 3 databases for free with every one hour updates and then upgrade for more databases and 15 minutes updates. I continued with that line of pricing for the rest of the features but it is probably not the best, number of databases is straightforward but the same is probably not true for the rest of the features, will give that some thoughts.

How would you price those features? I have been thinking about just having the limits over the number of databases and making the rest unlimited for the paid plans.

Regarding content: YES, 100%, I am a software developer and I enjoy writing code and solving problems, the same is not true for content creation unfortunately. I think that in terms of features there isn't a lot more to do for now, so it is time to move into marketing mode and record some good Youtube videos using the different features and giving it a better explanation, I promise!

I'm also an SE, but with a background in marketing. At the same time, I find it difficult to switch gears. One thing I find can work is to set 1 day marketing only, no code, or other similar restrictions so that I focus on that.

Pricing isn't hard, but it can be hard.

I'd love to help you out, but because I don't understand the use case enough, I don't think I'd be a valuable resource.

I've used Notion databases, but didn't even realize what it was.

Do people join just one Notion database to one google sheet? Or is it multiple? Is it really about sharing data between the two? Is Notion the starting point? Or is Sheets the start?

Are you targeting people who want more power from Google sheets (sharing the data in a way that is more consumable), or do they in Notion, and find themselves copying data from Google sheets. It's a subtle difference, but an important one for marketing.

Again, this comes down to what is the best use case you can find to describe what people do. Do you have a trend that you have seen with how most users are using your product? As in, they have a forecast in sheets, and want to link that up with data about the products they're selling which they have in a notion database, as an example? Or they have their marketing plan in Notion, and the tracking data in google sheets, and they want a way to display them all together?

This sort of thing should help you tell a clearer story for people like me that "almost" get it, but not quite.

Once you know those details, that can help you understand the customer user, and how many databases/sheets the customer may have. That helps you segment who you are targeting, what they care about, and what they understand so you can appeal to their pricing needs.

Does that make sense?

Notion is the starting point, having your data in Sheets opens possibilities of integrations that you cannot do with just Notion, so to answer the question, people that want more power from Google Sheets.

The most common user story is:

1) User uses Notion for personal use or is part of a business or organization workspace.

2) Already has databases in the workspace for different purposes, projects, tasks, leads, expenses, backlog, sprints, HR candidates, employees, etc. Notion has a list of customers and use cases that it is quite insightful here -> https://www.notion.so/customers

3) Now the journey separates in different stories:

  - Have a copy of Notion databases as backup.

  - Use Notion databases data as input to other services, and uses Sheets as the middle men.

  - Do business intelligence from Notion databases, you can use Google Data Studio for example.

  - Have charts from their Notion databases and embed them back in Notion.

  - Show summarized information and statistics from Notion databases in a page.

  - Share data from a database without giving access or sharing the entire database or page.

  - Get third party data into Sheets and then from there to Notion.

  - Use Sheets formulas that are not available in Notion, like GOOGLEFINANCE, IMPORTXML to scrape data, etc and have that data available in Notion.
So most of the time if not all, is having Google Sheets as a middle point to then enable the usage of not only Sheets features, but also all the integrations that are built around it. The value of Notion2Sheets is unlocking that.

Something to keep in mind, there are 2 hard limits:

  Sheets -> 100 request in 100 seconds per user.

  Notion -> 3 request in 1 second per workspace.
This is so cool! I wonder how their service resolve conflicts to sync changes back into Notion.
Thanks for the question!

When you sync a database, by default the connection will be Notion -> Sheets. Then you can make specific columns Sheets -> Notion, but not both ways the same column.

The idea is to enable a much bigger set of formulas and calculations that are not possible or really complicated in Notion so you can make them in Google Sheets and those values will be then sent to Notion, for example you can use GOOGLEFINANCE, IMPORTXML formulas or even mix and match different databases without the need of relations and roll ups.

Similar to how you define a formula property in Notion now but done in Sheets.

If you have a formula in a column in Sheets, you don't want it to get overwritten by a manual change in Notion . I am doing some testing with 2 way sync but with the current Notion API and change mechanisms in Sheets it is not straightforward to have something that just works for all the cases

What changes could Notion make to the API to make two-way syncing easy or even obvious?
It is a mix between Sheets and Notion.

From Notion side webhooks could help, getting notified when a page in a database changed so we can update Sheets right on time. If that notification tells which properties changed even better. Moreover that will let us offer real time updates.

From Sheets side, I have tried with the different triggers that Apps Script provides and they are not 100% reliable in how they get executed and the parameters you get. There are some bugs opened in Google issue tracker waiting to be fixed that should address some of the problems, but I don't have a lot of hope as they have been opened for years.