How To Improve Your Ecommerce Agency With Joseph Maxwell of SwiftOtter

Guillaume: Hello everyone, Guillaume Le Tual here, host of the Ecommerce Wizards Podcast where I feature leaders in e-commerce and business.

This episode is brought to you by MageMontreal. If a business wants a powerful e-commerce online store that will increase their sales or to move piled up inventory to free up cash reserves or to automate business processes to reduce human processing errors, our company MageMontreal can do that. We’ve been helping e-commerce stores for over a decade. Here’s the catch, we’re specialized and only work on the Adobe Magento e-commerce platform also known as Adobe Commerce. We’re among only a handful of certified companies in Canada, we do everything Magento-related. If you know someone who needs design, support, training, maintenance or a new e-commerce website, email our team at [email protected] or go to magemontreal.com.

Today’s guest is Joseph Maxwell. And I’m happy to have you with us today, Joseph.

Joseph: Good to be on here. Thank you for having me.

Guillaume: Yeah. So Joseph, a few years ago you won the prestigious Magento master award, so congrats on that.

Joseph: Thank you.

Guillaume: I was not surprised at all to see it happen. So yeah, if there was somebody to get that, that should be you. Joseph is also doing great work with all the coaching and training for Magento developers. All our new employees are sent to one of Joseph’s classes for training in addition to our own. So great work there. So Joseph today we’ll be talking about rescue projects for Magento especially since we don’t have Magento expertise, feel free to broaden the topic anytime you want. Before we start, can you tell us a little bit about yourself and your background as an entrepreneur?

Joseph: Yeah, definitely. I actually have been writing codes for a while. I started when I was 10 years old and I’m 33 now, so that’s 23 years, that’s a lot. I won’t say it was like any good for the first 10-15 years of my career or experience, I cannot call it a career at that point. But I had an absolute blast when I wrote it for many hours a day. Back in 2011 is when I started on the Magento platform. I very much enjoy working with it for the most part. One of my favorite aspects of this is, I’ve gotten in and built out so much of this training material that I feel over and over again has helped me very much to develop a very solid understanding of almost every area of Magento because I know there are some areas that I’m still weak in. And I’m not saying I’m the best anyway, it’s just that I feel like this has forced me in a very systematic way to work through almost every aspect of Magento, and I’ve loved it, it’s been really good for me.

So back in 2016, officially 2017, I started the company SwiftOtter. So we build websites on the Magento platform similar to what I know you guys do, and the trainings have kind of come out of that. So we had a lot of growth over the past year or two. I’m just really excited to work with the people that I get to work with and I still build this training material out and help merchants and help developers both succeed in what they’re doing.

Guillaume: Right. About the training part, I can relate to that. It was one of those crazy guys who actually read the whole help file, the photoshop and every single thing. So I knew the whole thing inside out back then.

Joseph: Good for you.

Guillaume: Yeah, exactly. You go systematically step by step, there’s no secret, if it’s in the dark I know about it. And the certification process is in most regards more important than the certification itself, of course certification is just there to confirm that you finally got it. But it is what you learn through that process, if you are just self taught you might overspend more of your time in areas that only interest you and so you might have weaknesses and blind spots in other areas. But if you go through training then you’ll have to check every step of it and you’re more well rounded which is better.

Joseph: Absolutely. I think I’ve seen it over and over again. Even in an agency setting, there’re so many people who are really good, and I’m talking about within the discipline of front-end or the discipline of back-end. Like they’re really good at certain things and don’t have a clue about other things. That certification process helps round out that knowledge and provides at least passable scores on some areas and obviously combined with the excellent scores that they get on other areas. So yeah, it’s very good as far as forcing you to systematically work through the system and you learn a lot. The extra productivity that comes from being certified and going through that process is tremendous. So yeah, I don’t see any downsides other than it does take some time to work through that process. But I’ve yet to see any downsides to making that type of an investment.

Guillaume: Agreed. All right, so let’s dive into our main topic, rescue project. So let’s say you have a merchant that has a disastrous project. I think we can explore many aspects here like, what you can do in the first place to try and avoid it. We can come back to that. But let’s say you have a disaster project in your hands right now or you’re afraid it might turn into one. Like, how do you see the situation? What would be your advice to a merchant?

Joseph: To a merchant, my number one advice is communication. Every situation that I see can mostly be boiled down to communication. Now, I mean, there are definitely clear cut times where it’s a developer inexperience on a project or mismanagement of one aspect or another definitely. But at the end of the day, much of this boils down to communication, as far as the umbrella problem here. So let’s take developer experience, for example, one might argue that the project was oversold, like, the developer capabilities were oversold and we got into this issue which could boil down to a communication problem. But I bring up communication first because I believe that is the number one cause for problems, lack of communication. And communication, in my opinion, is one of the best solutions for problems. Good way to get out of a problem is to communicate.

