Brian Balfour on the organizational reality of shipping 5 AI products in 9 months, the 75% team loss nobody talks about, and why Discovery is the next bottleneck.
This is such a sharp case study in what “AI transformation” really looks like in org-chart terms, not just on the product surface. The 75% team loss, the willingness to sunset Compass, and the choice to rebuild around small founder-like pods instead of legacy functions is the level of courage I wish more leaders would name out loud. Excellent leadership and article, thank you, Elena and Brian, for putting this together.
You nailed it Anna! The tech is easy but the organizational courage to restructure is rare. I am so glad Brian was willing to be that transparent about the human cost.
Thanks Elena and Brian for this conversation. Some really useful insights on Product Leadership right here. Discovery is indeed the new bottleneck when we have tools now that can ship in hours (and 10x worse products without proper discovery).
Hey, Raghav! The "10x worse products" part is what keeps us up at night, right? 🥲
When I talked to Brian about this, I was struck by how clear-eyed he is about the trade-off: speed is both a feature and a bug. Tools that let you ship in hours are incredible...if you know what to ship. They're dangerous if you don't.
The discovery bottleneck isn't going away. It's just becoming more costly to ignore, I think.
Have you seen this play out in your own work? I'm curious to know what "fast bad decisions" you've seen teams make.
Hey, Elena! I have seen many a times when I am trying to build or vibecode. Hear about the tool, apply it in building a prototype and MVP and then later realise what was the problem (discovery) we were solving.
Its something I still struggle with but atleast I have discovered that discovery is pivotal and you need to define a problem before you turbo-charge towards the solution with AI-assistance.
It is the ultimate irony, isn't it? AI gave us infinite speed just so we could "rediscover" Discovery. We are finding out the hard way that building the wrong thing faster isn't actually progress!
When the 'how' becomes instant the 'what' becomes the only thing that matters.
Thanks for such a useful and insightful dialogue, Elena! Really enjoyed it.
It’s so interesting to me seeing how the AI era has accelerated and in a way also amplified the common pitfalls that have existed in digital transformations for so long.
Discovery was important before, as you well know, but the pace of delivery meant that so much more learning was forced before you committed to building, simply for pace of learning and careful investment. Now, that balance needs to be created through having much more awareness, so you don’t just accelerate the speed trap and create bloat that much faster.
I think the line between discovery and delivery is in a way getting fuzzier and fuzzier. We are tempted with the ability to deliver to discover so much more easily, so that needs additional deliberation.
Peter, this is such a sharp observation - "the ability to deliver to discover" perfectly captures the tension we live ine!
You're right that the line is getting fuzzier. Brian mentioned something in our conversation that connects to this: "A prototype is just an artifact. There's tons of workflow around that artifact."
I think what's happening is we're collapsing the "build to learn" and "build to ship" phases into something that looks the same but serves different purposes. The discipline now is knowing WHICH one you're doing and not accidentally shipping your "build to learn" experiment.
The awareness you're talking about, I think that's the skill. Knowing when you're discovering vs. delivering, even when the tool is the same.
Out of curiosity, have you noticed teams struggling with that distinction? Or finding good frameworks for it?
Thanks, Elena :) It's a big tension! Behaviorally, the friction has been removed. It's the easiest thing to do, it's how velocity usually gets measured (ticket completion).
As you point to, the way forward imho is introducing friction of thought in how you now approach delivery.
That prototype as artifact line really resonated with me. I have a yet-to-publish article about **the right prototype**. It's a question that comes up often. My answer is always the same — what decision are you making and what do you need to learn to make that decision? Sometimes, the most pragmatic thing to do is ship something and measure outcomes.
That collapsing of the learn/ship is 100% happening. And from my perspective, shipping is another level of learning, but at a higher scale (or slightly smaller if you are A/B testing to control risk). Risk is the variable to always think about, which is a different beast depending on the stage of product maturity. Balancing speed and risk well = velocity, by getting things right, building on top of them, and watching the results compound.
Balancing is a huge skill and also a much more mature one. From my experience so far (much more in leaning to digital transformation context so far in my career), it seems that most teams struggle there. And stakeholders tend to measure progress too much by "what will be available when" vs. "what do we now understand about how to create value".
The most mature teams from what I've observed see delivery as simply another stage of learning.
The phrase that seems to have stuck well in the past is pushing for "learning as the backbone" vs "delivery as the backbone" because that treats everything as different stages of learning, and aims the entire team's attention towards more of the right things.
Delivery as the backbone is where you get build traps and speed traps, insurmountable technical debt, or begin to alienate your user base by drifting away from or obfuscating the value provided.
Everything is learning and discovering, and proving it works at scale across your user base. Then, you build from it.
Wow!! This is what a detailed oriented lessons from an real world case study looks like!! Tons of lessons out there to learn from. Thank you Elena and Brian for sharing them in so much detail.
This is such a sharp case study in what “AI transformation” really looks like in org-chart terms, not just on the product surface. The 75% team loss, the willingness to sunset Compass, and the choice to rebuild around small founder-like pods instead of legacy functions is the level of courage I wish more leaders would name out loud. Excellent leadership and article, thank you, Elena and Brian, for putting this together.
You nailed it Anna! The tech is easy but the organizational courage to restructure is rare. I am so glad Brian was willing to be that transparent about the human cost.
Thanks Elena and Brian for this conversation. Some really useful insights on Product Leadership right here. Discovery is indeed the new bottleneck when we have tools now that can ship in hours (and 10x worse products without proper discovery).
Hey, Raghav! The "10x worse products" part is what keeps us up at night, right? 🥲
When I talked to Brian about this, I was struck by how clear-eyed he is about the trade-off: speed is both a feature and a bug. Tools that let you ship in hours are incredible...if you know what to ship. They're dangerous if you don't.
The discovery bottleneck isn't going away. It's just becoming more costly to ignore, I think.
Have you seen this play out in your own work? I'm curious to know what "fast bad decisions" you've seen teams make.
Hey, Elena! I have seen many a times when I am trying to build or vibecode. Hear about the tool, apply it in building a prototype and MVP and then later realise what was the problem (discovery) we were solving.
Its something I still struggle with but atleast I have discovered that discovery is pivotal and you need to define a problem before you turbo-charge towards the solution with AI-assistance.
It is the ultimate irony, isn't it? AI gave us infinite speed just so we could "rediscover" Discovery. We are finding out the hard way that building the wrong thing faster isn't actually progress!
When the 'how' becomes instant the 'what' becomes the only thing that matters.
Thanks for such a useful and insightful dialogue, Elena! Really enjoyed it.
It’s so interesting to me seeing how the AI era has accelerated and in a way also amplified the common pitfalls that have existed in digital transformations for so long.
Discovery was important before, as you well know, but the pace of delivery meant that so much more learning was forced before you committed to building, simply for pace of learning and careful investment. Now, that balance needs to be created through having much more awareness, so you don’t just accelerate the speed trap and create bloat that much faster.
I think the line between discovery and delivery is in a way getting fuzzier and fuzzier. We are tempted with the ability to deliver to discover so much more easily, so that needs additional deliberation.
Peter, this is such a sharp observation - "the ability to deliver to discover" perfectly captures the tension we live ine!
You're right that the line is getting fuzzier. Brian mentioned something in our conversation that connects to this: "A prototype is just an artifact. There's tons of workflow around that artifact."
I think what's happening is we're collapsing the "build to learn" and "build to ship" phases into something that looks the same but serves different purposes. The discipline now is knowing WHICH one you're doing and not accidentally shipping your "build to learn" experiment.
The awareness you're talking about, I think that's the skill. Knowing when you're discovering vs. delivering, even when the tool is the same.
Out of curiosity, have you noticed teams struggling with that distinction? Or finding good frameworks for it?
Thanks, Elena :) It's a big tension! Behaviorally, the friction has been removed. It's the easiest thing to do, it's how velocity usually gets measured (ticket completion).
As you point to, the way forward imho is introducing friction of thought in how you now approach delivery.
That prototype as artifact line really resonated with me. I have a yet-to-publish article about **the right prototype**. It's a question that comes up often. My answer is always the same — what decision are you making and what do you need to learn to make that decision? Sometimes, the most pragmatic thing to do is ship something and measure outcomes.
That collapsing of the learn/ship is 100% happening. And from my perspective, shipping is another level of learning, but at a higher scale (or slightly smaller if you are A/B testing to control risk). Risk is the variable to always think about, which is a different beast depending on the stage of product maturity. Balancing speed and risk well = velocity, by getting things right, building on top of them, and watching the results compound.
Balancing is a huge skill and also a much more mature one. From my experience so far (much more in leaning to digital transformation context so far in my career), it seems that most teams struggle there. And stakeholders tend to measure progress too much by "what will be available when" vs. "what do we now understand about how to create value".
The most mature teams from what I've observed see delivery as simply another stage of learning.
The phrase that seems to have stuck well in the past is pushing for "learning as the backbone" vs "delivery as the backbone" because that treats everything as different stages of learning, and aims the entire team's attention towards more of the right things.
Delivery as the backbone is where you get build traps and speed traps, insurmountable technical debt, or begin to alienate your user base by drifting away from or obfuscating the value provided.
Everything is learning and discovering, and proving it works at scale across your user base. Then, you build from it.
Maybe we need a reply post :)
Wow!! This is what a detailed oriented lessons from an real world case study looks like!! Tons of lessons out there to learn from. Thank you Elena and Brian for sharing them in so much detail.
Thank you, Dheeraj!
Brian has so much to share, and what he’s doing at Reforge is incredible!
I’m very lucky to have shared his story with all of you and that you have found it full of wisdom.
Sweet! The right approach to transformation is everything!
I agree, and only great leaders can know what the right direction is! 🚀