ProdMinds is an interview series featuring product minds around the world.
Team Producter: Hello Kristof! Would you tell us a bit about you and your career path in product management?
Kristof: Hello, I studied New Media and Communication Technologies at Howest in Belgium, a program with a solid mix between programming, networking, video, and web development. That landed me a job as a front-end developer at a big media company. Later on, I moved to a small product company for a role that turned out to be a full-stack developer.
After a while there, I was given the Product Owner role purely because I knew most about the application and was in regular chats with customers and users. This led me to explore the topic of UX Research and Design, which ultimately spiked my interest in Product Management.
When I eventually reached the ceiling of personal growth at that company, I moved to another start-up with an entirely different mentality that had a bunch of new challenges for me.
Last year I also started working my own proptech start-up but there’s not much to say about that yet.
Team Producter: Which part of being a Product Owner is the most challenging for you?
Kristof: Ask ten people what a Product Owner does, and you get 15 different definitions, all with other tasks and responsibilities. The answer would be very confusing for people with a different understanding of the job title.
The roles I’ve been in have almost always been with a very wide responsibility. I’m working with internal and external stakeholders to decide on strategy and roadmap one day and am working with the teams to define the little details the next.
My biggest challenge has always been aligning with stakeholders, mainly internal stakeholders. They’re already working on the next big thing for the company but often fail to make it clear that it is something for 3–5 years or maybe not even relevant for us. I’ve begun to tackle this by defining specific terms to refer to the size and place of ideas so we can discuss what it is and how it matches the strategy. Sometimes a silly-looking feature idea simply doesn’t fit any of the strategic pillars we’re working on in the foreseeable future, and being able to discuss this with shared definitions of use cases, requirements, features, and so on helps me deal with it to a certain degree.
Team Producter: How do you think departmental silos affect product companies? In what ways do you build and maintain relationships with stakeholders from different teams?
Kristof: I think silos can be a massive hurdle for innovation and speed. Teams shouldn’t be split up based on titles or specialties but be truly cross-functional. And with that, I mean not just that they should have both front-end and back-end developers and throw in a tester to be complete. Why not even add someone from Customer Support who is specialized in the same part of the user journey?
Ensuring that siloed departments can keep working together, achieve the goals they are set to achieve, and align incentives, remains challenging when the company lacks a clear department-agnostic strategy.
As a Product Owner, these things are most likely out of reach, and you’ll have very little influence on them. To make the best out of projects where we depend on other teams, I try to make sure that we get together as much as possible. Put everyone who wants together in a kick-off meeting, ideate together, set clear objectives on which you can all agree, and dig as deep as possible during the time that you have available. Is someone not interested? Fine, I let them skip the meetings but try to find out why they are not interested in a one-on-one. They might be valuable to include anyway later on.
Team Producter: When it comes to listening to your users, what’s your method? Is their input considered in critical product decisions?
Kristof: It depends on the situation I’m in at the company and I’ve been in some pretty diverse situations. One important thing to note is that I’ve always been in B2B. At one company, I had direct access to the entire client database. I could reach out to whoever I wanted and do a workshop or have a chat. At another company, I had to wrestle my way into every opportunity I saw to talk to a customer or go on a site visit.
The conversations that I prefer the most are the easy-going ones where I can just listen to them explaining how they do their job. The first few are always very broad, but the more I learn, the more specific and guided questions I can ask, and the more easy-going and engaging the conversations become.
Without that kind of conversation, there is no point in making critical product decisions. Unless you are a true subject matter expert, the chances you make a wrong decision are too big and too costly.
Team Producter: Is there a method you use for prioritization? Or, Is there a custom approach you designed?
Kristof: There never is only one way to prioritize that will get you to a productive team.
My team’s methods are both User Story Mapping (User Story Mapping by Jeff Patton) with its swimlanes and R. Dutt’s vision fit vs. survival quadrant (Radical Product Thinking by Radhika Dutt).
With R. Dutt’s vision fit vs. survival quadrant, you can easily map out where each chunk of potential work falls. Based on this, you can start forming a balanced high-level roadmap that will have things for everyone and make it easy to communicate why things are prioritized the way they are. It has room for very outcome-based work and technical work that the user might not have a direct benefit from. Or things that sound stupid when you try to map it to a user’s desire, like data security. Of course, they want it! It’s simply something you need to take care of to safeguard your vision.
Then, when we start to dive into a chunk of work, I love to bring the team together and build a User Story Map of the journey where the use case fits into. A User Story Map can be a helpful tool even for fixing technical debt that falls into the “Investing in the vision” quadrant. Once we have all possible work mapped out, we start prioritizing actions and building out the MVP version of it by discussing which functionalities or actions we absolutely need to build for this to be a success.
Team Producter: We continuously iterate and improve our products — sometimes, it becomes challenging to keep everyone in your organization and users updated on what is new. How do you communicate product updates both inside and outside your organization?
Kristof: Outside the organization has never been one of my responsibilities, so I have little to add there. From a personal experience, I prefer to be updated by straightforward messages inside the product itself. A bit like Miro does with their product releases.
I prefer to work with both ‘information radiators’ and company-wide ‘show and tell’ meetings to spread that product updates inside the company.
Information radiators is a term coined by Alistair Cockburn in his book “Agile Software Development: The Cooperative Game”. It means that you have a wall or whiteboard somewhere in the office (or on a company-wide accessible digital whiteboard) that ‘radiates’ all the information into the room. It’s great to share ongoing work with colleagues who can casually pitch in on anything they see.
Show-and-tell meetings are an excellent opportunity to showcase recent work that has been finished and are a great way to hear from all the different departments within the company. It can help a lot in understanding how the work of sales, marketing, operations, or other company divisions aligns with your own work. It’s casual, so not as stressful as a demo or review meetings can be, and it doesn’t always have to be product or engineering doing the show-and-tell.
Producter is a product management tool designed to become customer-driven.
It helps you collect feedback, manage tasks, sharing product updates, creating product docs, and tracking roadmap.
You may also like:
Ferhan Gül
Ferhan Gül
