Retool
Welcome back to Chatter! This time I’m changing the format a bit. I wanted to deliver actionable insights for product teams, and finding real-life examples from well-performing products felt like a great place to start. So I sat down with Justin Gage from Retool and asked him about a feature launch that went well. Read on 📖.
New here? Subscribe to get the next editions 💌
Re-what now?
Let’s kick off with a word on Retool and the problem it solves. Simply put, Retool helps you build a better back-office, faster. If you’ve worked for a large tech company, chances are you’ve met engineers working on internal tools. Well, Retool is handling this tedious work for them so they can focus on other problems. Not only that, but they made building your back-office fun in the process. You should try it! It’s like popping up components from your design system in Figma, except in Retool they come to life in seconds.
And if you haven’t listened to Rick Astley for a while I recommend checking their design system documentation. It sets the tone for what to expect in the product: simple and effective.
Am I smelling another no-code tool?
Retool positions itself as a tool for technical folks, and you’ll need to be comfortable with basic SQL and Javascript to get the most out of it. But it’s safe to say that Retool wants you to write less code.
Is Retool that useful?
DoorDash thinks so. So does Brex. And Peloton. And Mercedes. And Tom Brad... Sorry I meant the NFL. Not sure Brady knows about Retool yet.
There’s a reason Retool has experienced massive growth since its start a little over two years ago. Guess what happens once you start using Retool? Not only do you build internal software faster, you build more of it! Shorter lead times lead to faster product launches, which in turn means more product launches. And then it compounds.
And that’s just the tip of the iceberg. Once built, these tools save precious time for the operations, support, and marketing armies who use them.
On fixing product debt
Retool’s success piqued my curiosity. I wanted to know what made their product special. So I contacted Justin Gage to find out and asked about a feature launch that went well. He chose to discuss improving SQL resource creation. Here it goes 👇️
Until recently, Retool users had to set up two resources for SQL: one for reading and one for writing to the database.
Now that was confusing for many customers. “Why can’t I run both queries using the same resource?” they mumbled. The truth is, there wasn’t a good reason for it. It was legacy code at its finest. Improving it took courage though. In Justin’s words:
This was a major change. Most customers were using this feature. We couldn’t introduce a breaking change because many customers ran older, on-prem versions of Retool. We needed to make sure that the users on our existing implementation could carry on. We also had to communicate to them and decide if new database integrations would run on our previous system or the new one.
Undaunted by the gazillion things that could go wrong, they decided on the following:
the UI wouldn’t change for customers running legacy versions of the feature
newly-created resources would run on the new system
they’d create a lot of content to educate users: emails, detailed changelog…
Shortly after delivering the update, the results were in. Users welcomed the change and cheered in Retool’s shared Slack channels. Customer complaints on Intercom went down from double digits per week to just a few. This made a huge difference for Alex Westreich, Retool’s one-man CS team back then, whose thoroughness helped surface the issue in the first place.
Alex treats support as a system and was super intent on tagging everything. However, Intercom’s automatic tagging capabilities didn’t cut it for us. These customer complaints were really specific and tagging took a lot of manual work.
Who needs PMs?
Beyond the results, I was interested in the prioritization framework that had made this feature a priority. The answer made it clear it’s still day one at Retool. Its team is laser-focused on addressing customer feedback. Justin says it better:
A lot of the product work we’re doing is obvious. If all users ask for something we don’t need a metric.
More surprising still was the answer I got when I asked about Retool’s product org.
Retool has no PMs. Our teams are engineering-led. Mostly full-stack.
An interesting reminder that PMs aren’t always in the driver’s seat. In fact, sometimes they’re not even in the car 🙃.
Haters
“Yeah but they didn’t have enough data to back their decision!”
Too much data sometimes hurts even more.
“Even so, no PM is a recipe for failure.”
Here’s some food for thought, courtesy of John Cutler.
Talk soon,
Tanguy
Subscribe and get the next editions 💌