We love the name Job the Builder. What made your team decide to build it?
Robby: You know, it’s funny. One of our previous developers who started the project has young kids and, as his working title, named it Job the Builder after Bob the Builder. Then we just never changed it.
The main reason for building Job the Builder was tool overload. We want to use the best solution for each job, rather than one tool that’s going to do some things well and some things not well. But this leads to inconsistencies across the each platform.
Things like job names and operational details were always referred to differently across platforms. So if you had Project ABC, then somebody would name it ABC in Trello and then it would be CBA in Slack and BAC in 10,000ft. There was never consistency.
Jason: At any given time, we’ve got 20-30 different projects going on in our office. Even with the best guidelines and intentions, producers are going to have different styles of naming things. At the end of the year when you want to look back on profitability, margins, and other aspects of the business, naming consistency is the difference between almost consistency and perfect consistency – even down to whether or not there’s an underscore or a space between key parts of a name. It makes a world of difference.
So our goal starting in Q2 this year, equipped now with Job the Builder, is consistency.
Our team is uniquely positioned with an internal innovation team that observes patterns across our production team, then they’ll go and build something to expedite our production process where possible.
As a creative development team, we want to maximize the amount of time that our people are using their creative talents and minimize the time that they’re doing rogue procedural work that can be automated.
So this just happened to be another thing where we realized that producers were probably spending 20-30 minutes sending out data to these different platforms every time we had a new job. And coupled with the fact that if they break the naming convention even in one small way, it exists for eternity in our system with a kink that will make reporting much harder later on.
It was a journey from the beginning to the end since we didn’t really have the perfect idea from the outset. It took a lot of refining that was solved with agile and more than four rounds of user testing as we were developing.
Can you walk us through how Job the Builder works?
Robby: This is the main workflow that everybody now uses to create a new job. It’s a one-page form where you can add:
- Project title
- Client and brand
- Project description
- Start and end dates
We also have several custom fields in 10,000ft to categorize projects so we can run various reports on a weekly, monthly, and quarterly basis. When you hit submit, four things happen:
- A 10,000ft project is opened
- A client folder is created in Box with our templated folder structure that can also sync with the desktop app
- A new board is created in Trello if you chose to do so
- A new channel is opened in Slack to discuss the project
On the confirmation page, you have direct links to all these different tools. All common fields in the tool are entered appropriately in each platform, which ensures consistency in workflow management and reporting.
How long did it take to build?
Jason: It probably took us six months end-to-end from inception. As you know, since service is our business, our internal initiatives can be deprioritized. So despite the interest in getting this launched, there were pockets of time where we weren’t in active development. Compacted, I would say it would probably be three months of work for a full-time developer.
We also had a junior developer work on this who was really excited about the project, so maybe it could have been done in more like a month with someone more senior. But that’s still just the coding consolidated. With all the user testing stretched out, I’d still say it would take two or three months.
It went through the usual birth and rebirth of any internal software project. In this case, the naming convention was the basic utility. But then, it’s easy to go down the path of “Oh, we’re building this big piece of software! Let’s brainstorm everything it could possibly do.” And then you realize, “Oh, god, that would take us two years.” So we had to get it back down to an MVP.
What lessons did you learn through this process?
Robby: It’s important to make sure all the stakeholders are involved from the beginning. From my perspective heading up operations, I have very different needs than the individual producers or our finance team. So getting each discipline aligned up front is key.
At first, we were eager to tackle everything at once, but as we broke it down into smaller chunks and ran it more like an agile project, we were much more productive.
Jason: Even the flow of logging into the application went through so many rounds of revision where we got feedback from Robby and our internal producers. We really didn’t want to discount usability and user-testing, so we did a cyclical development cycle where we spend the least amount of time possible to get each feature “to market”, and then user testing validated how the future unfolded.
I’d like to think that everyone is building products in that modern way. There’s some residual old school thinking of, “We’ll plan it all out on paper and then we’ll have the developer just go and build it and it’ll probably be close to perfect the first time and then we’ll launch it.” And it’s really not like that.
How much time would you estimate the project importer saves your producers?
Robby: Well, it saves about a half hour of time per project for producers now that they don’t have to log into all the different channels to create the job multiple times.
And you’ll love to hear this part – Job the Builder has actually improved our on-time timesheet submission. Previously, the last thing our team would do was open up the job in 10,000ft. When they’d get a new project, they’d be excited to get things moving and start talking about the project with everyone in Slack, but wait until later to create a project in 10,000ft.
Part of our team is in China, so if a producer here in New York waited a day or two to add the job in 10,000ft, our team in China wasn’t able to submit their timesheets and everything would get delayed. So it’s also saved a lot of people time hunting and pecking.
What was the 10,000ft API like to work with?
Robby: Our developer who worked on Job the Builder passed this along:
“10,000ft’s API was the easiest to use among all services that we used to develop. We only needed a simple secret token to use the API. For future reference, the token requires admin access, which will be really helpful for other developers to know so they’re not stalled in getting started.”
Do you have any advice for other teams who are building an internal tool?
Jason: With internal projects like ours, I would recommend creating a team with a UX person, a key backend developer, and a product manager. If you don’t have those resources internally, it’s okay to use an outside service as long as you have time to dedicate to it.
The PM is going to be able to look at the product objectively (which is not something the CEO can typically do), take feedback, and adapt the development work as needed. The main reason a lot of internal projects fail is because there isn’t someone who’s solely responsible for getting the product launched.
What about external software evaluation – any recommendations for going through the process of selecting a tool?
Robby: From my perspective, when you’re picking any tool, I think it has to hit 80% of your primary requirements. And then you have to figure if the other 20% is really that important or if there’s another way to get them done.
With 10,000ft, there are of course things I wish it would do a little bit differently, but it’s definitely 80% of what I needed and the other 20% could be solved by exporting data and building this internal platform. No piece of software is going to do 100% of what you want it to do, exactly how you want it to be done, so you really have to focus on the main challenges you’re trying to solve and then get creative with API integrations.
What’s the most valuable part of 10,000ft for Fancy Pants?
Robby: To give you some background; before 10,000ft, our teams in New York and China were using different tools to submit time sheets – we were using Harvest in New York and our team in China was using something they had built internally a long time ago. Exporting data was almost impossible and I could never tell the actual profitability of projects.
For me, the analytics and slicing and dicing the data in a million different ways is the most valuable part of 10,000ft. Since we started using custom fields, it’s made my life so much easier because I’m able to use analytics and reporting to get a bird’s eye view of how projects are tracking and how much we’re spending on projects.
Jason: I manage our technology team with resources that I oversee here in New York and in three different offices in China. So I have several reports on my user page that are just analytics for me to track everything – from who was doing what last week, to how the current year is going. 10,000ft enables me to manage and lead those people better. The analytics dash allows me to create a custom report with pretty high ease-of-use, so that’s probably the greatest value for me.
Job the Builder is really just a launcher. The project itself is centralized in 10,000ft, so it kind of speaks to the robustness and the extensibility of your platform. Especially when we started using custom fields, it just opened up a whole new level of flexibility.
So, I don’t want to make it sound too profound, but 10,000ft is probably the single richest resource as a piece of software that we use for our project information.
Robby: Our goal – both for ourselves in terms of profitability and for our clients – is always to increase efficiency. 10,000ft allows us to do that. And because we have such good timesheet compliance, like the best I’ve ever seen in my career, it allows us to be able to assess things on a weekly basis and really see how things are tracking. So if a longer term project is going far off the rails, we’re able to identify issues early in the process and course correct as needed.
Interested in how 10,000ft can help your team downsize tool overload and more efficiently manage your projects and teams? Contact us for a free consultation.