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.

“How do we win as a company?”

🎶Imagine there are no silos, it’s easy if you try🎶 – is what the legendary Beatle would’ve sung had he read this interview. Peter Sunna, VP Product at Kognic, explains exactly how to break free of organizational limitations and get your whole company to work for the good of the product.

Peter jumped right into the deep end of the pool when he joined Kognic, a highly technical startup, to establish the product department for the first time. 

Drawing from this role as well as 20 years of other experiences with digital products, Peter shares his thoughts on:

• the overlap between technology and product departments,
• how to align the team of a highly technical startup to work towards the same goals,
• the secret to fruitful collaboration between different departments.

Peter will challenge you to rethink the technology-product dynamic in your organization and give you specific steps to improve it.

About Peter

What’s Kognic up to?

Jakub Piłucki: Hello Peter. Hope you didn’t catch a cold at the Nordic Software Summit. Did you learn any valuable product insights or get to speak at the event?

Peter Sunna: Hi Jakub, thanks for having me. I used to work in Stockholm for 10 years, so the Summit was special to me because I have lots of old friends and colleagues there. The focus of the conference was sustainable growth, with great sessions on how to achieve more with less. Fortunately, this time I wasn’t speaking, so I got to relax and enjoy the event.

I just returned from TechBBQ in Copenhagen, where everyone was talking about AI. 

Same at TechHeads in Kalmar. I left there convinced that I need to rethink everything. After hearing people talk about AI in different domains, my head almost exploded from realizing how many unknowns there are in this area.

What about the Automotive Engineering Expo in Nagoya? How productive was that event for Kognic? 

Automotive is big in Japan so that market is really interesting to us. We got to see some differences compared to the US, Europe, and even China. In automotive, there are many layers, and companies usually pick the best providers for each of the horizontal layers in their stack.

However, in Japan there’s still very much a “we do everything ourselves” type of mentality. Since we want to expand in that market, one of our major goals was to explain the opportunity cost of buying a solution versus building it yourself.

Technology and product overlap

It seems there’s a common theme when I talk to people at events, which is that technology and product departments are coming together. What do you think about the growing overlap between the two?

To me, product and technology have always overlapped. I’ve always worked very closely with my engineering counterpart. It was never “product owns the roadmap, technology owns the architecture”. They can challenge me on the roadmap; I can challenge them on the tech.

I think this is the key to success. You have these two distinct roles with different responsibilities, but whenever things overlap, you can discuss and come to new conclusions.

One of our previous guests said that the most important thing for both technology and product leaders is to understand each other’s tradeoffs. The CTO should understand why you don’t target specific customer segments, and the CPO should understand why some tech choices aren’t feasible. What do you think about it?

We usually talk about risks when we’re creating solutions. The usability risk, the value risk, the feasibility risk, and the viability risk. Tradeoffs need to be made in these areas, and you need to understand them.

Say we’re building a feature and we want the best possible UX for it. That’s a viability risk, and the tradeoff is that the project might become too big to be worth it. You’re always balancing. 

That’s why I love having those discussions I mentioned. They help you understand the tradeoffs and risks. 

Before you joined Kognic, you had product roles at e-commerce and CMS companies. How did the technology-product dynamic change when you joined Kognic?

I had no experience in AI and automotive, and I noticed that Kognic was a very technical company. They built a very advanced product, but they also understood how it fit into processes in automotive.

Coming in to establish a product function, understanding both the technology and the automotive processes were my biggest challenges.

Understanding trade-offs may be easier said than done given how quickly both tech and user expectations are evolving. How did you get up to speed, and how do you keep up with the latest developments in an area as complex as embodied AI?

Before I joined, I read a lot about AI. I had some knowledge from university, but quite a lot has happened since then. I read up on the theory, just to understand the basics before coming into the company.

After I joined, I focused on learning the product and how it fit into automotive workflows, how customers can use our platform for annotations to build up their data sets for training AI models that power different car features. I learned all I could.

Now, I’m very careful to dedicate time in my calendar for catching up with industry news. So I dedicate at least 1 hour per day, it’s usually the first thing I do. Between 7:30 and 8:30, I check out what’s happening, explore technology trends or look at competitors.

There’s so much happening in AI every day that it’s easy to get FOMO. Instead of stressing about it, just make sure you dedicate some time every day to learn about it. I’m a big believer in good habits.

Product in a highly technical organization

Kognic is a very technical organization so, in theory, the CTO should be the king, and there might be a “build it and they will come” attitude. And yet, at the same time, we constantly hear from our experts that everyone wants to be product-oriented. What’s your take on that?

Two years ago, before I joined, Kognic was built around autonomous development teams that knew about the strategy, gathered their own context, and made decisions themselves. There was no product department then. 

I think that has been working really well for Kognic, but then scale became a problem. What works with 50 people might not work with 100 people. It became difficult to align the teams to focus on the most impactful things. Not just development teams, but sales and marketing. Is sales actually offering the thing you’re building? Is the market positioning correct?

Since we started building the product department, we’ve been focusing on how we can win as a company. I talk about it a lot in my product team. It all starts with knowing your answer to the question “how do we win?” When you have that, and your team understands it, you get much better discussions between technology and product.

This is the most important thing for the product function to figure out: how do we win as a company?

