I was a guest on Digital Product Talks, the COBE podcast, talking with Felix van de Sand and Daniel Wagner for a good eighty minutes about product organizations, product discovery, design systems, and what AI is doing to all three. Conversations like that have a way of sharpening things you’ve been circling for years.
The episode is in German. If that works for you, skip this write-up and go straight to the source. If it doesn’t – or if eighty minutes is more than you have – find the five points I’d underline below.
🎧 Digital Product Talks on Podigee | Spotify | Apple Podcasts (81:35)
Project culture is more management-friendly than product culture
🎧 12:45
“If you always dodge those conversations and tell yourself the people above have decided, so I’ll just do it – you’ll never build a really good product. You end up as an order-taker, and then you’re back at the feature factory.”
Teams don’t become feature factories because someone decides to build one. They become feature factories because the organization around them never left project thinking behind – the world of specifications, scopes, and tasks to be checked off.
And that world is genuinely easier to manage. You have a list of twenty items, sixteen already have green checkmarks – you are a good manager! Product work offers no such comfort. If you’re a manager under pressure, standing in front of your own boss and admitting you’re not entirely sure yet what you’re building takes a kind of confidence not everyone has.
Which is why no team fixes this alone. A team can name the problem – that alone helps – and can work out how it would rather operate, then go to its leadership and negotiate a test-and-learn window. Trust is earned in small increments. When we rebuilt otto.de, we started with three teams working differently inside a very large organization that wasn’t. Those three teams earned enough trust through results that today roughly a hundred product teams work by the principles they established. Not overnight. But it moved.
A product strategy should read like a fine-dining menu
🎧 22:00
“Product strategies are better when they don’t always want everything, but instead show a clear position: that’s where we want to go – and that’s where we don’t, or that’s simply not relevant right now.”
The format doesn’t matter. Word document, a drawing, a video – whatever lands with your people. What matters is that a product strategy creates clarity, and that it isn’t merely a collection of wishes.
Go to a good restaurant and the menu has five or six dishes. Barely a choice, and all of it excellent. The place on the corner offering everything from schnitzel to kebab to sushi should give you pause. And whatever position you take has to be aligned with the company strategy above it – the company wants X, therefore we as a product organization do Y. Writing it down is half the job. Maybe less than half. The real work is in the hard decisions of what not to do.
Product discovery is risk management, not a design nicety
🎧 30:40
“After fifteen years of user tests I’d say I have a pretty good instinct for what works in UX. And I’m still surprised how often I turn out to be wrong.”
Building and running software is expensive even with AI, and building the wrong thing doesn’t just waste money – it drives customers away, and it can keep you building the wrong product for years because you fell in love with your solution.
Two examples we kept coming back to. Sonos shipped an app update its own people had flagged as broken, and a company whose entire value proposition is user experience lost stars, users, and market capitalization in a matter of weeks. Duolingo replaced lovingly handcrafted lessons with AI-generated ones and lost users who’d been on thousand-day streaks. Imagine having a great personal language teacher and one day a small cassette recorder shows up instead. The risks to both businesses could have been spotted in advance. Neither case required magic – just talking to users before, not after.
And the objection that discovery is too slow in the age of AI has it backwards: if I run ten times faster in the wrong direction with AI, I’ve still lost a lot of time.
💡 Want to learn how product discovery works? Have a look at my training offers.
A design system can serve as a vocabulary book for AI
🎧 53:00
“You’re not less of a designer because you don’t have to draw that button from scratch every time. And you’re no less of a developer because you don’t have to write that same button again and again.”
I’ve been a design system person for a long time; I initiated OTTO’s first one, and later the second design system for our B2B portals. The old arguments still hold: consistency, efficiency, and a shared product language, so that a thing is the primary button and not “that red knob over there.”
But there’s a new one. We all know AI-generated code is middling and doesn’t always survive contact with complex production systems. A design system narrows the field: the model doesn’t reinvent every UI component, it draws from a coarser box with fewer degrees of freedom, and the output gets meaningfully closer to production-ready.
The caveat hasn’t changed either. A design system has to be treated as a product, with dedicated resources and real ownership. Run as somebody’s side project, it won’t last – and it can’t be pushed grassroots against management, because then it’s a hobby. The other failure mode is overloading it: everything in the UI, the brand guidelines, the copy rules, until there’s so much choice that there’s no guidance left. We have a simple rule – if something almost certainly won’t be reused, it doesn’t go in.
AI’s optimum lies between the roles
🎧 1:08:46
“Otherwise all you find is a local optimum. The designers work out among themselves how to use AI to do Figma better, and the developers can code faster. But I believe the optimum lies between the roles.”
This is what I’d push hardest on right now. When organizations start experimenting with AI, usually designers sit down with designers and developers with developers – and each group optimizes its own craft.
But our roles were drawn where they are because of what software development used to cost and require. Those boundaries were, to a degree, arbitrary, and they don’t have to stay put. Maybe I hand developers frontend code instead of a Figma file. Maybe I do the rough concept and the developer shapes the UI. Maybe the product manager builds a prototype instead of writing a PRD. You only find those things by experimenting across roles – user perspective, technical perspective, business perspective in the same room.
To the designers who are worried: people who say “I can generate a design in one click, I don’t need a designer” usually don’t know what designers really do. Building the final artifact is maybe the last ten percent of the work. The answer isn’t defensiveness, it’s making your actual contribution legible – to yourself and to everyone else.
The last question was what I’d change about how we design digital products, if I could change one thing:
I’d give product teams the trust and the space to find the solution that reaches their objectives, the outcomes we want – instead of constantly confronting them with long lists of features. Because I believe that’s how we get the best solutions.
