Noah Brier knew what he needed to do. As CEO of Percolate — the maker of full-stack marketing tools — he wanted to involve engineers earlier in the product design process to keep things innovative and agile. But he also saw the possible repercussions: A scramble to make sure the right people had the right information, duplicated work, wasted time. He didn’t want to create more process, so he built a tool instead that would automatically route relevant info to the right people.
Automating with tools over process like this has been a guiding philosophy for Percolate since the very beginning. In order to continue building great products to amplify brands like GE, Anheuser-Busch, and Unilever, the company has built a number of tools that no one on the outside ever sees. And, as Brier notes, this has laid the groundwork for the company to grow to over 150 employees in just over three years. In this exclusive interview, he shares why product-oriented startups should build internal tools early, how to approach the work, and how to get everyone on board to boost efficiency.
TOOLS OVER PROCESS
If you're running a product company, your number one job is to get everyone thinking about products.
At Percolate, internal tools aren’t only important to getting work done faster — they reinforce the company’s mission. In short, everyone — from sales to marketing to operations — should be thinking about how products work and what makes them better, Brier says. “This is what our entire business is built upon: creating products that solve problems for organizations, and we want everyone’s brain on what is package-able, repeatable, shareable.”
If you’re a salesperson, for instance, the email that you send out to prospects could count as a product you could easily automate, saving you all the time you might spend rewriting it again and again. If everyone is thinking in terms of products, they’re more likely to find easier, optimal solutions for their everyday work. The emphasis on internal tools promotes this mindset. It also limits variability when it comes to repeatable work and establishes a bar for quality, Brier says.
“When you automate things, you’re basically assuring that something will work exactly the way you intended it to work. A process is communicated. A tool is programmed. The latter leaves much less room for error,” he says. “The tool takes the guesswork out of whatever you’re doing. Sometimes with process, you have to just cross your fingers and hope people actually follow what you put out there.”
Of course there are still many areas where autonomy and creativity are key, but 80% of running a growing company is taking the same action over and over again. The more you can automate that 80%, the more bandwidth you can devote to the areas where a tool can’t help. “You want to give people the most time and space in the areas that really make a difference like strategic decisions, not how and when something is put on a staging server to get reviewed before it’s deployed.”
When you start out with ambition for scale, like Brier and Percolate, you want to start thinking about how you’re going to achieve revenue and headcount along an aggressive timeline and how you’re going to turn work into achievable chunks. “Internal products can start to answer a lot of these questions for you. They govern processes, making them easier to change as you grow, and they’re elastic as you add more and more people.”
One the earliest tools Percolate built is called Barista — it’s a knowledge exchange platform that allows anyone in the organization to ask a question so that it gets routed to the right people who can respond easily over email.
“One of the big challenges you see inside any product organization is how do you keep the business and product teams communicating constantly?” says Brier. “Product changes are happening and the business side needs to stay on top of them. It’s a central problem for every growing company, and automating this keeps it top of mind for everyone.”
To answer this challenge, Barista automatically populates all of the questions that clients ask while talking to salespeople and account managers, and it funnels them to the appropriate product experts so they can weigh in. “Again, there’s all this value to creating a repeatable process. At the end of every day, the questions that were answered get circulated to the entire team.”
Another product called Phaser keeps the product and engineering teams stay aligned as they sprint on many different projects at once. “It supports our entire product development workflow, interacting with Github, HipChat and Asana, moving tasks through all their phases of development on every platform as things move forward.” This leaves little room for doubt about project status or what needs to be done next. “When code is ready for review, a request gets automatically opened in GitHub and Phaser associates it with the right Asana task, and it gets assigned to the right point person.” If you try to rush something through before the right people have looked at it the system barks at you (or, occasionally, makes a snarky comment).
Before co-founding Percolate, Noah Brier headed up planning and strategy for the Barbarian Group, and founded meetup phenomenon likemind.
Tools ensure that every part of every product gets the thought and review that it needs before it is released.
When to Pursue an Internal Tools Strategy
“I would say that any product company should be a tools-based company from the very beginning,” says Brier. “If engineering is at the center of what you do, you want to make things systemic. Systemic improvements make big changes possible. Process improvements may or may not be effective.” True to this statement, Percolate launched its first internal tools between 5 and 10 employees.
From the beginning, Brier and his Co-founder James Gross had massive growth in mind. “Once you embrace this idea of scale, you want to set yourselves up for it. We implemented a lot of the tools we still use today really early on in the organization’s life and that has laid the foundation for us to make it through the bigger milestones. It really allowed us to go from 50 to 150 people between last year and this year — because we have been able to onboard fast while enforcing process with tools.”
According to Brier, establishing this focus on tools early has also made it part of the company’s DNA, and shaped its culture in interesting ways. “If you plan to grow, you don’t want politics. You don’t want an over-processed workplace. You’ve got to think about how you’re going to scale the ways you work. Tools are at the center of that. And from that perspective it’s worth the resources.”
At the same time, depending on your company’s objective, it might be possible to one day turn internal tools into customer-facing products. This is the case at Percolate, where ideas have the freedom to become internal experiments, and if they work, get released to clients. Having your entire company as a focus group has rare advantages: You get feedback from a highly-motivated group of detail-oriented people who you respect, and who are incentivized to put out the best product possible.
Spotting this opportunity, Brier made it a priority that the company spend time building and iterating on internal tools. At the very beginning, he was the one who coded a lot of the early tools to set this precedent. Following the logic that the traits of founders often become traits of their organizations, if you want robust internal tools, founders should be involved in building them from scratch, even if they don’t have engineering prowess.
“As a CEO, you spend a lot of time thinking about the challenges the organization is facing, so you have a good vantage point to either build the first iterations of these things, or work with someone technical to build them,” says Brier. Noticing the impact of his MVP products on team efficiency, it wasn’t too long before they had brought on two people to focus on internal tools full time.
As it turns out, the most compelling reason for building internal tools early may be the employees you haven’t hired yet. “When you’re deciding to invest in this sort of thing, you have to think about the employee who works at your company now, but you also have to think about the employee who’s going to work there in two weeks. We’re growing fast. If we hire 15 people in the next month, that means 10% of the company isn’t here today.” Tools help immerse everyone in your culture and make it easier for them to contribute right away.
If something isn't automated as part of a tool, you're going to have to keep communicating it over and over again.
BUILDING INTERNAL TOOLS
Before you do anything, you should search to see if affordable tools already exist to solve your particular problem. Even though Percolate relies on several custom tools, it still pulls in external solutions that make sense. Asanais just one example of a product that has helped the company spare its engineering resources and focus on what it does best. At the same time, Brier warns against trying to shoehorn a tool into a use case if it doesn’t fit. For example, when Percolate was trying to figure out a way to piece together it’s roadmap, a lot of existing apps did parts of the job very well, but nothing was perfect.
“We’ve had a bunch of instances where we looked around at lots of things but when we compared what was out there to our list of needs, it just didn’t do the job,” he says. “When it came to our roadmap, we never felt like we found something that worked for us, so we ended up building it. I’d say always build something yourself if you feel like it would take the same amount of time to modify something that’s already out there.”
This was definitely the case with Barista. As Percolate’s growth picked up pace, Brier and his team saw the need for a central repository of knowledge that would scale with the company and facilitate the interactions people used to have when they were sitting next to each other. No existing tools seemed to be able to accomplish both. So, they decided to bring in an outside developer who could make Brier’s wireframes a reality. Through this experience, he learned several tactics that he knows made Barista a success — and that can work for other internal tools.
1) Put them smack in the middle of existing workflows. “The single most important choice we made with Barista was to integrate it with email,” says Brier. Initially, the tool existed only in a web interface, but it became vital to the company when it started routing queries and answers to and from employees’ inboxes. “Email was already widely used by everyone. When we made it possible for people to reply to questions on Barista straight from their email, we saw many more people using it.”
Barista’s strength was that it would allow the people interacting with customers every day to funnel questions to product and then send answers back to users very quickly. Eventually, to make this even easier, the internal tools team integrated Barista and Salesforce. That way, whenever a new question came in from customers, it could be logged on Salesforce but automatically pushed to product on Barista. The product team would get notified every time a new question came in, and the software would send a digest of questions and answers to everyone a the company at the end of the day. This kept everyone in the know without them breaking their workflow.
Another key part of this was using Google App Engine to power single sign-on for all employees. This allowed them to access Barista with the same credentials as their email, removing even more friction.
2) As soon as a tool has traction, build out APIs. “The one thing that we didn’t do consistently is build out APIs for our internal tools,” says Brier. “If you don’t think ahead in this area, you’ll spend a lot of time backtracking to build APIs so you can exploit all these opportunities for integration.” For example, Percolate had to circle back to create a Barista API to make Salesforce integration possible. “Now we’re thinking about mobile too, and we need APIs for that. Of course you don’t have to worry about it if you’re simply shipping an internal MVP — any first version of an internal product should be pretty bare bones — but you want to keep this in the back of your mind at all times. As soon as you realize a tool is getting used and it could be used to answer more diverse challenges, build out those APIs.”
3) If you contract with someone external to build your first internal tools, make sure they work with the language that's core to your organization. This is an easy mistake to make if you aren’t paying attention and are more focused on getting a product fast. You need to look ahead to a time when your team will be able to iterate on it to fit future needs. You can predict everything an internal product will need to be able to do from the start. “In our case, we work with Python, so having the first version of Barista written in Python was a critical piece of the puzzle so we could continue to update and build onto it.”
4) Don’t let product engineering work on internal tools. “For Percolate, it was important to be religious about this split,” says Brier. “When you’re small and trying to build a company — and even when you’re bigger and diversifying what you’re doing — you need the product engineers to work on the product you’re delivering to customers 100% of the time. Don’t lose sight of the fact that that’s how you’re making money — money you can use to hire people focused entirely on internal tools.” Of course, product engineers should be involved in providing feedback and fueling innovation in this area, but not actually building tools that aren't specifically for them.
Maintaining this experimental spirit is very important to internal tools, Brier says. To a large extent, you need to be able to field qualitative feedback about where people are struggling, what they find themselves doing again and again, and what bottlenecks they keep hitting.
“At first, we would just say, ‘I think we need this, let’s give it a try,’ but as we’ve grown, more people have wanted to get involved in the process.” Today, the internal tools team has meetings with different departments to fully understand their top problems and translate them into tools. This means that tools get built sometimes for just 3 or 4 people to use. Sometimes they get built for the whole company. You want to prioritize based on how acute the problems are, and how important the work is to client satisfaction at any given time.
For example, someone in sales might relay a question they fielded from multiple clients, and a tool could help pull relevant data out of the system to help. That should go to the top of the list. Another example could be that a bunch of new salespeople are being onboarded, so HR needs a tool to help streamline that process and get them spun up. Everyone should be able to offer ideas for internal tools, but they should be stack ranked based on what is going to move the ball forward for the company as a whole — not just one team at a time.
Barista made such a big difference for overall company efficiency that the internal tools team has continued to iterate and is just now investing in a full redesign to add more features. “The big thing there is being able to pump out questions from clients, get answers fast, and make them easy to find.”
The ability to respond to requests from across the company means that the internal tools team needs to be among the most agile and effective engineering teams. App Engine also helps with this. “All of our client-facing products run on AWS, but we’ve chosen App Engine for internal tools because there isn’t too much infrastructure around what you build and deployment is so easy.”
A critical part of building good internal tools is also knowing when to roll them back. When it came to the roadmap tool, Percolate simply outgrew it. Suddenly there were too many teams, each with their own roadmap that would need to feed into a central plan, and there were better, different ways to handle the expansion.
As Brier explains, the tenet that you shouldn’t get too attached to what you build is doubly true for internal tools teams because they need to respond to the shifting interests of a small group of people. “It’s absolutely vital that internal tools never get too unwieldy. You really can’t become so wed to them that you’re not willing to kill them.”
Every internal tool should extend the functionality of your core product in some way.
ASSEMBLE THE RIGHT TEAM
“When we interview people for a role on internal tools, we’re looking for people who can write code like the best engineers, but be even more self-sufficient,” says Brier. “They have to be their own designer and product manager as well as an engineer. They have to be able to work with a variety of people who are frustrated with something is particular, and figure out how to answer that need.”
The best internal tools hires are worldly hackers, folks who like to help people solve their problems with code.
Because internal tools are largely for employees’ eyes only, these engineers have the luxury of prioritizing function over form, allowing them to optimize for great problem-solving. This is something you can press on during interviews to make sure you’re choosing the right people. Someone who is interested in making things beautiful may not be a good fit for building internal tools.
You also want someone who is research minded and who is likely to be very analytical about current workflows. “You want the people who step into an environment and wonder why everything happens a certain way,” says Brier.
Along similar lines, you should try to stack your internal tools team with people who are good at collecting and responding to qualitative feedback. This can be a unique person to find — someone who is a skilled coder but also interested in subjective opinions of their work. Because everyone at startups is moving so fast with so many responsibilities, you don’t want to burden your employees with providing regular or quantitative feedback about your internal tool systems. Monitoring should be light if you do it at all, but your internal tools engineers should be attuned how and how often people are using their products. They should spot opportunities to get feedback organically, combine it with the few usage metrics they can collect, and be able to make decisions on product direction.
“With Barista, the team can see whether people are asking a lot of questions or not. When are things slowing down or picking up? They can also look at controlled sets by team, so they can see how the product team is using a certain tool, or the deign team, and make assumptions. The thing about internal tools is that you’re constantly sitting with and among your customers, you just have to know how to get the most out of that,” Brier says. “You want someone who will notice if people would rather go have a conversation with someone than use the product you’ve designed.”
GET BUY IN
Of course, none of the effort or investment is worth it if you can’t get the people at your company to use the products that have been built for them. Ensuring that people buy into internal tools is more than half the battle. As Percolate grew from 5 to 15 to 50 people it became more and more challenging to roll out new internal tools and keep everyone engaged.
To get everyone onboard, Brier and his executive team did a lot of repeating. “I think this is true no matter what company you work at or what you're doing — you should repeat your mission, your vision, and everything else that is important so that people really internalize it.”
During every new hire’s onboarding, they spend their first week at Percolate getting exposed to the different tools that the company uses to communicate and get things done. It’s become a core part of the new hire experience. Of course, there are products that get used company-wide, and those that are only used on the team level. For the latter, the immediate manager carries the onboarding responsibilities.
For example, to get everyone familiar with Barista, Day 1 training directs new hires to use the tool to send around an email to everyone introducing themselves and asking three questions. This gives everyone great exposure to the tool while also helping them answer questions they may have, says Brier.
“I think the more that you can get your staff comfortable with the mindset that products are the most important thing, the better product you will build externally.”