What I Got Wrong, What I Got Right, and What You Asked

q&a

Three weeks of intent-based design conversations, distilled.

A few weeks ago I published a three-part series on intent-based design: the case for it, the method, and the playbook for pushing it from the inside. The response taught me more than the writing did.

This piece is a follow-up. Not a manifesto, not a method. Just answers to the questions that came up most often in comments, DMs, and conversations with PMs running into this stuff in real time.

“How do you do this when you don’t own the support tickets?”

This came up more than any other question. The honest answer is that you almost never own the tickets directly. They live in CS, or in a shared dashboard, or behind read-only access that expires every quarter.

The workaround that works: pair up with one CS lead for a single afternoon. Most CS leads have been waiting for someone in product to actually care about this data. Ask for ninety days of unfiltered tickets in a single export, raw text, no categorization. Read them yourself.

You don’t need permanent access to the system. You need one good export and a quiet afternoon. And honestly, the act of asking CS for the export is itself a relationship-building move. CS people know the friction in the product better than anyone, and they almost never get invited into the product conversation. Inviting them in is one of the most leveraged things a PM can do, separate from intent mapping entirely.

If CS won’t share, there is a fallback: sales call recordings. Ask your sales team for the last twenty discovery calls. Listen for the same verbs. The signal is messier but the principle holds.

“What if leadership is sold but the engineering teams aren’t?”

This is the inverse of the problem the series focused on. When the top is convinced but the middle isn’t, the pilot move still works, but the framing changes.

Instead of “we’re trying something new,” it becomes “leadership wants to test something, would your team be willing to be the pilot?” That gives the team a graceful out, a clear time-box, and a sense of being chosen rather than mandated.

The other move that works here: don’t ask the most senior or most stable team. Ask the team that has the most appetite for change. Often that’s a newer team, or a team that’s been frustrated with their current scope, or a team whose lead has been complaining about the same coherence problems you have. Energy beats seniority for a pilot.

And if no team has appetite, that’s data too. It usually means the cultural conditions aren’t there yet, and the right move is to keep doing intent mapping yourself, in your own corner, and wait for the conditions to change. Forcing a pilot onto a reluctant team produces evidence that the method doesn’t work, which sets the whole effort back.

“How does this work for early-stage startups with no support tickets yet?”

The method scales down further than you’d think. With no ticket history, the input is conversations. Three to five user interviews where you ask “what did you come to the product to do today” and listen for the verb. The output is smaller, ten or fewer intents, but the discipline is identical.

The advantage you have as a small team is that the political layer doesn’t exist yet. You can just decide. There’s no adjacent team whose ownership lines you’re crossing. There’s no leadership conversation to navigate. You’re the leadership conversation.

The risk for early-stage teams is the opposite one: optimizing too early for intents that haven’t stabilized yet. In the first few months of a product, the intents customers walk in with often change as they understand what the product is for. So treat the intent map as a living document, not a strategic commitment. Update it monthly. Once you see the same five intents show up reliably across new users, those are the ones to build the org around.

“Isn’t this just JTBD with new branding?”

This was the question I got asked most carefully, usually by people who’ve done Jobs-To-Be-Done work seriously and have valid skepticism about anything that sounds like rebranded research.

The honest answer is that intent-based design overlaps heavily with JTBD and owes most of its intellectual heritage to it. Anyone who’s run good JTBD interviews will recognize the verb-extraction discipline in step 1. The “what is the user trying to accomplish” framing is straight JTBD.

Where I think intent-based design diverges is in the operational layer. JTBD as I’ve seen it practiced is mostly a research method: a way to discover and articulate user needs. Intent-based design borrows that research foundation and adds three things on top:

1. Org implications. How teams are organized around intents, not just how research is framed around them.
2. Roadmap implications. Intents as the unit of strategic planning, not just the unit of user research.
3. AI implications. Intent maps as the foundation for AI investment, where each top intent becomes a question of “what is the AI-native solution here.”

If you’re already running JTBD well, you’re most of the way to intent-based design. The remaining work is taking the JTBD output seriously enough to reorganize how teams operate around it, instead of just using it to inform feature decisions.

So: same intellectual lineage, different operating model. Worth a new label only because the operating model is what most JTBD implementations stop short of.

“What metric do you actually report on for completed intents?”

This one came up from operationally-minded PMs and it’s a fair pushback. “Completed intents” sounds great in a manifesto and harder to define in a dashboard.

The version I’ve seen work: for each top-five intent, define a funnel. The entry event is the user starting the intent (often defined by a specific action or a session pattern). The completion event is the user achieving the underlying outcome (not necessarily inside your product). Completion rate is the ratio.

For a “send this report to my stakeholder” intent, the entry event might be opening a report. The completion event might be a share action followed by no return to support within 48 hours. Imperfect, but operational.

The point of the metric isn’t precision. It’s directionality. You want a number that goes up when you remove friction from the intent, and stays flat or goes down when you ship features that don’t serve it. Once you have that, it becomes the headline number in your reviews, and the team’s behavior reorients around it.

The trap to avoid: defining completion as a single in-product event (“user clicked share”). That’s just feature adoption with new branding, which is exactly what you were trying to move past.

What I’d change about the series if I wrote it again

A few things I think I underweighted.

The role of CS and support teams. The series framed product as the driver. In practice, CS is often where the intent layer is most visible, and the first move should sometimes be from CS, not from product. If you’re a CS lead reading this and you’ve been frustrated that product doesn’t listen to ticket patterns, you might be the one to start this in your org.

How much of this is just listening. I spent a lot of words on method. The deeper truth is that most of intent-based design is the discipline of taking what users tell you seriously, in their language, without translating it into your team’s terms first. The method is downstream of that posture, not a replacement for it.

The fact that AI changes the answer to “what do we build for this intent.” I treated AI mostly as a justification for the timing. It’s also a fundamental change in the answer space. For some intents, the AI-native solution makes the original feature obsolete entirely. Worth a piece of its own, which is probably what I’ll write next.

What’s next

I’m thinking about three pieces. A piece on the role of CS in intent mapping, since that came up in nearly every conversation. A piece on what AI-native solutions to common B2B intents look like, with concrete examples. And maybe a longer piece on the metrics shift, since “completed intents” is the part that always raises the most operational questions.

If any of those would be useful, let me know which one. The series writing got sharper because of the conversations it started. Happy to keep that going.

For now, thanks to everyone who read, replied, pushed back, or sent it to a colleague. You made the series better than it would have been on its own.

Onward.