2022 W40 - Discussing Rows mistakes
This post is the first of a new series on how're building Rows. As co-founder and CEO of Rows.com, I will be posting on a weekly basis on something that happened the previous 7 days.
Last week we had a small workshop with our senior team, including managers and team leads. "How can we make this company better?" was our topic. In a certain moment of the meeting, we discussed mistakes that could have cost us the company.
---
The mistakes we made.
We have taken many wrong turns in the pursuit of the ultimate spreadsheet platform. There were 4 of the largest:
Not investing enough in UX since the beginning.
Misunderstanding what it takes to succeed in the context of Integrations and Data.
Putting too much energy into Automations from day 1.
Misunderstanding the role of platforms in the success of a product-led approach.
Let's unbox them.
UX
We clearly did not invest enough in UX since the beginning. Our thinking was: "well, we're going to build a spreadsheet, and there's a massive technical effort in that, so why add designers now? Let's add them after we built some core experience."
It is true that most of the UX decisions came later and did not interact with most of the assumption on building a spreadsheet: we were always going to build a computation engine based off spreadsheets, and we were always going to need a grid. We also interviewed potential users to find use cases, and that provided good context.
But we also need to deeply understand the needs of those users in terms of their actual, daily workflows. While the under-investment into UX applies transversely, a particular job of our users would have benefited clearly from more UX research from the start was Integrations and Data.
Integrations and Data.
Our vision of the future of spreadsheets involves business people having access to Data from their SaaS and even private APIs. Starting Rows, I thought we would build these Integrations, and then users would flock to us.
I was very wrong. The access to Data isn't as important as the experience of Data.
The way we understand it now, solving data needs needs 9 steps:
Find the Data source the user is looking for. Is it Google Analytics, or Linkedin Ads?
Guide user to connect to the Integration, including login and tokens.
Find the particular data object that the user want to access. Does the user want Campaign conversions or data on Source traffic?
Complete the particular request for their data query. Which sub-account do we get data for, what's the time interval, and attributes, and aggregation dimensions? (Note: some of these are contextual, that is, they are dynamic and depend on a user by user case, so they have to be loaded on demand.)
Get the data in!
Setup a table from that data. Does the user want a vertical or an horizontal table configuration? Which headers does the user need, and in which order? How will new data interact with previous existing data in the table, will it rewrite it, or update it?
Enrich that table with data from other sources.
Refresh the data, manually or automatically.
Work the data: Summarize it (Pivots), Filter it, make Charts with it.
We built Integrations, but that's less than half of the job (of the 9 steps). In fact, even completing the basic data gathering, which is the first 4 steps, involves quite a bit of effort.
So, no, Integrations aren't about access, but about the whole experience around data. We are now fully committed to making those 9 steps the easiest and most powerful you've ever seen on a Spreadsheet.
Automations
Another thing we got wrong from the beginning was how much we needed Automations in the first versions of Rows.
When we started, Zapier was blowing up, and there quite some spreadsheets users who valued the ability to schedule some tasks, like fetching some data automatically. So we started building a platform for Automations from day 1.
In hindsight, that was foolish. And again this would be something we'd have found with deeper UX research. And also with a bit more common sense, to be very honest; It is logical that first we should help users get data inside spreadsheets successfully. Only after they're happy with data should we move to automating those tasks. We kind of went at it all at the same time.
Because we prioritized Automations, we built our first system directly in the backend, with a cloud architecture to compute spreadsheets. In retrospective, we absolutely did not need it. Foregoing Automations and building computation on the frontend and syncing it to the backend would in my perspective have multiple benefits, chief of all saving us a lot of trouble.
That said, today we have a performant system in the cloud that we're quite happy with.
Platforms
This one is going to be a bit more controversial.
Even though they aren't necessarily coupled, I have found that the maximalists of micro-service cloud architectures usually end up being browser maximalists too. In 2017, I was sold on this micro-service architecture, without a proper understanding of Productivity. We poured a lot of time on building a full micro-service architecture for the spreadsheets, and then more time than that fixing the problems that arise from the cloud. We also built Rows.com for Chrome exclusively for a number of years. Last year we tried reversing this by building a native app, but then the startupmaggedon happened and we postponed this project.
It is my conviction today that our approach was misguided.
Successful productivity apps with dozens of millions of users have a multi-platform, multi-browser, and multi-form-factor approach. Smaller apps usually go native first, then they expand; native platforms offer developers a faster way to an experience that isn't rivaled in terms of smoothness, with their deep integration with OS APIs and the native UI framework. This applies to to-do apps, note apps, calendar, and, yes, spreadsheets.
We should have started by putting some more importance in Chrome and Safari, and offer Rows on those browsers for desktop and mobile devices. Or we should have started on an ecosystem (Apple) and then expanded.
---
Today, we're much more UX centric and far more compatible platform wise. In terms of our team, for the last couple of years Design has sat alongside Product and Engineering, as equals.
The more we deliver on our vision through this new setup, the better reactions we get from users.
I'm back next week with a new company update.
