Scaling a company with Shortcut from early stage to exit

March 24th marked our first official (and virtual) Release Event. We showed off new features like Teams and our upcoming Productboard Integration, shared great insights and best practices from Shortcut customers, heard our CEO's vision for the future of Product Collaboration, and showed off some of the exciting things that are coming to Shortcut in 2021.

One of the customers we heard from was Charles Burgess, the former Head of Integrations and very early employee at Perch Security. He spoke with Dana Calderone, a Product Manager here at Shortcut about his experience using Shortcut as Perch grew from a team of people who could all fit around a single table all the way to the company being purchased by ConnectWise.

You can watch the recording of his 30 minute session below and / or read the key questions and points from his session below that.

Note that we were called Clubhouse at the time this was made. We've otherwise updated the transcript to say "Shortcut".

How'd Perch initially find Shortcut? And what was your experience like as your team initially onboarded?

We were a pretty typical startup. When I came to Perch, it was like everybody at one table in a strip mall, somewhere in Tampa, Florida. Because we were all at one table, requirements were more or less the CEO walking by and talking to us about the vision of where the product needed to go. That was all the collaboration we needed. When there's only two or three devs, you don't need to have a super involved documentation process.

For some reason, we had a tool called Target Process. I believe we had one other really advanced project management tool that while it had a ton of really awesome features, nobody on the dev team was really comfortable going in there or using it because we were moving so quickly that what you were doing changed from you're getting there in the morning to your lunch break. We ended up having a lot of really stale really stagnant stuff inside of our project management tool. It just rotted in there. It didn't reflect where we were as a product. It didn't have up-to-date requirements in it. It wasn't helping anybody.

What I needed as we started to grow and hire more developers was to have an eye on where things were in the development process. We ended up switching over to GitHub issues because developers really felt confident managing those. The most important thing at the time was making sure we could figure out where things were in the build process and were they being shipped on time? Do they need help? If people are already in the code tracking tool, we thought, well, Issues is a nice way to handle that.

Then we continued to grow and more people that didn't write code wanted to know how the product was doing, they didn't feel comfortable inside of GitHub the same way that developers didn't feel super comfortable inside of a large project management tool. We decided that it was time to find a tool that made everybody equally happy and equally uncomfortable. We found Shortcut, which was a great mix of lightweight project management that grew as we grew. Developers immediately loved it, it had dark mode, it had the ability to integrate deeply with GitHub.

To be honest, developers liked it but because it integrated so deeply with GitHub, a lot of developers never had to open it and use it. The tool stayed up to date automatically, if developers just typed the code correctly. Then all the people that were interested in progress and interested in seeing how the tool was evolving, actually had reports for the first time, which was a huge deal coming from GitHub issues. If you have 20, 30 repos across your GitHub it is almost impossible to pull solid reports out of a code tool because it's not meant to manage your project, it's meant to manage your code.

It was a big win for our team where for the first time, we could turn on a couple of integrations, and out of the box, we had great reports, out of the box, we had worked moving across the swimlanes automatically. For the first time, we had a tool where everybody from the development side all the way through upper management felt comfortable using it. Over time, we started to get more and more people in the tool too.

I think you describe right where we want to be in the marketplace. We don't want to be this super simple tool or this generic task management. We know developers want to move fast, but we also are specific to software teams and they need a certain feature set and certain tools, but we don't want to be overly complex where you need to hire somebody full-time just to configure the tool. We want to be that Goldilocks tool. I'm happy that you guys found that approach.

That's indicative of our team. We went from a seed round series all the way through an exit without hiring one full-time product or project manager and we had a team of like 13 development, engineering, product-related people, but there was nobody dedicated to managing them. Nobody dedicated to the tools. It was super collaborative, very independent and it worked super well for our team, but we definitely didn't have a budget to spare on somebody coming in and just moving tickets around on for it. That wasn't quite how I wanted to spend money, but we needed Ops people to manage servers at three o'clock in the morning, but we needed people to be figuring out what the market wanted. We needed to be having conversations with our customers and doing deep designs and interactive work.

You mentioned you're an early employee, you found Shortcut and obviously you guys grew into an acquisition. Walk me through how your use of Shortcut may have changed over time.

Kurt’s keynote about Teams is really indicative of the Perch journey. When I started, there was a marketing person. That marketing person became our marketing team and that marketing team ended up having full-time employees and contractors. Then the development person became the development team, became development ops, front end, back end.

By the time I was leaving, we got to a place where we had really advanced requirements gathering. We made sure that we talked to customers. We had a list of our early access, beta testers. We made sure that we had the integrations in play to get our designs from Figma and to notify people via Slack when important conversations were happening. We made sure that we had the development process move along. That maybe started out as to-do, doing, done up to now where we have QA people involved who have their own steps. Pushing to prod wasn't a one-step click anymore.

