How To Leverage Technical Discovery to Mitigate Risk and Boost Ecommerce ROI
As an ecommerce retailer, it’s critical to keep your technology up to date in order to stay competitive. Over the course of your business, you’ll very likely have to undergo an extensive development project, such as replatforming your site. Even though these projects are common, embarking on a big development project can feel scary. After all, your ecommerce site is the epicenter of your business, and working on it costs time and money.
At Command C, we use a powerful tool to help retailers from the start of these projects: the technical discovery. Through technical discovery, we work with merchants to navigate the complexities of their backend operations, as well as their ecommerce needs. In turn, we’re able to define the very best solutions for their specific business.
In this latest episode of Recommerce, Sara and Tiffany, a Command C Tech Lead, discuss the technical discovery process and how it can help retailers in planning your ecommerce project. You’ll learn:
- The components of technical discovery
- Why defining the problem in ecommerce is crucial to finding the optimal solution
- How ecommerce managers can make the case for technical discovery to upper management
- The three greatest benefits of technical discovery for the long term
Full Episode Transcript
Today we are going to discuss the single most cost-effective tool when embarking on a web development project, large or small: the technical discovery process. The larger scale a project, the higher the risk, and the more potential for ROI. So the point that we want to dissect, and discuss, and drive home today is that any time there’s a technical challenge, starting with research and discovery is critical to the success of the project.
I think it’s worth taking a moment to define what we mean by discovery. Our discovery process, for example, is tailored very specifically to each project. But it does consist of some pretty standard components that are all established in order to create a clear and concise definition of the problem.
The technical discovery process is the single most cost-effective tool when embarking on an ecommerce development project.
In tandem to that, we work to create a comprehensive list of constraints and requirements. Only when we’ve defined all of those elements, the problems, the constraints, and any requirements after that can the natural conclusion of this process – a proposed solution – take shape. I think it’s really important to identify where a merchant is coming from on any kind of project, whether it’s a big one or a small-feature edition.
The person who’s in charge, the ecommerce manager, is tasked with coming up with a solution to a technical challenge. They may not necessarily know the answer; in fact, we’d prefer that they don’t come to us with a solution because defining the problem is such an important part of discovery.
Defining the problem is such an important part of technical discovery.
The biggest challenges with this are twofold. One, the ecommerce manager knows a ton about their business. But it can be really difficult to come at the project with a truly open mind about what’s possible. There are a lot of preconceived notions based on the platform that they currently have that lend to boxed-in thinking.
Yes. I’ve observed that part of this is that we tend to work with businesses that have been established for some amount of time, right? More so than working with startups, we’re working with businesses that are coming from an existing piece of software and trying to optimize that piece of software. And what’s really important for us to understand about that particular merchant mindset is that they’re typically coming in with very limited beliefs about what’s possible based on that last piece of software that they’ve been using.
Exactly. And one of the things that we commonly bring to the table during discovery is a request for a list of frustrations. Something that’s always interesting for me to learn from a development perspective are the things that I know must be frustrating but have been so baked into the process for so long that it is what it is at this point and no one’s thinking of them as frustrations. And a discovery process allows us to find those, get at the root of those problems, and then propose solutions to potential problems that you weren’t aware of. They weren’t a part of the overall project to begin with, but now they’re able to be solved.
A second thing that’s really the elephant in the room has to do with the fact that the ecommerce manager, the person in charge of selecting the solution, is probably doing a bit of a tightrope walk around money. They’ve been given a budget. The budget may have been assigned by folks within the organization who may or may not understand the complexity of the problem.
In the technical discovery process, we always ask clients for a list of current frustrations.
Yeah. Thanks for bringing that up. I know it’s not an easy thing to talk about. But it’s a big factor in these things. So what we see quite frequently is a project that is more defined by both budget and preconceived notions about the solution than it is about the problem at hand.
That is not to say that there is no place for budget, right? Obviously, you cannot run a successful business without one. But even when there is a budget at hand, or I’ll go so far as saying a very constrained budget at hand, the worst and the most costly end-game solution is that you’ve invested both time and significant money into a platform that has a significantly shortened shelf life. Or creates more inefficiencies than it was intended to solve.
What we’re really getting at here, I think, is that there are a lot of merchants who immediately understand and grasp the need for an upfront discovery because of all these reasons that we’ve outlined. Even if the discovery process reveals that budget is the most important constraint, we can work from that, we can use that constraint to craft the solution.
Even if the discovery process reveals that budget is the most important constraint, we can work from that, we can use that constraint to craft the solution.
But conversely, there are a lot of merchants who are really ready to make the argument that it’s a time and money savings to bypass discovery. That they understand the project, that they need a developer to just build them something that we need to move fast, break things, get it to market, go, go, go. This is obviously, based on this entire discussion, not our preferred path forward. We really think that technical discovery is vital. Whether it happens as a standalone process at the beginning of a project, or whether it happens tandem and in part as a first phase of the overall project, it has to get done. It must absolutely be completed in order for the project to be successful.
Yeah. The other piece to this that I see being a real challenge and a roadblock time and time again, is that the ecommerce manager understands the need for discovery. But they run into difficulties when trying to get their CEO or their manager on board. Oftentimes, we always try to get those higher-ups to be part of these conversations about discovery because it can be a difficult point to convey and convince someone if you’re not a development team, right? If you’re not in touch with these things.
The discovery process that we’ve so carefully outlined, that we put together, really evolved for us out of years of doing rescue work. We found that projects where the initial research phase was kind of bypassed, whether due to lack of understanding or an urgency to get something completed on a deadline or in budget, when we took on projects like that, we were repeatedly running into challenges where the client or the merchant would come to us as a development team and say, “Oh, we forgot to tell you but we need this.” And it oftentimes is not a simple, “No problem. We’ll plug it into the outside and move forward.” In those cases, the answer from us has almost always been, “Sadly, we would have built this a whole lot differently if we had known.” And then all of a sudden the original budget is completely out the window. The lifespan of the solution has been dramatically shortened, and quite honestly, nobody’s happy at that point.
The discovery process that Command C has so carefully outlined evolved from years of doing rescue work.
Oh, it breaks my heart. Okay. Speaking of breaking, let’s break here. In segment two we’re going to come back and talk through three bullet points you can use to make the case to your team about why the discovery process is so imperative.
Interlude: You are listening to Recommerce, a podcast for ecommerce wearable brands navigating technical complexity and change brought to you by Command C, a development team that saves ecommerce retailers from outdated tech and ineffective operations with a strong focus on Magento and Shopify Plus. You can learn more about how we help at Commandc.com.
All right. Welcome back. We want to take the second half of this episode and talk about some tips that you can use to make the case for the discovery process to your higher-ups.
First and foremost is mitigating risk. I think we really addressed this in the first segment. I mentioned this a couple of times – getting a hundred hours into a project and then learning something new that would require us to re-engineer something that’s already been built. Or learning something new at the point in time when your team receives the project and someone who hadn’t been a part of the early discussions sees it for the first time and realizes that an important part of their day-to-day operations is not addressed by the solution that we’ve come up with.
The first reason to undertake a technical discovery is to mitigate future risk for your ecommerce business.
There’s also just the fact that sometimes projects hit a brick wall. Things that seemed possible due to other constraints are now no longer possible. And what’s really nice about the discovery process, and I always have to remind myself – as a developer I have such a concern about this – although I love problem-solving, hitting walls is no fun for anybody. And that concern comes through a lot in my discovery process. When we’re really learning, I have to remind myself that it’s okay if we hit a brick wall in discovery. It’s preferable for us to find those walls in discovery. We find all the ways that don’t work so that at the end of the day we’re proposing a solution that is going to meet your needs.
It’s important to use the technical discovery process to find everything that isn’t working so we can propose a solution that is going to meet all of your needs.
Yeah, fantastic point. The second point that is perhaps the most compelling is return on investment. So the discovery process is an upfront investment both in time and money, but keep in mind that it will always be at a fraction of the cost of the larger project. So thinking through that larger investment, the build, right?
In ecommerce, we have seen small, subtle shifts in approach either generate or save literally hundreds of thousands of dollars. So the stakes are very high here. If we can discover the items that have that kind of potential early on in the process, be it a feature, a platform choice, or other site optimization, the impact can be massive. Rushing through a scope of work just to get the project underway, I mean time and time again we see these things that are just so easily missed.
Old thinking and self-prescription lead to less-than-ideal results. So one of the things that I think about often is when a client comes to us saying, “Have you done X, Y, Z feature implementation before?” I am constantly having an internal dialogue with myself when we get this question and I completely understand where the client is coming from, right? Their jobs are on the line. They want to ensure that their recommendation for the firm they’re going to work with is going to be a sound recommendation and that ultimately the firm is going to do it right the first time. And they have the chops to do it.
So I completely empathize with where they’re coming from. I get how much is on the line. But the irony of that question is that it is just not the reality of our world. We literally have never ever, ever built the same exact thing twice. If we were, we would be building widgets, right? We would always be bringing the same old thinking to new problems and the solution would never change or improve. And that is the crux of it. We are incredibly intentional about learning from what we did the last time and improving upon it. We always try to bring this philosophy of new thinking. And new thinking requires time and space and research and investigation. So it’s the old thinking that defines solutions that aren’t optimized.
The second reason to do a technical discovery is to secure a greater return on your investment.
I don’t think anyone can see me nodding emphatically, but that’s what I’ve been doing for the last couple of minutes. I couldn’t have said that better. It’s one of my absolute favorite things about working in tech in general and in ecommerce specifically.
Yeah. One other point with regards to return on investment that I really want to drive home is that we are very rarely just looking at one tiny component of the larger business operation, right? We tend to be very holistic both in our approach and the scope of work that we’re doing. So, it’s rare that what we’re building or proposing exists in a vacuum. In other words, we’re not just talking about optimizing for frontend conversions, right?
The third benefit of the technical discovery process is that it creates a unified approach across your company to find the best solutions.
In the discovery process, we’re talking to all of your different departments, right? Customer service, fulfillment, the design team. If we are allowed to have those kinds of conversations, we may be able to identify and build in optimizations that save them time. That improves upon their workflow, and perhaps automate tasks that previously they were doing three times manually.
We have one client who reported a 20% time savings for their customer service team from an optimization that we made after working through the discovery process with them. The project wasn’t just about improving things for their customer service team. The project was a full ecommerce build, but we discovered this one aspect where we could make an impact and the result was massive.
So if we think about both those kinds of optimizations in the context of the longevity of the platform, it’s very difficult to quantify the kind of revenue saving or increasing that we’re talking about here. But as a very simple example, let’s just say you have to rebuild your platform every three years and each time it’s at a cost of $100,000. Now that doesn’t factor in your annual investment for optimization and maintenance at all. Assuming you’re in business for 20 years, which sounds crazy in today’s day and age, but assuming so, your overall investment in the platforms alone, rebuilding the platforms alone, is more than $600,000. If you can get an additional year, and that’s being super modest, out of your platform because it’s serving your needs and it’s well optimized we are looking at a cost savings of over $150,000 over the time that you’re in business.
That $150,000 in comparison to the few thousand dollars and a little bit of extra time, in the grand scheme of things, that you’re spending on the discovery process all of a sudden becomes a complete no brainer.
The technical discovery, I mean it’s clear, really makes great business sense from a financial perspective. Both because it optimizes your spending initially, but also, Sara, as you just explained, it’s really allowing you to get the most out of your overall investment in the long term. Build over build, you’re going to continue to see that return. There’s one other key point that I think is important to bring to the table when we’re talking about reasons for technical discovery, and it’s the unification of approach.
The technical discovery allows retailers to get the most out of your overall ecommerce investment for the long term.
Sara touched on it a little bit, but making sure that all of the stakeholders are at the table at the right time and that includes the development team. The development team is having conversations with the real-life folks on your team who have to be on the ground dealing with the tools that we’re building for you every single day. It just allows us to get all of the pieces of the puzzle together early on and it opens up lines of communication. So, as I alluded to earlier, we’re not getting to the end of the project and learning that there’s this whole other arm of the business that needs to be accounted for.
Absolutely. That unification is so key and eliminates a lot of potential for miscommunication down the line as well. So to summarize: The three key points to why the discovery process is so imperative are 1) mitigating risk, 2) return on investment and 3) unifying approach. And with that, I think we have to wrap up our episode. But this is such a meaty topic and I appreciate you delving into it with me, Tif.
Yeah, thank you. Sara.