AI made product development faster. Now teams face a harder question
AI is speeding up product execution, raising the stakes for judgment, measurement, reliability and accountable decision-making.
At Indonesia Product Conference 2026, Aditya Chintawar Founder and CEO of Kite, reduced a broad change in product development to two questions: "The old constraint: can we build it? The new constraint: should we build it now?"
That shift is easy to underestimate. AI is shortening work across research synthesis, reporting, prototyping, coding, data analysis and documentation. When more ideas can become working outputs with less time and effort, execution stops filtering the product roadmap as aggressively as it once did. The constraint moves upstream, toward choosing the right problem, and downstream, toward proving that the result is reliable and valuable.
Faster delivery, in other words, does not remove product discipline. It raises the cost of weak judgment.
Table of contents
Jump to each section:
- Execution is getting cheaper
- The harder question is what deserves to be built
- Measurement becomes a product discipline
- Reliability changes the definition of done
- Production exposes the real constraints
- What this means for marketing teams
Execution is getting cheaper
At tiket.com, Head of Product Prasetyo Andy Wicaksono described AI taking on repetitive work such as report generation, dashboards, data crunching, blind-spot detection and the creation of internal tools. These are not speculative uses. They are ordinary parts of product operations that consume attention even when they do not define the product itself.
Compressing that work changes the economics of experimentation. Teams can investigate more questions, assemble more evidence and produce more prototypes without waiting through every traditional handoff. The immediate benefit is speed, but the structural effect is a larger supply of plausible things to build.
That abundance creates its own problem. A team with ten feasible ideas still has to decide which one deserves customer attention, engineering capacity and organizational commitment.
Wicaksono put the distinction plainly: "Don't just focus on speed. Also focus on the depth and quality of the judgement we are making."
AI can make an answer arrive sooner. It cannot make the underlying question important.
Kai Indra
The harder question is what deserves to be built
Product management has often treated feasibility as a practical gate. Some ideas fell away because they were too expensive to test, too slow to prototype or too difficult to support. As those barriers weaken, teams can mistake the ability to produce something for evidence that it should exist.
The common assumption is that faster building creates a faster path to value. The contrasting reality is that it can also create more low-cost distractions. The strategic implication is that discovery, prioritization and problem framing become more valuable precisely because execution has become easier.
Chintawar's formulation captures the new burden on product leaders. "Should we build it now?" asks more than whether an idea is useful. It asks whether the problem is important enough, whether the timing is right, whether the organization can support the outcome and what will be displaced by saying yes.
When execution becomes abundant, restraint becomes a product capability.
This is especially relevant for AI features, where a polished demonstration can create a false sense of readiness. A prototype may show that a model can generate an output. It does not yet show that customers will change their behavior, that the output is dependable enough for the context or that the operating cost will make sense at scale.
Measurement becomes a product discipline
Zachri Alrashid, Head of Growth and CRM at MIFX, approached the issue from the business-value side. "There's so much happening with AI. It's impossible to keep up with every model," he said.
For product teams, that is an argument against organizing strategy around the model cycle. New capabilities will continue to appear, but novelty does not tell a team which customer problem matters most. A stable definition of success gives the organization something more durable than a sequence of tool evaluations.
Alrashid recommended staying focused on how success is measured, even when the measurement is relatively simple. That matters because speed can inflate activity metrics. More generated reports, faster analysis or a higher volume of experiments may demonstrate output, but they do not necessarily demonstrate better decisions, stronger retention or a more useful customer experience.
The more a team can produce, the more carefully it has to define progress.
Measurement also creates a boundary for experimentation. It gives product leaders a reason to continue, change direction or stop. Without that boundary, inexpensive prototypes can become expensive commitments through momentum alone.
Reliability changes the definition of done
"Reliability is an important aspect," Alrashid said. He described checking numbers, applying simple guardrails, building risk awareness and distinguishing between decisions that are easy to reverse and those that are difficult to undo.
These practices place AI evaluation inside product work, rather than treating it as a final technical check. The appropriate threshold depends on the consequence of failure. A draft that a colleague can quickly correct carries a different risk from an output that shapes a customer's financial decision or triggers an automated action.
That makes reversibility a useful design principle. Teams can permit more autonomy where errors are visible and cheap to correct, while requiring stronger review where an error could be costly, difficult to detect or hard to reverse. The objective is not to eliminate uncertainty. It is to match control to consequence.
Human involvement therefore has a more specific purpose than simply keeping a person in the loop. During the fireside chat, Kurby Chua Principal Customer Success Architect at Mixpanel, argued that organizations still need human involvement when someone must ultimately take responsibility for an outcome. Accountability is not a ceremonial approval step. It is a product requirement that should shape permissions, escalation paths and evidence.
Automation can distribute work but it cannot distribute responsibility indefinitely.
Production exposes the real constraints
The distance between an impressive AI prototype and a durable product becomes clearer after launch. A demonstration can be judged on whether it works once. A production system has to remain useful under changing inputs, real customer behavior, recurring costs and operational pressure.
That distinction framed Superbank's Group Head of Product Sofian Hadiwijaya’s discussion on why AI products fail after launch. The conference program pointed to cost and overlooked operational factors as central concerns. A later scaling panel was set to examine the same transition through safety, stability and cost efficiency across enterprise infrastructure and consumer products.
Those themes reinforce the story's central tension, but they should not be confused with reported outcomes from the speakers. The public agenda did not provide the concrete failures, adoption data or cost examples needed to compare pilots with production responsibly.
Even so, the product implication is clear. Launch is not the end of the build decision. It is the point at which assumptions about demand, reliability, governance and economics begin meeting real conditions. Teams that treat production readiness as a technical milestone risk discovering too late that the harder constraints were organizational and commercial.
An AI product is not proven when it generates a credible result. It is proven when the organization can repeatedly create, evaluate and stand behind that result.
What this means for marketing teams
AI is not only helping marketers work faster. It is also making it easier for them to build their own tools, workflows and lightweight solutions without waiting on a full product or engineering cycle. Chintawar also offered a practical seven-day playbook for teams getting started.
For teams experimenting with that shift, the IPC discussions point to a few useful principles:
- Start with the problem
Building is becoming easier, which also makes it easier to create solutions nobody really needs. Start with a specific marketing or customer problem, then decide whether building something is actually the right response. - Define success before comparing tools
Before choosing a model or platform, decide what the solution is supposed to improve. That could be reducing manual work, improving a customer experience or helping the team make better decisions. A working tool is not necessarily a useful one. - Test reliability before scaling
A prototype that works in a demo may behave differently with real data, users and edge cases. The level of testing should also reflect the consequences: an internal research tool carries different risks from something making customer-facing recommendations or triggering automated actions. - Keep someone accountable
Giving AI more autonomy does not remove human responsibility. Teams should know who owns the output, who can intervene when something goes wrong and who ultimately decides whether the solution is ready to scale.
The wider competitive shift is not simply that companies can move faster. Many will. The distinction will come from whether they can preserve judgment while the cost of producing another option keeps falling.
For marketers and product leaders, this changes the meaning of productivity. The strongest team may not be the one that releases the most AI-assisted work. It may be the one that can say no with evidence, recognize when an output is trustworthy and remain accountable when automation reaches the customer.
