Shaun: Alright, Vinay from Process Street, welcome to the Automating Business Podcast!
Vinay: Thank you, thank you. Excited to be here!
Shaun: So if somebody just landed on earth today and they didn’t know what Process Street was, what would you tell them?
Vinay: We’re a SaaS product that helps teams work better in less time with peace of mind. What that means is that we basically help companies manage their repetitive tasks; the things that they do over and over again. The simple way to think of it is a checklist that you use over and over again and follow for various tasks but under the hood there’s a lot of power there.
For example, if you needed to run a checklist every time you close a new customer, say you’re a software agency. And you have to do a lot of requirements gathering for them, and you have to collect a bunch of information about what type of website they needed, and integrations they need, and branding or design work that they need. And you have to run that checklist every time. We can plug it into your CRM your Salesforce or whatever. We can automatically run that checklist every time you get a new customer off your CRM.
And then we can do things like, if you’re collecting data along the way, so for example, a contract needs to be signed or there’s input that needs to be put into that checklist. For example, they tell you, “Yes, we need customer integrations”. You wanna track that. Then we allow that so you can input data. You can create decisions. You can create branching flows. You can push that data off into other systems. You can generate contracts and push it into QuickBooks or Xero and generate your invoices and do all that kind of stuff as well. So super powered checklists.
Shaun: That’s cool. You know, when I first came across Process Street I wasn’t really sure of the idea. And when I delved into it a little bit, it’s actually really cool. Because of course there’s a million and one checklist apps out there, right? I suppose, when apps first started getting built it was one of the first things that people built. [crosstalk 00:02:04] And I remember when I was training to be a developer, it was one of the first things that I learned to build as well. Probably everyone builds one at some point when they’re doing development. So I think it’s important to distinguish that this has the ability to have really strong integrations with other apps, right? And that’s what distinguishes it from the regular checklist app.
Vinay: Right. There’s a couple of ways you can think about a checklist app. So you can think about it as a to-do list. This would be kind of what you find in your iOs Reminders, or in your Outlook, or in your Gmail account where you can add a task and then that can get completed. We’re a little bit different in that we’re more of a processor or a workflow solution in that, usually the way that our product gets used is the manager of the business of the team will define a process and say, “Okay, every time we get a new customer we have to get these three contracts signed because we’re not compliant if they don’t sign these contracts and we’re at risk of losing sensitive data or something. So it’s really important that every time we get a new customer, these three contracts get signed. We also need to make sure that we collect these seven bits of information for them, otherwise we’re not able to generate that contract, or we’re not able to generate that invoice, or we’re not able to deliver the product or service to them correctly”.
So the manager will kind of define that checklist of things that need to get done. The manager will plug that checklist into different systems. So it will say “Hey, this checklist automatically runs up the CRM” and then it sends an invoice off Xero. And they’ll kind of set all that up first. And then every time that a sales rep closes a deal, he kind of just needs to follow this checklist. So it’s a little bit different to your iOs Reminders App where it’s a bit more … You call that more like a “to-do list” product in that, you’re imputing the tasks and then you’re completing the tasks and it’s a pretty simple task. It’s usually just a bit of text. Maybe it’s got a link or something in there.
Whereas, for us a task could be really complex. It could involve a video that’s explaining how to set something up. It could have a whole series of board deals that need to get completed, decisions that need to get made along the way, blinks off into other systems and things like that. It’s kind of defined by management and then run by the team and it’s run the same way every time to ensure consistency and compliance.
Shaun: Okay. So every app has an origin story and we, just before the call, learned that you’re an Australian. And I don’t get to interview many Australians because obviously there are a ton of Australians in San Francisco, Silicon Valley, and so on. But a lot of apps come out of the United States. So what’s your origin story? How did Process Street start and what was your involvement in that?
Vinay: Well it was basically just a pretty standard invention story I think of me basically scratching my own itch. I was running a company before this. We were twenty people; a distributed team. And I was basically having trouble keeping everyone on the same page, getting everybody to complete consistent work, especially across distributed timezones and what not. And I was looking for a kind of workflow solution, or managing [inaudible 00:05:30] stuff in Excel or Google Sheets. I didn’t find anything that wasn’t really bulky and heavyweight and many generations earlier than the products that I was used to using.
So we went about just building it ourselves with my company as the first customer. And then just started integrating it from there … got some of our friends on it … just got more and more feedback. And then, eventually, built it up to the product it is today.
I’d have to say that the original idea for the product was a lot smaller and then it kind of expanded out as we learned more about what companies needed and what their pains and problems were. We were able to build out the functionality and go after bigger and bigger markets, and bigger and bigger companies. And now we have tons of Fortune 500 companies as customers and what not.
Shaun: So I suppose, of course, the problems that you were having in your company even though they are similar aren’t necessarily identical to those of other companies. And that’s one of the problems with a lot of particularly automation apps that it’s hard to find a “one size fits all” approach. How do you make sure that an app like Process Street meets the needs of a Fortune 500 company but also meets the needs of a mechanic shop down the road?
Vinay: Generally, you’ll find that the kernel of the problem is the same and there’s more pieces that get built on top as the organization becomes larger, and their teams are bigger, and their processes are more complex, and they’re dealing with more compliance and security issues, and their ticket values are higher.
It’s kind of like the kernel of the problem is the same for all companies, right? Like, companies trying to do things consistently. They have to be compliant. They want to deliver a high quality product or service to their customer. They want to retain knowledge inside of the business and make sure that employee turnover doesn’t affect their growth. They’re kind of the core problems of the same management wants visibility to be able to see what’s going on in the status of the company. It’s all pretty much the same problems just at different levels of scale. So generally, what you find is that anything that works for the enterprise will also work for the small business. But the enterprises has additional things that the small businesses don’t need.
The core functionality of our product works well. It needs to be easy to use. It needs to be easy to understand. It needs to be quick to receive value. It needs to do the core purposes of the product. But an enterprise might have a thousand processors running versus a small mechanic might have just ten cars or customers that it’s working on. So the UI needs to be slightly different for an enterprise because you have a list of a thousand things, which might need to get organized and sorted in different ways or different people might need to see different views versus there just being one manager.
So the differences in the product … If you have five-hundred team members in the organization and you’re assigning things, or giving permissions to things, or viewing what’s going on in the business or in the product. Then all that gets a little bit different when there’s five-hundred people doing all of this work inside of the app versus five people doing work. It’s just … You need different views to be able to process things effectively. You need to be able to manage those users easier, group them easier, control their sign on permissions easier. There’s all these security things that the enterprises need.
So it’s kind of … The core product is the same and aiding the build for the small business is also useful for the enterprise. But the enterprise has this peripheral stuff around it that is purely for the enterprise. And so, yeah … [crosstalk 00:09:38]
Shaun: So you must’ve, along the way, seen some really amazing, dramatic changes, positive changes for small and large business in terms of how their manage processes, right? There must be some really cool stories about how people have taken maybe their paper processors and transformed it into something completely integrated and systematized.
Shaun: So, that’s the good. What challenges have you faced along the way? What stumbling blocks have there been? I know from building any app, it doesn’t go smoothly. And then there’s customer feedback and people vying for different features that maybe aren’t on your roadmap yet. How have you gone in that sense?
Vinay: Yeah, I mean, all sorts of different problems. On the product development side … And I mean, actually, in startups in general, prioritization is one of the trickiest things you’ve gotta deal with. Because you’ve always got ten years worth of work to do and three people and nine months to actually … before you run out of money. And so, how do you figure out what of those ten years worth of things that you can do … which is the nine months that you actually have to focus on that’s gonna get you to the next stage that your company doesn’t die? And then, at the same time that’s all tied together.
So not just necessarily your company doesn’t die but just what are the pieces of the product or features that you can build that are gonna have the highest impact in the shortest amount of time. You also got to weigh that against the complexity of building those features because something could have a really high impact but it could take you twelve months to build. And then, you’re gonna run out of money by that time so it doesn’t matter.
So kind of balancing that prioritization work load has been a real challenge. Well it was a big problem we had for a while. Right now we feel we’ve got it pretty well under control but we basically have to spend a lot of time building a ton of processes to figure that out. We’ve got a free product so anyone can sign up for free for the free account, which is a blessing and a curse in that it’s great for distribution, and getting people to sign up, and getting word-of-mouth out about the product. But it also creates a little more noise in what’s going on.
So we have a lot more people on the product, and a lot more feedback, and a lot more input that we have to process, and a lot more people pushing us in different directions. Versus if we were … And we’re a pretty horizontal product, everybody can use it for all sorts of different use cases in different industries and different countries. Versus if we were a very specific you know, “We just to checklists for oil rigs” or something. Then it’d be a lot more aligned towards a specific thing. So figuring out processes to manage all of that data, all of that user feedback, and then sifting through that and identifying what we should focus on and what we shouldn’t focus on. Just kind of figuring out systems to rate, and aggregate, and group feedback, and then systematically prioritize it. So you kind of build out a roadmap that you believe is essentially hitting the highest priority elements based on all the different points of data that you have.
Shaun: It’s a balancing act, isn’t it? It’s kind of, if you imagine the old three ring circus. You’ve got somebody spinning plates, you’ve got somebody on the trapeze, and somebody on the high wire. And you’re running all of that at once, right?
Vinay: It’s that except the floor is closing at the same time. Like, slowly the floor is closing. So it’s like you’ve got a balancing act and your floor is disappearing. What do they call it? They say building a startup is like building a train and the tracks at the same time.
Shaun: That’s a good analogy. [crosstalk 00:13:41] And it’s hard to keep all of your customers happy, right? Because, like I was saying before, I think it’s hard to find that “one size fits all” product. And I think amazing products are never really “one size fits all”. They’re good at what they do. So I suppose the next question is, where is Process Street heading? What is on the roadmap? What are the cool things that are happening soon?
Vinay: Well we just launched a big feature this month that we’re really excited about called “Conditional Logic”, which basically lets you construct self-building checklists where the tasks get built out along the way based on decisions that are made in the process.
So if you’re a software agency, kind of stick with that example, and you sign up a new customer and maybe you have three core product offerings. You have a website package. You have an integrations package and you have a design package. And someone can choose one, two, or three of those options when they’re purchasing the product. You can essentially chose at the beginning of the checklist. Does this customer want design, integration, and website or just design? And then based on what you select, it will build out tasks sent to the design time, build out the integration tasks sent to the integration team, etc. So the checklist builds itself based on decisions that were made earlier. Kind of think of it like a branching process. So we’re really excited about that.
And we’re kind of … Some of the stuff that we’re focused on at the moment is just really building out more advanced functionality like that that basically lets companies handle more complex and varying workflows besides a simple start-to-finish checklist. And essentially that’s what our real product category is, is Business Process Management software and we kind of handle complex business processes. But we like to talk about it as checklists because a lot people don’t even know if I say, “Yeah, we’re a BPM software”. No picture comes into a regular person’s mind as to what [crosstalk 00:16:00]
Shaun: Yeah people are pretty … enterprise level probably [crosstalk 00:16:03] know that term. And that market, not to insult other systems but, it’s full of really outdated products. That’s why it’s really awesome to see a product like this coming to the enterprise level because the bigger companies they’re moving away from their ARP’s. They’re moving away from their systems and becoming a lot more, to use a cliché term, agile in terms of what they’re doing, right? So that’s really cool. Okay. [crosstalk 00:16:36] And … Oh sorry, go on.
Vinay: I was gonna say, that’s like an interesting market trend that we think is happening, and we’re focused on capitalizing on and that’s … Enterprises are moving off on premise, off bundle products, into a SaaS stack of some sort where they’re running Salesforce and [inaudible 00:16:56] and this and that and Marketo and Workday. The traditional BPM products came about because companies hit this tipping point of they had too many on-premise products, or enough on-premise products where they had an ARP installed. They had two or three homegrown apps that they built internally … whatever, a few other things going on. And now they kind of have this need for building cross-functional workflow. So something that manages a workflow between the CRM and the support team and the finance team or something like that … Or maybe between multiple offices or multiple countries, things like that.
So that’s where the need for traditional BPM products came. And now we’re basically seeing that companies are shifting into this SaaS stack, essentially. And they’re now starting to hit this tipping point of the have ten, twenty, thirty, fifty different SaaS products deployed inside their environment where there’s now this need to actually build cross-functional workflows across those different SaaS products because you might have a process that actually runs across four or five different systems. And it works and the sales team just lives in their CRM and the finance team just lives in their finance system and HR team just lives in their HR system. And there isn’t … You can kind of move data between those different systems, using just direct integrations. But there’s no real way to coordinate the work across all those systems effectively and that’s kind of where we come in.
Shaun: So on the technical side of things, to the extent that you’re willing to discuss it. We don’t want you to tell us all your secrets but what platform is this built in? What programming languages? Where is it hosted? That kind of stuff.
Vinay: Sure. We’re hiring. You can go check out Process.st/jobs. We’ve got plenty of engineering jobs up there, and you can see most of our technical stack on those job ads, so it’s not really private information. But if anyone’s looking for a job, check us out. We also hire remote so people can be anywhere.
So the front end is built in Angular 1 because we started it before Angular 2 came out. We haven’t done the migration yet. It’s built API first with [inaudible 00:19:22] on the backend. Postpress is our database and then everything’s on AWS in terms of posting.
Shaun: Cool. And so for particularly small and medium businesses one of the big concerns is security and so on. Presumably, you’ve got pretty strong security protocols in place, right?
Vinay: Yeah, absolutely. For the enterprises, it’s even more important. But we follow all the standard [inaudible 00:19:50] security practices. We use all of Amazon’s security functionality in there, which actually handles a big chunk of that. But yeah, absolutely. Processes are very sensitive and we make sure that it’s very secure.
Shaun: Cool. Alright, well … look that’s it from me today. So thank you very much for taking the time to talk. I really, really appreciate it.
Vinay: Yeah, no. It’s been great.
Shaun: And I will provide a link in the show notes as well for anyone interested in signing up to Process Street. It is a great app. And I’ll also be creating a walk-through video from my perspective on how people can use it particularly in small and medium businesses. But as we talked about, the same lessons are kind of transferable to enterprise level as well.
Shaun: Vinay from Process Street, thanks so much for your time!
Vinay: Thanks so much. Great to be here!
Shaun: Thank you.