The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Stay on top of modern development’s challenges with the three C’s of product-tech relationship

Previously, in CTO vs. Status Quo, we discussed product-oriented development and how developers must step outside the engineering organization to learn more about customers and their needs.

Today’s guests from CM.com, Remco Magielse, Head of Product, and Bas Gijzen, Head of Technology, acknowledge its need but point out that the same goes the other way – product people must be more technical than ever before to succeed.

 Only then the whole organization can face the 3 C’s of modern-day software development.

• Customer

The modern user’s expectations are through the roof. They want quick and reliable service and have more options than ever. Products and technology must combine excellent user experience with a high-performing tech base that can quickly adapt to new requirements.

• Complexity

These requirements are coupled with the ever-increasing need for data and tools. According to Dynatrace, 85% of tech leaders believe the sheer number of tools, platforms, dashboards, and applications makes their cloud environment complex.

• Continuity

As the company grows, it has to dedicate more time to educating new employees. This increases the attrition rate, especially among seniors who keep the organization going. How can product-tech cooperation be kept efficient when those who make it efficient leave?

These are the C’s or challenges we’re going to tackle today. Does that sound interesting? Let’s see what Remco and Bas have to say about all this!

Say hello to Remco and Bas

Sławomir Turkiewicz: Hello Remco, Hello Bas. As I prepared for our conversation, I discovered that CM.com had only recently established a multi-year partnership with the Dutch Olympic Committee. As a result, the Dutch will use CM.com’s technology for ticketing, event apps, and mobile communication during the 2024 Olympics and Paralympic Games in Paris.

That sounds like a big deal – congrats. Can you tell me more about it?

Remco Magielse: Thanks for having us. I’ll step back to clarify why these deals are so important to us.

We started out as an SMS aggregator 25 years ago. We’ve grown by sending messages globally to our customers, adding more options and channels as we grew.

6 or 7 years ago, we also started making apps that help customers send messages to and answer customer questions. We also developed voting technology. It was, for example,  used for the Eurovision song contests to count votes.

As you can see, we have developed more value-added software layers on top of our messaging platform.

Then, we started with ticketing as a separate platform. It helps our customers deliver a great end-to-end mobile-first experience. Purchasing tickets on the go and scanning them with a phone, getting drinks, making payments – it’s all integrated and covered in use cases for this type of live event. We’re different from regular ticket providers in trying to help the event organizer sell out this event. We’re not just there to deliver tickets. We help them with the optimal arrangement. 3 years ago, we tested and showcased this solution at the Dutch Grand Prix. This famous event returned after almost 30 years.

The Olympics is another step toward providing clients with software that improves customer experience. Using our platform, they have all the ticket-related capabilities under one platform.

Am I right to assume that these capabilities also include AI? After all, CM.com positions itself today as an AI-driven conversational software. How will you use these AI-based capabilities during the Olympics event, Bas?

Bas Gijzen: There are a few touchpoints where we integrate generative AI.

We help companies respond quickly and accurately to their clients, for example by making up for staff shortages. Many of our customers have a contact center or a customer support desk somewhere. They can’t endlessly scale the number of hired agents at peak events. Hiring more consultants just for one event that runs for a few weeks doesn’t make sense. And so our AI-based tools use natural language detection to respond to the end user’s language, partially making up for human agents. 

We also offer an AI assistant that helps consultants respond to customer contact software. It also stores human-provided answers in the knowledge base for use later.

Remco: There’s also some AI in our customer data platform. We do customer profiling based on interactions users have in different channels. If you land on a website, you might be targeted by an Instagram advertisement, go into a conversation, and then to a landing page where you can order tickets. They are delivered via email. All these interactions fall into a single platform where the event organizer can segment them and tailor their message toward different user classes.

The Dutch Grand Prix experience with CM.com

Technology & product relationship

AI is, of course, a fraction of the subject matter you guys cover.

When I heard about the Olympics deal, I thought that your technology-product relationship is a bit like the Olympiad – the period between two separate Olympic events. You need to improve it continuously over time and never lose sight of your principles. How do you see it from your perspective?