So in this example, I hate to even talk about this subject but it’s so relevant and so necessary because it kind of goes back to the training and why we are doing this. There have been a lot of projects that have just been completely mishandled and messed up, a lot of it comes back to developer experience. They don’t understand specific areas of the system. Here’s an example, we just recently took over a project that had a really complicated, you might say, configurator. A very well known agency built this out, if I say the name you’d recognize it, and as I was working through the code myself, I saw a number of situations where the developer did not use Magento best practices. For example, in communication from this configurator which kind of lives on the front-end and then communicates via a web request back to the back-end to like save information or fetch new information like pricing or whatever. He was actually using the mechanism, and I’m trying to keep it in layman’s terms here, used to render HTML but it was actually returning like the structured data format called JSON. That was one issue.

The second issue on top of that is, the developer who built this out actually ended up creating a three or four, maybe it was five endpoints. Endpoints meaning like HTTP or internet destinations for this type of work, so like saving this particular configuration. At the end of the day it added extra bugs, there were multiple paths to be able to get to this which created a lot of problems. And so all of this stuff, that’s why I put that into developer experience, comes down to communication in my opinion. So the merchant, I think, unfortunately, gets afraid that the developers are just going to dump them. And unfortunately, the developers on the same play point are also afraid that the merchant is going to dump them. So the lack of trust in my opinion is where the breakdown of communication starts. So we’re going to unpack there a little bit with a couple of ways to approach that but I feel like that’s a decent overview as far as how these problems start. Does that make sense?

Guillaume: For sure, communication is one of the very big ones. Being oversold also, as you said, even if you go to one of the big name agencies with hundreds of employees that belong to a group of 1000s of employees, that belongs to a multi-billionaire group. I mean, you might not get the A team when you go there. So the sales team does the sales pitch based on the capability of the A team but then you’ve got the F team and you hope the project doesn’t fail.

Joseph: It’s a real thing. I’ve seen it in a lot of projects where we’ve done a decent number of audits. I see and I get a firsthand look at some of this stuff and it’s amazing the code that is put out there. Then merchants spend their entire development budget for the next year on fixing bugs. No wonder they’re frustrated because it feels like all they do is fix bugs all day long and so they’re not able to develop and kick out new features.

Guillaume: Yeah, so it feels like we are standing still and not making progress. We’re not building new features, tracking new market tactics or whatever, we’re always fixing problems. So that comes from a lot of bad practice implementation, that’s for sure a big one. So I would call that the craftsman’s ability and the craftsman’s skill level, whether it’s a programmer front-end and back-end developer for system integration or whatever else, communication is overarching for everything. Then you have the skill of the project manager. They’re all important, of course, ideally, you have A players all across. But let’s say if you had to pick between a very strong manager with an okay developer or very strong developers with an okay manager, which team would you pick?

Joseph: If I could back up on that question. I think the challenge is first, merchants don’t get a pick and maybe some of these companies are different, but if they were able to pick the second thing is, how would they make that type of decision? In my opinion, it is a difficult way to approach that because at the end of the day I think it comes back to developer capabilities. And I’m going to throw this out, it’s kind of a self serving plug but ultimately it’s not. I think certified developers are one of the most important metrics. I’ve heard people discuss that and basically, some companies actually are charging more for certified developers. But at the end of the day the question is, why aren’t all the developers certified? And I get reasons why or why not, that sort of thing off road. But at the end of the day, again, forcing developers to go through this process of getting certified benefits them and obviously, also benefits the company with better reputation, there’s nothing else higher up on the partner’s page, you know, in that ranking order, I think they’re two. And we can get into how to motivate developers to issue certifications, that’s a completely different topic. But I believe that one of the best ways to validate that is to ask for the certifications of the developers working on your project on what they are certified in.

Guillaume: Exactly, which level? So there are three levels, we have the professional, the expert, and the master. Definitely try to get the certified staff on your project, that will help. But that is not a guarantee of success, it’s just that they’ve met a certain threshold, it’s not 100% to earn a certification, you know, even any test at school or university, you don’t need the 100% mark.

Joseph: Less than 70%, between 60 and 70% is a stressing score.

Guillaume: Exactly. So they’re not perfect but they’re very good. The next part comes down again to communication and work ethics. So I’ve seen some programmers who were technically wonderful but were lacking in work ethics. They might actually underdeliver compared to a technically weaker one that has more customer care, more care for people, more human touch, attention to details, trying to polish the final product really well. So the human aspect from my point of view is more important as long as you have someone who’s reasonably qualified and has certification. I’d rather pick the guy who’s certified, who is not a genius but cares about the customer, cares about the final product and has pride in the quality of their work and really wants to deliver something amazing that he’s proud of.

