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.
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. This was one of the biggest eye-openers from the recent Domain-Driven Design training for product management I gave with Connected Movement.
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 organisation for providing us with this platform, and a special thank you to every single participant who joined us.
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' – 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.
For me, it was also a personal challenge: could I use Wardley Mapping for a solution space with eight people? 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.
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. 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.
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
@yellowbrickc,
@__maxs__,
@hschwentner, and I ran at the DDD Europe hands-on labs.
It teaches how to apply DDD principles for more effective collaboration and building better digital products together, as I also write about in the co-authored book Collaborative Software Design!
Beyond the confirmed Dutch course, an English edition is available on September 15th and 16th in Amsterdam.
More details can be found here: https://connected-movement.com/course/domain-driven-design-voor-product-management/
Domain-Driven Design voor Product Management - Connected Movement
I'm particularly 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 @xinyao and johncutlefish@mastodon.social giving a joint keynote is a fantastic development and a great sign.
This emphasis on better collaboration between these diciplines was the inspiration for my 'Domain-Driven Design for Product Management' course. - 2/