Shortcut became this hub where everybody could collaborate. Before that engineers were in Github, marketing was in Microsoft projects, there were some people doing things in SharePoint and Slack. There were some conversations that were being held in email. This didn't make it easy for any of us to work together. It just made it where most of our conversations ended up happening in Slack because it was the lowest common denominator as a team. I have nothing against Slack, but if you've ever tried to search through Slack for important critical decisions on a feature six months later...

But with Shortcut we had all the comments and the ticket and you have the design right there linked from one place, and we could tag people from different departments and different teams, we ended up getting to a place where it was so rhythmic getting these integrations and these different features out the door at Perch where it would start on one team workflow and we would just keep moving it onto other boards like got to that place. We came up beautiful relay across the company where rather than it being a data loss or fidelity issues, making it from a Github issue into a project management tool, into the other project management tool or into Slack or into an email, we never lost anything. All the info remained in Shortcut in a place where you can tag an upkeep.

I think we do something really similar internally. If you go into any given story or an epic, everything is integrated and attached. If there's ever a question about why we made a decision or who was involved in a conversation, there's a record right there on how it was done, why it was decided the way it was, when it got released, all of those different details. I think it's a really powerful thing.

Absolutely. We even leverage tasks pretty deeply in the same way. It allowed people to see their one step in a larger feature. As you were gathering requirements and you knew that the design needed to come from somebody or that somebody needed to add that towards change at the end, we didn't have to make a bunch of different stories. We could keep signing the individual nuggets to people, and everybody just had the visibility that they needed.

Tell me a little bit more about that. Obviously, you grew to a development heavy team. Which is often what a really small and fast-moving team looks like to a very cross-functional team with a lot of people who are not directly involved in the development process, but obviously tangentially involved and need to be aware of what's going on. How was that communication throughout Shortcut?

Honestly, the best communication came through the Slack integration. It's where we're already living, so the ability to have stories and comments post into Slack and vice-versa was huge. It lowered the barriers of entry for people. Let's be real. Sometimes you get lazy on a Monday morning and you're not willing to open a browser window and go leave a comment on a story.

Somebody added you in something, it's really easy to see the Shortcut bot-message inside a Slack, reply to that bot, and then see it post back in the channel. We would do it in a pretty convenient way: we'd have one project (which would now probably be a team inside Shortcut). We mapped to a channel in Slack and then anybody who's interested in what's happening can subscribe to that channel.

Every comment that is left on an integrations-related ticket would pop up in the main channel and somebody can click through it and become part of that conversation and then have their replies go into Shortcut as needed. We had the best of both worlds, instinct communication, and a really solid paper trail.

How has Shortcut helped you become successful either as an individual or as a leader at Perch or just Perch holistically as a company?

Shortcut definitely helped me embrace the mantra of hiring really talented people and giving them the tools to get the job done. It's really easy to become a micromanager or to be very milestone or report-oriented. The people that I was working with are 10 times smarter than me and they were able to build a wonderfully complex cybersecurity tool in a very short period of time.

That only happens when they're able to jump in, get the info that they need, talk to the people that they need to talk to, make sure they're making the right decision, and then feel empowered to execute on that. I don't want to add any extra red tape, but I also don't want to have any confusion. When we picked a tool that was too small and too nimble, people were gluing the info together themselves and they might've been missing part of the compensation.

When we picked the tool that was a little too big and a little too cumbersome, people were intimidated to use it, and it didn't have the info that they needed in it. With Shortcut, everybody felt empowered to use it. It's cute and purple, and because it integrated so deeply with all these other tools that we already use, everyone felt comfortable with it.

The designers felt comfortable because they had live updates of changes in Figma right in their Stories. The developers felt comfortable thanks to the Github integration. Marketing loved the Slack integration. It enabled us to talk better as a team, using the reports page on our sprints and retros and have these really nice guided conversations. For a lot of Devs that I worked with, they'd never before seen metrics displayed in a way that they felt like they could use to become better developers.

Do you have any advice on how to leverage Shortcut to help you scale or any tips for anybody else?

First things first. Leverage the integrations and make sure everybody in the team knows how to use them. There are so many people on our team that didn't check the checkbox to turn on Slack replies so they thought I had some superpower that I could have Shortcut conversations in Slack. I was faster than they anticipated. Give everyone on your team those same superpowers, make sure they know how to use the tool, send them the blog posts, send them the articles and make it fun because if people feel like they have the freedom to take more actions then they’ll take them. Things don't scale when you as a manager are acting as a bottleneck.

<!-- Code for CTA component starts here-->

<div class="post_body_cta"><div class="post_body_cta-heading">
Give us a whirl
</div><div class="post_body_cta-text">
Because you shouldn't have to project manage your project management.ut.
</div><div class="common_buttons_wrap"><a href="/signup" class="button primary text-color-white w-button">Get Started - free forever</a>
<a href="https://api.app.shortcut.com/oauth/signup" class="button is-google w-button">Sign up with Google</a></div></div>

<!-- Code for CTA component ends here-->