Transcription
Aderson Oliveira: I had a great conversation with Vinay Patankar. He is the CEO of Process Street, which is a SaaS platform that allow business owners to document process and procedures and checklists, and we have discussed about the importance of documentation of processes to grow a business, to scale a business, even to sell a business as well. You know that your business will be more valuable if you have documented processes in place. That's a fact.
Listen to this conversation. He knows a lot. Actually, I am a user of that tool. We use that quite a lot in our business. I use it every single day with my team. I love the tool, I love the platform. I'm not being paid to say that. Again, have a look and I hope that you enjoy the conversation.
Hello, hello, Aderson Oliveira here. This is another interview for the OuchSourcing Podcast where I talk to business owners, to specialists, to experts in the outsourcing space, and everything that surrounds this space, like tools to help us doing outsourcing: working with virtual teams, working with virtual assistants. Today, I have with me Vinay Patankar. He is the CEO of Process Street, which is a SaaS platform that helps business owners document and create checklists. Vinay, thank you very much for being here. Welcome.
Vinay Patankar: Thank you, thank you. It's a pleasure to be here, Aderson. Very excited.
Aderson: Very good, very good. I want to start by saying that I am a client of the platform. I love the platform, I love Process Street. Process Street, together with my team, helping to automate and put processes in place, and systematize has really helped me quite a lot to grow as a business owner, and as a professional as well. So, I'm very happy to be talking to you.
Now, let me link this back to the main point of our conversation, which usually are around outsourcing. The reason why I think it's so important a tool like Process Street, or just process in general for outsourcing is because whenever you're doing outsourcing, if you are working with a virtual team, a virtual assistant that we require to be doing work on a recurring basis, you have to document those things, you have to establish processes, otherwise what, Vinay?
Vinay: Otherwise, things get missed, mistakes happen, you lose track of work, and in general, your team's inefficient. But, I think that - and we'll talk about this more as well - it's interesting. I'm really excited to be on this podcast, because actually, one of the reasons that I first went about creating Process Street was to help manage what I now call the remote team. I don't really use the word "outsourcing" anymore, and it's just because, in the end, I don't -- I mean, I think, actually, technically, outsourcing came from outsourcing work to another company, so you actually hire a second company that might be a call center or something offshore.
But, for me, what it really is about is just kind of running a remote team, and basically having people in different places, and then one of the big advantages of running a remote team is that you can leverage exchange rates and different costs of living in different countries, and so people who live in another country might have a lower cost of living, and the average salaries in those countries might be a lot lower than what they are locally, so you can kind of leverage on that.
But, essentially, I was running it on the outsource remote team. I had some people in India, some people in the Philippines. It was about 20 people and probably 15 of them were kind of in those two countries, and actually was already documenting my processes. We had stuff in Word, we had stuff in Excel.
The big issue for me, and one of the big reasons that we created Process Street in the first place was, yes, documenting your process is important, but when you have people, especially in different time zones in other parts of the world, actually tracking that they do the work as well and getting visibility on that work as it's being completed or after it's been completed was actually the big piece that was missing for me.
Now, Process Street's evolved and we do a lot more stuff than just purely tracking. We do a lot of automation and whatnot now, but that was kind of like the real initial kind of pain point that I had, and that was around by either - and this is what I was doing - I'm having to stay awake until 6 o'clock in the morning, running my team kind of like a local team inside an office where I'm there, I'm checking in with everybody throughout the day, managing 15 people or whatever, and that requires 15 hours of one-on-ones a week plus group meetings and etcetera.
Kind of the experience of trying to run a virtual team that was in a different time zone the same way that I've been used to working in local teams before in the same room just wasn't working out, and it was just creating a really bad work-life balance for me, A, because of the time zone, and B, just trying to run a distributed team that everyone's in different places. But, the same types of processes or strategies that you use to run a local team just doesn't work, and you end up spending -- it's harder to coordinate six people in six different places rather than six people in one room.
I'm keen about saying, basically, synchronous communication strategy, which is kind of how most small businesses run is it's very synchronous, right? So, you're in a meeting, you're in a phone call, you're in a room, you're talking, you're at lunch, and you're kind of having a quick back and forth, and running a remote distributed team across different time zones really requires you to switch your mindset into kind of asynchronous communication and asynchronous work, and I couldn't really find a good platform that, basically, A, did the documentation.
I mean, I could find plenty of platforms that did documentation. That was easy. It was Google Docs or whatever. But, I wasn't getting visibility across what work was getting done, who was getting it done, what was left to do, and actually, getting that kind of asynchronous checks that this had been done, this had been done throughout the day and then getting that at scale across the bigger team.
That was the real initial motivator for me to start looking for a platform like Process Street to implement in my business, which I then couldn't find something that I liked, and then went about building it myself. You didn't ask me that, but that was the story of Process Street.
Aderson: That's awesome because you gave the background story, and that was one of the points as well, so you covered that already. My question to you is why are business owners, then - reluctant may not be the right word to use - but why do they have a hard time documenting those business' processes that they know, logically, that it will make sense to them, but they just don't do it. Why?
Vinay: I think, firstly, you've got to segment out the word "business owner" for example. Public companies document their processes, all of them. You have to if you want to go on the stock exchange, right? So, it's not that business owners don't document their processes. I think that lots of companies do and it's a well-known practice, especially in enterprise, but I think the real gap comes to smaller businesses.
I'm sure you have, but I'm not sure if people in your audience have read the book "E Myth". I actually have a podcast episode with Michael E. Gerber, who's the writer of E Myth, and he kind of talks about it a lot in that. So, public companies are run by MBAs. The CEO is a public company that went to Harvard, they did an MBA, they worked in very structured companies for 20 years, they understand how businesses are supposed to be run.
But, what do small business owners - he covers this in E Myth - they're not MBAs. They haven't gone to business school, they've never studied process design, they've never studied case studies of different businesses, they don't have all the resources of the big company. Usually, they're a specialist in like some skills. So, they're a programmer, they start a web agency, they're an architect, they start an architect firm, they're an accountant, they start their own CPA practice, or whatever, and they don't actually have like a business MBA background.
They've never been coached, they've never seen processes in action. Maybe they've consumed a few processes in some of their jobs, but in general, they just don't have the education, or the skill set, or the training to just prioritize that. So, that's one problem is just understanding the importance and just not having the business education around why it's important, and I think that a lot of them, maybe not the CPA example, but a lot of those other, they might not have accounting skills, they might not have other business skills too that are important. Process is just kind of one of those buckets. They may not have strong sales skills, or marketing skills, whatever, right?
I think that's generally a challenge for small business owners. Firstly, you're not an MBA, mostly, and then secondly, you're coming from doing one specialized job to suddenly you have to do accounting, you do processes, do sales, do marketing, do recruitment, do culture, all this stuff that you probably don't have experience with, don't have expertise in.
That's one problem is just, A, understanding the needs and then prioritizing them properly, and then the second big problem is around timing resources. It kind of ties into that that big businesses, enterprises that they have business analysis teams, they have their process specialists in the company that go around, and document, and write, and update, literally full-time jobs building and maintaining processes, right?
Small businesses don't have people to do that. We work with a number of consultants that come in and help small businesses, but generally, they don't have a dedicated resource. If you're a 10-person company, one of those people is not building processes. They're selling, or servicing customers, or doing something that's much more closer to the money than writing processes.
The number one complaint that we get from our customers, especially in the SMB segment, who can't afford to pay 10 grand for a consultant, or don't have an internal resource that they can just say, "Hey, you're on processes for now 20 hours a week for the next quarter," they go. It's they just don't have enough time and/or money because they're sharing.
Those are kind of the two main reasons. It's just like, "I'm too busy closing deals, I'm too busy servicing customers, I'm too busy putting out buyers, I'm too busy with this project that might make me more money than I believe that immediately focusing on my processes will make me." So, that's the number one concern I reasonably hear why people don't go about documenting the processes, and we can talk about a number of strategies on how to basically tackle that if you want, but those are the two key reasons. I think it's, A, lack of expertise, and then, B, lack of resources, money, and/or time.
Aderson: Let me ask you this. You briefly mentioned, you brushed to the next question that I have here, which is about your client profile. You spoke about the big enterprises that they know how to do it, they know what to do, they understand the need to have processes in place, and you have this small business as well. So, who's your typical client profile? Who's the typical audience that Process Street is more geared towards?
Vinay: The majority of our customers right now are small businesses, 5 to 50 employees, and that probably accounts for 90% of our customer base, and then we have 10% that are larger companies that are 50,000 or 100,000 employees. We don't have full-on enterprise roll-outs on 100,000 employees, but we have, maybe, a sales team of 50 people, or a marketing team of 50 people inside a 100,000 company, whatever.
That's kind of our typical profile at the moment, and we're basically moving towards being able to service larger and larger teams. Because, what we've identified is that the bigger the team, the bigger the process problem. Smaller companies, yes they do have process problems that they need to solve, but in general, the pain and then the return on solving that problem is much higher for a bigger company, right? If you're selling $10 million a year, then you can improve your sales process by 5%, then the return on that is 50 grand or 500 grand on that improvement versus a smaller company that is not doing as much.
Aderson: Let's look at the actual process there, and maybe in a percentage base or maybe in a rough number, I can only imagine that a lot of companies, and maybe that's about bigger companies that they document some processes, and they keep collecting dust somewhere. Maybe it's an additional format, or maybe it's a paper format, whatever it is, but do you find that your users, they come, they document a process and they actually execute on them or some of them, they leave it there, just collecting a little bit of dust, they never look back, and then one day in the future, they say, "Oh, I had that process there”? Talk to me a little bit about that.
Vinay: People use the platform for all sorts of stuff, but the people that we're focused on and the people that we're interested in are people that have executable processes, because if you're just writing a document and leaving it there to collect dust, then we don't provide too much more value than Google Docs or plenty of the free products out there. So, for us, the customers that we're really interested in and that we see that are most successful on the platform are the ones that are executing processes.
There's a number of reasons for that. One of them is that it solves this dust-gathering problem of processes in that like if you're actually actively executing the process, it means the process is getting read every time that it gets executed so that if it's getting executed once a week or once a day, that means the process is getting read once a week or once a day because someone's running through that process actively, and as the process gets executed every day, people notice, "Oh, this is wrong, this could be fixed, this could be optimized, I could put a shortcut to a link for this in here or whatever," and they can continue to kind of speed that up and speed that up and improve the process as well as fix anything that actually gets outdated. "Oh, this is wrong. We changed this password, we changed its link, we changed this setting," or whatever, and they can quickly update it. Whereas, if they only read it once every six months, even if you read it six months later, you're not, maybe, going to remember, "Oh, we changed that little thing."
It does solve that problem. It also adds a lot of other things. So, you can get visibility, you can get tracking on what people are doing so that they have --
Aderson: I'm going to interrupt you there. That second time that you said "visibility", and I had a point here to ask you about that. I want to dive a little bit deeper into how is that visibility becoming concrete? How is that visibility visible? What is that?
Vinay: What's a common process that you use with your virtual systems?
Aderson: Every week, we publish this video live. So, the publishing of that, a newsletter, social media, on the website, this is all done via Process Street, not automated, but systematized via Process Street.
Vinay: Awesome. So, a good example would be content creation, or podcasting. When it's on a weekly schedule, visibility is a little less important in that the historical audit trail is great to have and you can do some analysis on previous podcasts and say, "How long, on average, does it take us to edit a video or publish? We get it out in four days or five days, is there a particular point in that process that is slower?" because you're tracking every step in the process, it all gets logged, we have reports in all of that.
You can do a little bit of historical optimization, but you can see this starts to get really -- that actually becomes really powerful when there's a lot of stuff going on. So, if you had a team of 10 people, each of them publishing one piece of content per week and you actually wanted to optimize that content creation and publishing process, then having all that down is important.
But, in your case, a good example of visibility would be, say, you did batch recording of podcasts. So, you spent a whole day and you did 10 interviews, and then your plan is to drip out those 10 podcasts over like a 10-week period. Now, in that kind of scenario, it could be like client on boarding, and say you get 10 clients in one day, and you're managing multiple things in parallel now, right? You're trying to set up 10 different clients in parallel, which is one of our most common use cases on plan implementation.
Now, you want to know, "Okay, I've got these 10 podcast episodes, I need to drip them out," and you want to see, "Which ones are edited, which ones do we have the graphics for, which ones do we have the transcripts for? What's the status of all those different podcasts?" So, now, in Process Street, you'd be able to easily pull up an overview screen, you'd be able to say, "Okay, podcast 1 is 80% done, we've got the editing, we've got the transcript, we've got the images. We're just waiting on the final show notes, or something. Podcast 2 is like 70% done, podcast 3 is 60% done, we're waiting on this and this."
Now I can get a visibility across like the different -- assuming you have someone doing editing, someone doing graphics design, someone doing the show notes, you can get visibility across all those people and where they're at in their different tasks on the editing and production of those 10 different episodes. So, now when you go, "Okay, we need one for next week," you can pull up that report, "Okay, this one is 80% done and this one's 70. I think this 70% one is going to fit better with this other blog post that we're releasing this week, so let's push the 70% one up and push that one out this week, because I think this is going to work better."
You kind of can see the visibility of where everything is at, instead of if you have a Word document, that was like this is how we edit a podcast, then to know what the status was, you'd have to go and say, "Oh, editor, have you finished editing that one? Okay, what about this one?" You have to go to the designer and say, "Is the image ready for this one? We want to switch this one out," and you have to go to the writer, and you kind of have to patch together all that information, and you don't have a clear visible picture of the status of all the different episodes that you're currently editing, right? That would be an example of visibility.
Aderson: I love that example because, actually, we do record in batches. However, we were not releasing like that. I mean, on a weekly basis, we would go through a cycle. Instead of doing what you're suggesting, we are doing a weekly cycle of each from editing to publishing live. So, that's happening every week, but again, nothing better than talking to a specialist to suggest things to improve. Again, that's a great insight there.
Vinay: If you're breaking out the work, like if you have an editor, a designer, and a writer, then they're working on different tasks, not necessarily in parallel, right? So, if your editor finishes editing one episode by Tuesday, what? You're just going to have him sit there and wait until next Monday to start the next episode? There's no point. You should just be able to continue go to work down his list of editing stuff, keep going, keep going, keep going, then when the designer's ready, he can come in and keep going. Like, they should be broken out into different streams, right?
Otherwise, it's less productive because the designer's waiting, or someone's waiting for someone else for the next step, and someone's kind of sitting there twiddling their thumbs for a while where they should all just have queues of work to do, and this Process Street does this automatically with inbox and everything so they can just kind of log in and see their queue. They just start at the first one, do the editing, move onto the next one, do the editing, the designer starts at the first one, does the image, moves onto the next one, does the image, and they kind of all just get linked in together.
But, each of those individuals, they don't have any downtime, they don't have to wait on other people, they don't have to coordinate anything. They can just kind of move down their list of the tasks that they have to work on that's like within their specialization area, right?
Aderson: Love that. Let me ask you this, Vinay, just like what you did, you gave me some suggestions on how I could improve my process. Actually, I know that you have a platform, you have that software platform, and let's put it this way, that's it. But, do you have, let's say I go to Process Street, and I say, "Hey Vinay, I need someone to help me with my processes here," do you have recommended vendors that you can put people in contact that says, "Hey, you can go to this guy here, to this company here, to this firm to help you build your process, to systematize your process"? Do you have something like that in your roster there?
Vinay: Yeah, absolutely. We have people everywhere: U.S., Canada, UK, Australia that are all vendors or consultants. They're process consultants, they are very strong in documenting processes, they're very strong in automating and integrating systems, they're strong in Process Street as well as setting up other types of tools, like maybe a CRM, or maybe a Slack or whatever, and linking them all together. So, we work with a number of consultants that do that.
Just in our experience, typically, if you're a company of less than 20 employees, I haven't just seen many of those partnerships work out in that the cost to return kind of pricing doesn't seem to work out for those smaller companies just because the consultants can be quite expensive.
But yeah, we have a lot of our kind of bigger customers that are maybe 50 to 200 or 300 employees that work with consultants, and they basically will do that together. So, they'll buy Process Street, and they'll hire a consultant for three months, and they'll kind of just deploy the whole thing that way.
Aderson: Let me ask you a question. Do you eat your own dog food?
Vinay: Oh yeah, absolutely. All of our teams use Process Street.
Aderson: Really? Tell me where one process that went through at some point or where it will go through today at some point, maybe, through your inbox, or maybe to provide you some visibility? I mean, just give me one example of your own processes.
Vinay: I'll give you a few. So, marketing, we use it for content creation and content promotion. Similar to you, we use it for publishing blog posts, guest posts, help articles, emails. We kind of have pre-published checklists on all that content, peer-reviewed checklists. Then, we have motion process, so every time a piece of content goes live, it's, "How do we promote it?" Those are common marketing ones.
Sales, we use it for a big one is like proposal generations. So, if we're offering a discount to a particular client, and be like, "Hey, if you sign up for two years or if you use this, we'll give you a discount," kind of thing, and we generate that proposal automatically for signature and everything through Process Street.
In the customer success team, we use it for client onboarding, for customer onboarding so when a new customer signs up, we basically take them through a walk through the product, and help them get up there, get set up with some of their processes.
That's one thing we do, actually, is we do offer a kind of customer success call for all customers that sign up, and then if you're a bigger customer, maybe more than 20 users, then we'll give you a few sessions to help you get set up. So, we use it for that process.
Then in engineering, they use it for pull requests. So, every time they want to pull request from that master branch, which is basically a coding thing, they use it for sprint planning, they use it for sprint retrospectives. We use it for our backlog prioritization, which is essentially prioritizing issues and bugs that we're going to work on for that Sprint. Yeah, we use it in all the teams.
Aderson: If you don't mind me asking, do you guys have a prioritization of features to come of, "We would like to see this coming next and this coming next"? Actually, this is a good segue to ask you what's coming next to Process Street?
Vinay: We have a whole prioritization process. Most of that doesn't run in Process Street itself. We use a tool called Product Board, which is specifically designed for building software products, and tracking it, and it kind of like integrates with our support and everything, and pulls in all the user requests and that kind of stuff.
But, we use Process Street. So, every week, we have a backlog prioritization meeting, essentially, where we go through a number of the open tasks, the open bugs. Because, if you're in a startup, you basically end up thousands of open issues in JIRA, which we use for the engineering team, and to just even go through and look at all those things is like a whole day, right? So, basically, every week, we just break off like 20, or 30, or 50 of them, and kind of just go through them constantly, and we use it for that.
Aderson: Perfect. Very good, very good. One quick mention that I would like to make is about integration, integrations of Process Street with third-party tools, and I think that most of them are done via Zapier? Is that correct? I mean, can you talk a little bit about integrations in general?
Vinay: Yeah. Integrations are a big part of Process Street. Zapier is the easiest way to do it. At the moment, we also have an API that you can work with if you're a larger customer. So, we not only try to automate your tasks within Process Street, but a big piece of it is actually moving data between systems. Client onboarding is one of our biggest, most common processes. Companies that do client onboarding are generally selling a more expensive product. So, it could be a lawyer bringing on a new customer, it could be a marketing agency bringing on an enterprise. We have a lot of -- like enterprise software companies that have to kind of deploy the software, and do integrations and stuff, and it's quite a long, complicated installation type of process.
A process like that will start at the CRM from sales. So, we'll start in sales force, the sales rep will close the customer. That will automatically launch a process for customer success, or many teams, so that might bring in someone for customers. Sales might bring in implementation, it might bring in finance. They'll all get different tasks related to onboarding as customers.
Customer success could be like scheduling meetings, doing requirements, gathering, training different people on the team, in the customer team. Those could be some of the customer success tasks. The implementation team could be doing custom integrations. There, we could basically push issues or tasks into JIRA automatically that come out of sales force so that the implementation team has their tasks set up. In JIRA, we'll do a two-way sync so we can complete tasks as well.
Then, finance would integrate with, say, QuickBooks. We might integrate with HelloSign or some other type of document signing tools so finance can work on finalizing contracts, get the agreements signed, send out the invoice automatically, and track that in QuickBooks. So, we can kind of build out this process that's normally the salesperson emailing customer success, and sending some email off to invitation, and then finance calling them, and doing that whole thing, and we can pretty much automate a lot of those steps and control the flow of information through those different systems from sales force into JIRA into QuickBooks into HelloSign, and give you visibility on where that process is.
In that same example when I was telling you, "Okay, maybe you have 10 different clients you're currently onboarding," and you could exactly the state of those different clients and what's been done, and which teams have finished their tasks.
Aderson: Awesome, awesome. What's next for Process Street?
Vinay: Yeah, I skipped that question. Right now, we feel we have the best user experience on the market in terms of a worker automation product. But, we still are lacking in a lot of the more powerful features that a lot of the other BPM tools offer. Our focus right now is essentially working towards being able to handle every type of process possible, and that's kind of like within our own systems. So, that doesn't include integration and stuff, but our first step is just, within our own system, building out the feature sets so that we can kind of handle every type of process.
Some of the things involved in that are conditional logic. This is one of the big ones where, if you have a process that changes based on decision in the process, it will rebuild the process based on those decisions. So, a simple example could be, say, you're a marketing web agency, and you build websites for clients, and you have different packages. So, say you have a web design package, a logo design package, and an integration package or something like that, depending on what the client buys, you might have just the website, you might have the website and a logo, you might have the website and integration, you might have all three, right?
At the beginning of the process, you can kind of select, this guy wants logo and website. Based on that, it would kind of build out the website tasks, sign him to the web team, build out the logo tasks, sign him to the design team. So, you can kind of automatically vary your processes based on decisions that were made before. That's a big one on conditional logic.
Then, working towards that. So, stop tasks kind of saying, okay, in that same example, maybe they take the logo design and the web design project, and in your process, you might have "deliver a first draft of designs to client" as one of the steps. So, first, the web design team has to go through and do a first draft, and then the logo design team has to go through and do a first draft, and the customer success manager, or the project manager has to then present those two first drafts to the client.
We would kind of create these stop tasks that we call is another feature called "stop tasks" on like that meeting task which presents us to the client, and it basically says, "Before you can do this meeting task, first, the logo design team has to submit their draft and the web design team has to submit the draft." So, it kind of puts you in control into the process. Instead of it being just a free-flowing checklist, you can really say, "This has to get done, and this has to get done, and until those two things are done, we can't move onto this one."
Other things like variable due dates, variable assignments, just making the processes kind of more malleable to hand more use cases, approval tasks to be able to create -- ability to create approval loops between a worker and a manager, so working on just building on that functionality, that's our immediate focus.
Aderson: Good to have the vision on where this is going to. It must be a challenge to make sure that you can implement those things that you are talking about without making the product, the platform more complex. So, that might be a balancing act from your side.
Vinay: Absolutely, yeah. We think we've done it. Of course, there's going to be more complexity, but what we're really benchmarking ourselves against is the complexity of the competing products. Like, there's no way for us to build a product that has conditional logic that doesn't have some level of complexity. But, the way that we're designing it and the way that we're going about it, we believe, is a much better experience than a lot of the competition in the market, especially the big incumbents, the enterprise like SAP and IBM, stuff like that.
We're able to kind of deliver that same core functionality, but we're able to do it in a way, and this is kind of being in the core of the design philosophy. We're able to do in a way so that it's understandable by someone who doesn't have an MBA, who's never gone to business school, who doesn't understand what a flow diagram is or how a flow diagram works.
Actually, when you see a lot of the existing BPM tools, all they've done is they've taken a flow diagram and they've just put it on a computer, and that's how all those products work, they've maxed off IBM and whatnot, and we're kind of redesigning it in a way where, if you say, "I have this repeating task that I do all the time like making a website for a client," and it has these things like sometimes they need a logo, sometimes they don't. How do I just like do that without understanding what a flow diagram is or what a decision point is or whatever? And that's kind of what we're going for. So, we want to still build that functionality, but we want to make it more intuitive for people who don't have any kind of background in process to build in our design.
Aderson: I'd like to step back for a second and go higher level here. Not tool-specific, not platform-specific, but what is one thing, and I guess that about process in this case, that you'd like people to leave this conversation knowing about, or something that they, "Hey, you guys should look at this thing here"? What is one thing that you'd like people to leave this conversation knowing about?
Vinay: The point that I'd like to address that I talked about earlier is the number one reason that people don't build processes, well there's just two reasons. One is like they don't remember that they should. That's a whole different story, but once they know that they should build processes that they don't have enough time to build them. What we like to kind of teach people, and we have a good blog post on this on how to build processes when you don't have time, so you should totally link to that.
But, we try and teach people around this concept of lean process development, which we took from the kind of lean startup movement, which starts around basically building MVPs, minimum viable processes. In the startup, it's minimum viable product, right? And then working from there.
In Process Street, it's really, really easy. Actually, in any Word document or whatever, it's really easy to build a very basic framework of the process. Here are the 10 steps, one sentence per step, not even, just a task per step, and that's kind of like the basic line of a process, and what we try and guide people to do when they don't have time to do processes is don't take this kind of giant project and say, "Oh, we need to build all the processes for our company, and then try and treat it as a big project, and then try and list every single thing that your company does," and then like, "Oh shit, now we need to build processes, and you've got like 100 things here," and you're like, "Oh, I have to build 100 documents, and then I have to maintain 100 documents."
It just spirals out of control, and if you're not in the place where you can afford a consultant or you have dedicated resources, that's like the wrong approach because it paralyzes you before you can even start, and then you just never get anything done.
What we try to teach people to do is basically build minimum viable processes. It's like first pick one or two processes that are the most valuable processes in your company. So, generally, it's either they're very frequent, get done a lot, or they're very high-value, they're close to the money, and they're worth a lot of money. So, client onboarding, employee onboarding are three common ones, because not only you're spending a lot of money on an employee's salary or clients are worth a lot of money, and you want to make sure they get done right, and then just build a framework. So, build an MVP. Just say, "Okay, these are the kind of normal 10 steps that we do every time we set up a client," and then just start there, and then don't touch it again until you onboard your next client.
Now, when you go and onboard your next client, open up that document, the process of using Process Street, and run through it, and say, "Okay, is this everything that I need to do?" and if there's anything that you forgot in that, add it in. If there's anything that you're doing along the way like, "Oh yeah, I need to go enter this into this portal," just grab the link from the portal and say, "Here's the link to the portal," and just chuck it in the description, so the next time you go, you have the link to the portal.
Or, if there's a document or a form that the client needs to fill, just drop it in and say, "Okay, here's the form for next time. I don't have to go find it from that Dropbox folder or somewhere anymore," and every time you run the process, just give yourself an extra five minutes to just iterate the process a little bit. Just make it a little bit better. Start doing that yourself, get your one process from the MVP, and slowly iterate it over time until it becomes a fully-built process. Once you're happy with that one, move onto the second most important process in the business.
If you can then do this for your managers or other people in your team so you can get them to start building MVP processes and then running on them, that's how you eventually get process coverage, right?
Aderson: I like that. I love that approach, that approach of having a rock, a rough rock that you polish, and you keep polishing, and you keep polishing. You don't have to polish it right there and then. You keep polishing over time.
Vinay: Yeah, so, "I don't have time," is not a real excuse for that approach because writing a task list of 10 steps takes five minutes, and that's it, you're done in five minutes. Then, basically, every time you actually do that task, you just tack on an extra five minutes to do a little bit of process optimization or you just do it as you're doing it.
What happens is, now, making and managing processes no longer takes any time in your calendar, like it's not a thing. It's not a task in your task list, it's not a block in your calendar. It's just part of your culture, like it's part of your day-to-day operations, and you're following your processes, and you're slowly iterating them, and you take a little bit of extra time out to do it when you're doing that task, but in the end, you won't even notice that time. It's also helping you get that job done.
If you build your processes right, you put the information you need, you put in the form that you need, you put in the link that you need, you put in that email or whatever that you need to send, it actually, over time, makes doing that process even faster because you're not going around looking for this if it's on Dropbox, or looking for that thing over there and trying to find that form again, or whatever. You can make it easier and easier to do the process over time, and so you can make it even easier for you.
But then, the huge one out of that is when you grow and you want someone else to come in and do that process, they can just come in, sit down, it's now ready to go, it's all perfect, you've optimized it, optimized it over time, and they should just be able to pick it up and start running. So, when you do get ready to scale or you start scaling.
You asked me what our customer base is, and we have lots of small businesses, but I think a common trait in a vast majority of our customers is they're either growing quite fast or they're trying to grow fast. In that, they're growing companies. They're not stable businesses that are three people and have been three people forever. They're companies that are trying to get more customers, trying to get more clients, trying to grow their team, trying to grow more locations.
They're trying to grow their business, and creating these stable processes is crucial to helping you scale your company. Because, as you add more people and add more customers, things start to break down, right? So, even if they're small businesses, they're focused on growth.
Aderson: Awesome, love that. I love the one thing there that you are wrapping things up. We are wrapping things up here. Before I let you go, just tell us how can people reach out to you, contact you guys, contact Process Street. I mean, just give us the bread crumbs.
Vinay: Absolutely. You can sign up for a free account with Process Street. We have a free-for-life plan at www.Process.st or just search Process Street in Google, and then you can follow me on Twitter @vinayp10.
Aderson: Awesome. Again, as I said before, I'm a client, I cannot recommend enough the tool. Tutorials are great. I mean, if you just want to get started, there are plenty of tutorials. There is an onboarding call as well. I've not been paid to do that. I mean, this is really sincere, honest feedback here. Vinay, thank you very much for being here, thank you very much for your time, for sharing your experience, your knowledge, awesome.
Vinay: It's a pleasure. Sorry about the sun in the face.
Aderson: No problem. That's good, great. Talk to you, bye.