A year ago I wrote about how AI would shift the bottlenecks in product development from the middle of the cycle — writing code — to the end, where we help customers understand what we built, try it, and turn it into value (money).
Thanks, Rich – Every time I see another piece championing the value of increasing shipping velocity over strategy and discovery, I know it won't end well.
Some companies can afford to load their products down with technical & UX debt.
But as you say, you still only have the same 12 words to position your product.
Hi Rich - love the post and your insights. The forward-deployed engineer pattern is telling. When you see it emerge post-contract, discovery was skipped, positioning is off and the product is incomplete. The customer is now funding the product thinking that should have happened upstream. This doesn't scale and should not be declared as victory.
A product has always been more than the software code. Now that delivery becomes quicker, the other functions like positioning, pricing, messaging, creating value become more visible.
"If your customers need a full-time engineer sitting next to them to understand what your product is supposed to do, how it fits their environment, and how they measure success from it… these are product problems, not deployment problems. (Or you’re eager to adopt a professional services model.) The discovery and decision work that should have happened before launch is now happening after the contract is signed, on the customer’s dime or yours."
Exactly, and that's the whole point. A product is an (somewhat educated) guess at what a number of prospects would find valuable. The higher the number the better because that's how you make the economics of building it make sense. But lately those economics make the very notion of "product" obsolete. There's no need to mediate the eventual value creation for a customer (and thereby creating the customer) via what we used to call "products" in software. MS Word is a product, and the fact that only 3% of its features are used by any given user is the flipside of the old product development economics.
What FDEs do is restore the term "engineering" to its original meaning: solve a problem by assembling relevant technologies and building blocks on site. They deliver the value directly, yes on the customer's dime as it should be, by hearing firsthand what words these "actual users actually use to describe their perceived problems" in this particular customer context.
That under the legacy regime "the he discovery and decision work should have happened before launch" was an artifact of legacy economics. And it is now happening after the contract is signed precisely because the new economics of engineering made it possible since last November.
Clearly, I disagree. Participating in this fundamental argument over four decades means I have a strong POV that "product" means much more than what one customer uses one tools/platform/kit for.
My broad point is that the economics of single-user/single-consultant/single instance/FDE is unsustainable financially. See for instance https://www.mironov.com/4law2/ "Legacy" is how first-timers ignore the pattern, because this time it will be different. Let's revisit FDEs a year from now
Thanks, Rich – Every time I see another piece championing the value of increasing shipping velocity over strategy and discovery, I know it won't end well.
Some companies can afford to load their products down with technical & UX debt.
But as you say, you still only have the same 12 words to position your product.
Hi Rich - love the post and your insights. The forward-deployed engineer pattern is telling. When you see it emerge post-contract, discovery was skipped, positioning is off and the product is incomplete. The customer is now funding the product thinking that should have happened upstream. This doesn't scale and should not be declared as victory.
A product has always been more than the software code. Now that delivery becomes quicker, the other functions like positioning, pricing, messaging, creating value become more visible.
"If your customers need a full-time engineer sitting next to them to understand what your product is supposed to do, how it fits their environment, and how they measure success from it… these are product problems, not deployment problems. (Or you’re eager to adopt a professional services model.) The discovery and decision work that should have happened before launch is now happening after the contract is signed, on the customer’s dime or yours."
Exactly, and that's the whole point. A product is an (somewhat educated) guess at what a number of prospects would find valuable. The higher the number the better because that's how you make the economics of building it make sense. But lately those economics make the very notion of "product" obsolete. There's no need to mediate the eventual value creation for a customer (and thereby creating the customer) via what we used to call "products" in software. MS Word is a product, and the fact that only 3% of its features are used by any given user is the flipside of the old product development economics.
What FDEs do is restore the term "engineering" to its original meaning: solve a problem by assembling relevant technologies and building blocks on site. They deliver the value directly, yes on the customer's dime as it should be, by hearing firsthand what words these "actual users actually use to describe their perceived problems" in this particular customer context.
That under the legacy regime "the he discovery and decision work should have happened before launch" was an artifact of legacy economics. And it is now happening after the contract is signed precisely because the new economics of engineering made it possible since last November.
Clearly, I disagree. Participating in this fundamental argument over four decades means I have a strong POV that "product" means much more than what one customer uses one tools/platform/kit for.
My broad point is that the economics of single-user/single-consultant/single instance/FDE is unsustainable financially. See for instance https://www.mironov.com/4law2/ "Legacy" is how first-timers ignore the pattern, because this time it will be different. Let's revisit FDEs a year from now
deal