Sponsored by
👋 Hey friends!
You share a mockup in Slack.
Three people react with a thumbs up. Nobody says what’s wrong with it, and you leave not knowing whether it was good or just easy to agree with.
Steps 1 and 2 are the part I used Jira Product Discovery for in my first PM role, keeping evidence and priorities in one place.
State of Product reveals what AI still hasn’t solved
80% of product professionals say AI helps them ship faster, but customers aren’t seeing value any sooner. Atlassian’s State of Product 2027 explores the gains AI is delivering and the challenges that remain, from decision-making that hasn’t kept pace to gut instinct overriding customer evidence.
On Wednesday I wrote about wanting design and engineering to push back on your first draft. Today is how I set one up so they can.
I’ll use a prototype I built on my own: For the purpose of this example I built a weekly recap for a restaurant owner. The numbers in it are sample data I made up, and I’ll say where real evidence would go.
1. Write out the problem and the evidence.
Mine: a restaurant owner is too busy to dig through reports, so they don’t notice what’s changing.
In real work, the evidence is owner interviews, support tickets, or usage data. In my sample data it was a regulars gap: guests with 3+ visits came back every 18 days in September and now come back every 24.
If you come from CS, then your evidence is tickets and QBR notes. If engineering, error logs and escalation threads. If marketing, campaign and conversion data. If analytics, funnel drop-offs and cohorts.
2. Write your opinion as one sentence.
“I think good looks like ___, because ___.”
Mine: lead with what changed, then one button for what to do about it, because an owner who doesn’t have time for reports needs the next step, not the chart.
3. Name what you want pushed back on, out loud.
Mine: it doesn’t follow a real design system, I haven’t mapped the nuance, and there’s no support like (i) info icons yet. That’s design’s part.
Then I’d point at the Menu screen. The beet salad is down 28% over six weeks, and “Remove from menu” is one click. Six weeks could be seasonal, so I’d ask design and engineering whether removing a dish needs a second step.
4. Decide how you’ll learn after launch.
If you’re shipping the first version of something you mocked up, write the experiment plan before the build.
If I shipped mine, I’d start with a small group of restaurants and watch two things:
Whether owners click “Send a thank-you offer to regulars,”
Whether that 24-day gap starts to close. I’d pick the cutoff before launch, not after.
💡 A prototype is your opinion made clickable. It isn’t a design. UX is more than prototyping and designing pretty UIs, and the designer’s part is what you can’t see from where you sit.
If you’re 1 to 2 years in and have a design partner, send them steps 1 and 2 before you build anything.
Hit reply and tell me: what’s the one problem you’d prototype this week? I read every reply.
P.S. If you’re working on your first prototype, my clarity calls are free. We can look at your problem, your evidence, and what to ask your team. Book a time on ADPList.
This one’s for my CS and support folks. Your tickets are exactly the evidence step 1 asks for.
Most AI Tools Weren't Built for This
B2B customer issues move across teams and systems, not through a single chat window. A new Harvard Business Review Analytic Services briefing paper, sponsored by Front, breaks down where AI tools fall short in B2B service and what to ask before you invest.