So, if you’ve landed here, chances are you started reading my website page about Design Thinking. If you haven’t, I suggest you start there…

I sold my previous business, Business Tech, in 2017. “Google Merchant Center” (GMC) was our flagship addon / plugin for the PrestaShop e-commerce platform . It allowed online merchants to send their entire product catalog to Google. They could then advertise their products on Adwords and Google Shopping. It is an incredibly complex piece of software, meant to comply with hundreds of technical requirements from Google.

I had built the first version all by myself in 2010 in less than a week. I pretty much crammed everything in a handful of big clunky “classes” (think of it as different Lego components). It evolved quickly on that basis until 2015, when my Lead Developer decided to re-code it based on a highly Object Oriented framework he had created. He broke everything down into dozens and dozens of much smaller pieces and added logical layers of abstraction. This allowed us to handle the forever increasing complexity imposed by Google’s services. Him and another of my developers together took about 2-3 months to do so.

We had many competitors on this product, including PrestaShop and Google themselves. True story, we literally eventually blew both PrestaShop and Google out of the water along with everyone else. PrestaShop ended up offering us a deal to be the exclusive official GMC addon / plugin promoted on their marketplace. And guess what ? My “quick and dirty” code carried us through 5 whole years to become the undisputed #1 on the platform. Why ?

Design Thinking Lesson #1: It’s not just about the software

It’s also about the post-sale tech support and customer service. PrestaShop is Open Source. Which means any merchant can have tweaked the shop’s code, many times in very BAD ways. Add to that differences between versions, website hosting specific constraints, bugs in PrestaShop itself, conflicts with other addons / plugins, people simply not following instructions… Even the very best addons publishers, including us, would get at least 1 client out of 5 come back with some sort of problem or question after installing it. And because their business depended on it, they wanted it fast and efficient.

One day, Florence D, an executive at Google I had been in touch with on various topics, calls me to tell me they are going to release a free version of the GMC addon for PrestaShop. We were selling ours for 99€. And weren’t we scared about that ? To be honest, I was scared alright. But I also knew that:

1) Google knew very little about all the weaknesses and intricacies of PrestaShop and
2) They didn’t know how to do customized support with a high level of technicity. They were too big for that. In my business, the developers themselves did a big share of the support. Not just someone with a database of scripted e-mail responses.

And so Google eventually failed and we won. PrestaShop cancelled their partnership with them when they proved unable to adequately service PrestaShop merchants. They just didn’t know how to do the tech support on that micro-level. Google has an “automate everything” approach that just does not work with the messy and organic reality of Open Source software. That is Design Thinking in action right there. It’s about understanding what people really want. And what people really want is software that works well, AND fast, quality tech support in case a problem arises. Human understanding first.

Design Thinking Lesson #2: Things change a lot all the time in the world of technology

Google had changes and new rules pretty much every month in the first 3 years of the GMC service. It did slow down after a while. I did not produce an example of beautiful Object Oriented code, but it worked. It worked really well. It was correct in its perception and translation of reality. I made sure that every important detail in the Google documentation, and a good amount of specific needs based on different types of merchants were covered. And I found ways to make some configuration choices automatically for them, while giving them the flexibility to fine-tune options to their needs. It was also secure, fast and well architected enough that it could handle catalogs of up to 100,000 products. Which pretty much covered 99% of merchants.

We were always pro-active, monitoring Google’s roadmap for any potential disruptive changes and additional features that would serve our clients. We then always reacted fast on the ones we knew would be crucial. As well as the ones that would give us an opportunity to make our clients’ lives even easier and innovate. Opportunities that only concerned a small percentage of users, such as a rules specific to a single small country, or very industry specific like personalized gifts, would be put on a “potential developments” list, and would be implemented only if enough people asked for it.

Correctly reading the market and our clients’ needs as well as quickly delivering and innovating before the competition made us successful. Not because we had the cleanest code out there. Our clients never saw the code. All they cared about was that our product allowed them to get high quality scores and get all their submitted products accepted by Google. So, again, Design Thinking’s core message: Human understanding first.

Design Thinking Lesson #3: Beautiful code did become necessary

That being said, I must say that good, modular Object Oriented code has tremendous value. My Lead Developer made the right choice at the right time. The complexity had grown a lot and it was getting hard to manage. For starters, once a code library has thousands of lines in a single file, it becomes messy and hard to read. Although, overdoing it and splitting it into too many pieces can have that effect too.

Good Object Oriented code has another advantage: things inside a “class” or building block tend to be “encapsulated”. Therefore, there can be no conflicts. For example, between 2 different variables that were given the same name by 2 separate developers.

Finally, Object Oriented code is necessary when more than one person works on a project. If everything is in one file and 2 developers at once work on the same file, then there are possibilities for conflicts in their changes. Even with versioning software such as Git. Teams work better with multiple smaller files that are logically separated. For example, one person can work on adding settings elements in the interface, while another changes the way a product catalog file is generated.

My team of developers grew, and it became necessary for them to re-organize everything for them to do their job more efficiently and enjoyably. And once again… Human needs. This time my employees’ needs, not our clients’.

Conclusion: Satisfying human needs comes first

And this, in my eyes, is Design Thinking’s important core message. That, and understanding that technology alone is often not enough. It’s everything around it that matters too. Like properly structured support and customer service. Everything arises from human needs or objectives. It seems like common sense, but yet we were able to beat Google because they were playing on our territory and we understood small online merchants better than they did. Nothing more. A lot of things look like common sense in retrospect, not so much before the fact.

While envisioning solutions one must always weigh in the pros and cons and put things in perspective. Consider the benefits and cost for every aspect of the business, not just the technical one. At first, the quick and dirty code was “dirtier” but less complex and hence faster to modify to satisfy client needs. It served its purpose well. But later on, it became necessary to re-write it with better structure and style, to allow my developers to better do their job.

But by that time, we had already secured a completely dominant position through the consistency of our product and service. And so Design Thinking is also about timing by prioritizing: knowing when and how to build what and in what order…