We just wrapped a three-day Product Summit. Day one mixed connection with substance: a team culture activity, brand-level "2H big bets" headlines, an Executive Insight talk from Bob Fontana, and then the real work — a 1H 2026 reflection on what we said we'd do, what actually happened, and the gap between the two. We closed the day with Big City Pickleball and an informal dinner. Day two pointed further out: guest talks from Trevor Ragan (Learner Lab, on getting better at getting better) and Tim Sanders (Practical AI), then a first pass at 2027 big bets. Day three was a working session on that 2027 plan — including bets that hadn't made the original survey — followed by closing remarks and a team reflection before everyone scattered for the airport. The format itself was a mix throughout: small-group discussion, then presentations, back and forth for three days straight.
I went in expecting a product conversation. I came out thinking mostly about engineering — not what we should build, but how a group this different manages to agree on anything at all.
We Are Not Speaking the Same Language
The room was Product Managers, engineers, and people from the Project Management Organization, and the differences weren't personality — they were method. Some people arrive with a top-down instinct: build the portfolio, frame it for the CXOs inside the TAG, get the narrative straight before the details are settled. Others arrive bottom-up: what's the problem, is it real, and does anyone actually have it. Both produced credible-sounding bets in the same session. Only one of them usually survives contact with an engineering estimate.
Neither instinct is wrong. A portfolio view is how you get budget and air cover for anything that takes more than a quarter. A problem-first view is how you avoid spending that budget on something nobody needed. The failure mode isn't picking the wrong one — it's not noticing which one a given bet came from, and then reviewing it with the wrong questions. You cannot ask a portfolio bet "what problem does this solve" and expect a satisfying answer, and you cannot ask a problem-first bet "how does this roll up to the CXO narrative" without watching someone reverse-engineer a story that wasn't there yesterday. Engineering sits at the point where both kinds of bets have to turn into actual work, which means engineering is usually the first to notice when a bet was never translated out of the language it was pitched in.
Everyone Is at a Different Point With AI, and It Shows
Trevor Ragan's talk on getting better at getting better, and Tim Sanders' talk on practical AI, landed very differently depending on who was in the seat. Some of the room is early — still hunting for the first real use case, still building the habit of reaching for the tool before reaching for the old way of doing things. Some of the room has been living inside AI-assisted work for a while now, and the question on their mind wasn't "what can this do" but "am I actually more productive, or do I just feel busier in a new way." Burnout came up more than once, not as a complaint about workload but as a specific worry: that the speed is real but arrives with a quieter cost that doesn't show up until later.
That gap matters for how bets get proposed and reviewed. A bet framed by someone early in their AI journey often reads as "we should use AI for X" — the tool is the point. A bet framed by someone further along tends to interrogate the second-order effect first: not whether the model can do the task, but whether the team will trust the output enough to stop checking it, and what happens to quality and morale if they do. Both are legitimate inputs. But a room that doesn't know which kind of AI experience is behind a given bet will either over-index on novelty or over-index on caution, depending on who spoke last.
Nobody Agrees on What a "Bet" Actually Is
This was the one that surprised me most, given how much of the summit was structured around the word. Some proposals on day three were, plainly, a technical solution looking for a home — "we should build/adopt X." Others were closer to a governance question — how do we decide who's allowed to use AI for what, what needs review, where the guardrails go. Both got pitched using the same "big bet" template, and both got the same kind of nodding in the room, but they're not the same thing and they don't get evaluated the same way.
A technical bet has a build cost, a maintenance cost, and a fairly clear definition of done. A governance bet has almost none of that — its cost is organizational friction, its payoff is risk avoided, and "done" is closer to "adopted" than "shipped." Engineering can estimate the first kind in a planning session. The second kind needs a completely different conversation, usually with legal, security, or whoever owns the CXO relationship in the room. When both show up labeled "bet" with the same one-pager format, the summit ends up comparing a sprint's worth of work against a policy change, as if they compete for the same slot on the same roadmap.
There's a second axis hiding under the first: how far out the bet reaches. The 2H big bets from day one were already brand-level headlines — specific enough that engineering could put a rough number on most of them before lunch. The 2027 big bets taking shape on days two and three were closer to hypotheses: directions worth exploring, deliberately unscoped, because committing to specifics a full year out is its own kind of lying. That's a reasonable difference to have. But it means a "bet" in the same one-pager format could be a scoped, buildable thing due this half, or a speculative direction nobody expects to survive contact with next year's actual roadmap. Cross that with technical-versus-governance and a single template is now standing in for four different objects: a scoped technical bet, a scoped governance bet, a speculative technical bet, and a speculative governance bet. Most of the friction in the room came from reviewing all four as if they were one thing — asking a 2027 direction for 2H-level specificity, or letting a 2H bet borrow the "it's early, we're still exploring" latitude that should only apply to next year's plan.
What This Means for Engineering Inside Product
None of these three gaps are things engineering can resolve by writing better code. They're closer to translation problems, and translation is exactly the kind of thing an engineering org sitting inside a product org is well positioned to do — if it treats that as part of the job rather than a distraction from it.
Concretely, that looks like a few habits I want to carry out of this summit:
- Name the instinct before reviewing the bet. Ask whether a proposal came from a top-down portfolio need or a bottom-up problem, and review it on those terms instead of forcing every bet through the same checklist.
- Ask where someone is in their AI journey before weighing their AI take. Early enthusiasm and hard-won caution are both useful signal, and both are misleading if you mistake one for the other.
- Split the "bet" template. A technical bet and a governance bet shouldn't compete on the same roadmap slot using the same estimate. Give them different templates, and probably different reviewers.
- Tag the time horizon, not just the type. A 2H bet and a 2027 bet earn different levels of rigor before they're reviewable. Don't ask a still-forming 2027 direction for 2H-level specificity, and don't let a 2H bet borrow the "we're still exploring" latitude that should only apply to next year's plan.
The summit's real output, for me, wasn't the list of 2H bets — it was the reminder that a product org this size isn't one team with one method. It's several methods sharing a roadmap, and the engineering group's most useful job might be making sure everyone knows which method they're currently arguing in.
