How Groupon Is Engineering Its Comeback

Two years ago, a PM at Groupon with a moderately complex feature to ship would spend something close to half their week on coordination. This is not a complaint about the people involved. It is a description of what the operating model required. A new feature moved through requirements, design, engineering estimation, back to product for scope negotiation, back to design for revision, through a backlog prioritization meeting, into a sprint planning session, and eventually into development — where it would immediately encounter questions the requirements hadn't anticipated, triggering a new round of clarification cycles. By the time a feature actually shipped, the PM had touched it in some administrative capacity fifteen to twenty times. Most of those touches were not value-adding. They were coordination overhead — the cost of moving information between people who were not in the same room and not using the same tools.

What did not happen during all this coordination was the work that should have defined a PM's job: understanding customers deeply enough to ask better questions, identifying which of the many things we could build would actually move merchant retention or customer rebooking, writing specifications precise enough that the team could execute without constant check-ins. Those things got squeezed into the margins because the coordination machine consumed the calendar.

When we restructured product squads around agentic infrastructure, the coordination costs did not immediately disappear — they shifted. The question changed from "how do we get all these humans aligned" to "how do we write specifications that are unambiguous enough for an agent to execute against." Those are superficially similar problems but structurally different ones. Aligning humans is a social problem that rewards persistence and political skill. Writing executable specifications is a precision problem that rewards clarity and honest uncertainty.

A pre-AI spec at Groupon looked like what you would expect from a mature product organization: a feature brief with context, goals, user stories in the standard "as a user I want" format, acceptance criteria that were thorough but written in natural language, and a section on open questions that never really got resolved before development started. This was not bad spec writing by industry standards. It was legible to a human engineer who could read between the lines, ask clarifying questions, and apply judgment about what the PM probably meant when the language was ambiguous. A human engineer could work with "the UI should feel intuitive" because they had enough context to translate that into something buildable. An agent cannot.

A post-AI spec at Groupon specifies the state of the system before the feature exists and the state of the system after. It lists every decision the implementation will require and provides the answer to each, or flags it explicitly as a decision the engineer needs to make and describes the criteria for making it well. Acceptance criteria are written as observable outcomes with test conditions: not "the checkout flow should be fast" but "time-to-complete-purchase from cart page should be below two seconds at the 95th percentile under load conditions comparable to a typical weekend evening." Open questions are not left open — they are resolved before implementation begins, or the specification waits. The discipline of writing this way caught ambiguity that previously got resolved inconsistently in the implementation phase and surfaced it earlier, when resolution is cheap.

The thing that surprised me about this discipline is how much it changed the quality of the thinking behind the specifications, not just the specifications themselves. When you know a vague statement will be unusable by the system that has to execute it, you are forced to do the work of figuring out what you actually mean before you write it down. We found that a significant fraction of the feature ideas that entered our planning process in vague form did not survive the act of specifying them precisely. The vagueness was not stylistic sloppiness — it was genuine unresolved thinking about what problem we were solving and what success would look like. Making specification precision a requirement exposed that unresolved thinking earlier. Some features got sharper. Some features got killed. Both outcomes were better than what would have happened under the old system.

The assumption that collapsed fastest when feedback loops got shorter was that we could validate product decisions through planning rather than through execution. Groupon had a culture of extensive pre-launch analysis: user research, competitive benchmarking, traffic modeling, internal debate. That analysis was valuable, but it was also expensive, and it was not more reliable than a two-week test with real users. When the cost of execution dropped, the math changed. It became faster and cheaper to run a small-scale test than to hold a planning meeting to debate whether the test was worth running. The first three months of running at higher experiment velocity invalidated assumptions we had held for years: that a particular merchant category would not respond to a specific type of promotion, that customers in a given geography rebooking within thirty days was a meaningful signal of satisfaction, that a specific onboarding step was causing drop-off. Each of those beliefs turned out to be more complicated than the planning documents suggested. The tests revealed the complexity. The planning meetings had smoothed it over.

The merchant side of this is worth being specific about. Groupon's business lives or dies on whether merchants renew their contracts and whether customers come back. Those outcomes are affected by dozens of variables that are difficult to attribute cleanly to any single product decision. What we can describe directionally: merchants who onboarded through the revised self-serve flow — which was rebuilt through two iteration cycles within a single quarter, a timeline that would have been impossible twelve months earlier — showed better activation rates in their first thirty days. Customers who went through a restructured post-purchase experience that was designed, tested, and revised in six weeks showed higher rates of returning within ninety days than the comparable cohort from the prior year. We are careful about attribution because the business environment shifts and causal claims are hard to defend. What we are confident about is the directionality: faster iteration cycles have not traded quality for speed. The outputs are better and they are arriving faster.

What did not change is the list of things human PMs still own and will continue to own. Merchant relationships are the clearest example. The trust that a long-tenured account manager has built with a merchant who has been on the platform for eight years is not a product artifact. It is a relationship, and relationships are not delegable to agents. When a merchant is having a bad quarter and is considering not renewing, the conversation that determines whether they stay is a human conversation. Agents can surface the data that identifies the merchant as at risk, can draft the outreach, can summarize the account history. The conversation itself belongs to a person.

Strategy is the second category that stays human. Agents are very good at executing against a specified direction. They are not good at questioning whether the direction is right. That question — are we solving the right problem, are we going after the right market segment, is the assumption underlying this roadmap actually true — is the question that distinguishes good product leadership from capable product management. Agents did not change how that question gets answered. They changed how quickly we can test the answers we come up with.

The third category is judgment under conditions of novel ambiguity. Agents handle well-specified problems well. They handle ambiguous problems poorly, because ambiguity resolution requires drawing on context and values that are difficult to encode. The situations where something genuinely unexpected happens — a regulatory change, a major competitor move, a market shift that our models didn't anticipate — require human reasoning about uncertainty that agents are not equipped for. Those situations are not common. When they arise, they require humans who have been paying attention and have enough context to reason well under pressure.

What I would tell a product leader at another company who is about to go through this: the bottleneck moves, it does not disappear. Before agentic infrastructure, the bottleneck was execution speed — getting from decision to shipped feature took too long. After agentic infrastructure, the bottleneck is decision quality — the value of faster execution is determined entirely by whether you are executing on the right things. If your team's product thinking is weak, agentic infrastructure will expose that weakness quickly and mercilessly. You will ship more things faster and discover sooner that they do not move the needle. That is an improvement over discovering it slowly, but it is not a substitute for the hard work of understanding your customers and your business deeply enough to make good decisions about what to build. Speed compresses the learning cycle. It does not replace the learning.

The teams at Groupon that have benefited most from the transformation are the teams that were already good at product thinking. They have gotten faster and have used the speed to test and validate more aggressively. The teams that struggled with product clarity before continue to struggle with it — just at higher velocity. Building the right spec discipline was our attempt to address this directly: to make the practice of clear thinking about product problems into a prerequisite for using the infrastructure, not an optional supplement. It has worked better than I expected and not as completely as I hoped. Teaching teams to write precise specifications turns out to be less like installing a tool and more like developing a habit, which requires time and practice and the willingness to be wrong in front of each other.

Groupon is rebuilding something real. The comeback this describes is not primarily a technology story — it is a story about what happens when a team with hard-won operational knowledge of a difficult business gets faster feedback loops and better execution infrastructure. The technology enables something. What it enables is people who understand merchants and customers and the specific texture of this market making more decisions, faster, and finding out sooner which decisions were right.