ICP Before Roadmap II event cover with Allyson Moellenhoff and Chad Cook

ICP Before Roadmap II: Who Will Buy, Use, and Renew?


Create Your Own Gravity · AI Mastermind AfterShow · November 10, 2026

I opened this AfterShow with a pattern I keep seeing. Someone builds a genuinely good product, then tries to help everybody with everything. I’ve done my own version of that. After one conversation with Allyson Moellenhoff, I changed direction on a whole side of my business.

Katrena Drake hosted Allyson and Chad Cook for ICP Before Roadmap II. The question I kept coming back to was this: Who has a problem urgent enough to change how they work, and who will pay to make that change happen? Get specific about those people and the roadmap gets a lot easier to write.

Start with the people you can sell to today

Allyson drew a distinction every founder should make before budgeting for another feature. Your audience includes everyone you could plausibly sell to. Your ideal client profile, or ICP, describes the customer you can credibly sell to now. There’s room to expand later. In the meantime, a narrower starting point gives your sales conversations and your product decisions something in common.

Katrena described how she uses two questions to narrow an expansive list of technical possibilities. Which use case are we solving? In which market, and for whom? That filter matters when every additional market asks for a different sales conversation and every new workflow takes engineering time. If a prospect says they’d love to have it someday, find out what would have to happen for them to pay for it now.

Follow the work from the buyer to the person using it

Chad looks at a day in the life of the people who will touch the product. The buyer can tell you what earns a budget. The daily user can show you where another click, handoff, or login would make their day harder. Someone downstream may rely on the output without ever opening the tool. With an AI product, security may have a say in deployment, and finance may ask how token costs change as usage grows.

Here’s how I’d use that in a customer conversation. Ask someone to walk you through the last time the problem came up. Where did the work start? Who had to approve it? Who used what came out the other side? Once you see the handoffs, you can decide which part of the workflow your first version needs to handle well.

Show the workflow while it’s still easy to change

Chad uses a demo to show the idea and invite feedback before there’s much code to rewrite. A prototype then lets you explore how the workflow and the underlying pieces might fit together. By the time you commit to an MVP, those conversations should have sharpened the scope.

Allyson’s advice was to show a few screens, give people room to react, and ask what they would actually use them for. Katrena put that in the context of research. If you’re considering a few audiences, show them the same proposed workflow and see who has enough pain to change and pay. Look across the conversations for recurring patterns before moving a feature up the roadmap.

Think about renewal before the first sale

Allyson walked through a failure that can take months to become visible. The buyer signs. Users log in and give it a try. The tool doesn’t fit their day, so they go back to what they were doing before. If you only talk to the person who signed the check and have no view of actual usage, you might learn about the problem at renewal and mistake it for a pricing or market problem.

Chad’s answer was to build the relationship early. Tell customers where the product stands, ask where it’s falling short, and keep listening after the sale. If the workflow works, you should be able to see people choosing it again when the work comes around.

Put your next feature through this test

  • Name one customer you could sell to today and one problem that would make them move.

  • Show the buyer and a daily user the same proposed workflow. Ask the buyer what would earn a budget, then ask the user what they’d have to change to use it.

  • Write down the repeat behavior you’d expect to see if the product helped. Use what you learn to choose the next thing to build.

Before I add something to the roadmap, I want to know whose day gets easier and what they’ll do the next time that problem shows up. That’s the kind of answer I can build around.

Why this matters now

On November 11, Databricks announced an always-on version of Genie. Reuters reported how CEO Ali Ghodsi uses it to answer questions from company data and prepare briefings. That example makes Tuesday’s point concrete: an executive can see value in a quick briefing, while someone else has to supply the data, check the answer, and act on it. If you’re building an AI product, ask each of those people what would make them use it again next week.

Reuters reporting on Databricks Genie · Databricks announcement

Register for the next AI Mastermind AfterShow.

Related Post