I talked with Jack Ryan about product engineering at Intercom scale: what changes when implementation gets faster, and what does not.
Jack has spent years as a principal engineer without people management, after earlier startup years where engineering success and company success were basically the same thing. That background shows up in how he talks about responsibility. Product engineers do not get to stop at "I shipped the ticket on time." The question is whether the thing you shipped is being used, whether customers are happier, and whether the work connected to real business outcomes.
Reframe what counts as success
One idea I kept coming back to is how easy it is to celebrate the wrong milestone. Shipping on schedule feels good. Jack's push is to look back at usage, customer happiness, and whether the work mattered to the business.
Metrics can start those conversations, but he is skeptical of sweating tiny week-to-week movements on a single number when qualitative signals and customer conversations often tell you more. That is a useful product engineering habit: treat data as a prompt to learn, not as a scoreboard that replaces judgment.
Feedback loops you will actually see
The practical thread in the episode is wiring customer signal into your day. Jack talked about Slack feeds, sales-call snippets, forward-deployed engineer patterns, and other ways to let feedback "wash over you" instead of living only in a quarterly research deck.
The other half is discipline before you build. Customer requests are inputs. The product engineer's job is still to ask why someone wants something before treating their feature request as the spec.
