The Cost of a Yes: Vimal Stan Steven on What Product Leaders Must Decide Before They Build

A product can look thoughtful long before it becomes necessary.

The workflow can feel cleaner. The customer can appreciate the idea. The team can believe it has solved something meaningful. A few weeks later, the same customer may return to the old way of working because the product solved the visible request before understanding the behaviour around it.

Vimal Stan Steven, Senior Director of Product Management at SpotDraft, has seen that pattern closely across 18 years in SaaS, analytics, messaging platforms, enterprise software, AI tooling, and product operations. The lesson he draws from those years is about earning enough conviction before asking a company to spend its people, capital, roadmap, and customer trust on a problem.

He calls the pattern the Cinderella problem.

“You build a glass shoe and then you go out looking for Cinderella,” he says. “Versus if you’re trying to build Nike, you go out and measure feet.”

A glass shoe may be beautiful. A team can build something polished, technically credible, useful on paper, and impressive in a room. Customers may praise it. Leaders may approve it. Sales may find a story around it. Interest can begin to look like validation, especially after months of effort have already gone into the build.

Adoption asks for a different kind of evidence: whether the customer changes how work gets done when nobody from the product team is present.

For Vimal, product leadership begins in the space between appreciation and adoption. A team has to learn whether it is solving a problem customers admire in conversation or a problem they feel strongly enough to change behaviour around.

He adds another layer to the metaphor.

You can either choose to be the knight in shining armour or Phil Knight. Neither are wrong, but don’t do one while chasing the other.

A team can rescue one customer with a bespoke solution. A team can build a platform for a wider market. Trouble begins when it wants the intimacy of the first and the economics of the second.

Vimal calls it a directionality problem. “Opinion about the problem compounds. Opinion about the solution calcifies.”

A problem becomes richer with exposure. Customers add context. Usage reveals friction. Competitive pressure clarifies urgency. Internal debates sharpen the edges. A solution behaves differently once a team has invested in it. People begin defending the shape they have already built. The roadmap starts protecting past decisions.

AI has made the question more urgent. Teams can now research, prototype, document, design, and ship with far less friction. Roadmaps can move faster. Interfaces can multiply. Agents can respond. Features can appear before organizations have built the discipline to decide whether those features deserve to exist.

As the old cost of building falls, judgment becomes the constraint.

Conviction Before Commitment

Vimal’s move from engineering to product changed the question he was trained to ask.

Engineering had taught him to look at a problem and find a way to solve it. Product leadership required a different instinct: pause before the solution, study the problem, and decide whether solving it was the right use of the company’s attention.

“I was a software engineer for about seven years,” he says. “To overcome that conditioning of saying how do we build cool things and make this stuff work, to then take a step back and say should we be even making this work, that was a big change.”

A technically strong team can almost always find a way to build. Vimal’s question comes earlier: what will the company stop doing because it chose to build this?

A yes rarely stays inside the sprint plan. Customer expectations shift. Sales teams carry new promises into the market. Support teams inherit new questions. Documentation has to catch up. Integrations need maintenance. Future roadmap choices begin carrying the weight of a decision that may have felt small at the time.

Credibility matters because saying no, slowing down, or asking for more evidence requires trust. Vimal’s language for the discipline is precise: “epistemic discipline made visible.”

“What do we know? What do we not know? How will we find out? How can we learn without committing to an expensive mistake?” he urges leaders to question.

Credibility isn’t built by being right. It’s built by making the boundary between what you know and what you’re guessing visible to every room.

An analytics platform his team later built tested the same discipline. The early direction resembled a conventional BI tool. Customer feedback revealed a different reality. Many users were sales managers, education advisers, and operations leads who were closer to Excel in their daily working model than dashboards, query builders, or analytics layers.

The team shifted before the architecture hardened. A weaker product culture might have defended the original plan because the concept looked sophisticated. Vimal’s team treated the feedback as a correction. The issue was whether the product matched how non-technical users actually made sense of data during the working day.

“The framework is constant,” Vimal says. “The language is local.”

