← All cases
Discovery AI Products Idea stage

A non-technical founder spent 4 months explaining to developers what a 'smart recommendation' actually means

How to translate product intuition into a language developers can finally build from — so they ship what you actually had in mind.

Duration
5 weeks
Complexity
Medium complexity
Format
$4K (Discovery format)
Period
over the last 2 years

This is an illustrative composite pattern from 8 years of work in IT — not a specific client.

Context

The founder of an ed-tech product with an AI component — a recommendation system for high-school students that helps map out a personalized learning path. The team: her, one designer, and three outsourced developers. They had shipped a first version without AI — just a catalog, and it worked. Now the goal was to add “smart recommendations.” The budget for the AI part was roughly $40K, and there was a launch date.

The pain

The founder had a clear vision of how the recommendations should “feel” — at the level of “it’s like when a student sees three options and knows exactly why these three.” But when she handed this to the developers, they asked things like: “What’s the input vector? What’s the relevance metric? How do we handle cold start?” She didn’t know how to answer — it wasn’t her language. The developers read this as “the client doesn’t know what she wants herself,” and started building the simplest option (“top 3 by rating”), which the founder rejected a week later as “not it.” The cycle ran for 4 months. The team was burning out, the budget was draining, and the launch date was slipping closer.

Approach

Five weeks. Week 1 — three long conversations with the founder (2 hours each) plus a review of her notes, the voice messages she’d sent the team, and reference screenshots. We were looking for what her “sense of the right recommendation” was actually made of. Week 2 — two interviews with students (prospective users, aged 14 and 16) and one with a teacher. What does a “useful nudge” mean to them? Week 3 — translating everything we’d found into a structured document for the team: 7 rules describing what a recommendation should NOT be (it’s easier to catch the intuition that way), 4 types of student queries that should each get a different approach, and a list of input signals that definitely exist in the product. Week 4 — a joint 3-hour session with the team: we walk through the document together, the developers ask questions, and we write down the technical decisions together (which algorithm, which metrics). Week 5 — finalize the document and hand it over to the team for implementation.

Result

The team started building the recommendations from a clear structure. The first working versions appeared 3 weeks after we stepped out — and the founder didn’t reject them, because they matched the same 7 rules she’d previously “felt but couldn’t name.” The budget that had already been spent on 4 months of searching was stopped — from there the team worked to a plan with a predictable date. The overall slip from the original launch date was about 6 weeks, but the launch actually happened, instead of shifting endlessly.

What it taught

“The non-technical founder doesn’t know what they want” is almost always untrue. They know it 100% — but in the form of feelings, analogies, and examples from life. The job of discovery is to translate those feelings into a format the team can work with. It’s not a one-week job, but without it any AI project turns into an endless cycle of “not it — try again.”


This is an illustrative composite pattern from 8 years of work in IT — not a specific client. AG is in a validation phase.

Next step

A 30-minute conversation.

Discuss your project

GET IN TOUCH

Let's talk

I'll get back to you within 24 hours — to schedule a discovery call or discuss your inquiry.

Prefer direct contact?

or send a message

Or email directly: taras@kuznya.studio

Got it. Talk soon.
I'll be in touch within 24 hours.