Remco: A trend that you definitely see today is that product and tech are coming closer together – to the point that you often see one person doing both as a CTPO. This shows how much we move towards technology-based products in which technology and products are deeply interwoven.

At CM.com, we hire product and tech people separately. Their responsibilities overlap to an extent, but there are some differences. Product people are more outbound-focused. They spend more time on external communication, market, and customer needs. They push information outside the organization and back. They have a high-level perspective by default.

Technology, on the other hand, focuses on the inner workings of the products. They are detail-focused. So when I ask Bas if we can do something technology-wise, I trust that he has the answer I seek. In turn, he trusts me when it comes to customer insights.

Naturally, it doesn’t mean that I never step into the tech territory, and he never steps into the product territory. There’s also a lot of overlap in our day-to-day work.

Bas: I agree. Whether focusing on the product or tech, it’s all about understanding tradeoffs.

Tradeoffs exist in both the product and technology space. You can’t target all customer types at once. You can’t choose all technologies at the same time. You need to use your time wisely and focus on activities that bring you the most value in return. I think that the main job of tech and product people is to support each other with the knowledge necessary to understand the trade-offs and make the best decisions for the sake of everyone.

I have already talked to CTOs about how the technology-product relationship has changed. It seems that back in the day, these departments worked in silos. The tech leader was in charge of infrastructure, which was seen as a cost. The product leader only handled product cycles.

Let’s start with you, Bas. How do you see the role of a tech leader today?

Bas: The technology has become much more complex and encompasses all product development aspects.

These days, everything is connected in one way or another. Every application, module, or feature communicates with each other. 20 years ago, most systems were built to run independently of other systems.

The complexity of technology has consequences. For example, you can’t get away with doing things on the cheap as easily as you could before. In particular, these cheap alternatives don’t scale, eventually creating a lot of burden or technical debt. As a result, the tradeoffs between different options are becoming more pronounced.

User expectations are also at an all-time high. Back in the day, it was very common not to be able to transfer money over the weekend. Today, the user expects a money transfer to take no more than 10 seconds – 24/7.

The rising difficulty of keeping up with technology and user expectations requires tech & product people to band together. They need to exchange knowledge and cooperate with each other a lot more to achieve their objectives.

What about you, Remco? As a Head of Product, do you feel the same?

Remco: Yes. I would call the cooperation and communication Bas mentioned as working on a shared vision. Knowing where the product is heading and understanding the opportunities and limitations ahead takes a lot of work for both parties today.

I also agree about customer expectations, especially in the B2B context. The product must comply with everything, be fully configurable, scale globally, and operate 24/7.

Nowadays, it’s also simpler to put a new product onto the market. You release much earlier because there is more focus on post-release iteration and reworking. It’s easy to see why: most products today are software-based. It’s easy to tweak them at any given moment. In hardware, product development is much more front-loaded – there isn’t much you can do once it’s out.

That’s probably also why these technology and product roles merge closer. The technology’s effect on what you deliver as a product is much more apparent.

One thing that hasn’t changed is the importance of understanding the value proposition. Can you articulate the value that your product has for the customer? That’s still essential – why and how much money would the customer spend on it?

You mentioned the impact of technology, Remco. The previous CTO vs Status Quo interviews convinced me that today’s tech leader is more product-oriented than ever. There is an increasingly large overlap between technology and product. Is the work of a product leader also getting more technical?

Remco: It’s definitely the case. With so many products built around software, you need to understand the technological constraints in which you move if you want to solve a problem for the customer. Will the product handle the traffic when the customer spends twice as much time in it? What if it needed to scale a hundred times?

Product delivery also works differently today. It’s easy to deliver something once. But to deliver something every day to 10,000 customers globally, as modern software-driven products often require, is a challenge. This means you need an efficient product-engineering organization.

Conflicts

Let’s talk about product-technology conflicts. If the responsibilities of these two department leaders overlap, clashes of different perspectives are unavoidable.

The product leader wants to introduce a big new feature. However, the tech leader can see that it will take more time to implement than the product believes it will. It may require a major rewrite. How do you resolve it?

