Loft AI — What and Why to Build Before Building It

Joined as the first PM hire. A detailed PRD was already waiting — tags, folders, recommendations, social features. I wanted to validate it first. Talk to people. Understand the problem before committing to the solution.

Before a single line of code was written, I needed to answer three questions: Is this the right problem? The right solution? The right user?

Pocket, Instapaper, Raindrop — all built on keyword search and manual tagging. RAG-powered semantic search was still new in consumer products. None of the established players had it.

The gap: save an article about "managing remote teams," retrieve it later by typing "how do I run standups better?" — and actually find it. Keyword search can't do that. If we could validate this with real people, it was a genuine differentiator worth building around.

Recruited through personal network and Slack communities where knowledge workers spent time. Screener questions filtered for genuine pain — not product curiosity. Every question anchored in recent memory, not hypotheticals: "Walk me through the last time you saved something and then tried to find it again." Stopped when the same patterns repeated — insight saturation.

Three pain points surfaced consistently:

• Scattered content — saved across Instagram, Twitter, LinkedIn, tabs, notes apps. No single place.
• No native organization — platforms put the full burden on people to tag and remember. No built-in structure.
• Retrieval failure — after 2–3 months, people couldn't find what they'd saved.

The PRD framed this as an organization problem. The research reframed it as a retrieval problem with an upstream scattering cause. That distinction changed the architecture.

On segmentation — demographics didn't predict behavior. Neither did frequency. What predicted behavior was motivation: why do people save? Three segments emerged:

• Productivity Savers — save to use later, retrieve frequently, deadline-driven
• Lifestyle Curators — save for inspiration, retrieve sporadically
• FOMO Savers — save compulsively, almost never return

Focused the MVP on Segments 1 & 2 — highest pain, highest retrieval intent. FOMO Savers parked entirely.

The PRD assumed a desktop knowledge worker. The data said most people discovered content on mobile — even those working at desks all day. That meant the save moment happened on mobile, which changed everything about where to invest first.

Mapped the call against four risks:

• Value: Would people use a mobile app? → Yes — most discovered content on mobile
• Usability: Is saving from mobile learnable? → Yes — sharing content between apps is already a familiar mobile pattern
• Feasibility: Can we build it? → Yes — RAG + vector search on mobile is well-understood
• Viability: Does freemium work? → Yes — usage-based gating fits

Partnered with ML engineers on RAG architecture, embeddings, and vector search. Cut PRD scope: no recommendations engine, no social features, no tag hierarchy at v1.

• Rewrote product scope: 7 planned features → 3 for V1
• Reframed the core problem: organization → retrieval — changed the entire architecture direction
• Made the mobile-first call with data, not assumption
• Identified RAG as a genuine differentiator — validated with people before committing to it
• Narrowed target to Productivity Savers + Lifestyle Curators, parked FOMO Savers entirely

Motivated behavior predicts architecture. Understanding why people save — not just that they do — changed the platform, the UX, and the sequencing entirely.

The ambiguity at the start wasn't a blocker — the PRD gave a direction, the research gave a destination. The work was figuring out which questions to ask, in which order, until the shape of the product became clear.

Discovery defined what to build and why. The next case study is how we shipped it — AI evals, mid-sprint crises, and getting to App Store in 12 weeks. Read it →