Joseph: That’s great. I think the challenge is, how would a merchant discern that? Because I 100% agree with you, you are absolutely right. One thing I would suggest is that it comes from the top. If the top of the leadership at a company is motivated, they’re driven and their desire is to please the customers and ultimately do what’s best for the customer. Because ultimately, and I’m going to throw this out here, the position that you and I are in could be viewed, well in providing advice, you know, as we talk to customers we provide advice, could be viewed as a conflict of interest. Because ultimately, if we are just only out there to push and get more work and more hours and all that stuff from the most sinister, terrible point of view, one could say that bugs are actually self-serving. Because that kind of keeps the process going as opposed to doing everything we can to minimize at least, problems and any other unnecessary expenditures in an engagement which then makes the customer happy. So having a long term ethical approach, and I’m not saying I’m honestly not aware of any companies that do maximize bugs or do any of these stuff.

Guillaume: Yeah, but you don’t have to with Magento quite frankly.

Joseph: That’s the problem. But having developers, and it comes from top down and I’ll elaborate here in a second, who are focused on the big picture, who are focused on how can I eliminate this bug once and for all as opposed to temporary fixes, you know, learning, testing, and building out automated CI/CD and some of these stuff that will ultimately reduce problems in the long run. That’s the kind of stuff that I believe ends up coming back and making merchants happy. Giving advice that actually goes against the best interest, I say, the best interest that reduces the number of hours that a merchant spends, goes to build trust. And that all comes down to trust.

Guillaume: Yeah, it’s true. I see what you mean there, it would be to our benefit as agency owners to maximize the billing hours, but that’s a short term view. People who think like that have a super short term view, you know, I have been around for 15 years and we’re planning for the next 15. So the long term view on the contrary is, you want to be a source of trust and a source of expertise. They come to you and say I do have a consultation with the CEO. That’s valuable and it’s perceived both ways and with respect from both ends. And then you give them advice that’s best for them. I had a startup come to me while he had two businesses which is a huge one. And then he’s starting a new one on the side, well, if you’re a startup, you don’t have the financial backing of the other one, like, you should not use Magento. This is a learning management system, go shop in the LMS section. Then they come back to us and they are like, wow, you actually turned down my project? And I’m like, yeah, I did. I just did that. So that’s it, you should not go for Magento. It’s not the right fit for this. When they see that kind of integrity they’ll trust you way more in the long run. It’s such a beautiful relationship.

Joseph: Absolutely, that’s what it has to be. In some of these cases, we could talk about millions of dollars over the course of years. And it comes down to that mutual trust, the merchant has to trust the agency, the service provider, the service provider has to trust the merchant. It’s a mutual trust. And when that happens, it works so well. When that stops happening, in my opinion it’s best just to fire the service provider. I know that’s a harsh word to use but that needs to happen sooner rather than later. Honestly, I will say that one of the biggest mistakes that we have made over the course of time is not letting a merchant go soon enough.

As much as I wish we could help them, I know that there have been a couple of times where I feel like that trust has been lost and we’ve tried to regain it and we’ve done our absolute level best. Honestly, that trust is usually lost in our experience and we take notes on this to help us learn and to avoid these mistakes in the future. It goes back to communication, we didn’t communicate. That’s usually how that ends up starting to devolve. Coming back to your other comment about a better developer team or better project manager, it’s kind of hard to sacrifice the project manager because depending on the company, the PM, at least for us and some other companies, is the person who builds that trust, who establishes that trust, who keeps that relationship going, who communicates on everything. They’re basically the face of this company to the merchant, and so having the right person as the PM is ridiculously important.

Guillaume: I’ll ideally just take the strongest team overall for the whole thing. But otherwise, the stronger PM, I believe is more important because of that communication, clarification of expectation in the Agile workflow. That would be like a senior product owner who will really deep dive into the user requirements and then the acceptance criteria and really follow through with all the technical solutions and really map the whole whole thing. So he’s like the glue holding all that together strongly and keeps the customer relationship and happiness there. And if there’s something because the team is not that strong, he’s just going to rework it, he’s just going to take it on himself just like no, we honor quality here, just redo that, that doesn’t get our signature on it, and just keep pushing the team as a coach. I believe that is the most important one, an amazing PM and they’re just as hard to find as master developers.

But ideally, you get it all across the board. That is also another signal. As a merchant you are evaluating a new team, do you have a very strong PM heading this? Do you have very strong craftsmen? And do they have certification? That in a nutshell is a first due diligence verification. Then past projects like, what level of technical difficulty and complexity is your project at? Can you show me something of equal or higher complexity that you’ve done before? I don’t care if it’s a big name or a small name, don’t show me that you’ve done a landing page for Nike, I want to see a super complex integration, and what was the most difficult project that you’ve done and the engineering problems you’ve solved on it? Show me that and explain to me how you’ve solved it.