Bas: Like I said, communication is the way to go. You both need to go to the whiteboard, break down what needs to be done, consider different options, and decide whether to proceed and how to proceed.

You need to determine why something is not technically feasible and how you can change product requirements to turn the situation around. Perhaps something is too big? Perhaps some compromises or shortcuts in product development can be made. Or, to the contrary, perhaps adding something on top of the existing solution could be a game-changer, like creating an MVP as part of the main solution.

On a side note, you should probably not give up on a product idea just because it would take a lot of time to build. If it makes sense and you determine that the return on investment is worthwhile, then you should make it happen, even if it took months to develop. Having said that, often, it’s better to have a workable solution in 4 weeks rather than a perfect one in 12 weeks or months.

What about you, Remco? How worried are you about technical constraints in your day-to-day work?

Not too much. That’s because we are good at MVP development, which helps you work around all kinds of constraints, provided you iterate over time. A recent example is a new feature we released called Safeguard, which helps companies avoid unnecessary costs by preventing bot traffic.

There’s a lot of fraudulent traffic in the messaging domain. Bots generate messages, and our customers pay the cost of sending them. We came up with an idea for a bot-detection feature, but we estimated it would take 9 months to complete. We couldn’t commit to this then. Instead, as Bas said, we returned to the whiteboard and tried to figure out the simplest deliverables that would bring the most value. Eventually, we were able to come up with a workable solution that was actually delivered in a few weeks.

At the end of the day, conflict is not a bad thing. When used well, it encourages people to communicate and devise creative solutions.

What if the tech department wanted to slow product development to make time for refactoring? The tech leader is in a tough spot because refactoring may have no immediate business value. There may be a conflict along the speed vs. quality axis. Can you avoid it?

Bas: As a tech leader, I believe that you should always refactor a bit. In the long run, it actually speeds up development.

We usually save some time each week for work that doesn’t directly impact the roadmap. One team calls it a free-choice Friday, and another one – whatever-you-want Wednesday. Sometimes, developers use that time for refactoring.

I believe that developers should refactor the code they actually worked on developing. It fosters accountability. If a developer works on a new feature, they should think about how to implement it in a way that will make further development easier. As Kent Back says, you should try to make a difficult change easy and then make the easy change.

Another Boy Scout rule is always to try to make things a little cleaner than before you came. If you do that, the quality of the code should remain good.

You might also need to remove some old libraries or implement key security-related changes. Such refactoring can be a project of its own. You should discuss it with the product department and put it on the roadmap.

How do you feel about putting refactoring on the roadmap, Remco?

Remco: It doesn’t matter how big a refactoring project is. What matters is if it has some customer value. Some optimizations may be technically challenging and interesting to tackle but ultimately add little to the bottom line. It’s better to invest that time into something else. Customers don’t care about clean code. They won’t pay a penny more for it. 

But you can usually find a way to use refactoring to help customers. If your optimized code helps process messages faster or removes some redundancy to increase uptime, you add customer value.

Still, the challenge is to decide how big the benefit is compared to the effort invested. If you were to increase uptime from four 9’s to five 9’s, which took you 20 weeks of work – was it worth it? Each case needs a separate discussion. Again, it’s all about a constant feedback loop between production and technology

Feature prioritization is also an interesting area. Typically, the product leader has more of a say in it. However, the tech leader may have product ideas of their own. How would you introduce them, Bas?

Bas: I do that by coming up with an example. I will sometimes make a small proof of concept. It must be something that can be done really quickly and easily, though.

If I can’t do that quickly, then all I can do is make my case out loud and try to see if the product team feels the same way.

General processes & synergy

We discussed potential conflict areas between the tech and product departments and possible solutions. Let’s make it more general now. What are the most important rules both sides should remember to cooperate effectively and allow synergy to occur?

Bas: You need to do everything with the customer in mind. Naturally, that requires deep research into your target’s preferences, but luckily, some customer needs are constant. Pretty much every software product today has to be fast, secure, and compliant. There is also likely some expectation of how the specific class of software your product belongs to should look. I wouldn’t recommend straying too far from it.

