Product strategy · Essay

Navigating objections for your AI project idea

Sujeet Mathew Jose · Berlin

The first time I pitched my AI-powered skincare engine to the room, I got a no. It was the polite kind, where everyone nods, someone says "interesting," and the idea goes into a parking lot that nobody ever drives back to. Even though there is a lot of AI hype in market, there is also sometimes pushback from management based on the ROI of efforts. I write this for anyone thinking of creating AI-powered projects and facing pushback from management. Read on for lessons on how to navigate the rough seas.

So, coming back to the pitch. I had a PRFAQ. I had a market opportunity slide. What I did not have was an answer to a single one of the questions my leadership actually cared about.

It took me about two weeks to understand what had happened. My leaders were not against the idea. They were against the risk of it, and they had expressed that risk as three questions. I had treated those questions as obstacles to argue past. They were not obstacles. They were the requirements document for my next pitch, handed to me for free. Here is what the three questions were, and what I did about each one.

Question one: can we actually build this?

This one sounds like a technical question. It usually isn't. When a senior leader asks whether you can build something, they are rarely doubting your team's competence. They are telling you, rather, that it's a new technology. The dynamics of building the system might be very difficult considering we did not have applied scientists on the team, or that we had never had previous experience building AI systems. It's the risk of a non-deterministic project undergoing a long developmental cycle and yielding no benefit for a long time.

You cannot fix that with a slide. A slide showcasing our AI confidence is just a claim.

So I stopped writing about it and built one. I put together a custom GPT engine over a few evenings, wired it up with a slice of our real product data, and made it produce the actual output the eventual feature was supposed to produce. It was ugly. It had no interface worth showing. It was wrong maybe 15% of the time — no evals were present for the custom GPT. But I gave the leaders an interface to try it out, and they found the results satisfactory. They even got some beauty experts on the team to try the custom GPT, and the results were satisfactory there too.

That was the point. When I sat down with my leaders again, I did not ask them whether we could build it. I asked them what they thought of the output. Which recommendations felt right, which felt off, and where the reasoning fell apart.

The conversation changed completely. They had a positive bent of mind about our ability to create such a tool. I worked with our engineering team to create a rough estimate — three months to launch, based on the prototype I had built. We spent one hour discussing the core principles of the product, the mechanisms of scoring, quality thresholds and edge cases. Nobody asked whether it was possible again, because we were already standing inside the thing, poking at it.

If your feature is AI-powered, you almost certainly have a way to build a rough version of it yourself in a weekend. Do that before you build a deck.

A bad prototype outperforms a good presentation every time, because a prototype invites people to have opinions, and a presentation invites them to have doubts.

Question two: will customers use it, and why would they trust us?

This was the hard one, and for a while I answered it badly. The question was clear: customers would know that, being an ecommerce website, we were actually trying to sell products to them. We had no previous precedent or evidence of being credible in the skincare space. Besides, maybe customers themselves were not ready to trust AI to give them replies confidently. How would we do?

My mistake was treating customer adoption and trust as a single thing you either have or don't. Somebody would say "customers won't trust us for this," and I would counter with brand equity and qualitative research showing the problem was genuine, faced by thousands of women. We were talking past each other, because when different people in that room said "trust," they meant at least three different things.

Trust in data handling. Will customers be comfortable sharing their personal skin data with Zalando? Would they doubt Zalando handling their data safely and respectfully, versus spamming them with emails and marketing materials?

Trust in the recommendation itself. Would customers feel this advice is any good?

Trust in the motive. Might customers doubt whether Zalando is genuinely trying to help them, or trying to sell them the highest-margin or sponsored item?

Trust in the mechanism. Will enough customers trust that AI can give them the right recommendations at all?

Once I split it apart, each version became answerable. Then I stopped theorising and went to get evidence. I ran interviews with real customers. I walked them through the concept and let them push back on it. I showed them raw output from the prototype and asked what they made of it, including the parts that were wrong. I brought the transcripts back, quotes and all, including the unflattering ones.

