How to Stop Building Products That Work Perfectly and Feel Like Nothing

The one question I now ask before touching Lovable — and why it eliminated three features I almost shipped.

Key Concepts 🚀

Backward Design: Defining the emotional outcome you want your user to experience before you write a single requirement or ship a single feature.

Emotional Debt: The gap between features that technically work and experiences that actually feel like something. It shows up as churn before it shows up as bugs.

Exit Emotion: The specific feeling you choose for your user before building: relief, clarity, pride, calm. You decide this first. Everything else follows.

I built a product that worked perfectly and felt like nothing.

DraftKit had clean auth, a fast rich text editor, and export logic that ran without error. I was moving fast, shipping features, and checking boxes. But when I talked to users, the feedback kept circling the same thing: they would use it once and not come back.

Not because it was broken. Because it was empty.

The real failure was not technical. It was intentional. I had never asked myself what emotion I wanted my user to feel when they closed the tab.

The Roadmap for Today

• Why most features fail before they matter: The Pendo data that should make every PM uncomfortable

• The feedback that broke my definition of “done”: The moment a user showed me I was building toward the wrong finish line

• Why corporate roles train this skill out of you: The structural problem most PMs never name

• The Backward Design Method I Follow: Three steps before I write a single requirement

• A copy audit you can run in 10 minutes: Something concrete to do before your next sprint

Let’s get into it. 👇

Hey, I’m Elena! 👋

AI Product Manager, builder, and founder of DraftKit.app and the AIAdventChallenge.com. I write Prompt-Led Product, a newsletter for PMs who are tired of just writing requirements. This is for the product leader who wants to actually ship. The kind where you stop managing tickets for a second, open a prompt, and build the logic yourself.

Built by you. Led by your product taste. 🚀

---

If you are new here, three posts to catch up:

• How I Vibe Code With Empathy in Mind — the philosophy behind designing for feeling, not just function

• I Broke My Own System: My Year of Building in Public — where the Build Series begins

• How I Keep My AI Product Profitable — the cost and margin decisions behind shipping fast

Join a community of builders from companies like Reforge, Product School, OpenAI, Lovable, Pendo, and Miro shipping AI products.

The Ghost Town I Built With My Own Hands

When I started building DraftKit, I treated it like a sprint. I wanted to move fast, keep the codebase clean, and ship features. I was prompting Lovable and checking boxes: user auth, editor logic, export flow, onboarding screens.

Every feature worked. Every deployment was clean. I was shipping.

But something was off, and I could not name it until I talked to users.

❌ What most builders assume: Speed plus working features equals a product people return to.

✅ What is actually true: A product that works but feels like nothing is a ghost town with clean code.

The product was designed for the database. The tables were clean, the queries were efficient, and the edge cases were handled. But I had never stopped to ask what the person sitting in front of the screen was supposed to feel.

Strategic advice: Before you write your first requirement for a feature, write one sentence: “When my user finishes this flow, I want them to feel ___.” If you cannot complete that sentence, you are not ready to build yet.

Why 93.6% of Features Get Ignored by the People You Built Them For

This is not just a DraftKit problem. According to Pendo’s 2024 Global Product Benchmarks, the average feature adoption rate across 6,800+ applications is 6.4%. That means for every 100 features a team builds and ships, fewer than 7 are driving the majority of actual product engagement.

The rest are shipped, forgotten, and left to clutter the interface.

Most teams read that stat and think about prioritization. That is the wrong lesson.

The real problem is not that teams build too many features. It is that they build features before deciding what feeling those features are supposed to create.

❌ What most builders assume: If it ships, users will figure out why it matters.

✅ What is actually true: When you do not know the exit emotion, you have no filter for what belongs in the product and what does not.

Shreyas Doshi breaks this down as “product sense” — the ability to simulate what a user feels at each step, not just what they do. He frames it as a skill, not an instinct. And like any skill, it starts with asking a question before the build begins.

What did I learn? 🤔

This is called Backward Design in education theory. You start at the end:

“what state do you want the user to be in after they interact with your product?”

Then you work backward to build the path that gets them there. Most PMs learn it once and use it never, because their environments reward shipping over designing.

The “Then What?” Moment That Rewrote My Definition of Done

I thought the drafting process in DraftKit was the product’s core value. Users would start a draft with a collaborator, AI would help them shape it, and I had built a clean export function for when they finished.

I was proud of the collaboration flow.

Then a user showed me it was a dead end.

She pointed out something I had missed completely: the product stopped at the exact moment the user’s momentum was highest. They would finish a draft together and then? A success toast. A blank screen. Nothing.

She forced me to ask the question that changed how I build: “Then what?”

There was no workspace. There was no path from the draft to the final post. My product was a generator when it needed to be an execution engine.

I had built toward the wrong finish line because I had never defined what the exit emotion should be.

The moment I asked “how do I want my user to feel when they are done?”, the answer was immediate: they should feel like they shipped something real together, not just talked about shipping something.

