2022 W46 - Pushing the Limits

Humberto

Rows is now "Building in Public". Every week I'll post about one thing that happened! The previous post was on Making the most the WebSummit.

---

This past week we increased the Platform Limits of Rows in two of our most popular features.

Every product has limits.

And limits tend to clash with what the Power User wants.

On Monday a customer asked us to increase the number of rules in Conditional Formatting, previously capped at 10 per page. His spreadsheet has a particular table displaying 12 months in separate ranges. He needed 2 conditions per month for a total of 24 rules.

After a brief consideration we increased the limits of that feature. We also increased the limit for another feature for which we'd received another request the week before.

News:

You can now add up to 25 Conditional Formatting rules per Table, up from 10.
Every Dropdown can now support up to 10k (ten thousand) options or values referenced by a range, up from 2k.

This was a good improvement. We immediately got feedback from the customer that requested the change.

A feel good email from a customer following the upgrade in the limits of the dropdown

This update follows 3 other platform limit improvements in the last quarter:

Increasing the maximum size of Tables, from 20k → 100k rows and 100 → 400 columns.
Raising the limit of stored data per Cell, from 200KB → 2MB, which is super useful for API payloads.
More importantly, increasing the number of Tables you can stack on a spreadsheet page, from 5 → 10.

I can see a pattern in how we deal with Limits at Rows.

1. It makes sense to have limits

Building a spreadsheet is hard, and you obviously don't want it to fail. So, to launch a new feature, we test it and set a limit that is adequate to it. That results in several Platform Limits.

2. Limits get old fast, and for different reasons

We don't stand still. Weekly we launch features and make improvements in quality and speed. This opens the opportunity to increase limits.

Meanwhile, we continuously measure SLAs. In fact, we look at metrics daily. So we have a view into what we could do, yet we don't always proactively increase the limits when the technical capacity.

On top of this, users keep have better ideas about new spreadsheets to build. That frequently means more power, and bumping limits is needed there.

There's also business considerations. Some of the limits will be triggers to upgrade accounts from free tiers to paid ones. This means that some of the discussions on limits need to include business deciders.

Finally, it is a proxy for product-market fit. For every customer asking for an increase in feature X there's a person (or team) of people using Rows actively in their day-to-day.

3. Our process is currently reactive!

When an important user hits the limit and reaches out, we take a look.

Generally, requests will be analyzed in the next Quarter Planning, because something seemingly as simple as changing a limit might end up being a big change in a cloud service. There's simply too many requests competing for attention and time.

Sometimes we suggest the task of improving limits directly to the team and they get on with it fast. This was the case last week! (Our team is super. Thanks team!! 🤗).

4. For the future - watch those curves!

As an organization, we have been moving towards measuring these types of limits. Knowing how many Spreadsheets and Users are hitting each limit relative to those which aren't is important to know the impact.

Already over the last quarter we studied how many spreadsheets were hitting the limits of Tables per Page, and we measured it immediately after. We knew there were thousands of spreadsheets already at the max (thousands). After we raised the ceiling, we saw a couple hundred spreadsheets using that newly available power!

40% of spreadsheets have more 2 or more Tables per Page

And that's a short story on product limits.

See you next week!