Then we can say do you have the chops to do that specific job? And as an agency, you need to know where to stop. There was one project that was just too big for us and we said, “You know what, let’s go see that mega huge agency and see if we can get a partner or maybe even just pass it over and have a reference for you or something.” Because at one point, you have to say that’s too big, it doesn’t fit in the blender, or a team of a few dozen people, it just doesn’t fit for us. That’s for the mega agencies of this world. So that’s important. Does the agency truly have the capability? And is it only the A team who can do it or other teams, perhaps the one you’ll be assigned to, can that team do it too? Because that’s how a company is built. It’s built on multiple teams, new product owners, new project managers, new lead developers, new back-end and front-end developers being grouped together as teams. That’s very important to keep in mind, you don’t want to end up with the interns, you know.

Joseph: That’s another challenge, like you said earlier, it’d be really nice to hire rockstar developers, everyone on the team is just like a master-level rock star, and I’ll throw this out there if any of my team is listening, I’m really privileged that our teams are rockstars. But that said, to junior developers, if you’re listening to this don’t take offense. Merchants don’t want to work with junior developers, they want to work with senior developers, that’s all they want to work with. But at the end of the day, they don’t want to accept the cost for only working with senior developers. So again, it kind of comes back to that communication, setting expectations, correct estimates, on the project and these issues. And at the end of the day, once you get the labels aside, junior developers do great work then it doesn’t matter. Again, it comes back to having these conversations if it comes up, because again, I’ve had a couple of conversations come up, they say, “We think we don’t necessarily want junior developers working on our site.” And I’m like “You can’t have it both ways.”

Guillaume: Yeah, there’s a business solution for that, which is the rate card. You may have a blended rate for the whole agency but if you have a rate card then you can have the junior doing the more simple stuff and it’s perfectly logical. It goes back even to the old principle, the master and the apprentice. You don’t really want the master to be cleaning up and scraping the canva, give that to the apprentice. So it’s just normal to have a few juniors if you have some masters supervising them, but you do need to have the master expertise that’s available when needed to unblock them, otherwise you will have to work as a deliverable.

Joseph: I think the other thing is, from the agency’s perspective, being truly honest about who’s on the team, like you said, it is absolutely normal and good to have a mix of junior developers on the team because that’s how they come up through the ranks. If a junior developer works by themselves, and that was kind of my story although I did have a mentor for some of the time, the learning curve is really hard especially with some of these conversations. So the key point is, though, helping the junior developers get up to speed, but what I was originally saying was, the agency needs to be honest with themselves as far as the true capabilities of their developers.

I have seen quite a number of cases where senior developers, at least in their job title, cannot pass the professional level test, again, professional is the lowest level of certification. They cannot pass that test, which again, means somebody’s not being honest with themselves. As an owner, it’s easy for me to overstate my capabilities and have to work with that, even with people I work with, I want to be honest with myself which allows me to be honest with my clients as far as where our skill level truly is at and what things we’re very good at, what things we’re decent at, and that sort of thing. I think having those honest assessments and using certifications as somewhat of a barometer for the team’s capabilities is, like you said earlier and I completely agree, not a 100% test. But I would put it into a decent category to kind of just help identify job titles.

Guillaume: Yeah, for sure it does matter. Number of years of experience does matter too, but not as much as the question of talent also. How much work do you put into each work hour? You can go to the gym and just hang out for three hours and you never really worked out. So there’s a question of how much work. If you try to put them into broad categories of like rescue projects. There’s the worst total disaster that’s close to a scam where the agency or the freelancer took a lot of money and sort of delivered nothing or close to nothing. I’ve seen that extremely rarely, once every several years. It’s a very rare use case.

Joseph: That’s lawsuit material there.

Guillaume: Yeah, exactly. That’s different and that’s very, very rare. Typically, it’s more of a lack of technical capability, or overselling or a company growing too fast, that kind of stuff, mismanagement of a project and then they’re not able to deliver on the goods. Some of the problems there typically happen with unclean project management that there was work done all over the place. But then if you tried to part ways with that other company, it might be complicated. If you’ve really just worked on the time and material it’s simple, they give you the code, you pay the bill and you leave, typically, unless there’s a cancellation fee, or something like that. But if there is no such thing, and they work by milestones, and they get paid by chunks of 20%, or whatever, then it can be hard to really say where you’re at if they’ve worked in an unclean way. There’s stuff started and not finished all over the place that doesn’t work, that can be more part of a conflict. And it’s harder for even the other agency to take it over. They say, “Okay, do you even have documentation where you’re at? No, okay, fine, we’ll do our own inventory of what you want and where you’re at on each feature of the project plan, and clean it up.”