The trust question was answered by qualitative research — we showed customers the final experience many times and asked for their feedback on the quiz. In 90% of cases, customers said they wanted to share more information, not less. The lesson we learned is that when the benefit or problem solved was right, customers were willing to share data. Zalando's brand value also reassured them that their data would not be misused in any way. The motive question, for instance, was solved by showing our reasoning: we made it clear from the start that we would not involve any sponsored products or bias toward any product or brand in our recommendations. Customers would experience trust through the quality of our recommendations. Trust in the mechanism and in the recommendations was solved by showing customers that we were consulting dermatologists and skin specialists in developing the feature, and that it was not purely AI-based.

That last part is what shifted the room. Bringing only supportive quotes makes you a lawyer. Bringing the objections too, along with what you plan to do about them, makes you credible. One customer told us she'd want to know why a product was suggested before she'd believe any of it. That single sentence ended up shaping the feature more than any internal debate did. We added a critical piece — the rationale for the suggestion — to the recommendations, making the feature more complete.

Question three: does this make economic sense, and why hasn't anyone else done it?

Two questions in a trench coat, and they need separate answers.

On the economics, I had been making the wrong argument. I was promising incremental revenue, which meant I was promising to convince people to buy more. That is a hard promise to keep, and an easy one to be beaten up over later.

So I changed the claim. Suppose we never move the revenue number at all. Suppose customers buy exactly what they were always going to buy. Even in that scenario, they now buy it with confidence instead of guesswork. They know why the thing suits them. That confidence shows up in places the revenue line doesn't capture immediately: fewer returns, fewer abandoned baskets, higher basket size, fewer people who bought the wrong thing and quietly stopped coming back. A customer who chose well is worth more over two years than a customer who gambled and won once.

Framing it that way gave the project a floor. The upside case was still there, but the downside case was no longer zero.

The competitor question deserved a blunter answer, and I gave it one. If our competitors had already built this, we would not be having a strategy conversation — we would be having a catch-up conversation, and the ceiling on catching up is parity. The absence of anyone doing it is not evidence that it's a bad idea. It is the entire opportunity. Every advantage a company has ever held started as something nobody else had bothered to do yet. If we only ever move once a competitor has validated the move for us, we have outsourced our roadmap to them.

I was fairly direct about this. It landed better than I expected, because it named something the room already knew and hadn't said out loud.

The part that actually got me the yes

Answering the three questions was necessary. It was not sufficient. What closed it was making the decision small.

I did not ask for the full build. I asked for a short experimental development cycle with a defined proof point at the end of it, and a commitment that we would not scale a single step further until that proof point was met. We would launch in one small market — not the big ones, not everywhere at once. One.

I named the metrics in advance and wrote them down, including the numbers that would tell us it wasn't working. And I said the sentence I think mattered more than everything else in the pitch: if it doesn't work, we don't scale it, and I will be the one to say so.

That converts your ask from a bet on an outcome into a bet on a process. Leaders who will not approve a large, irreversible commitment will very often approve a small, reversible one, because the cost of being wrong has been capped, and they can see exactly where the exit is.

What I'd tell you if you're stuck at the same no

Write down the objections you got, in the exact words they were said. Do not paraphrase them into something easier to answer.

Then treat that list as your build order. Prototype your way out of the feasibility question. Break the trust question into its component parts and take evidence from real customers, unflattering quotes included. Give the economics a floor that doesn't depend on your most optimistic assumption. And on the competitor question, say the obvious thing: being first is the point.

Then make the yes cheap. One market, one cycle, agreed metrics, a stated condition under which you kill your own idea.

The no I got at the start was not a rejection of the project. It was a list of everything the project was missing, delivered by people who did not have time to write it up for me. The second pitch was mostly just doing my homework.

← All writing