A product leader has to move the same reasoning across engineering, sales, leadership, design, and customer conversations without losing its integrity. The judgment stays stable. The language changes for the room.

Defaults, Learning and Adoption

The analytics platform eventually grew to 20,000 daily active users, but the early decision was deliberately narrow.

The team launched with one report. Instead of broad customization or a sprawling dashboard builder, the report carried defaults shaped around roles, industries, and operating contexts so that a sales manager or regional lead could open the product and see something useful without first learning a system.

Defaults carry a point of view. A good default tells the customer that the team understands the job well enough to choose on their behalf. A poor default exposes the distance between the product team’s imagination and the customer’s reality.

Product managers were doing roughly 200 customer calls a quarter, learning how users thought about their work, where pressure appeared during the day, and how data moved from information to action.

One customer asked for a specific report during a call. The product manager built it during the conversation and asked the customer to refresh the screen. The report appeared while the call was still live. A request that would take weeks in many organizations became part of the same conversation in which the need surfaced.

“It’s not enough to say we teach you how to use the platform,” Vimal says. “We also helped them bridge the gap between data and insight.”

Platform growth was tied to those operating choices: restraint in the first release, opinionated defaults, hundreds of customer conversations, and a willingness to learn before expanding.

One of Vimal’s clearest lessons came from a user who rejected a better product.

The team had built a faster analytics report. The new version was cleaner, more flexible, and stronger by every visible product measure. The user still preferred the older report.

Her reason was practical. The old report took time to load, so she had built a routine around the delay. She opened it, moved to email, handled something else, and came back when the data was ready. The delay had stopped feeling like friction. Her day had absorbed it.

“We were selling a better shoe, not asking if she needed shoes,” Vimal says. “Better is very contextual.”

People often build small routines around imperfect systems. A slow report becomes a pause. A clumsy workflow becomes muscle memory. A manual step becomes a way to stay in control.

The commute analogy makes the point. Many people complained about the daily drive to work, then quietly missed parts of it when remote work removed the commute. The drive was inefficient, but it created a buffer between home and work, a place to think, decompress, make calls, or change mental roles. Removing the inefficiency also removed a rhythm.

Product teams often compare a new product with the old product. Customers compare a new product with the life they have already built around the old one. A faster report competes with an email break. A cleaner interface competes with habit. A better workflow competes with a routine that has learned where to sit in the user’s day.

Status quo has an advantage no new product can match. It is already installed in behaviour.

After the new reporting experience launched, some users kept returning to the older path. Conversations showed something simpler than a feature gap: users were following the route they knew. The new product already covered the use case. The team gave notice, removed access to the old path, and moved attention to the new experience.

Every Yes Has Economics

A product decision is also an economic decision. The cost may show up in engineering, support, pricing, sales motion, customer success, architecture, or the company’s ability to say yes later.

Vimal saw the pressure clearly while building the analytics platform. A major enterprise account had significant data needs and strategic appeal. The parent company already had dedicated teams servicing the account, and the opportunity had obvious commercial attraction.

The team chose to learn from the account without pursuing it too early as a customer.

“The danger isn’t the first request,” he says. “It’s the twentieth, when the team no longer thinks like a product team.”

The risk was platform drift. A young product can begin by serving a large account and slowly become shaped by that account’s operating model. Each request may sound reasonable. Each customization may feel commercially justified. Over time, the team stops building for a market and starts servicing a relationship.

Requests are not bad. It’s the pattern. Are you servicing that same customer repeatedly? Then you’re building for that specific customer, not your customer base.

Revenue can make the wrong decision look responsible. Technical possibility can make the wrong decision look easy. A strategic logo can make the wrong decision look ambitious. Vimal’s point is to understand the kind of company a yes is quietly creating.

Pricing created another version of the same lesson. A messaging platform Vimal worked on served customers with spiky usage. Educational institutions might send very few messages in ordinary months, then thousands during admissions or promotional windows. Seat-based pricing failed to match the behaviour. Pure usage-based pricing created anxiety for customers who needed budget visibility.

“The pricing was creating friction the product didn’t have,” he says.

