1. Be ready to rethink, change your mind, and take a few steps back

Back in April 2020, just after learning that we were supposed to be preparing for the launch of our new DXP, I discovered something surprising:

We weren’t.

During the DXP’s “almost ready” stage, our development team made some suggestions that were just too appealing to pass up. Yes, we could have ignored them easily enough if exclusively focused on deadlines. But because we really wanted our tool to be the best version of itself, the project came to an abrupt halt.

The changes suggested by our developers drew on newer technologies and less obvious frameworks, tempting us with a promise of significantly better, easier to optimize performance as well as extensive flexibility. On the other hand, we had already made promises to our customers. And just as importantly, we had made even bigger promises to our own content team, which hoped this new tool would solve all of their problems.

We had already invested a lot of time, work, and resources into building this tool, and the suggested changes would throw a lot (if not most) of it away. And, that wasn’t even the worst of it. The biggest concern was that no one could guarantee us that this sudden change in direction would make the kind of difference that would justify such a substantial delay.

After a bit of quick research and whatever testing we could manage in such a short time, we decided to take the leap.

Looking back, it was a ballsy move that could have ended in a small catastrophe. We did all we could to determine the likelihood of success, but we were also extremely lucky, in large part because both our content team and external partners had the patience to wait way longer than expected.

Was it worth it? Definitely. Even if we had not decided to change our direction, it was still crucial to properly consider and test these suggestions to see whether such a technological somersault was more likely to make us into a DXP champion or break our back.

Was there anything we could have done to avoid that stress? Well…

2. Remember to consult your tech people continuously

Yes, we could most probably have made things easier on ourselves. As fun as it is now to brag about being such a fearless company that didn’t hesitate to take this major risk, neither our content team nor our external clients were all that happy to wait the extra few months it took us to rebuild the whole application. And I can’t blame them.

The development team also had to deal with the additional pressure of working way behind the set schedule while impatience and tension built up all around them.

The suggestions about using different technology for our DXP were made as if in passing. We learned about them almost by accident. Looking back we wondered: had we consulted the development team enough? Had we given them enough space for creativity before we started building?

3. How about on the way?

It is one thing to tell people what you would like them to build, hear out the simplest method they propose, give your approval, and start building. It is another to make them feel responsible not only for taking all the steps necessary to build a platform, but also for selecting a strategy and, most crucially, deciding what success means at the end of the project.

Since the release of Reffine DXP, we have learned to keep this lesson very close to heart when approaching our new products. We constantly look for new ways to engage people and make it easier for them to raise issues, share ideas, and speak their minds. It is not always easy, but this is the only way to avoid total surprises and unexpected chaos.

4. Talk, talk, talk

This lesson is one of the very foundations of the product world: talk to people!

Fortunately, we learned this not too long before releasing our new DXP when product feedback interviews proved critical in the launch of our Stock Locator. So as soon as the new DXP was released for the first batch of websites managed by Reffine, we were ready to talk.

And because the first users of our new product were in our own content team, we were in a privileged position to receive feedback. Our own users worked tirelessly with us preparing feedback, describing not only bugs but also features that they wanted to see added, and spending hours on end explaining what they loved and what they hated about working with the platform.

For our part, we used every opportunity to talk and, most importantly, listen to our users and understand why some of them felt like this new version was actually worse in some ways than the one they had used before. In addition, we made sure to speak to and survey any new members of our content team. After all, our team was used to the old version of the platform, which may have led to an instinctive dislike of some of the DXP’s new features.

All of this effort paid off. When we later organized a set of feedback interviews with our external clients, their requests in most cases had already been added to our backlog for one of the subsequent planning sessions. The general performance score for the new platform was 7/10 only a few weeks after the product was released. Some of our clients even mentioned that, apart from some missing features, it was possibly the most intuitive CMS that they had worked with, to the point that they felt it could be learnt within just a day of work.