Sometimes, the customer might have a unique need that requires developing a new feature. It’s not always the right thing to rush to development. You need to consider selling this potential new feature to other customers. However, if you can find a way to make it adaptable, then you should go for it. There’s hardly anything better than features informed by your customers’ actual needs.

Remco, you mentioned a CTPO – one manager who wields both technology and product power. He believed that being a CTPO gives you a unique ability to look at the intersection of technology and product to see the invisible obstacles in the development process. Can two people do that, too?

Remco: Yes, two people can also fill the same role. In the end, both roles involve decision-making. We decide on the next feature to build and how to build it.

Fulfilling both the technology and product roles gives you the speed advantage when deciding: you can simply decide on your own. But if the decision is to be properly informed, you need to build around yourself a strong team capable of challenging your ideas. Otherwise, you’ll get into tunnel vision.

This tunnel vision can happen even if you have a partner to challenge you. Sometimes, I’d get an idea that I thought was brilliant. But then Bas would explain to me how there was no way it could ever work. At other times, his input would not put my idea to rest but instead make it stronger by helping me understand potential threats and disadvantages better.

What do you think about it, Bas? Is the rising popularity of a CTPO role a good trend?

Bas: As Remco said, I think a CTPO needs a strong support team to inform and challenge its policies. On the other hand, when you have two people, their challenge is to get along great. Only then can they produce excellent results.

You two definitely get along great. I can see that. But I also think there’s a great danger in relying too much on a personal relationship. People come and go. How can the technology-product relationship be continuously improved even when the leaders change? Am I right to assume that it calls for the right organizational culture?

Remco: In a healthy organization, an employee’s departure should be an opportunity for others to take on their responsibilities. Last year, we saw that happen when some of our key employees pursued other opportunities.

For leaders, discontinuity is yet another challenge to manage. In doing so, you should rely as much on the process as on individuals. There’s a delicate balance involved because you don’t want to be a fully processed-driven organization where people are just numbers.

Education is the key to finding and keeping the people who keep the organization going, and it’s strongly related to managing growth.

We’ve been through some years of hyper-growth where we tripled the organization. It changed the dynamics in our organization because we suddenly had people who had to dedicate themselves almost fully to educating others. We’re now striving to streamline the education process. The goal is to free up even more time for our best and most senior employees but still ensure that newcomers get all the knowledge they need to take over when their time comes.

Bas: One way we improve education is through process automation. People involved in the processes are encouraged to find ways to automate as much of them as possible.

Automation is another way you can try to decrease the dependence of your organization on any one individual, maintaining a certain level of quality when your new hires are still learning.

Resources

Thanks for your insights, Remco and Bas. Again, I can definitely see why CM.com grows so quickly and constantly innovates under your leadership. 

You should never run out of opportunities to learn from practice. Still, could you recommend some books or materials to managers who want to foster the product-technology relationship more effectively?

Remco: There’s one book that I think everyone in the product domain should read, Inspired by Marty Cagan. It’s probably on the bookshelf of lots of Product Managers.

An Elegant Puzzle from Will Larson is another one worth checking out. It describes actual situations in the engineering management role so you can easily apply them to your circumstances. It’s still very up-to-date.

Bas: I’d add Extreme Programming Explained by Kent Beck and The Software Engineer’s Guidebook by Gergely Orosz. The first one is pretty old, but it’s still full of excellent practical advice for those who work in fast-paced, iterative environments. The other one is a good source of knowledge for tech people who want to become leaders.

What’s next? Three actions for CTOs to take

And that’s it! What do you think about Bas and Remco’s approach to dealing with modern software development challenges through strong product-technology cooperation?

If you want to implement their findings in practice:

1. Abandon silos and collaborate widely over product development. You’ll lose more time developing the wrong feature or not taking tech limitations seriously!
2. Consider all tradeoffs when making a product development decision. Only product and technology have the know-how to do that together. And when they do, they may even come up with new ideas to tackle a problem creatively.
3. Involve both your product and engineering people in education efforts – streamline and automate them as much as possible to lower the attrition rate of your top performers and lower dependence on any one person.