Internal Tools At Corso

Internal Tools. The thorn in our side.

There's a reason why no Product Management books address internal tools. It's because every person who claims to be an expert on Product Management, at one time, has managed an internal tool they are ashamed of. It's not a pleasant topic and it doesn't sell well, whether you are selling a book ... a roadmap ... or a resume.

In general, as Product Managers, we would rather treat internal tools like Sloth from Goonies: chained up in the attic to be neither heard nor seen. Sure, we might throw a Baby Ruth at it once in a while, but it really is better to keep the malformed creature out of sight and out of mind.

I remember my first experience with an internal tool as a young Product Manager. I was in charge of a CRM product. We had an intense implementation process which included data entry of all the users with names, roles, permissions, etc.

Trying to do my job as a new PM, I tried to "seek to understand" this internal tool. I asked a support rep about it. I learned that about five years before I became a PM at the company, this internal tool was created with the good intention of being customer facing in order to shorten implementation time.

"Well, it doesn't really work, so we don't really have our customers use it." I could tell she was trying to be nice by using the word "really" a lot. We just have them fill out an excel spreadsheet and then we input all the data for them. It's okay, really."

Bless this poor support rep for putting up with this garbage internal tool that was definitely anything but okay.

Unfortunately, most software companies around the world have internal tools that are in the same broken condition. And we all know why. It's because they never get prioritized. We all want to create more interesting products for paying customers, so that's what goes on the roadmap. It's that simple. I had an entire backlog of ways we could have made this internal tool better. None of those user stories saw the light of day. It comes as no suprise to any PM that this tool got ignored. It continues to torture poor support reps to this day.

So when we started Corso I naturally had some PTSD about internal tools. I remember I had a conversation with James, our CTO, about how to solve this problem.

"James," I said. "I don't want the dev teams to have to worry about internal tools. Your bandwidth is limited, they will never get prioritized, and our internal tools will always be broken even if we have good intentions. But I know the tools we need and they are going to be important to our success. What do we do?"

James, being much smarter than me, came up with a solution that has proved to be one of the most valuable decisions we have made. It cut our go-to-market time significantly, probably in half. And now we, as a product team, have a suite of internal tools that requires practically zero engineering time to create or enhance.

Here's what we came up with.

I think there are several options out there but the solution James chose is Retool. https://retool.com/

Like the tagline of the website says, Retool helps you build internal tools, remarkably fast. All James had to do was connect the application to our database, set me up as an admin user, and we were off and running.

Now, admittedly, Retool did require a bit of a learning curve. I had to learn how to write a GraphQL query in order to read and write data. I had to understand how the components worked. And I had to set up a few integrations built into Retool. But after about two weeks of trying things out, I was creating extremely useful apps that we now use every day at Corso.

The best part is that I don't have to think too much about user experience, which of course is very time consuming (and nobody wants to give internal tools the time). UX is another reason most internal tools fail. With an application like Retool, you do have to compromise on the idea of a custom designed and branded internal tool. But it's an internal tool. Who cares?

Out of the box, the Retool components are good, and in my opinion, it actually helps to work within their constraints. This way I don't overthink things. We came up with a basic template for how we want lists and details to be displayed and now we follow that pattern. After all, 90% of internal tools are just lists and details.

I know this sounds like a sponsored post for Retool. It's not. But I do love it for the following reasons:

• For the first time I am working for a company that has decent internal tools. I don't have to be embarrassed anymore. We actually use them in our demos.
• The product team owns the internal tools so they don't take up time on the engineering roadmap.
• As a product leader, I can go beyond Photoshop mockups and train on much needed technical skills such as APIs, GraphQL, and how actual data gets populated in applications.
• We can go to market much quicker, having our internal tools in line with our client facing apps.
• It's much less expensive. Compared to development time or 3rd party licenses, Retool licenses are a fraction of the cost.

Within Retool we have built tools to help with:

• Client onboarding CX.
• Client settings and configuration
• Client support work flows
• Consumer support work flows (B2B2C support)
• Data monitoring and dashboards
• Sales commissions
• Billing and invoicing

As an example, here are a couple screenshots of our Client Onboarding CX flow in Retool. It's awesome. Status updates are posted immediately to Slack so everyone is on the same page as we launch clients and follow a process to delight our new customers and help them get familiar with Corso.

Our strategy around internal tools seems to have resolved a couple of painful problems.

First, the business doesn't want to prioritize internal tools and engineers don't want to work on them. Since product teams know that internal tools are critical to the success of the product, we have given them the training, tools, and ownership to make them work. It follows our Guiding Principle #2: Ownership and authority must be shared between those closest to the problems, and those who deliver the solutions.

Second, we are able to move with much more efficiency and speed. The cost of development or 3rd party licenses has always been a struggle, especially for an early startup like ours. This strategy allows us to have internal tools that can be built to our specific needs by "non-coders". This allows us to move fast.

When we started Corso, I was really worried about all the internal tools we would need to create to make Corso successfully scale. I've been down that road. I didn't even know tools like Retool existed, and I'm so glad James got us moving in this direction. It really makes working at Corso so much better.

And I'm also proud that this may be the first blog post you've ever read about the awesomeness of internal tools. :)