This helps us understand what’s differentiating us in the market. We can show the value clearly and attract more customers.

At Kognic, Product can focus more on the core aspects of the strategy, on how we win, rather than identifying exactly what the team should be building. This was a huge “aha!” moment for me.

A really good definition of the product manager’s job is that it’s “coordinating actions across the organization to make the product successful”. So you make sure that the company is aligned on the strategy, engineering is building the right thing, marketing is highlighting how we’re differentiating, sales is offering the right value, and so on.

Having that strategy, you can frame the conversation in a more productive way. You’re not just talking about “what can we build?” You start with the strategy, and say “this is how we want to win, how can this technology help us do that?”

Okay, so how do you align on product strategy?

The strategy keeps changing because we’re a startup. We pivot all the time, but that’s also what I love about it.

One of my goals joining Kognic was to stabilize things. I don’t think I’ve succeeded with that for the first year, we were struggling to find our way forward. We were able to get new revenue but didn’t have a clear long-term path. The roadmap would change quite frequently.

The roadmap is always a difficult topic because it shows you how well you’re executing on your business strategy.

Whenever you start building a roadmap that supports your strategy, I think it’s important to think about the roadmap as mainly a communication tool. It’s a way to explain what it is that you want to build.

It’s very important for the roadmap to show where we want teams to be involved. If we have done a good job of framing the strategy, the key outcomes that we’re looking for, the ways we want to differentiate – it becomes easier to build that roadmap.

For some teams, you can just say that we want to increase revenue, and then they can take that goal and map out the main problems to solve. Other teams are not as mature and will need more guidance. Perhaps, you need to identify the specific problem to solve, and then they can do a good job of solving it.

Your product is annotated datasets for the embodied AI industry. How important is data for your internal decision making?

We’re focusing a lot on productivity, we want to be the most productive annotation platform for video or radar data. One of the main measurements we’re doing now is how productive annotators in our product can be. If it’s an image with cars in it, how quickly can they verify the correct number of cars?

We want our annotators to be as productive as possible. Their productivity comes down to many different factors. One factor is how good our tool is. Do they struggle to use it? Another is our process for onboarding and guiding annotators. Are we making the right batches for them to work as effectively as possible?

So that’s one example of how we use data internally. It’s very complex to measure productivity accurately, but doing so helps us make better decisions.

What data interests you most when looking at the rest of the industry?

There aren’t many productivity metrics for annotations out there that we can compare with. But we can compare our rates, i.e. what we charge for annotations in our platform and what the competitors charge.

Advice from a product leader

What advice would you give to a product leader, one that’s about to enter a highly technical organization like Kognic for the first time?

Build a really strong relationship with the technical leader.

In the beginning, I still thought our roles were divided. They take care of the technology, and I make sure we have a good strategy.

Now I see that these areas are closely connected. When you have a good relationship, you’ll have fruitful collaboration, and it will positively affect your teams.

What about the other side of the equation – what should the CTO do to get the most out of collaborating with the CPO in a highly technical company?

Personally I’d really like for the CTO at a new company to challenge me on the strategy part. And to be able to explain the strategy to their team. 

So feedback and communication are the keys to a good tech-product dynamic, right? 

When I was starting my career, I heard a lot about the importance of communication. Now I think that maybe it’s not just about communication but about collaboration. 

My ability to cooperate with the CTO translates to the rest of the organization – how well the PMs collaborate with engineering managers and design leaders, and so on. I think it all starts with collaboration at the highest level.

How much should Product worry about Marketing and Sales in an organization like Kognic?

One of the things I’m seeing is that the product role is becoming more tied to marketing. 

You have to be able to explain the value of what you’re building and how it’s different, which is very much a marketing activity. But it’s so essential to how you win that it becomes one of the key things for product people to work on.

And what about innovation and R&D? Say, the product leader really wants to stand out in the market, but the technical leader wants to break new technological ground. How do you compromise in this scenario?

We can’t just be innovative for the sake of innovation. We need to align on what’s the goal that we’re working towards. That will guide us.

If we have agreed on how we want to win, it’s easier to discuss innovation. From this perspective, we can frame innovation as something that helps us show how proficient we are at tech. It doesn’t need to become the next big bet that we’re taking as an organization.

Resources

Are there any resources that you could recommend for the leaders who want to learn more about the technology-product relationship?

Lenny’s Podcast – plenty of great advice there.

I also mentioned the importance of habits earlier, and “Atomic Habits” is a great book I can recommend here.

Regarding tech-product collaboration specifically, I always recommend the “Innovator’s Dilemma” and “Crossing the Chasm”. They’re quite old, but they’re essential reading.

What’s next? Three actions for CTOs to take

Peter proves that building a complex product in a rapidly changing startup environment doesn’t have to be a constant battle – even more so when it comes to deep tech product management.

However, if you want to tighten the relationship between Product and Tech, no matter how deep tech your organization is, bury the hatchet and:

• Collaborate, don’t just communicate – it all starts at the highest levels but has a ripple effect on the whole organization, including the roadmap.
• Learn about different aspects of your product, not just the ones you’re focusing on.
• Build your strategy around your company’s answer to the question, “How do we win?”

Product leaders are not your enemies – in fact, they can be your greatest allies in your company’s journey.