The team designed a tiered structure that matched the customer’s usage pattern more naturally. Vimal built the sales enablement himself because the market needed a clear explanation for a pricing model the sales team had not yet used. He closed the first deal on the call.

Pricing became product work. It changed how customers understood the product, how sales explained value, how confidently buyers committed, and how well the business captured the behaviour it was built to serve.

Capital efficiency begins long before finance teams see the burn. Waste begins in wrong ICP choices, weak architecture, premature customization, product drift, stale assumptions, and sales motions the product cannot support.

The current “SaaS is dead” debate misses part of that reality. AI may make software easier to build, but ownership still has a cost. A company can build its own CRM, then inherit maintenance, hosting, staffing, integrations, support, security, and workflow evolution. The build may look cheap while the operating burden quietly becomes a business of its own.

Cheap creation can hide expensive commitment.

AI Raises the Price of Poor Judgment

Vimal uses the term “feature slop” for a risk that is becoming easier to miss.

Feature bloat is familiar. Products grow past their usefulness through years of additions, stakeholder requests, enterprise commitments, and roadmap pressure. Feature slop is more specific. It emerges when features get shipped because creation has become easy, with too little discipline around whether they should exist.

AI changes the cost of output. Research can be summarized faster. Specs can be drafted faster. Prototypes can appear faster. Code can move faster. The organization may feel more productive while accumulating more commitments than it can absorb.

Vimal’s test is simple.

“Can you articulate what you expect to learn before shipping?” he says. “If yes, it’s an experiment. If no, it’s hope. And hope is not a strategy.”

He compares good product experimentation to sonar. A team sends a signal, listens for the return, and lets the response guide the next move. Without a hypothesis, speed becomes spray. The team produces more, learns less, and mistakes activity for progress.

AI also creates a second-order leadership problem: apprenticeship. Junior product managers, designers, and engineers traditionally built judgment through first drafts, flawed prototypes, research notes, revisions, critique, and exposure to the consequences of decisions. AI can now produce many of those early artifacts, narrowing the training ground for judgment.

Companies will have to design apprenticeship more deliberately. Younger professionals still need to learn how tradeoffs are made, how weak signals are interpreted, how customer language is translated, how prioritization works, and how a product leader decides when evidence is strong enough.

At SpotDraft, Vimal’s current work sits inside this shift. The company has built agentic capabilities that can help teams respond to customer requests with unusual speed. Agents can produce responses, workflows, and drafts faster than many organizations can triage the original request.

Judgment remains outside the agent. A product leader still has to ask whether the request represents one customer’s problem or a wider pattern, whether the experience will hold under real usage, whether the organization can absorb what gets shipped, and whether the feature deserves a place in the company’s future.

AI increases what teams can make. It does not increase, by default, what organizations can responsibly carry.

The Product Leader’s Real Work

A stronger product conversation begins before the roadmap hardens.

Product teams seldom lack ideas. They lack engineering time, customer patience, implementation bandwidth, and the ability to carry every promise they make. A full roadmap can still be strategically weak when it reflects the loudest requests instead of the most important problems.

Leaders need conviction about the problem, sharper evidence than “customers want this,” and a learning agenda before shipping. They also need to know whether a request represents one customer or a customer base, and what the company will stop doing because it chose to build.

Those questions matter more as AI reduces the friction of production. Teams can now create prototypes, workflows, agents, dashboards, integrations, and polished demos faster than ever. The harder question is what deserves to survive after the prototype works.

A polished demo is still easier than changed customer behaviour. A customer request is still easier than market conviction. A feature is still easier to launch than to support, explain, price, measure, and eventually retire.

Vimal’s closing metaphor forces the choice into plain sight. The knight in shining armour solves for rescue: one urgent customer, one visible problem, one heroic intervention. Phil Knight solves for a market: many feet measured, patterns understood, a repeatable product built with discipline.

Both ambitions can be valid. Confusing them is where product cost begins. A team cannot build a bespoke rescue and call it a scalable business. Before the next yes, the product leader has to decide which ambition the company is actually serving.