It typically comes back to lots of faults there. So it is just craftsmen, then it’s project management failure. That would be on the provider side of things. I don’t know if there’s anything you want to add to those high level categories, or sometimes maybe just a misfit between the provider’s good work, but they don’t get along well, then they want a new provider, but that typically just hands up like okay, you finish the job, they delivered a website, and then the support goes to another company when it’s not a fit, because they still delivered the job. I don’t know if there’s anything you want to add?

Joseph: I think that sums it up well definitely, failings on the provider side. It pretty much like you said comes down to overselling, project management failures and development failures.

Guillaume: Even though we’re advising merchants now to help them with a failure project, recovery project, what are the responsibilities of the merchants as well? Or issues that they might have caused, what’s the merchants part here? It’s not necessarily 100% the fault of the provider sometimes.

Joseph: Now I can get on my soapbox, because I’m not talking about people like us. That’s not how I operate. I agree because there is responsibility on both sides. And I think a couple of aspects that I have seen contribute to this, again, I’m going to talk about communication in that. One of the first things is putting pressure on the provider to fit within a certain budget. Like, “Hey, I got this large project and here’s X amount that we’re going to do for that and by the way, we need all these features, and these are really important features, and we cannot live without them.” And the provider says, “There’s no way we can get this done for this budget.” And the merchant says “Yes” or “We’re leaving” that sort of thing. Depending on the workload of the provider, if they really want the work, they might try to sit down and try to sharpen their pencil and try to get this project done.

The big project we just released here was, I think a classic case, they’re like, “Hey, we’ll do discovery in the next phase, just sign here.” And they get into the discovery phase and they’re like, “Well, we were supposed to ask this question.” And they’re like, “No, that was before.” So basically, we’ve already come down to the project and here’s what we’re building for you and you’ve already signed. I don’t know exactly how much in that specific situation was the merchant putting pressure on them in that way. But trying to fit too many features into too small a budget, I think is a no go recipe for disaster from day one.

Guillaume: Yeah. Another one would be to not understand the level of complexity that goes in building this because there are millions of websites out there and you may just have a bit of magic thinking.

Joseph: Like Amazon.

Guillaume: Yeah, just like Amazon. Real story. “I want this better than Walmart.” “What’s your budget?” “10K” “What? You want to do better than Walmart with 10k?” That’s probably like their weekly spending or something on the website, maybe even daily, who knows?

Joseph: Or an hour.

Guillaume: Maybe, who knows. There’s the question of realistic or unrealistic expectation, but without going that far can be just to understand the level of complexity of the work that has to be done. That’s one really, really important aspect. Another one is unless you have a very clear product by service that you bought from the provider that says, and we’re going to deliver this many content pages with two rounds of revision and photoshopping and whatever. So unless you have a very, very clear checklist of what’s included and what’s excluded, and even then, unless you have, like, I don’t know how many pages documenting all this, there will be all kinds of gray zones that are really unclear and takes a lot of work and can create a lot of scope creep, even if both parties are of goodwill.

So there’s a question there that sometimes is simply solved by saying, “Hey, we work hourly” because then it solves the gray zone question, both parties are sort of more or less aligned, help us save time, and we’ll help you save money. There’s always conflicts that you say, “Hey, you win, if it takes you more time.” But you say, “No, we have so much work, that is not what we’re trying to do, we’re trying to just deliver this project as fast as we can, and respect the budget.” The amount of gray zones is unbelievable. And I’ve seen cases of also trying to upgrade the project. It’s sold as an entry level project, you could say it’s trying to turn a Toyota Corolla into a Ferrari, but don’t want to pay the upgrade price in between. It’s like, this was sold as a template editing project, now you want a full custom for absolutely everything and you want to reinvent how Magento works and spin it on its head.

Joseph: Absolutely. I think it comes down to expectations. If the merchant sees the provider as expert practitioners, which should be the case and the merchant should be worthy of being seen as an expert practitioner, then I think that can work just fine. Because they will say, “Okay, well, this is what is being stated as being necessary in order to accomplish this feature, that makes sense, I understand, I’m going to pay for that.” And I totally agree with you that there are sites of almost any size with so many gray areas, and there has to be that understanding going into it that as best as we’re going to do to try to nail all this stuff down, it’s not going to be nailed down plus, as you actually see it. Hopefully, there’s mockups involved in that discovery phase. But as you actually put your hands on it, and click around it, there’s probably going to be stuff you want to change. So having that understanding that there will be change orders and we’re going to work through this process, it could be a months long, or even years long, involved process to get the site kicked out the door. It’s not going to be just something we can flip a switch.

