Kenny (Baas) Schwegler

flash-back quote to all the low-code programming ;)

And it's a two-way street! Because the teams are so close to the product, they're constantly observing and finding new opportunities themselves. Less time dictating, more time discovering and building together. That's where the real magic happens for great products.

Instead of getting bogged down in writing super detailed requirements and just handing off designs, POs are freed up to dig deep into market research, really understand opportunities, and collaboratively model solutions right there with the team. It's a fundamental shift in how we work.

This was one of the biggest eye-openers from the recent Domain-Driven Design training for product management I gave with Connected Movement.

When teams truly own their domain and design architecture through Domain-Driven Design, combined with Team Topologies and solid Continuous Delivery/DevOps practices, Product Owners get to do so much more actual product management.

I cannot agree more! Using Wardley Mapping in person requires a lot of expertise so that the tool is not in your way, which a digital board eliminates for you. Which is handy in a collaborative format. At clients, I usually use miro sitting in a room together doing Wardley or User needs mapping :)

Because when you're dealing with genuine complexity, relying on just one collaborative modelling tool is simply going to fall short!

My sincere thanks to the ‪@dddeu.bsky.social‬ organisation for providing us with this platform, and a special thank you to every single participant who joined us.

where we'll capture all our learnings from the session. Our hope is that this becomes a sort of blueprint, inspiring others to experiment with these tools and discover what works best for them.

And working with eight people on Wardley Mapping is already tough, but on a whiteboard where moving things feels like a huge effort compared to Miro? Even tougher.

In the coming months, I'm setting up a new DDD-crew repo – tentatively called 'When to use what CoMo tool' –

I usually rely on it for mapping the current landscape, often in a "together, then alone" approach for design. And yes, it was challenging, but we definitely uncovered a ton of valuable insights. The main thing missing was that initial map of the current landscape to kick things off.

But honestly, it was just as much about us learning and digging into the strengths and limits of each tool right there with the groups.

For me, it was also a personal challenge: could I use Wardley Mapping for a solution space with eight people?

The big idea was to give participants a firsthand feel for how using different modelling tools can unlock completely different insights for intricate problems, ultimately leading to a much stronger design. We used Wardley Mapping, Domain message flow modeling, EventStorming, and Domain Storytelling.

So, imagine this: one complex design problem, four different collaborative modeling tools, four facilitators, and 45 minutes to solve it with a group of 8! That was the intense setup Krisztina, ‪@maxsc.bsky.social‬, ‪@hschwentner.bsky.social‬, and I ran at the DDD Europe hands-on labs.

It's a common aspiration, Collaborative software design leading to wonderfully autonomous teams and truly decentralized decisions. Yet, the reality, as ‪@evelynvankelle.bsky.social‬ and ‪@kenny.weave-it.org‬ so thoughtfully discussed at Fast Flow Conf NL, central decisions don't just disappear.

Beyond the confirmed Dutch course, an English edition is available on September 15th and 16th in Amsterdam.

More details can be found here: connected-movement.com/course/domai... - 5/5

This emphasis on better collaboration between diciplines inspired the 'DDD for Product Management' course. It teaches how to apply principles for more effective collaboration and building better digital products , as I also write about in the co-authored book Collaborative Software Design! - 4/5

I'm thinking about whether we'll see more product managers this year. I've long pushed for better collaboration between architecture/development and product management, so ‪@settling-mud.bsky.social‬ and J@johncutle.fish‬ giving a joint keynote is a fantastic development and a great sign. - 3/5

Kicking off with my hands-on collaborative modeling lab with Kristzina, ‪@maxsc.bsky.social‬ and ‪@hschwentner.bsky.social‬ which seems to be full! It's always a highlight of the year, and I'm keen to see who's attending. - 2/

Good news for those interested: my Domain-Driven Design for Product Management course on June 23rd and 24th in Utrecht (in Dutch) is confirmed and running!

Meanwhile, I'm heading to Domain-Driven Design Europe today. - 1/

Registration Registration for devopsdays Amsterdam 2025

Don't forget to use the discount code #FRIENDS_OF_SPEAKERS for 20% off a regular 2-day ticket. Seriously, these tickets go fast!

Buy your ticket(s) here:
devopsdays.org/events/2025-...

We'll share practical insights on how to reduce that intrinsic and extraneous load when making crucial architectural choices.

It's going to be a great time – a truly community-driven event with plenty of opportunities to network. 3/4

Without a solid grasp of user needs, value chains and team boundaries, those decisions can quickly add to your cognitive load.

If you're going to be in Amsterdam on June 18th, you're in luck! ‪@thomaskrag.bsky.social‬ and I are presenting at #Devopsdays Amsterdam on User Needs Mapping. 2/4

Ever feel like your brain is overflowing when making architectural decisions that impact other teams in the organisation? It's a common challenge, especially as teams become more autonomous. 1/4

Is that a new hope for you?

While my DDD training often helps groups take those essential first steps, I can't shake the feeling that if we don't fundamentally change how people are educated from the outset, we're simply expending too much effort trying to fill an ever-growing need for developers. - 10/10

That real-world immersion helped me recognize and shed the less effective skills I’d been taught, revealing how software engineering truly needs to function to maintain adaptability and resilience in the face of organizational changes. -9/10

I was applying Domain-Driven Design, robust OOP principles, and practical software architecture, working with 120 services in an event-driven system, deploying to production multiple times a day, even on Fridays. - 8/10

We're still missing the mark on teaching the crucial skills I was fortunate enough to gain in my first six years in the industry. Back then, it was simply expected that developers understood the business. My first month, I got a two-day workshop focused entirely on asset management. - 7/10

But that’s just automating the creation of code, often built on the same foundational principles of abstraction and "platonic" thinking that cause problems in the first place. The outcome will be the same, just delivered faster. - 6/10

In either scenario, it takes more effort and makes adapting far harder when those core business concepts shift.

Now, there's this notion that AI will simply let us "vibe code" our way through development. - 5/10