The double diamond is a liability. Engineers ship faster than designers can explore. The PM role is dissolving and the three profiles that will survive this era look nothing like who we've been hiring
This is a profoundly great question, I should have covered it. My rule of thumb: 80/20, but not the way most people think. 80% of your time goes to delivery using the stack you already trust. 20% goes to experimentation, but structured experimentation, not random tool-hopping.
In practice this means I pick one real deliverable per week and force myself to use a new tool or workflow to produce it. Not a side project. Not a sandbox. An actual client artifact. Because the only way to evaluate whether a new tool is better is under real constraints - deadlines, feedback loops, quality bars.
The trap most people fall into is treating experimentation as something separate from delivery. "I'll try that new thing when I have time." You never have time. Instead, you build the experimentation into the delivery itself. Ship the thing AND learn the tool. It's slower the first time, faster every time after.
The other thing I'd say: you don't need to evaluate every new product that drops. Most of them are incremental. I keep a shortlist of 3-4 workflow bottlenecks I want to solve, and I only look at new tools through that lens. If it doesn't address one of my actual bottlenecks, I ignore it. That filter alone saves hours per week.
Interesting, and I'll keep that in mind, Experimentation is a joy but sometimes it can guide you straight into a rabbit hole. Keep up the good work and it´s awesome to get your updates on different aspects of the rapid transition we currently are in :)
How do you split between delieverance and experimentation with new workflows as a consequense of new products being released weekly?
This is a profoundly great question, I should have covered it. My rule of thumb: 80/20, but not the way most people think. 80% of your time goes to delivery using the stack you already trust. 20% goes to experimentation, but structured experimentation, not random tool-hopping.
In practice this means I pick one real deliverable per week and force myself to use a new tool or workflow to produce it. Not a side project. Not a sandbox. An actual client artifact. Because the only way to evaluate whether a new tool is better is under real constraints - deadlines, feedback loops, quality bars.
The trap most people fall into is treating experimentation as something separate from delivery. "I'll try that new thing when I have time." You never have time. Instead, you build the experimentation into the delivery itself. Ship the thing AND learn the tool. It's slower the first time, faster every time after.
The other thing I'd say: you don't need to evaluate every new product that drops. Most of them are incremental. I keep a shortlist of 3-4 workflow bottlenecks I want to solve, and I only look at new tools through that lens. If it doesn't address one of my actual bottlenecks, I ignore it. That filter alone saves hours per week.
Interesting, and I'll keep that in mind, Experimentation is a joy but sometimes it can guide you straight into a rabbit hole. Keep up the good work and it´s awesome to get your updates on different aspects of the rapid transition we currently are in :)
You have the ability to destillate chaos into action, great read as always.