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.