I think that comes back to another point. I do evaluate as I’m talking to a merchant is, how reasonable are they? Is it from a perspective of, we’re going to make mistakes, and are we going to be able to work through that mistake? Or when it comes to scope creep, are they going to understand that we’re trying our best on this, fixing this bug or implementing this feature, but it is taking longer than what we thought? And that’s again, where communication comes back in because if we get to, say 98% of the budget for this, and we call them up at that point and say, “Hey, we think we’re going to have another 50% of budget needed for this particular project.” That’s where you start putting on the brakes real hard, we got some big problems versus if that is communicated much earlier, do we want to stop this? Do we want to back out on this feature? Do we want to put it on hold? Do we want to space it out over several months? All of that stuff is important.

One other aspect of this, and I think it applies little bit less to new projects, as it does maybe a little more onto maintenance is budgets. I believe, from my perspective, merchants shouldn’t be afraid to share the budget with the provider provided they trust that provider. And I think, again, that’s kind of those first initial conversations, I always bring a budget. When we, as a provider, know the budget that you’re going for, that you’re going to be happy to spend, we will stick within that. Even for new builds, depending on whether they want it to be metered out and that sort of thing, that’s where it becomes relevant as well. Those budgets are absolutely key, because for example, let’s say in the onboarding phase, the merchant throws over 50 tickets and says, “Hey, all these are really high priority, and we got to get them fixed as soon as possible.” Well, then they get hit with a $50,000 bill or whatever, then they’re freaking out like, “Well, that’s way too much. We don’t want to spend that.” It’s like, “Well, but you wanted us to work on all these and we provided you estimates.” So there’s kind of a disconnect.

Guillaume: Oh, yeah. You approved all the estimates.

Joseph: You did?

Guillaume: Yeah. But I didn’t know it totaled that much.

Joseph: That’s right. It does.

Guillaume: So that’s a funny one. If you approved all the estimates, one by one, it’s your responsibility to keep track of the total. You did provide a written approval, I’ve seen that real case.

Joseph: But that’s where the project manager comes in because the project manager, if the budget has been discussed or even if the budget has not been discussed, the project manager should be keeping the client apprised as far as possible.

Guillaume: Oh, yeah, if it’s really a project. But I was thinking of support like you were saying.

Joseph: Exactly. Even on support, yes.

Guillaume: Anyway, that’s funny. When I place an order I know I have placed an order and I know I’m going to pay this. That’s just a funny story.

Joseph: It’s a legit story.

Guillaume: I know, we’ve lived that too. It’s an annoying story. It’s funny that you have to even spell it out. Otherwise, most providers will work hourly and not per project base. Or they may have an initial project base for something with some kind of initial offer and then they will go hourly after that. So on the hourly side, for any project, you have to decide priority number one and you cannot have three? There’s only one. So it can either be the budget must absolutely be respected, say, like kind of have round numbers, pretend that you have $100,000 debt set and you cannot go over it because it was actually a loan from the bank. So it can be the budget or the timeline, it must go live by June 1, or whatever because it’s an event, or it can be a list of features where you must have all those features and we cannot compromise on that. But you cannot have all the three as priority number one. So you will have to pick which of the three is priority number one, we don’t move the timeline or the budget or the features list. For most of the merchants the question of timeline is the most important for a company of a reasonable size. Budget, as long as it stays reasonably within the range tends to have a bit of flexibility. And maybe we can sacrifice one or two features that we thought were a must have or maybe are just nice to have, or we could have them in phase two.

So you have to pick which one is your number one priority, because otherwise, it’s a recipe for frustration, disaster, useless drama, and unproductive drama. There’s a fourth one, which is your provider’s costs and profits, or lack thereof, if you start to squeeze them and then you start having a super toxic relationship of trying to lead the provider. It will change how they treat the client, they’ll start cutting corners because they just want to survive. And that is typically just a failure on another level of trade of character, of communication, of legal contract, clarity of proposals, and stuff like that. It is always preventable when it gets there for any business. But anyway, you have to pick one of the three and stick to it, which one’s priority number one.

Joseph: And that’s where it goes back to being reasonable. In my opinion, it encompasses this whole idea because you have to understand that there is X number of hours to get this done. Now, you can flex that number of hours up, or flex it down if you hire more qualified people. I say qualified, you know people who are more experts or not. So that’s an option. But your chances are, your hourly rate is going to be affected by that. It’s hard to find a company where you have enough people on staff that are of expert or master level, if I can use a certification terminology, that’s not going to be just ridiculously expensive or have rate cards that are associated with that. So again, it comes back to that understanding that it’s just going to take time to build the project, there’s going to be some bugs, hopefully, they’re going to be minimal, but there’s going to be some bugs and there’s going to be some problems.