That single answer forced me to build the workspace, bridge the draft to the post, and cut three features I had been planning.

Strategic advice: Map your current product flow end to end. Find the moment where the user’s momentum is highest. Ask yourself: what happens next? If the answer is “nothing much,” that is exactly where your product stops being a tool and starts being a dead end.

Why Corporate PM Roles Train This Skill Out of You

Here is the part most product writing skips. This skill, designing from the emotional outcome backward, is learnable. But if you spent years in a large company, your environment may have systematically removed your ability to do it.

In corporate product roles, PM teams are routinely separated from their end users.

Feedback gets filtered through customer success, sales, legal, and account management before it reaches the people actually building the product. By the time the signal arrives, it is a sanitized list of feature requests with no emotional context attached.

❌ What most builders assume: Market research and NPS scores tell you what your users actually need.

✅ What is actually true: None of that tells you how your user felt when the product stopped working for them.

I spent years in that environment. I found ways around it, talking to users directly even when the process said not to. Not because I was being difficult, but because a PM who cannot hear the user’s feeling is building blindly.

The irony is that companies spend millions on market research while blocking their best product people from the one thing that makes that research unnecessary: a direct conversation.

When I started building independently, the shift was immediate. I could hear users, detect the need behind their words, and ship a demo the same day. That direct feedback loop is what turns backward design from a theory into a reflex.

Strategic advice: If you are inside a structure that limits user access, find the smallest possible workaround. One direct call per week is enough to rebuild the skill. You are not looking for feature requests. You are listening for the emotional friction underneath the words.

Check out the Build Series. Part 1 | Part 2 | Part 3 | Part 4 | Part 5

The Backward Design Method I Follow Before Touching Lovable

This is the process I now run before I write a single requirement. It takes about 20 minutes and has changed what I build more than any other habit.

✅ Step 1: Define the Exit Emotion. Write one sentence: “When my user finishes this flow, I want them to feel ___.” Pick one word: relief, clarity, pride, calm, control. This is your filter. Every decision in the build gets tested against it, and anything that does not serve it gets cut.

✅ Step 2: Write the Emotional Journey, Not the User Story. Most Jira tickets look like this: “As a user, I want to export a draft so that I can publish it.” That is a function description, not a journey. Instead, write a narrative: what does the user feel when they land on the page? Where does the friction cost them emotionally? If the narrative does not end at the exit emotion you defined in Step 1, the feature is wrong before you build it.

✅ Step 3: Build as Consequence. Now, and only now, you open Lovable or your tool of choice. The database schema, the UI layout, the button copy, the empty state, the success message: all of it serves the emotional journey you wrote in Step 2. If a feature does not move the user toward the exit emotion, it is noise. Cut it before you ship it.

What Happened When I Applied This to DraftKit

After that feedback, I ran the method from the beginning. The exit emotion I chose was specific: users should feel like they shipped something together, not just talked about shipping something.

That one sentence eliminated three features I had been planning and forced me to prioritize one I had been ignoring: the shared workspace where collaborators could move a draft from rough idea to ready to publish.

I also burned down the landing page. The old version explained features. The new version explains outcomes. The copy shifted from “collaborate on drafts” to “go from draft to done,” and that change came directly from knowing the exit emotion before touching the design.

Strategic advice: After you define your exit emotion, read every line of copy on your current product. Anywhere the copy describes what the product does instead of how the user will feel, you have found a conversion problem hiding inside a UX decision.

When to Skip This and Just Ship

This method slows you down by about one sprint if you apply it to a product that already exists and has functional debt. If you are building from scratch, it actually speeds things up because you stop building features that will not survive contact with real users.

The one time I skip it: when a user cannot do the job they came to do. Functional debt comes before emotional design. Fix the crash before you optimize for delight.

For every net-new feature, every redesign, and every new product: run the three steps first.

Here Is the Uncomfortable Truth About Building With Intention

Most PMs know they should talk to users. Most builders know they should validate before building. The knowing is not the problem.

The problem is that the environments most PMs work in reward shipping features over designing feelings. Quarterly OKRs measure output, not emotional resonance. Roadmaps get approved based on feature count, not exit emotions.

👨🏻‍💼 The PM who stays in that environment keeps shipping technically correct products that feel like nothing, wonders why retention is flat, and asks for more data.

👩🏼‍💻 The PM who starts asking “how do I want my user to feel?” starts making product decisions that are harder to explain in a roadmap review but easier to validate with one real conversation.

Run this before your next sprint:

• Open your product’s most-used flow. Read every button label, heading, and empty state message on the screen.

• Count how many describe what the system does versus how the user will feel after completing the action.

• If more than half describe function, your interface is designed for the database.

• Fix one of those labels before you ship anything new. One label. That is the starting point.

What emotion are you building toward right now — and if you opened your most-used flow today, would a user actually feel it?