“Nee fok Thomas” - this article is brilliant. We’ve just launched JemX and the struggle we have is taking what we’re learning from essentially deploying AI consultants into our customers to figure out their biggest problems. We can solve them. One by one. But how to translate that into product and scale (as you have mentioned). That’s the hard part. Thanks for sharing.
Great piece. The pendulum swing from PLG to FDE is classic pattern recognition gone wrong, where one overcorrection just sets up the next. Back when I was working on a verticalized SaaS implmentation, we saw this play out in real time: teams that stayed embedded too long started optimizing for the loudest customer instead of the product roadmap. The Jolly example is smart bcause it treats the embedded role as part of adoption mechanics rather than as a workaround for immature product.
precisely. when the engineer/consultant is at one customer for too long, at some point they often start to behave like an employee of the customer. I had that a couple of times at some of the bigger SuccessFactors projects.
Love this article, Thomas, and the ’80s musical reference.
Having worked both outside and inside consulting, this resonates deeply, especially in healthcare. In areas like healthcare administrative workflows, early engineering at the customer is not a go-to-market strategy; it is how you learn to build scalable platforms. The real complexity in healthcare lives in broken processes, fragmented data and systems, and the human workflows holding everything together.
At the early stages, bringing non-healthcare team members close to that frontline reality is essential. It shows what truly needs to become product and what should disappear through standardization in order to scale.
The risk is letting engineers operate without sufficient domain context or without being part of a team that brings the best of all worlds together, turning them into permanent translators. When that happens, you are not building scalable enterprise infrastructure; you are doing projects.
Knowing how and when to apply humans in the loop, and when to deliberately pull them back out, is the difference between building a platform and becoming a consultancy, particularly in healthcare.
Couldn't agree more. This shift to FDE deeply mirrors current AI solution immaturity.
"My father was especially thrilled to see me move off his payroll into payroll" nice phrasing. I enjoyed reading the writing.
“Nee fok Thomas” - this article is brilliant. We’ve just launched JemX and the struggle we have is taking what we’re learning from essentially deploying AI consultants into our customers to figure out their biggest problems. We can solve them. One by one. But how to translate that into product and scale (as you have mentioned). That’s the hard part. Thanks for sharing.
Yeah, that's the really hard bit. That's where a great product manager earns their wedge. have a look at https://www.linkedin.com/in/teresatorres/ work.
Great piece. The pendulum swing from PLG to FDE is classic pattern recognition gone wrong, where one overcorrection just sets up the next. Back when I was working on a verticalized SaaS implmentation, we saw this play out in real time: teams that stayed embedded too long started optimizing for the loudest customer instead of the product roadmap. The Jolly example is smart bcause it treats the embedded role as part of adoption mechanics rather than as a workaround for immature product.
precisely. when the engineer/consultant is at one customer for too long, at some point they often start to behave like an employee of the customer. I had that a couple of times at some of the bigger SuccessFactors projects.
Love this article, Thomas, and the ’80s musical reference.
Having worked both outside and inside consulting, this resonates deeply, especially in healthcare. In areas like healthcare administrative workflows, early engineering at the customer is not a go-to-market strategy; it is how you learn to build scalable platforms. The real complexity in healthcare lives in broken processes, fragmented data and systems, and the human workflows holding everything together.
At the early stages, bringing non-healthcare team members close to that frontline reality is essential. It shows what truly needs to become product and what should disappear through standardization in order to scale.
The risk is letting engineers operate without sufficient domain context or without being part of a team that brings the best of all worlds together, turning them into permanent translators. When that happens, you are not building scalable enterprise infrastructure; you are doing projects.
Knowing how and when to apply humans in the loop, and when to deliberately pull them back out, is the difference between building a platform and becoming a consultancy, particularly in healthcare.