Guillaume: It’s unavoidable, even Apple with an army of testers will have bugs after release. So that’s unavoidable. It’s not if there will be some, it’s just a question of how we handle them. We give them a 30 day bug fix warranty after the publication of the work just for inspection. So it’s part of the game but it’s normal. It’s how you handle the problem and then fix it.

Joseph: Absolutely.

Guillaume: We’re talking about horror stories here and it feels like yuck. But anything else that you’ve seen may be on the merchant’s side, of course not the person who’s listening because they are not going to do that, but other situations like this where the merchant had something they could have done better, or taken a part of the blame. Any more of those situations?

Joseph: Communication is really the biggest thing that I have observed from a merchant’s perspective. There’s a merchant who recently, we took over the project and they were partially taking the blame for the failure of the previous project because of lack of communication and their expectations they had for this project. Again, I think those were somewhat inappropriately set by the previous provider. But I think being incredibly clear with expectations even on an issue by issue level, this is exactly what we are looking for. And one little hint for merchants that are listening to this, if you want to reduce the number of developer hours when you’re in maintenance mode on a ticket or whatever, make sure you have a very clear replication scenario and that’s something we push for all the time. Because if we don’t have a clear replication scenario and we get in there, we’d want to do our best and understand where you are at, whoever submitted the ticket, and understanding that if you don’t have a lot of time you’re probably not going to give us a whole bunch of detail.

So we’re going to go in and try to figure out these details, which just does take time. So if the merchant is okay with that, perfect, fair enough, no problem. But depending on the merchant, if they’re more cost conscious that can over time add up, so make sure to do that. But yeah, clear expectations on these tickets, well defined acceptance criteria is another thing. If the provider helps you with that, great, throw your own first edition of acceptance criteria for each one of these phases of the build, or of the different aspects of the build. That’s, again, being very clear what you expect out of this and if the merchant doesn’t live up to that well then, find out why and, you know, have those conversations. I think those are the couple of last things I would want to mention.

Guillaume: Yeah, for sure. If you want to save on costs that’s the clearest explanation there can be. How you can replicate the bug and in which scenario does that happen, on which page you’re at and give your URL whether you are on your phone or on your desktop, especially if we don’t have a screenshot of it and so on. So for sure, you’re going to save money. If you’re in a rush, fine, but know that the bill is going to be higher because first of all, the bug has to be replicated before it can be fixed. That’s for sure.

Now let’s say as a merchant you’ve heard all these tips on how to pick a new provider, anything else about how to choose the next provider? We’ve sort of covered that, like the need to have good communication, strong PM certified developers, a company that does not overpromise on its abilities and sort of knows its own strengths and limitations like, can it really take the project, and, who will work on it. Okay, you might have one certified guy, but will I get that certified guy on my projects? Okay, so while we’re getting there, clarification on billing, juniors can be fine for some tasks. You can save money sometimes with juniors but they may need more time. You just need to send them to the correct task and this can actually be good sometimes.

Joseph: And that’s how they uplevel, again, it comes back to understanding. That’s how junior developers get better and depending on the company they might discount or have a different rate card, but that’s how this junior developer gets more capable and the more capable people you have on your team, the better off you are. So it’s ultimately a big win for the merchants themselves as well.

Guillaume: You need the trust in the relationship. Yeah, so a certified Adobe Magento agency is good. But again, back to who’s going to work on it, that’s important too. I think that covers lots of really high level things.

Joseph: I liked what you said earlier about past experience. I also liked the perspective you took on that. I think that it can be a mistake for merchants to say, have you done this project before, like, for somebody else? As opposed to saying, what level of complexity are you all comfortable with? There are some big agencies I’ve seen that put out very subpar work, because from my observation they’ve put out a whole bunch of, say, smaller cookie cutter websites which unfortunately are kind of just like Shopify in my opinion, but they were on Magento. I mean, that’s basically like putting in a new theme and throwing it out. But then there comes a project where there’s some heavy checkout customizations and they are significantly struggling with this, because all their experience is easy stuff. There’s nothing wrong with such an agency just to be very clear on that, it’s just that, again, being honest with what type of projects you can accept. And as a result from the merchant’s perspective, getting references is not a bad idea at all. And again, if you’re looking to spend 100 grand or a million, or whatever it is going to be, having that understanding, like, okay, I’m actually working with them and I trust them, I think that’s the biggest thing.

The provider should be providing a path to accelerate trust, and again, trust does take time and so it’s not going to be immediate, but the quicker you can build that trust the better. And you see, again, understanding that it’s going to be apples and oranges but I want this apple, what’s the closest orange to this apple that you’ve built? Like if I need this weird ERP integration for an ancient platform that we’re using, have you done any ERP integrations or any of these tools? If not, well, is that going to be an issue? Have you done any integrations with anything at all? l mean, just trying to broaden the scope of an understanding as far as what level of expertise they have on some of what seems to be the more thorny issues of a build.

Guillaume: Yeah, exactly. Very often, merchants tend to overvalue things like, I want grocery, have you ever done a grocery website before? That’s not relevant that much unless it is a marketing agency, they can speed up their marketing if they do a lot of the same. It cannot be bad to have done similar things. Then you can say, on which ERP are you? Let’s pretend it’s Epic or whatever, have you integrated that before? Then you can say, what else do you need from a technical point of view? Well, you know, a homepage of product detail page, a product listing page, normal checkouts, etc. Well, I guess we don’t need any kind of grocery experience to fulfill this. You’re the same as every other website from a technical point of view. We’ll just have a different branding and logo on it. So it’s part of the assessment of technical capability of that provider.

Joseph: Absolutely. Yeah, and that’s well put. Good job.

Guillaume: Yeah. Then it will be a question of transitioning from your current provider to the new provider, assuming that goes well, like clear settlement, handing over the code, handing over to the Git repo for the version control stuff. And then you have the financial settlement with them, and then you’re ready to move on with the next agency. The next agency will work hourly, like nobody takes over a past project at the project phase at flat rate. They will take back the construction fee as is, but it’s hourly. And then you want to really box this module per module or section per section. Let’s really nail the homepage, let’s finish this thing. And then okay, we’ve checked them with the homepage now let’s move one module at a time and try to reduce the scope to what many will call the minimum viable product, you could upgrade that a little bit to the minimum lovable product, and then you can publish this thing and then do a phase two to put additional features on it.

Joseph: That’s absolutely right. That was another head downer. The new agency should do an audit. I guess the one caveat is, the merchant could also do that, not from a code perspective but from a functionality perspective. Like, here’s where we are at, here’s the bug list and ultimately in a situation like that moving over, I think it’s much more successful if they deprioritize things. I’ve seen cases where everything after a move like that becomes the highest priority. And as such, there is no prioritization, because everything is the highest priority.

Guillaume: Everything’s critical.

Joseph: Yeah, and in fact that means nothing is critical which means that you’re not getting as much service. So you have to be honest with yourself. I’m saying this from a merchant’s perspective, you have to be honest with yourself and say, this new development team has only so much bandwidth. Again, that’s where a budget can be very helpful, because if the merchant and the provider agree on a budget of $50,000 a month or whatever, then that’s the provider saying we have this much bandwidth and the merchant saying I want to spend this amount of money. It’s kind of an agreement in that way, which is really valuable. And then we say, we have this amount of time so what are we going to focus on? And so having issues properly prioritized can make a significant difference as far as the effectiveness of this new engagement.

Guillaume: Yeah. And to go further on this, I’ve seen some cases where a feature is mentioned as critical to replace the existing website with a new website, like, “Hey, you don’t even have it on the current website”. If you want to go to the market super quickly how is that truly critical because your current lifestyle doesn’t have it? So you can have a bit of an honest introspection and say, you’re excited about that feature and you would really love to have it and see it go live, then it’s up to you. But if you are willing to wait an extra two weeks’ sprint to have it, then you can have it.

Joseph: Well, the other part of that is, provided everything is properly scoped out we could actually deliver and then two weeks later deliver this new feature, which is almost not going to be a problem at all. So just getting the site out the door as quickly as possible and then adding on whatever we want as opposed to getting it perfect, which I love the quote perfect is the enemy of done, so we can strive for perfection. Back in my earlier days we did a very large project that was literally that. We were just like, we don’t want this feature, we want that feature and that can push out the timeline. I look back and it’s like, yeah, we got the site out but we certainly could have done a lot better with that project.

Guillaume: Yeah. We’re coming on top of the hour Joseph. Just a shotgun question, any last thoughts on this topic?

Joseph: So I think we’ve covered it pretty well. I mean, both from the agency’s perspective and the merchant’s. I guess one of the things I would say is, do a retrospective. When you’ve gotten to the point for an agency to let a client go or a relationship has gone south, do a retrospective and write it down. The same goes for the merchant who is not happy with a provider, do a retrospective to see what you could have done better. Your memory will be no fresher than it is at this very moment, write it down and you will have hopefully an honest assessment of what you could do better because obviously writing down acknowledges that you had some part in this. Write it down and then hopefully reference it later in your next engagements.

Guillaume: I’m going to add that retrospective is good even when things are going well at the end of any work sprint. It’s part of the Agile process at the end of each work, but retrospective is just a continuous improvement cycle. What did we do great, what could we do better next time? So Joseph, thank you for sharing your thoughts with us today. If people want to get in touch with you, what’s the best way to reach you?

Joseph: Go to our website, SwiftOtter.com, you can contact us there. Shoot me an email, [email protected].

Guillaume: All right. Thank you, Joseph.

Joseph: Thank you.