It doesn’t. It signals anxiety and lack of mental clarity.

Scratching my head to figure out what’s going on here. Maybe it’s the AI era of “workslop” starting to bleed into how people communicate? When it’s (too) easy to generate words, people forget the job is to reduce them.

Let me assure you: More ≠ competence. The job is clarity.

Back in my 20s and early 30s, I played bass alongside my friend Chuck Suong — a great drummer, and someone who could say more with a single groove than most people could in an entire verse.

Whenever I’d get fancy — young, overplaying, trying to prove something — he’d just look over, shake his head, and say: “You don’t get paid by the note.”

Product leaders: Neither do you.

Every extra sentence is a decision. Every explanation is cognitive load you hand to someone else. In high-stakes conversations — especially with CEOs — that load compounds fast.

But this isn’t new. Product has always been an editing discipline. If you can’t say it simply, you probably don’t understand it yet.

Your CEO doesn’t need more information. They need to trust that the product org has it handled — and that when you speak, it means something.

Let’s get into it.

Start with the CEO’s World

The CEO is context-switching between an investor call, board prep, a pricing conversation with the CFO, a recruiting decision — and then your update. Your whole world is a piece of theirs.

Each day starts with a stand-up meeting for the Fin leadership team, where we go over current customer issues, roadmap items, staffing, resourcing, and any key sales deals we need to be aware of or help push forward. A big part of my day is reviewing Fin product work..Outside of product work, as a founder, board member, and executive, I have a lot of other responsibilities: welcoming new hires, prepping for board meetings, and handling various high-level tasks across the business.

- Des Traynor at Intercom: The Open Source CEO on what the role demands

The product leader who gets this communicates differently. They stop writing updates that prove how much is happening and start writing relevant updates that show where things are headed. The CPO’s job is to hold the path — to give the CEO a clear, confident picture of how the product drives the business. That clarity, delivered consistently and concisely, is what trust is built on.

Part of holding that path is understanding the CEO the way a great PM understands their customers — with real curiosity about where their head is, what the board is focused on, what’s keeping them up at night. The better that picture, the sharper every update becomes.

Stay calibrated: The best CPOs treat the CEO the way a great PM treats a customer. You wouldn’t ship product without talking to users. Don’t manage up without doing the same work.

A few questions worth asking regularly — not about product, but about the business:

• What's the narrative we're telling that you're least sure we can back up?

• What have you changed your mind about recently?

• What’s the thing you’re getting asked about most right now?

The answers change what you escalate. They change how you frame the roadmap. They make your communication relevant.

Follow their curiosity: When the CEO asks a question mid-conversation, answer it directly. Then:

“Can I ask — what’s on your mind there?”

That follow-up is almost always worth it. Their curiosity is rarely random. There’s a board conversation behind it, or an investor concern, or something they’ve been sitting with. When you follow it, you don’t just answer the question — you understand why it was asked. That makes you sharper.

The Operating System

Four simple tools to help avoid the mistake of verbosity in your communication with CEOs.

1. Frame it: Audience → Insight → Ask

This framework is a tiny slice of what Nancy Graves, an executive communication coach, taught me, and working with her genuinely transformed how I communicate. I've adapted the shorthand slightly here, but I want to be clear: this is her work, and it barely scratches the surface of what she does with executives and teams. If you have the opportunity to work with her, take it.

• Audience (”As you know…”): Where did you leave off? Sum it up in one sentence so they don’t have to fake context.

• Insight (”Since then…”): What’s changed? New data, a shift in direction, something you’ve learned.

• Ask (”As a result…”): What do you need? A decision, alignment, a green light. Be specific.

Example:

Anchor. Bridge. Ask. No preamble.

(Full post on framing here.)

2. Lead with the conclusion — and have an opinion

The Minto Principle: lead with the conclusion. Always. Let the details follow only if they’re asked for.

But here’s what most miss: you’re not a neutral information highway. The CEO doesn’t need a summary of competing options with a polite “thoughts?” at the end. They need your read. State the recommendation, name the tradeoff, and say why.

My mentor, friend, and two-time boss Steve Goldsmith used to say, “Give me something to say ‘Yes!’ to.”

Weak: “We’re losing enterprise deals. SSO, audit logs, and role-based permissions keep coming up. We could prioritize those or continue with the MCP v2. Wanted to get your thoughts.”

Strong: “We’ve lost five deals worth $200k in the last three months — all blocked on SSO, audit logs, and RBAC. My recommendation is we pause MCP v2 and clear these gaps first. Core retention is strong, so we have room. And this is squarely aligned with the Q2 company goals. I can have a scope in 48 hours if you’re aligned.”

Same situation. One is a status report. One is leadership.

The weekly update that earns trust is the one where the CEO reads the first line and already knows where you stand. One sentence summary. What’s changed. Three priorities, each with a why.

3. Pre-wire

Golden rule: No surprises. The meeting is the punctuation mark, not the sentence.

Don’t make the mistake of setting up an expensive meeting, and expecting your CEO to think through it and debate live.

Pre-wiring means every key stakeholder roughly knows what you’re going to say before you say it. A one-paragraph Slack drop on Monday. A 15-minute sync on Tuesday. A shared draft Wednesday with a comment asking for a reaction. By Thursday, no surprises. The meeting becomes a 15-minute alignment check instead of a 45-minute discovery session.

You shape the story, or someone else will. Drop context. No surprises.

4. The Micro-Yes

When you need to push back or challenge a decision, ask permission before you ask the real question. The moment someone feels ambushed, you’ve lost them.

Without it: “Why are we prioritizing monetization before we’ve validated retention?”

With it: “Can I ask a follow-up on the monetization timeline?” [yes] “I’m curious what’s driving the urgency — my instinct is we need to validate retention first, but I want to make sure I’m not missing context from the board.”

Same challenge. The first is a confrontation. The second is a conversation.

(Full post on the Micro-Yes here.)

Bonus: Tie It Together in a Prompt

Try this with Claude, with the ultimate goal of doing it yourself.

You are my executive communication editor. Rewrite what I give you using these rules:
— First line = where I stand. Lead with the conclusion.
— Have an opinion. Recommendation, tradeoff, why. Flag any hedging.
— Structure: Conclusion → As you know → Since then → As a result.
— Cut anything not earning its place. No throat-clearing.

Rewrite first, no commentary. Then a terse list of what you cut and why. 
If I'm missing a recommendation, tradeoff, or ask — flag it and ask the one question that unlocks it.

Draft: [PASTE]
Audience + context + what I want: [PASTE]

Remember: You don’t get paid by the note word.

CEOs need to trust that you’ve got it handled — and that when you speak, it means something. Every word you say either sharpens or dulls trust.

Product has always been an editing job. And in this AI era of abounding content slop, the clear, precise communication of a seasoned operator cuts through louder than ever. Do the work!

It resonated more than I expected. 🙏 And I started getting even more questions from engineers, like:

“Am I over-indexing on this one comment?” “What’s a better way to ask, ‘how much would you pay for this?’” “What should I do differently with my next call?”

So I’d write back with a take, or a reframe. Or we’d talk through the one question that would have changed the conversation. Sometimes I’d mark where they led the customer. I’d name the thing they missed.

But then…

I got very busy building these conversations into a product!

Introducing Lisnloop.

It’s the first product from Arbor — built from patterns across our client work. A simple chat interface, but underneath it's dense with product wisdom for product engineers working in early-stage SaaS. Opinionated, specific, narrow. All geared around customer “listening loops” (hence, the very available name/domain).

What it isn’t: Lisnloop doesn’t “do discovery” for you. It makes you do the work, so you build your gut, so you build better stuff. It doesn’t validate your idea so you can feel good.

What it is: A product sparring partner that makes you sharper at discerning customer signal. Lisnloop has your company and product context from day 1, thanks to a background Company Snapshot at signup, and then it uses your actual work from Linear to ground the conversations.

Let’s ask Lisnloop what it’s good at:

How engineers are using Lisnloop right now:

• Before a customer call — Get specific about what you’re trying to learn and Lisnloop generates learning goals and a conversation outline. What assumption are you testing? What behavior would change your mind?

• After a customer call — Paste the transcript. See where you led the customer, where you stayed surface-level, and Lisnloop builds a better outline for the next customer call. (Yes, it can pull customers insights from those transcripts, too. But if you're just harvesting quotes, you're missing the point. The goal is you getting better at asking the right questions.)

• When you’re early on a project — Shrink the bet until it can teach you something this week. Connect Linear and start the chat from there; what’s the smallest thing you could ship that would build conviction?

• When CS or Sales is feeding you “what they’re hearing” — Turn anecdotes into patterns you can actually build against.

• When you have a pricing hunch but no signal — What are they paying now? What would they cut? Lisnloop pushes past “would you pay for this” (everyone says yes) to questions that reveal real willingness.

• When you need internal buy-in — Frame the bet clearly enough that someone else can disagree with it. Shape the message before the meeting.

A note on how it’s built, since engineers care:

The stack is intentionally quite boring. Next.js, React, Postgres/Neon, Vercel. Commercial AI APIs with strict data handling — your conversations aren’t used for training. No hidden agents, no mystery flows. The whole thing is designed to be observable and auditable, because that’s table stakes if you’re asking people to think out loud.

More detail on the privacy page if you want to trace exactly how data moves.

(Ping me if you want to poke at the repo…or want to pitch in!)

Free for engineers. Capped to (hopefully) stay free.

If Engineering with Insight resonated, this is the next step. Bring a transcript from your last customer call, or a half-baked idea you’re not sure about yet.

Use it with your work, and watch your judgment change. You start to feel which problems are alive, where friction really is, and what “good enough to learn” looks like

If you’re an engineer working across the entire product lifecycle, try lisnloop.com →

🙌 Huge thanks to all the engineers who have pushed on Lisnloop over the past few months to help me shape it — both the code and the product (Igor and Matt, in particular!).

Things we’re looking at next: Other integrations/MCP servers (PostHog for data pulls to add quant data, CRMs for finding the right customers to chat with, etc), more interactive project spaces, pushing work to Linear, etc. So let me know what would be helpful!

This post is for the product engineer: builders who care deeply about what their code unlocks for users. Think PostHog’s definition in practice: full-stack bias, customer empathy, design taste, roadmap opinions, and a habit of shipping small and learning quickly. They pair user feedback with usage data and competitive context to decide what’s next. They have the drive and curiosity to own outcomes, not just tickets.

Because “Product” is not simply a title (“Product Manager”); it’s the work. The best engineers are building not only the product — they’re building an understanding directly with customers.

Recently, Igor and I worked together on extracting better insights from customers during prep for a big launch, and he shared his reflections on LinkedIn.

Discovery isn’t about validating your solution. It’s about understanding their problem first.

Let’s call it customer listening (hat tip to Agata).

This is a guide for the engineers and teams who want to build that customer gut. Over time, that intuition compounds, and you start to feel what to build next.

What to Use and When

There are two kinds of conversations (listening sessions) worth mastering:

Generative conversations help you find problems, patterns, and workarounds worth solving. You’re problem hunting, not validating a solution or approach. These happen early, when you’re chasing problems and shaping ideas.

Evaluative conversations test whether your solution actually solves the right problem effectively. These happen as you near launch or post-release.

We’ll focus largely on evaluative conversations here (but the best engineers keep their curiosity alive by weaving generative questions into those evaluative conversations).

Run a Call That Teaches You Something

Close your laptop for a second and remember the mantra: You’re here to become fluent in your customer’s world.

Now: Use this like a one-pager before your next Zoom.

1. Write three bullets before you meet

• The assumption you’re testing

• The behavior that would change your mind

• The outcome that gives you confidence to ship

Without this, you’ll collect anecdotes and miss insight. Once you define your goals, the right questions write themselves.

2. Recruit for fit, not convenience

Once you know what you need to learn, recruit people who can actually teach you that. Talk to people who live the problem you’re exploring. If you realize mid-call it’s a mismatch, pivot — explore their actual workflow for generative learning, then wrap.

• If your learning goal is “understand existing workflows,” talk to active users who are deep in the process today.

• If it’s “see if new users understand the value,” recruit fresh eyes who’ve never touched the product.

• If it’s “explore expansion or adjacent use cases,” talk to power users or customers who’ve hacked the product to do more than you expected.

Avoid convenience sampling. Your loudest customer or the one who answers Slack fastest isn’t necessarily your best teacher.

Diversity matters — a few contrasting perspectives often reveal the boundaries of your insight faster than another round of similar users.

3. Establish a truth-seeking tone (30 seconds)

“Thanks for doing this—please be frank. If something feels confusing or useless, say it. That helps me fix the right things.” That sentence buys you truth.

4. Map their baseline first (5–10 min)

Seek stories, not opinions. You must understand the current reality you’re competing against — their existing workflow is your baseline. Again, your goal is to learn about the customer and their world. Questions like:

• “Walk me through the last time this came up.”

• “Could you show me how you do this today?”

• “What is the most annoying part of that process?”

If they can’t recall a real moment, the problem probably isn’t real.

5. Let your product speak first (10 min)

Share the build or prototype. Don’t narrate. Watch where they hesitate, what they ignore, what they try to make it do. Then probe with questions like:

• “Where would this live in your day?”

• “What does this replace?”

• “What would stop you from trying this this week?”

• “If you could add one thing to this…”

• “If this disappeared tomorrow, what breaks?”

Anchor in behavior, not opinion.

6. Close the loop crisply (2–3 min)

• Reflect back: “Sounds like the value is X, but trust hinges on Y. Did I get that right?”

• Ask for a real-world trial: “Any upcoming use case where this could ride along?”

• Get permission to follow up in a week.

• Bonus: “What’s the one question I should have asked you?”

Share Words on Product

Better Questions, Better Signal

The quality of your learning depends on the quality of your questions. Replace hypotheticals with real stories, and polite prompts with provocations.

If your question starts with would or do you think, reframe it until it starts with when, how, or why.

Instead of… → Ask…

• “Would you use this?” → “When was the last time you needed to do this? What did you do?”

• “Do you like this?” → “What’s confusing or unnecessary here?”

• “Would you pay for this?” → “What do you already pay for that solves part of this?”

• “Would this save you time?” → “What’s costing you time right now?”

• “Would you switch?” → “What would make you leave your current tool — and what would keep you there?”

When you want to leave them thinking:

• “What’s the question we should’ve asked you today, but didn’t?”

• “If this product disappeared, what would you actually miss?”

• “What’s the one outcome you care about that no tool ever measures right?”

When you’re testing whether the problem is real:

• “Appreciate you testing this! Now, if I turned this back off tomorrow, what would break?”

• “What’s the ugly but reliable hack you fall back on?”

• “How do you know when this process is ‘good enough’ to ignore?”

When you’re exploring willingness to pay or switch:

• “If this could replace [tool], how would you expect pricing to compare?”

• “What’s the moment you’d say, ‘This just paid for itself!’”

• “What have you already paid for to solve this — even halfway?”

• “If your budget got cut tomorrow, what would you fight to keep?”

• “Who else would need to love this for it to stick?”

👉 A note on willingness to pay: WTP is tricky, and ultimately, the credit card is the test. These questions help you sniff signal, but there are loads of scientific ways to do this as you lead up to a launch — think Van Westendorp, Gabor–Granger, conjoint testing, etc. You could go nuts here. But the main rule of thumb in this realm is to lead with value before cost. Users don’t pay for features; they pay to make something disappear.

The Engineer’s Advantage

Great engineers don’t wait for insight to be handed to them. They go get it — by asking sharp questions, grounding in real moments, and closing the loop with code.

• You already isolate variables and run tight loops. Treat interviews like debugging: reproduce a real moment, inspect inputs and outputs, validate hypotheses against behavior.

• You already ship iteratively. Use flags, small cohorts, and session replay to pair what people say with what they do.

• You already manage complexity. Ask one question at a time; change one thing at a time.

Do this for a few weeks and your judgment changes. You’ll feel which problems are alive, where friction really is, and what good enough to learn looks like.

Try: list one thing you don’t know about your user. Then schedule a 20-minute call to find out using the guidelines above.

Build fast. Listen better.

Bottom Line

The engineers who engage with users — especially outside of pure validation — change the company. It builds product sense and customer empathy.

Don’t wait for product direction. Go find it — then build what you learned.

The question hit close to home, because in my work, I see that most product and engineering teams in SaaS feel the importance of story — they know it’s an important skill — but can’t explain what it really is.

tldr: Every great product has a story arc. Story in the product world is the structured movement from tension to transformation. It’s a formula. (P.S. The story is actually about the customer.)

Here’s what I shared and how to try it.

Think about your favorite book or movie. Typically, story follows a simple arc:

1. The world before (tension)

   What does a normal day look like for your user before your product exists? What tradeoffs are they making? What are their struggles?

2. When things change (turning point)

   What triggers the realization that “this can’t go on”?

3. The new world (transformation)

   How does their day look different now?

That’s the (simplified) story spine. Everything else — roadmaps, OKRs, decks — flows from it.

Our colleagues in Sales have known this forever. They sell the before and after. For product builders, the story is told inward to the team, and outward again to users.

When your team can tell the story forward and backward, you’ve struck gold.

• Forward: What transformation do we deliver for our customer?

• Backward: What truth about the user or problem made this product necessary?

Why it matters

It helps teams say no to features that don’t serve the transformation and make better decisions. It builds alignment across disciplines because every team can picture the same “before” and “after.” They know what kind of world they’re trying to build and for whom.

Story acts as a strategic backbone. It’s a living artifact that connects purpose (why we exist), product (what we build), and proof (how we know it’s working). When the story is clear, prioritization gets easier, communication gets sharper, and belief starts to spread.

Try it: A fast path is to try it with a single customer story that you know well, and then extrapolate that to a broader product story (which really is a customer story):

1. Before, ACME Corp felt _______ and struggled with _______

2. The turning point was _______

3. And now? ACME Corp _______

Your narrative becomes the throughline for how you describe, prioritize, and measure work. It’s alignment — at least at the story, context, or “why” level that makes the next level of alignment (the what/when) much easier.

A clear story clarifies strategy; a clear strategy strengthens the story. That turns into velocity.

There are loads of books on storytelling, but here are a few on my bookshelf.

Bottom line: Every great product has a story arc that centers on the customer. When teams can name the tension, see the turning point, and describe the transformation, strategy starts showing up in decisions.

Every product leader evaluating their team has sat in front of a 2x2 at some point with performance on one axis, potential on the other. It’s a neat mental model and pairs well with a competency artifact. Your job? Hire the upper right, weed out the lower left, and coach the others. Easy, right?

But if you’ve used it to evaluate a product team, you’ve probably asked yourself the same question I did: What is “potential,” anyway?

Performance we can measure! Shipping on time, hitting metrics, running clean sprints. Potential is slipperier. It’s harder to see in the moment. But it matters even more, because your roadmap will eventually inherit the qualities of your people.

People shape bets, and bets shape growth.

What “Potential” Looks Like in Product People

Potential is about whether that person can grow the team, the roadmap, the business. You’re looking for repeated patterns, not isolated wins. Here are the patterns that often separate the High Potential PM from the Low Potential PM:

1. Appetite for Ambiguity. Energized by creating clarity from messy, undefined problems.
   Anti-pattern: Shine when problems are well-scoped, but freeze when the walls disappear.

2. Reframe from First Principles. Zoom out, reframe, ask: “Why are we solving this at all? What makes this the most important problem? How might we…” Will toss a polished plan if it’s the wrong plan.
   Anti-pattern: Anchor on best practices or copycat solutions. Optimize within the frame, but never break it.

3. Connect to the Bigger Picture. Articulate how their work ladders to business outcomes, customer value, and long-term bets.
   Anti-pattern: Can explain what shipped and which metric moved, but not why it matters in the larger system.

4. Cast Vision, Ship Versions. Hold the dream and the tactical next step in creative tension. Can flex up into vision and down into backlog grooming seamlessly and take the team along.
   Anti-pattern: Excel at one (usually execution), but rarely stretch across both.

5. Learning → Action Loops. Seek out critique, adapt when the ground shifts, and show evidence of compounding. Every cycle makes them sharper.
   Anti-pattern: Learn just enough to execute the current task. Thrive when the plan holds, struggle when it doesn’t.

The “Low Potential” PM

Patterns are what define this quadrant — repeated freezing, repeated lack of reframing, repeated avoidance of the bigger “why.” Over time, you start to see the profile:

• Excellent at executing well-scoped tasks

• Reluctant (or unable) to zoom out, connect dots, or explore beyond the brief

• Motivated by polishing the known, not venturing into the unknown

They’re dangerous because they can look like your best people for a long time. They’re consistent. They deliver. Stakeholders love them because requests get done quickly and cleanly. But here’s the catch:

• They generate momentum, not velocity. The train runs on time, but it’s stuck on the same tracks.

• They calcify the roadmap. Incremental wins pile up while bigger bets languish.

• They teach the wrong lessons. New PMs learn “execute fast and clean” instead of “reframe, test, and grow.”

To spot potential during hiring and coaching:

• Watch for generative thinking. Do they create new options, or do they optimize the options you gave them? If they can’t zoom out, they won’t stretch your roadmap.

• Look for learning velocity. Ask about a time they were dead wrong and what changed in their approach afterward. High potential PMs can show compounding growth; low potential ones give you a canned failure story.

• Insert ambiguity. Give them a project where the outcomes aren’t obvious and success can’t be reduced to a single metric. Do they generate hypotheses, or just wait for you to define success?

• Force reframing. Ask them to articulate the “why” behind a roadmap arc or for the story behind an investment. If their answer is “because sales asked” or “because the metric dropped,” nudge them higher up the chain.

• Model compounding. Don’t just debrief the project. Ask: “What did we learn here, and how should it change our playbook going forward?” High potential PMs carry the lessons forward — the next roadmap cycle looks different because of the last. Low potential PMs will rinse and repeat.

If after repeated chances they still can’t flex, then they’re executors (though, useful in some contexts).

Why This Matters

If your team is stacked with high performance / low potential PMs, your roadmap will look similarly: Polished delivery, little true progress. What looks like a well-oiled machine is actually a machine that can’t turn, can’t experiment, and can’t chase compounding returns.

As AI takes on more of the rote execution — the scheduling, the sprint hygiene, even the spec drafting — the premium on potential only grows. Machines can crank. People need to create, reframe, and teach others how to see differently.

Bottom line: High performance without potential is a mirage. It feels good in the moment, but it quietly locks your roadmap — and your org — into incrementalism. Spot it, coach it, or cut it before it calcifies.

Every leader wants “aligned autonomy,” the dream upper right quadrant from Henrik Kniberg’s 2×2. I used this for many years to illustrate the idea of a more empowered, bottom’s up structure. And for many years, I misinterpreted this and caused unnecessary confusion.

Looking back, here’s what I know from my own mistakes and from what I see from working with startup teams:

In the spirit of honoring autonomy, leaders (CTOs, Founders, CPOs, etc) tell teams to “set your own goals and own your roadmap.” Then those same leaders complain nothing is shipping fast enough, or that the work doesn’t move the company forward.

Usually, this comes from a good place! We want empowered teams feeling accountable for outcomes, doing the best work of their lives. But…I’ve also seen this from a place of fear — shying away from clear direction out of fear the team will revolt or quit. 😩

The job of leadership is to frame the opportunity with precision. And — stay with me here — it’s okay to be heavy handed about it.

Crossing The River, Revised Edition

To illustrate the nirvana of perfect alignment and autonomy, the leader in the cartoon says: “We need to cross the river. Figure out how.” Sensible at first glance — set the goal and let team the figure out how. But, a more actionable frame might be:

“This is the river. This is the bank we’re aiming for. Here’s the weather you must respect. Based on what you know, where do you see this differently?”

Presuming the teams deeply understand their customer, their JTBD, their tech stacks, etc, expect them to bring real leverage to the problem space with an opinion on the order of operations.

If the team disagrees, they should prove it with the identical framing (bring the insights). If they’re right, you’ve found a sharper problem. If they’re wrong, you’ve strengthened alignment. Either way, the customer and business wins.

Example: Analytics for Enterprises

• Frame: 25% of enterprise deals stalled because customers needed role-based access controls to switch. That’s $1.2M in pipeline this quarter.

• Constraints: Must ship in <90 days; no re-architecture of identity services.

• So what: How might we close this gap to unlock those deals and hit our Q2 revenue target?

Set direction, define boundaries, and tie to financial impact. This is strategy.

Too often leaders show up to planning empty-handed, waving around strategy slides, rah rah speeches from All Hands, or lofty OKRs. But those aren’t actionable inputs for teams.

Now, let’s evolve this into something meaty and concrete. Before you ask teams to write a roadmap, arm them with FOCUS.

The F.O.C.U.S. Brief (Quarterly, Team-Level)

F.O.C.U.S. is an exercise in rapid, disciplined writing by leadership. Wait, writing!? 🫢Yes, writing still matters — crisp writing is evidence of clear thinking, and spending millions each year even on a few small teams demands clear thinking. (Use your actual brain before turning to AI to help augment.)

It’s the bumper lanes for a team’s quarter:

• Frame the problem: Why this, why now, and for whom.

• Outcome: The single metric that matters this quarter, plus guardrails.

• Constraints: Timebox, budget, quality bars, tech boundaries.

• Universe of autonomy: The space the team controls, including leading metrics they’ll use to know if it’s working.

• Stop rules: Kill criteria, pivot signals, review cadence.

➡️ In a past role, we had the cost of each team on a spreadsheet and stared at it every quarter. Every quarter, we asked: Would we write this $1M check against the direction we’re giving them? What precision do we owe them to get the most ROI back? That mindset forces clarity.

Imagine the CTO, CMO, CEO, CPO, Founder getting aligned behind a few of these — this is product work at the heart: Editing, crystalizing. If you can’t frame the bet crisply, you shouldn’t write the check.

Three Moves For This Quarter

What leaders want:

• Autonomous progress on the right problems

• To predictably buy outcomes with bounded risk

• Teams that surprise them with how, not what, they’re chasing

So, try this next quarter:

1. Name the bottleneck. Growth, retention, sales friction, reliability, etc. Write one F.O.C.U.S. Brief per team. Open up debate and dialogue the week before planning.

2. Publish constraints and kill criteria. Remove ambiguity; speed comes from clarity.

3. Change the review. Don’t ask for status. Ask: What did you try? What did you learn? What decision did you make? How did the metric move?

The discipline of writing F.O.C.U.S. Briefs forces leaders to do their job: Define the river, name the bank, respect the weather, and tie it back to outcomes. Then hand the wheel to the team. (P.S. This is also powerful coaching for those teams to do the same thing: Frame and execute.)

That’s how autonomy — fueled by clarity — actually creates a culture of speed.

How about you? What’s worked, where do you see this differently?

Bottom line: Leaders owe their teams a crisp frame of the problem, boundaries, and outcomes so teams can own the “how” with speed and confidence. A F.O.C.U.S. Brief is one way to turn aspiration into action, and action into results.

They're laser-focused on their corner of the product, polishing features and optimizing flows. Meanwhile, the human on the other side of the screen is cobbling together workarounds, switching between six different tools, and muttering under their breath about "why doesn't this just work?"

Your users don’t think about your product nearly as much as you do. They’re busy thinking about getting their job(s) done.

I use a simple framework that leverages Jobs to be Done to solve this disconnect for teams of all sizes, but in particular, product engineering teams — the teams of engineers working with users, settings goals, and making product decisions. It gives clarity on what actually matters, and has reframed roadmaps for the teams I've worked with.

Where JTBD Falls Short

Quick shared understanding: Jobs to be Done (JTBD) is a research approach that looks at the specific tasks and workflows people are trying to get done in their daily work, beyond just how they use your product. Rather than focusing on user personas, JTBD digs into the bigger picture of what's actually happening and why — the steps before and after someone touches your SaaS tool, the hacks they've cobbled together, and where things break down in their real processes.

The problem? Most JTBD work stays theoretical. (This is also true for a related artifact, the Customer Journey Map.) It becomes a piece of art sitting in Notion or Confluence, gathering digital dust. Beautiful research that never influences a product decision.

To make JTBD practical, you need to merge it with the product lens. You need to connect the human job directly to your product reality — where you're winning, where you're failing, and where you should focus next.

The Exercise: A Simple Table

Create a table with the 8 columns below — 4 to capture the human job to be done, and 4 for your product. Use a Notion database, a table in your wiki, a Google doc, or even pen and paper. It should look like this:

Let's say we’re building a marketing platform, and we’ll use a job typically associated with a Demand Gen Manager at a B2B SaaS company as our example. This person sits between marketing and sales, responsible for driving qualified leads and proving marketing's impact on revenue.

Focus first on the JTBD (the first 4 columns):

Start with the Job (simple shorthand description) and the Job to be Done. Just take a crack at it based on what you already know from your customers or try the prompt below: "When I [situation], I need to [motivation], so I can [desired outcome].”

Then move on to Frequency (how often the user does that job) and Impact (how crucial that job is to them).

💡Just because users do something frequently doesn't mean it's strategically important or impactful to their daily workflow or success, and the converse is also true.

Want a headstart on JTBD? Try this prompt with your favorite AI tool, then take the output to validate and evolve with real users.

As an expert user researcher specializing in Jobs to be Done methodology, I need you to identify 3-5 Jobs to be Done for a specific user in the [INDUSTRY] industry. The persona is often a [JOB TITLE] at a [COMPANY STAGE] company, and I'm specifically looking at their workflow around [SPECIFIC SITUATION/PROCESS]. [ADDITIONAL CONTEXT: team dynamics, current pain points, goals, constraints, or tools they use]. For each job, provide: 1) Job (short name), 2) Job to be Done using the format "When I [situation], I need to [motivation], so I can [desired outcome]", 3) Frequency (how often), and 4) Impact (High/Medium/Low). Focus on jobs that are currently underserved or create friction in their workflow, considering both functional and emotional needs.

Now move on to your product with the next four columns:

Current Priority. Only you can answer this. Focus on your goals for the next 6 months, and be judicious about what rows you assign high priority. Some jobs — low impact, low frequency, etc — might not even carry willingness to pay. Also think your product vision and the type of company or product you’re building:

• Point — Teams focused on solving specific pain points might intentionally keep many JTBD rows low/no priority. An example might be a company like Carrd, where many jobs for their users might be unaddressed because Carrd is hyper-focused on a niche, specific use case, while a Squarespace might want to tackle many more.

• Compound — Teams focused on building compound products/startups, like Rippling aim to solve towards many or even all of the rows, but must apply rigorous product thinking around which rows to go deep and differentiated on, vs parity. A low impact JTBD for a compound startup might led to a decision to integrate rather than build, for example, and they might be okay with a score of 2/5 for a long time.

Lastly, Current Features, Score, What’s Missing. Look at your product and separate out the chunks of features and functionality here mapped to each specific JTBD. Then score it on how well that set of features truly helps the user do that job, and be critical. Put yourself in your users’ shoes. And list the gaps that would increase that score.

Repeat these steps until you’re confident that you’ve got a succinct, accurate view of that person’s responsibilities across 5-10 rows of jobs to be done — even if some of those jobs do not intersect with your product.

What You'll Discover

Most teams discover they're over-investing in jobs they already handle well while completely ignoring high-priority jobs that could differentiate their product. The scoring creates an honest assessment of where you actually stand. It gives your team shared context to ask sharper questions: Which job does this serve? How important is that job? How well do we handle it today?

I was working with a SaaS founder recently who was operating in an industry I was unfamiliar with, so I had some homework to do. After some research, I used this framework to first get inside the customer's head, then asked the founder to help me validate it, and then we paired on each row until we felt like it captured the real human jobs. Then we mapped those to their product.

It became abundantly clear almost immediately where the product was letting users down. We built out a survey, pulled up the data in the analytics tool, and did a few quick user interviews to validate those assumptions. And now, that founder is using this table to help prioritize what's next for their product.

One 30-minute conversation completely reframed their roadmap.

Making It Stick

Here's how to embed it into your product engineering team:

Review it monthly. Jobs evolve as your users and business mature. What was important six months ago might not be today. Particularly helpful if your SaaS product begins to move upmarket — often introducing more personas and more specific roles/responsibilities.

Use it for prioritization. Before adding something to your roadmap, ask: "Does this improve our score on a high-priority job?"

Fast onboarding for new team members. This table gives new engineers user context on the customer quickly.

Take it to customer calls. Validate your assumptions. Are these really the jobs your users care about? Are you missing something obvious? Take the JTBD and reframe it as a question to get the user’s score on how well your product is helping: “When you’re preparing for your monthly revenue review, how well is the product helping you prove which marketing activities actually drove closed deals…?”

Reference it in specs. When writing requirements, connect features back to the jobs they serve. This helps engineers understand not just what to build, but why it matters to the user's workflow.

⚠️ An Aside on Personas

Before we wrap…short rant.

You might be asking how this relates to personas. You know, those perfect, imaginary friends who promise empathy, user-centric thinking, and clarity in product decision making. Goodness, the time I spent crafting the page-turning biography of “Marketing Maria” — her role, company, favorite coffee order, and t-shirt size…

My issues with putting personas on a pedestal:

1. Real users — unique humans with specific motivations — are messy, and don't fit neatly onto a card.

2. Why chat with users if you have a persona to represent them? Knowing that "Marketing Maria" is 41 and loves running doesn't help you build a better product; go talk with the actual Maria.

3. Personas often emphasize attributes over actions, leading to decisions based on who users are, rather than what they need to accomplish. Something a JTBD focus solves.

Put JTBD first, and let personas play a supporting role.

</rant>

The Real Value

This exercise around JTBD will save you from building features nobody uses. It's the fastest way to align your product engineering team around what actually matters.

Your team(s) should be asking questions like: Which job does this serve? How important is that job? How well do we handle it today?

I've used this approach with early-stage teams who felt stuck, growing teams who lost sight of their users, and established teams who wanted to find their next area of differentiation — like expanding their product footprint into adjacent jobs and personas.

The better context teams have, the more they get inside the user's head, the better decisions they make.

Ready to Build What Actually Matters? Try it with your team this week. Build the table, fill out 5-10 jobs, and take a step back. You'll know exactly where you're winning, where you're failing, and what to build next.

Need help facilitating the exercise or want a fractional product leader who can embed this user-centered thinking into your team's DNA? Let's talk: arborproductsolutions.com

Most product teams have rituals for sharing work at different stages. At FullStory and LaunchNotes, I hosted “Product Studio.” At Atlassian, we “Sparred.” At H-E-B, we dubbed the time “Design Lab.” But the ritual alone isn’t what sharpens the work. What matters is whether truth makes it into the room.

Every time product feedback culture slipped on my teams, I could trace it back to two blind spots: What I modeled, and what I taught the team to expect.

I remember (painfully) a situation when I set a product strategy that called for a major investment — and the team quickly realized it was 10x harder and far less valuable than we’d hoped. But week after week, review after review, no one — including me — said the hard thing. It dragged on, burning trust, wasting time, and leaving the customer with a half-baked solution no one believed in. (Looking back, I think I fell victim to anti-pattern 2, below.)

The quality of your product is a reflection of what your team is willing to say out loud. As a senior product or UX leader, your job is to build a culture where truth can survive the room.

Here’s how to fix yourself first, then your team — by avoiding common feedback traps and tailoring input to each stage of product development.

Fix Yourself First

If you're the most senior person in the room, you're shaping outcomes — even when you think you're just brainstorming. Your musings become mandates. Your preferences ripple through roadmaps.

So ask yourself: How much is getting built just because people think you want it? Even when it’s wrong? Your role is to make truth safe. Here's how:

Name the Power Dynamic. Say it out loud:

“I know I’m the VP, but I’m genuinely unsure about this direction. I need your perspective — especially if it contradicts mine.”

This clears the air and creates permission for challenge. Shoutout to Agata Bugaj from my time at FullStory — a masterclass in making others feel empowered to disagree.

Model Messiness. Let your team see you struggle. Share half-baked thinking:

“I’m stuck between three paths. What are we not seeing?”

This isn’t just vulnerability for its own sake — it normalizes ambiguity and invites others into your thought process.

Celebrate Disagreement. When someone pushes back, highlight it:

“That challenge helped me see the blind spot. Thank you.”

The more you highlight candor, the more you’ll get it. Disagreement isn’t a threat — it’s the oxygen of great work.

Then Fix the Room

Even on high-performing teams, feedback sessions go sideways in subtle ways. The habits are familiar. The damage is quiet. But over time, the cost is massive.

As I’ve reflected, I found three anti-patterns to watch for (ones that I should have caught earlier) — and an opportunity to emphasize the importance of the phase to frame feedback requests.

Anti-Pattern 1: Validation Over Truth

It’s natural to want validation. We all crave affirmation, especially when we’ve worked hard. But when teams show up to feedback sessions looking for applause instead of critique, the product gets weaker — even when everyone means well.

What it looks like:
Designs arrive glossy and over-polished. Nobody asks hard questions. You feel tension in the room when someone critiques anything significant.

Why it’s dangerous:
Instead of evolving the idea, the team protects it. Risk-taking fades. The work plateaus because everyone’s afraid to poke holes in it.

What to do:

• Praise in-progress, messy work.

• Ask directly: “What are you unsure about?”

• Set the norm: Feedback isn’t failure — it’s forward motion.

Anti-Pattern 2: Defending Over Discovering

When feedback sessions turn into mini-trials, something's broken. The goal isn't to defend the solution — it's to explore the unknown. If your team treats critique like attack, innovation dies on the vine.

What it looks like:
Every comment gets a counterargument. Docs sound airtight but aren’t evolving. Sessions feel like debates, not collaborative discovery.

Why it’s dangerous:
Teams stop listening. Nobody wants to be wrong. And the product calcifies.

What to do:

• Try a "no-rebuttal" rule for one session. Only listening allowed.

• Ask presenters to name 2–3 things they're unsure about before they begin.

• Reinforce this truth: We’re not defending work, we’re discovering what works.

Anti-Pattern 3: Winging It Instead of Directing

Most feedback isn’t bad — it’s misdirected. When the ask is fuzzy, the responses will be too. That’s not a failure of intelligence. It’s a failure of framing.

What it looks like:

“Any thoughts on these wireframes?”
Cue silence. Or worse, nitpicks about button colors and spacing.

Why it’s dangerous:
Unclear prompts lead to scattered input. You burn time discussing things that don’t matter yet — and miss the things that do.

What to do:

• Require every review to begin with a clear ask.

• If there's no framing, push back: “What kind of feedback will help you move forward?”

• Give templates. Build the muscle. Frame it right, or feedback fails.

The quality of feedback you get is directly shaped by how you ask for it. Coach teams to frame requests with surgical precision.

Level It Up: Teach Feedback by Phase

Even great teams get stuck when they ask the right questions at the wrong time. Someone critiques hex colors in an early sketch, or suggests a whole new feature during final polish. The result? Derailment and decision fatigue.

Teach teams to anchor feedback by phase — and make it clear what kind of input moves the work forward.

Early Discovery Phase (20% Baked)

“We’re exploring a new path. Pressure-test our assumptions.”

This is sketch mode. Feedback should focus on thinking, not polish.

✅ Ask:
– Are we solving the right problem?
– What’s missing?
– What assumptions feel worth validating?

❌ Skip:
– Visual tweaks
– Friendly copy
– Brand alignment

👉 Redirect: “Could we revisit that later? For now, we’re still stress-testing the direction.”

Definition & Delivery Phase (70% Baked)

“We’re validating the experience. Are we solving the problem the right way?”

Here, structure and copy are solidifying. Still time to shift — but the foundation is laid.

✅ Ask:
– Does the journey fit within the overall product experience?
– How will we know if we’ve solved the problem?
– What feels awkward or over-engineered?

❌ Skip:
– Rethinking the whole direction
– Late-stage pivots
– New feature ideas

👉 Redirect: “Great thought — we’re committed to this version for now, but let’s revisit that next round.”

The Bottom Line

The quality of product feedback is a direct reflection of how leaders model curiosity, manage power dynamics, and teach teams to ask for the right input at the right time.
If you want sharper work, start by creating sharper conversations.

So here’s the challenge: This week, say the honest thing — and encourage your team to do the same.

That’s how great teams get sharper — and how great products get built.

We’re seeing a wave of teams starting with what AI can do, then working backward to justify it. Features get built. Launch videos get cut. And customers…shrug.

Customer-first thinking is what builds lasting products.

The question is not, “What can we do with AI?” But rather, “What has been impossible for our users until now?"

And that requires laser precision on the user and their Job to be Done (JTBD).

Garmin: AI Misfire

I’m a recent convert from Apple Watch to the Garmin ecosystem, and I love what my Garmin watch has unlocked for me in terms of training (and of course, battery life).

Garmin has built a loyal following by being reliable, rugged, and deeply attuned to its users — especially serious athletes and outdoor adventurers.

They recently launched a subscription service, Connect+, that contains AI features.

And many long-time Garmin customers lost their minds at the concept of a subscription service (something very un-Garmin), and were full of cynical observations about the AI ingredients.

Some excepts from a few of the threads:

• “Wow, their LLM can do math…”

• “They used chatGPT to give you a math equation that you now have to pay for.”

• “Am I missing something or is connect + just some useless ai insights.”

• “AI is a solution looking for a problem. Every tech or tech-adjacent company is scrambling to get AI products out ASAP...”

• “The so-called ‘Active Intelligence’ feature seems more like a gimmick than a valuable addition…”

A cautionary tale! Obviously, I have no insider info — I can certainly speculate on how and why this launch came to be though.

Garmin's stumble reminded me that even great product teams can lose the thread when tech leads the conversation. We nearly did the same as we built towards the Graph beta a few months ago.

Graph: Interrupting Our Own AI Momentum

While building Graph, we got caught in a similar current. AI was evolving fast. We saw all the things we could do — summarization, insights, predictive nudges. We spent months arm wrestling the LLM and building in possibilities.

But then we hit pause.

We went back to user interviews. Re-read transcripts. Asked ourselves:

• What is our user trying to accomplish, really?

• Where are they frustrated, not just functionally, but emotionally?

• What moments make them feel like they’re winning?

That reset was critical.

It reminded us that AI should serve the solution — not be the solution.

Rediscovering JTBD in the AI Era

JTBD — A Refresher

Jobs to Be Done (JTBD) is the practice of understanding what customers are really trying to accomplish — not in your product, but in their lives. It brings clarity when technology muddies the waters.

The classic example is the fast food company’s curious early morning milkshake sales. My former colleagues at FullStory wrote a post from 2020 that’s just as relevant today five years later.

As Christensen put it:

When we buy a product, we essentially 'hire' it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we 'fire' it and look for an alternative.

Don’t get fired. In times of disruption, JTBD becomes an even more critical compass! Stay anchored to why your customer has hired your product.

How to Leverage JTBD in the Age of AI

How might we leverage the tried and true craft of jobs to be done in the context of AI?

1. Micro-Moment Mapping

Break the experience into emotional moments:

• “When I realize I’m behind on reporting…”

• “When I’m unsure if I’ve missed a signal in the data…”

Use sticky notes or FigJam. Write them in first-person, emotionally charged language.

2. The Job Statement Template

Try this template from Figma.

“When I [situation], I want to [motivation], so I can [desired outcome].” Unbelievably powerful artifact to serve as a center of gravity for your team.

Example from Graph:

“When I’m reviewing last week’s sprint, I want to quickly see what changed and why, so I can make better calls in Monday’s meeting.”

AI doesn’t show up yet. We’re still in the human experience. And when that sentence is front and center, it makes it much easier to stay focused on the user rather than the technology.

3. Forces of Progress

Use the four forces to understand what's pushing your customer toward change, and what might be holding them back:

• Push of the situation — What's frustrating or broken in their current workflow?

• Pull of the new solution — What hope or promise does a better future offer them?

• Anxiety of the new — What worries or risks make them hesitate to adopt something different?

• Habit of the present — What routines or muscle memory keep them anchored in the current way?

Plot these forces across your key JTBD moments. Where is momentum blocked? Where is trust low? Where is friction highest?

Then: where might AI help?

• Can it reduce the anxiety of trying something new?

• Can it make switching feel familiar or low-risk?

• Can it amplify the promise of a better outcome?

Find the high-leverage spots where AI can make the experience feel effortless to the user.

Then, when you have a deep understanding of the JTBD, AI becomes a tool for acceleration, not distraction.

The Pressure Test for Product Leaders

Before you ship that AI feature, ask yourself these six hard questions:

What job, exactly, does this solve — and what made it unsolvable before?
If you can't name the struggle it resolves, you're inventing use cases, not serving real ones.

How does this change the way users complete the job?
Is it 10x faster? More intuitive? Less stressful? Or just... more expensive?

Would we ship this without AI?
If not, why now? Are we chasing substance or spectacle?

How do we measure success in job terms, not feature metrics?
Job completion > AI engagement. Show outcomes, not usage.

Where does this create new risk, confusion, or false confidence?
AI can erode trust when it fails. What’s our mitigation plan?

Are we solving for customer delight or investor theater?
Great products win hearts. Demos win pitch meetings. Which are you building for?

Bottom Line: Stay Grounded and Lean Into AI

The best question teams can ask is, "What has been impossible for our users until now?" It puts the customer at the center, and forces focus on their JTBD.

Breakthroughs happen for teams who combine the deep discipline of user understanding and the intense power of AI. It’s only the beginning!

It's the moment a founder starts to share the keys to their creation. The vision they've coded into existence, defended against rejection, and built through pure will. From their perspective, the wrong choice isn’t just wasting a six-figure salary — they’re gambling with their company's direction, team morale, and the precious runway they fought to secure.

So, if you are a product leader looking to join a founder’s crusade, know that your success hinges on your ability to become a trusted steward. When you step into a founder's world, you're not just leading a product, you're handling someone's life's work.

I've spent close to two decades in this dance, from my first role at NetSpend, through my work with the HipChat founders at Atlassian, with Emil Ivov at Jitsi, with the FullStory founding team, and most recently with Tyler Davis at LaunchNotes. And I love it. 😊

If you're eager to become a Founder Whisperer, the playbook is deceptively simple: Respect the past, craft the narrative, and deliver relentlessly. So simple, yet nearly impossible to execute if you chose ego over empathy.

1. Respect the Roots: Listen First

Stepping into a product role at a founder-led company isn't just a new job — it's being handed the keys to someone's life work. Your fresh perspective and expertise matters, but waltzing in with all the answers is product leadership suicide.

The founder is entrusting you with their vision — years of blood, sweat, and tears encoded in features and customer conversations. Walking in with "the answer" or trying to blindly transplant your last company's playbook screams, "Everything you've built is wrong." No founder signed up for that.

One founder confessed to me:

Our first PM asked me for the list of things we were working on, threw them all on a spreadsheet and then prioritized them. This was terrible. It just felt like he was saying: "I know better."

The good ones don’t start at the roadmap. A good product leader focuses our thinking in the direction that matters and says: "Here's the situation, here are the issues we are facing, let's work together to find a solution.” No agenda, only the objective of doing right by the users and the company.

That first approach this founder mentions is the product equivalent of a hostile takeover! Instead, start with genuine curiosity.

Product Plan of Attack: Seek to understand the present. Make understanding the present your obsession before touching the future. This means honoring battle scars while moving forward.

Start by digging into:

• Past decisions (the "why" behind them). Look beyond what was built to understand the context, constraints, and reasoning. What problems were they solving? What trade-offs did they face? Assume positive intent—always.

• Customer feedback (the raw, unfiltered truth). Skip the sanitized reports. Immerse yourself in customer quotes, support tickets, and sales calls. Feel their pain points and desires firsthand.

• Technical constraints (the realities on the ground). Even brilliant product visions crumble against technical debt. Understand the infrastructure's strengths and limitations to grasp what's truly possible.

• Failed experiments (the valuable lessons learned). Every startup has a graveyard of ideas and launches. Understanding these failures reveals which experiments might deserve another shot and which mistakes aren't worth repeating.

Acknowledge the journey that got the product here. Frame your initiatives as the next logical evolution, not a revolution (unless, of course, you’ve been hired for a revolution!). Seek to understand the founder's original vision and how the product has evolved as you co-author the next chapter.

Surprise: Your first few months aren't about showcasing your brilliance through radical change! They're about earning the right to shape the future through genuine curiosity and respect for what came before you. Create a narrative that respects the past while building what's next.

Which leads us to…

2. The Power of Story: Vision to Narrative

When you join a passionate founder, you're often stepping into a vision that's bursting with possibilities. Your unique value isn't initially in adding more ideas — it's first in editing and crafting that abundance into a story that actually resonates with users.

One founder reflected on this with me, realizing:

For founders like me — who have a good understanding of a technology and who are looking to make that technology useful to more people — I realized I lived in a different reality than users. I could see all of the possibilities, and wanted to share them all with our users! If I had my way, I’d serve up a chaotic mess. It might work, but it won’t be a blockbuster.

For that, you need a good story. You need someone who can help you turn the mess into a coherent and enjoyable play. A person like this would make you feel like you have gained a new layer of understanding and not that you are giving up control.

Founders often see the entire sprawling landscape of possibilities, while users need a guided tour with a compelling storyline. They don't want the entire universe of features — they want transformation packaged in an experience they can understand.

Product Plan of Attack: Step in as the master storyteller who translates the founder's expansive vision into a focused narrative that users can't resist.

Here’s how to leverage the power of story:

• Unearth the core narrative. Work with the founder to identify the central problem you solve and the transformation you enable. What's the "hero's journey" your product facilitates?

• Find the Why. Go beyond features to articulate why users should care. What deeper need does the product fulfill? This provides the emotional core of your story.

• Create a coherent customer journey. Map the ideal experience with a logical flow and clear progression. Each feature should advance the narrative, guiding users toward their desired outcome.

• Visualize the story. Use journey maps, storyboards, or simple narratives to bring the product's story to life. This creates shared understanding between the founder, product team, and wider organization.

By crafting a compelling story, you're not diminishing the founder's control — you're amplifying their vision. You're providing the structure that turns a chaotic collection of features into a product that connects with users and achieves blockbuster status. This narrative skill is your superpower in the founder-product leader partnership.

Which means it’s time to start shipping...

3. Just Ship: Build Trust Through Execution

Fail to deliver, and your product leadership role at a founder-led company will be painfully short-lived.

One founder put it bluntly:

I worked with multiple product leaders who started by just trying to own the roadmap and theorized about the product they wanted to create. They all talked about trust but implicitly they all behaved as if they trusted the founder’s input less than their own.

This went very badly…

Talk is cheap. In founder territory, trust is demonstrated through relentless, rapid execution.

Product Plan of Attack: Share their obsession. Match their intensity. The fastest path to a founder's trust is proving you care about their creation as deeply as they do. Adopt the founder’s mindset.

• Match their attention to detail. Founders know every pixel and edge case. Show you care about the details others miss.

• Hunt for quick wins. Fix that long-standing bug. Address the low-hanging fruit everyone knows about but no one has fixed. These early wins demonstrate that your understanding translates into tangible value.

• Show the same urgency about customer problems. Then go beyond. Founders feel user pain personally. Mirror that urgency and proactively hunt for solutions.

• Care about the little things everyone else ignores. Notice subtle friction, inconsistencies, and minor improvements. This signals you're truly invested.

• Get on sales calls before you're ready. Volunteer for customer conversations to understand needs from the front lines. Show you're willing to get your hands dirty and grasp the business from every angle.

Deliver early wins. Communicate clearly. Show up obsessed with details and customer problems. Remember: Founders want to see their vision come to life! Your execution should prove you understand their core intent and can translate it into a product users love.

Bottom Line

The most successful product leaders in founder-led companies don't try to wrestle control — they earn influence through understanding, storytelling, and execution. They recognize they're stewarding someone's life work, not just “managing” a product. By respecting the product’s roots, harnessing the power of story, and building trust through delivery, you’ll transform into an essential partner for founders.

This simple tactic — the "micro-yes" — transformed my communication as a product leader after learning it a few years ago, and I use it everywhere, even at home with our kids!

Like the concept itself, this (micro)post is short and sweet.

What is a Micro-Yes?

A micro-yes is a small request that precedes your actual message. It primes and makes way for your message.

It seems trivial. It's not:

• Before, I used to ambush: "This PRD lacks key details and needs to be rethought."

• Now, I lean on the micro-yes: "Can I walk you through what’s missing in this PRD?"

What happened in that question?

1. It transferred control and acknowledged the other person's autonomy.

2. It eliminated surprise and signaled what's coming so they can prepare.

3. It created commitment to engage constructively.

The difference between starting with a question is huge, even though the feedback that follows might be identical. (And as curious product people, asking questions should be a superpower, so this should be second nature!)

The perfect micro-yes is respect + curiosity. It’s specific, short, honest, and easy to grant.

Try It

To challenge ideas:

• "I think we're optimizing for the wrong metric. Can I explain my reasoning?"

• "Before we move on, could I offer a different perspective?"

• "I'm seeing this differently. Can we take a moment to explore some alternatives?"

• "I think there's another angle we haven't considered. Can I walk you through it?"

For tough conversations:

• "I noticed you've missed the last two deadlines. Can we talk about what's happening?"

• "Your comments in that meeting landed differently than you might have intended. May I share what I observed?"

• "This work doesn't meet our quality bar. Can I show you specifically what I think needs to change?"

• "The approach you've taken diverges from what we agreed on. Could I understand your thinking do we could talk about it?"

Go Forth!

Five seconds can be the difference between a conversation that builds trust that unlocks progress and one that builds walls.

Your challenge: This week, identify three tough conversations ahead of you. For each one, craft your micro-yes before diving into conversation. Track what happens when you lead with a question before the critique.

A micro-post on the easy-to-implement “micro-yes!” Go forth and conquer.

Bottom line: The micro-yes transforms an ambush into an invitation – five seconds that mean the difference between defensiveness and receptivity. It's the simplest, highest-ROI communication tool you can add to your arsenal: Just ask permission before proceeding, and watch how quickly walls come down and trust builds up.

Feels good to be back in full-tilt startup mode: Top-notch team, learning new tech, building with the customer! 🚀

With the beta now public, I took a pause this week to reflect on what I’ve learned through this process: Building an AI-first product has challenged my almost two decades of product building!

The key insights for product people building AI-first products and designing prompt systems:

1. Prompts are the new PRDs — editing is more crucial than ever.

2. Embrace the intrinsic variability of AI, rather than wrestling it.

3. A product that talks back requires a rethink of user research.

⚠️ Quick note: AI is a tool. The hard product work remains — understanding the user, nailing the job to be done, and bringing the solution to market. AI is not a free pass. Don’t be lazy. The PM fundamentals are still crucial, but the playbook is totally different when building on top of AI.

Let’s dive in.

1. Creation ➡️ Curation

Great product work has always demanded excellent editing. The product manager’s role is to deliver focus, and editing is the primary instrument: Surgically dissecting a product, a project, a PRD, a problem to get to the heart.

I believe more in the scissors than I do in the pencil. —Truman Capote

But when building a product around generative AI, the scissors are almost the entire product development process. The PM is never starting from nothing, thanks to the pre-trained language models. You move from author to editor immediately.

From blueprints to breadcrumbs: Prompts are the new PRDs.

Instead of requirements and user stories, it’s iterating to crystallize what a good result looks like, and then curating and directing the AI to understand that, and ultimately, take action through tools (i.e. what an LLM “uses to interact with the world”).

As someone with an education, a background, and a deep passion for words (hence Words on Product), this was a new challenge for me: The art of clear communication…with machines! When you’re building around generative AI, a few thoughtful words in a prompt become more powerful than a 5-page product requirements document.

When designing prompt systems, Product teams now need to distill complex ideas into clear, concise instructions that find the right balance between specificity and flexibility so AI can leverage its capabilities while still guiding it towards the desired outcome.

Applying a writer’s mindset to prompt engineering requires extreme clarity of thought and deep understanding of the user’s JTBD (job to be done). Prompt engineering is a creative act!

👉 Try: If you’ve worked with prompt engineering at all, this will resonate — Start thinking in much tighter loops. It’s experimentation to the absolute max. Quantifying the impact of prompt changes is the real work here (as much as one can quantify in a non-deterministic system). Read about how Gong uses Elo — We’ve had a blast learning to build quantitative checks and balances. Check out the fine folks at LangChain, and if you’re looking for a good educational resource, Anthropic’s Prompt Engineering Tutorial is fantastic.

2. Embrace Variability

In traditional software development, the goal is often predictability and consistency. Every input is expected to produce a specific, predetermined output.

But working with generative AI means embracing a new paradigm where variability is unavoidable. Generative AI models, by their very nature, introduce an element of unpredictability. Given the same prompt, they may produce slightly different outputs each time.

😅 As a control freak, I had to stop wrestling AI and lean into variability. Here’s how:

• Reframed variability as a strength! Started thinking about where inconsistency would be delightful, and create a more engaging experience. When that’s paired with transparency for the user, it can feel magical. Variability is human.

• Identified where an LLM is just simply the wrong tool — When a use case or JTBD demands accuracy or consistency, lean on good old fashioned architecture or systems design. Often with AI, less is more.

This shift in mindset opens up some wild possibilities. By embracing variability, we can create more dynamic, personalized experiences that adapt to user needs and contexts. It also presents a challenge around designing systems that can handle a range of outputs while still honoring accuracy. The key is to find the sweet spot between leveraging AI's creative potential and maintaining a coherent user experience. And that starts with the user’s job to be done.

👉 Try: Turn the perceived bug (variability) into a strength for your product experience for users —

• Set clear expectations. Communicate that AI outputs may vary, leading to personalized solutions.

• Implement feedback loops. Allow users to rate and grade AI outputs for continuous improvement.

• Prioritize trust. Even early adopters are skeptical right now. Build your experience around trust (accuracy + relevance + transparency).

3. Rethinking Research and UX

If you were working in Product around 2010 or so, this feels like the start of the mobile wave: A new technology unlocked a whole world where end users were still learning, UX patterns were not codified, and teams had to rapidly adapt.

This time, it’s designing for AI-first experiences, and it’s all about how humans and AI collaborate. It’s largely conversational because dialogue is where collaboration happens.

Think back to previous products and features you’ve built — How have you gotten early stage, evaluative feedback from users? Often, the choice is between designing a mocked up flow vs building a quick version. While there are always huge benefits to the latter, former is usually faster and cheaper.

But when you’re building with LLMs, how do you put together evaluative research when the product experience is intrinsically variable and the AI-first UX is conversational? 🤯

And, as you know, speed and cost aren’t the only considerations when it comes to reducing risk in what you build. You often need to be testing feasibility in the same breath.

Throughout our feedback loops on this new product, I found myself going back in time to the challenges that we faced during my time working on HipChat at Atlassian (ancient history, back in 2014!) — evaluative research in a chat-based experience that’s dependent on a UX that moves, breathes, interacts. Funny enough, ten years later and I’m pulling from those same learnings in different ways.

So — How do you test a product that talks back? In the words of our Researcher, Chelsea Davis:

Conversational AI is about researching how people communicate. Everyone communicates and searches for information differently. You’re after the question behind the question, then take that and give the product the context and framing it needs to get to the result sooner for the user, reducing friction. And it starts anticipating what the user needs. You have to be a student of human communication.

As a result, we’ve chosen mocked up flows only sparingly and only for specific, nuanced interaction testing or research that’s so early it feels more generative than evaluative. More than not, we’ve opted to simply build because:

• Presenting users with a pre-defined, ideal workflow mockup introduces zero variability and doesn’t allow for the user interaction or conversation, which means we miss powerful insights.

• Feasibility in the context of “how might we” has been just as important, since we’re working with new technology.

• Iterating is fast, and we have the right team that can move with speed for the sake of the user.

By building and giving the user a set of crayons paired with hints, we have learned much faster. Use little nudges, wayfinders, example prompts, suggestions, or setting the stage with phrases like, “Let’s pretend it’s Tuesday before your Engineering Meeting…” to help the user pick up the crayons.

The goal is to understand the types of questions your users have, and then anticipate the action the agent should be taking for that JTBD.

👉 Tip: Take a step and learn some of the UX patterns that are emerging on sites like Shape of AI. Create a basic UI and have a team member act as the AI, responding to user inputs in real-time. This approach allows you to simulate variability, test conversational flows, and gather rich qualitative feedback without the need for a fully functional AI system. Check out Wizard of Oz testing.

Here are a few things that we watch for in testing:

• How people communicate directly with the LLM — how they type, what context do they assume the tool has, etc.

• How people react with their body language when the LLM assumes incorrectly — do they try again? Use different words? All of those reactions go back into training.

• How people build trust in an LLM — What types of accuracy, relevancy, and transparency play out in the user experience? Do trust symbols like references get old message after message?

Just Do It

Every single day during this process has brought a new wave of learnings, and challenged how I work as a product person. Honestly, it’s revealed a pure form of the product process: JTBD + Editing. It’s channeled the core competencies — adapting, prioritizing, empathizing — but in new ways!

A call to action specifically for senior product leaders: Learning by doing is simply the best. There is no substitute for diving in and doing the work. And, while I don’t know where AI will be in five years, I do know that what we have now is not all it will be. Now is the time to lean in. You cannot learn by watching or directing your team. You must do to learn. It’s moving too quickly. 🚀

Bottom line: Traditional product development methods need significant reimagining for AI products, with emphasis on prompt engineering, accepting AI's variable nature, and adapting user research for conversational interfaces.​​​​​​​​​​​​​​​​ Ironically, it feels like a more pure form of product, pulling mightily on JTBD!

Check out Graph

This is for the early-stage startup CEO or CTO who has 1-3 PMs: You need something to create shared understanding of expectations, but you don’t have a deep PM background, and you’re trying to move fast.

At the early stages — think seed stage or series A with a startup of 10-50 people — execution and speed matter more than process perfection or even long-term career clarity. Your energy is better spent removing obstacles and leading the company than crafting complex frameworks.

Honestly, we've overcomplicated what makes a great product manager anyway.

I know because I've written and rewritten PM competency frameworks for years. With each iteration, I suspect that I added more than I deleted in the name of "clarity." Looking back, that extra content didn't always help the product team — and it certainly took up my time.

After getting back into early-stage startups last year with some advising work and then joining LaunchNotes, I laid out each of the PM competency matrices I've developed over the years and boiled them down into what matters, specifically at an early-stage startup.

What follows is a lightweight system with examples you can customize to guide your growing product team at this stage. No bells, no whistles.

👉 Simple by design: Three measures (Scope, Influence, Consistency) across four practice areas (Execution & Agency, Communication, Insights & Empathy, Strategic Thinking).

How to use this framework

Think of this is a conversation starter for your PM(s), not a checklist. What to do:

1. Start (15 minutes)

   1. Copy the practice areas into your wiki as “PM Excellence” or “PM Expectations”

   2. Adapt the content based on your stage and situation

   3. Highlight the practice areas that are most critical for your company and stage

2. Align (30 minutes)

   1. Walk through the practice areas together (If only one PM, in a 1-1; if more than one PM, in a group then additionally in 1-1s)

   2. Discuss what “good” looks like; get their feedback and thoughts

   3. Agree on a focus area for the next quarter

3. Ship

   1. Use this new shared language to structure 1-1s

   2. Reference specific examples when giving feedback

   3. Revisit every quarter to check on progress and adjust

Measuring Impact

Progress for the PM is measured through impact:

• Scope: Are they handling increasingly complex problems and larger surface areas? Hungry for more? A junior PM might own a feature; a principal PM shapes entire product categories.

• Influence: How effectively are they driving outcomes without direct authority and resolving conflicts before they reach you? Influence is the essence of product management.

• Consistency: Are they reliably delivering value, sprint after sprint, quarter after quarter? Handling increasing pressure, and providing early warning when things might slip? Spikes and sprints fade; consistency is what sets the best apart.

Practice Areas

The product craft is about value creation: Balancing art and science to attack the right problem, at the right time, for the right customer. Everything flows from there.

🏃1) Execution & Agency

At early-stage startups, execution is everything — survival and growth is all that matters. Great PMs build and ship just enough to validate assumptions and unlock the next stage, making swift decisions with incomplete data while keeping the team focused and aligned.

Measuring impact:

• Scope: Moving from owning single-feature delivery to orchestrating multi-quarter initiatives

• Influence: Evolving from following established processes to setting ambitious milestones that teams rally behind

• Consistency: Delivering predictable results while maintaining speed and quality

Signs they're ready for more:

• Ships ahead of schedule while maintaining quality and team morale

• Proactively identifies and tackles adjacent problems outside their scope

• Creates reusable processes that other PMs can follow

• Manages multiple complex initiatives simultaneously without dropping balls

• Makes and defends difficult trade-off decisions with minimal guidance

  <!--An example to build on-->
  
  **EXECUTION & AGENCY**
  
  **Getting it done looks like:**
  
  • Finding a way, especially with constrained resources
  • Making rapid scope tradeoffs that keep velocity high while managing technical debt
  • Converting uncertain market opportunities into small shippable bets that validate direction
  • Setting ambitious milestones and goals
  
  **Anti-Patterns**
  
  • Perfect over progress: Perfecting specs instead of shipping to learn
  • Analysis paralysis: Waiting for complete data in an early-stage environment
  • Scope creep: Adding "nice-to-haves" that delay critical learning

🎙️ 2) Communication

There are enough risks in a fast-moving startup, but miscommunication kills momentum faster than anything — and it’s a risk you can actually control. Your PM needs to cut through chaos with clear priorities, unite the team around critical decisions, and ensure everyone knows exactly what to build and why.

Measuring impact:

• Scope: Progressing from clear product briefs to compelling product vision documents

• Influence: Growing from status updates to strategic narratives that drive organizational alignment

• Consistency: Maintaining a steady drumbeat of clear, purposeful communication across all the company

Signs they’re ready for more:

• Other teams proactively seek their input on communications and processes

• Successfully drives alignment across functions during challenging pivots

• Creates frameworks for communication that others adopt

• Resolves cross-functional conflicts before they escalate

• Effectively tailors complex messages for different audiences without guidance

  <!--An example to build on-->
  
  **COMMUNICATION**
  
  **Creating shared understanding looks like:**
  
  • Keeping the company aligned during rapid pivots and direction changes
  • Developing lightweight processes without slowing things down
  • Translating complex, muddy customer problems into clear, actionable MVPs and specs
  • Employing different techniques based on the audience to build trust and drive clarity
  
  *Anti-Patterns**
  
  • Over-process: Creating heavyweight processes that slow down the team
  • Meeting overload: Substituting meetings for clear written communication
  • Vertical only: Communicating up to leadership but not across to peers
  

📊 3) Insights & Empathy

Early-stage success hinges on finding product-market fit. Strong PMs rapidly collect customer signals, translate them into testable hypotheses, and help the team learn just enough to make the next meaningful decision.

Measuring impact:

• Scope: Advancing from feature-level user research to market-level opportunity synthesis

• Influence: Developing from data reporting to insight-driven decision making that shapes strategy

• Consistency: Building repeatable processes for customer feedback and data-driven validation

Signs they’re ready for more:

• Identifies market patterns before they become obvious to others

• Builds and validates hypotheses with creative, scrappy research methods

• Creates scalable systems for gathering and synthesizing customer insights

• Influences product strategy through strong, data-backed narratives

• Consistently predicts customer needs before they're explicitly stated

<!--An example to build on-->

**INSIGHTS & EMPATHY**

**Digging for signal and synthesizing looks like:**

• Finding creative ways to get customer feedback when you don’t have many customers yet
• Building conviction and anchoring decisions with very limited information and data
• Shipping with metrics of success, and looping back to measure if it was the right call
• Shepherding the customer problem — deep empathy with the user to nail the core use case(s)

**Anti-Patterns**

• Surface level: Collecting but not synthesizing customer feedback
• Data worship: Waiting for statistical significance with small sample sizes (AKA “sandblasting the soup cracker”)
• Solution jumping: Falling in love with solutions before validating problems

🧭 4) Strategic Thinking

Strategy at early stages is about focus and speed — making choices. The best startup PMs work with you as the leader to identify the few critical bets that matter now, translate them into concrete next steps, and keep the team laser-focused on what will unlock the next stage of growth.

Measuring impact:

• Scope: Expanding from sprint plans to quarterly roadmaps to multi-year product vision

• Influence: Moving from executing strategy to shaping it through strong opinions and clear rationale

• Consistency: Regularly connecting business objectives to customer problems in ways that galvanize teams

Signs they’re ready for more:

• Consistently connects daily decisions to longer-term founder vision

• Proactively identifies strategic risks and opportunities

• Influences company strategy beyond their immediate product area

• Successfully advocates for and leads strategic pivots when needed

• Builds compelling business cases that give you, the leader, options

<!--An example to build on-->

**STRATEGIC THINKING**

**Making specific choices that connect business goals to customer problems looks like:**

• Turning founder vision into concrete experiments that validate direction
• Balancing quick wins and strategic bets that could transform the business
• Making hard trade-off decisions that concentrate resources on next-stage growth
• Prioritizing customer segments and ICPs based on data and gut

**Anti-Patterns**

• Short-term only: Focusing solely on immediate wins without connecting to larger vision
• All vision: Big ideas, big talk, no concrete next steps
• Narrow view: Optimizing for one metric at the expense of company growth

Scaling Up

When This Framework Needs to Evolve

How will you know if you need more than this simple framework? When you notice:

• PMs struggling to understand growth opportunities

• Inconsistent expectations across managers

• Difficulty in compensation or promotion decisions

• Need for specialized PM roles or tracks

This framework works best for teams of 1-3 PMs. As you scale beyond that with company growth, you'll likely need to add:

1. Structured Career Paths: Defining clear differences between Senior, Lead, and Principal roles and ideally support dual-track career tracks (People Leadership track)

2. Specialized Tracks: Separating platform, growth, or core product competencies

3. Formal Reviews: More structured performance evaluation processes

4. Documentation: Written expectations and examples for each level

But don't rush to add complexity. This simple framework can scale surprisingly well if you trust your PM(s) to own their development within the framework, and keep a few conversations per quarter at an altitude that focuses on impact rather than just output and driving work.

A few resources:

• Petra Willie’s PM Wheel

• GitLab Product Management

• Ravi Mehta’s What’s Your Shape

• Intercom’s PM Expectations by Level

Bottom line: If you're a CEO or CTO at an early-stage startup drowning in frameworks while trying to guide your small PM team, keep it simple. At the early stages, execution and speed matter more than process perfection. Use this, customize it, and keep shipping!

Remember why you hired PMs in the first place: To help you move faster and create impact. Don't let the tools get in the way of the work.

E.L. Doctorow said once said that 'Writing a novel is like driving a car at night. You can see only as far as your headlights, but you can make the whole trip that way.' …You just have to see two or three feet ahead of you...
Anne Lamott, Bird by Bird

Especially in today's market, take it one turn at a time.

Like product development itself, clarity on career growth requires reflection — internal and external signal — that turns into action.

That clarity helps you recognize the right opportunities when they appear, and it guides your development in your current role. As a result, your self-awareness — perhaps the most valuable PM characteristic — will come across loud and clear in career conversations.

This is the framework I’ve used for my own career, and also while coaching PMs. There are five dimensions of reflection, each with question prompts and a “balance check” to help guard against excessive introspection (i.e. The Reflection Trap). If you’re serious about this, challenge yourself to write your reflections using the canvas worksheet, because crisp writing is evidence of clear thinking.

The Career Canvas: Five Dimensions of Reflection

1. Energy Drivers

Where do you find your flow?

Key reflection questions:

• What were the three moments over the past year when you lost track of time because you were so absorbed in the work?

• Which meetings do you look forward to, and which do you dread? Why?

• When peers seek your input, what types of problems do they bring to you?

• What type of work makes you want to immediately open your laptop and dive in?

• If you could spend 80% of your time on one aspect of product management, what would it be?

Balance Check: Avoid the reflection trap by focusing on observable moments and concrete situations, not just feelings. Energy patterns reveal themselves through impact and outcomes, not just internal reflection.

2. Environmental Fit

What conditions unlock your best work?

Key reflection questions:

• In your highest-performing periods, what was unique about the team structure or dynamics?

• What's the hardest feedback you've received about your working style? What environment is necessary to lean in and go to work on that?

• Think of your best manager—what specific behaviors made them effective for you?

• What level of structure vs. chaos brings out your best thinking?

• How do you prefer to receive recognition for your work?

Balance Check: These reflections must be grounded in your real experiences and feedback, not theoretical preferences. Your environment shapes your performance in ways others can often see more clearly than you can.

3. Impact Scope

Where do you want your influence to be felt?

Key reflection questions:

• What's the most meaningful impact you've had in your career so far? Why?

• When you look back in three years, what do you want to say you helped build or change?

• What scale of problem energizes you — from specific individual user pain points to industry-wide challenges?

• Which matters more to you: depth of impact on a focused area, or breadth of influence across many areas?

• What type of metrics excite you? (e.g. user engagement, revenue growth, etc)

Balance Check: Impact isn't just what you think you achieved — it's what others experienced. Your reflection should incorporate both your intentions and your actual influence on teams and users.

4. Craft Focus

Which aspects of product craft light you up?

Key reflection questions:

• In which situations do peers or team members most often seek your guidance?

• What product decisions come naturally to you versus requiring conscious effort?

• Where in the product process do you find yourself wanting to dive deeper?

• What skills are you actively building that excite you?

• What type of problems do you solve differently than other PMs you know?

Balance Check: Strong product craft emerges from both inner aptitude and market validation. Pay attention not just to what you enjoy, but where your work consistently creates value. Your strongest skills often live where your interests intersect with what others seek from you.

5. Growth Velocity

How are you accelerating your learning?

Key reflection questions:

• What feedback have you received in the last six months but haven't addressed?

• What skills gap makes you most uncomfortable in your current role?

• Which aspects of product management still feel like a mystery to you?

• What's the biggest risk you've taken recently to grow your skills?

• What would make you feel more confident in your next career conversation?

Balance Check: Learning happens in the space between reflection and action. Don't mistake learning about something for actually developing the skill. Look for evidence of growth in your work outcomes and others' changing perception of your capabilities, not just in your own assessment.

Getting External Signal: Becoming a Feedback Magnet

The Reflection Trap is endless, excessive introspection — overthinking past decisions without learning from them, or focusing on feelings while ignoring impact. The “balance check” in each section above helps guard against this trap.

First Round’s excellent becoming a feedback magnet is a must-read. Strong self-awareness comes from combining reflection with external feedback.

Make it easier for those around you to give you feedback. Reflection without external input is incomplete and often misleading. Here's how to ensure your self-awareness is grounded in reality:

Create micro-feedback opportunities

• Schedule skip-level 1:1s with key stakeholders

• Ask other PMs to join your customer calls

• Volunteer to present at team meetings

• Share your work-in-progress thinking

Ask specific questions

• "When was the last time you saw me really excited?"

• "How could I have handled that question differently?"

• "How would you describe my working style to someone else?”

• "When have I gotten in the way, instead of helping accelerate?"

Share Words on Product

Turning Reflection into Action

Each insight should drive clarity that results in action — an experiment, a conversation, a decision.

Write a conclusion — Synthesize the insights

Take what you’ve written down across the five dimensions and synthesize. (Do the product work!) What patterns emerge? What types of businesses, stages of companies, teams might be a good fit?

Then:

Document your patterns

• Keep a "wins" document to track successful moments

• Note which types of work consistently energize you

• Record feedback themes you hear repeatedly

• Track what you learn about your working style

Create growth experiments

• Volunteer for projects that stretch you in areas you want to develop

• Seek out mentors who excel in your growth areas

• Say “Yes” — try it all

• Start side projects to build specific skills

Build your opportunity radar

• Share your learning goals with your leader

• Network with PMs; join communities like Lenny’s

• Follow companies solving problems you care about

• Stay connected with past colleagues who know your strengths

Making Decisions

Remember: The goal isn't perfect self-knowledge — it's to generate enough clarity to act with intention. Like product development, career growth is iterative. Each move is an opportunity to learn, adjust, and grow stronger in your understanding of yourself and your impact.

When opportunities arise, evaluate them against your reflection across those five dimensions:

• Does this role play to my energy drivers?

• Will this environment enable my best work?

• Does the impact scope align with what motivates me?

• Can I apply my craft strengths while growing in areas that interest me?

• Will this accelerate my learning and growth velocity in meaningful ways?

The best product leaders aren't planning every step — they're developing deep self-awareness and recognizing the right moments to grow or pivot. Start building that awareness now, whether you're searching for your next role or maximizing impact where you are. Know yourself, know your move!

And because of how competitive it is out there now, I’ve talked with many seasoned product managers who are looking for their next opportunity for the first time in a few years — overwhelmed with prep, buried in blog posts, anxiously rehearsing responses. “How have PM interviews changed?” “What types of case studies are in now?”

Listen product friends, while much has changed over the past few years — technology, the market, even the role — consider this a reminder that the fundamentals remain:

This is not “How to pass a PM interview at Meta.”

This is me opening up my playbook and sharing the rough scaffolding I’ve used to build the interview processes at companies of all sorts — mature companies like Atlassian and H-E-B, growth companies like FullStory, and even seed-stage while advising the team at Enterpret.

While the details change, the themes have been consistent. Use this to get anchored in the eternal truths of product interviewing.

Tell your builder story.

Product Interview Themes

Theme: Product Leadership

Focus: Curiosity, goal setting, strategy, pricing, vision casting, empathy.

Questions in this theme lean towards the philosophical, backed up by tactical examples. I’m expecting to learn the candidate’s POV on product. The process they use to author and influence strategy. How they think about the DNA of great products. And most of all, how effective they can communicate it all.

You might get questions like:

• What are the three most important characteristics of a product manager? (Which one are you strongest in?)

• What’s the most fascinating thing you’ve learned from a customer?

• How would you describe bad product strategy?

• How would you go about sizing up the total market for our product?

• Describe your current product strategy and how that strategy came to be.

• What’s the most delightful customer experience you’ve had lately?

• You can only ship one thing this year. What’s your process?

• Describe a time when you had to make a counterintuitive product decision. What was your reasoning?

• Tell me about a time you failed to lead the way you should have.

• What's your method for quickly validating new ideas?

With many of the more theoretical questions — like “Size our total market” — the most productive dialogue occurs when the candidate worries less about an accurate answer, and instead focuses on their thought process, the series of steps they would try to get an answer, and what they’ve done in the past (and how those steps might be different in another environment).

With many of the more practical questions — especially questions around their current strategy and product vision, like “Describe your current product strategy” — the path to success is (unsurprisingly) through crisp, clear communication. The best conversations occur when the candidate is efficient at helping me understand their business, challenges, priorities, and ultimately, how they’ve created shared understanding amongst teams towards a common goal.

Conversely, a rambling regurgitation of words disguised as “strategy” tell me two things: The candidate’s perception of strategy and the candidate’s level of communication maturity are both insufficient.

A few memorable exchanges with candidates:

• A candidate described bad product strategy as “spending a ton of time writing words that don’t help anyone do anything differently.” Agree! A good start! We went on to unpack the candidate’s role in their company’s strategy drafting process (which, as it turned out, was relatively passive). And, this is where the red flag went up: This candidate was unable to articulate any action they took to help remedy the problems they were so eager to diagnose, nor did they have a sense of what “good” looked like. They inherited what they considered bad strategy, and took few steps beyond complaining and judging. It’s easy to criticize from the sidelines, especially when it comes to product leadership.

• Great product people love talking about great product experiences. A candidate shared a story about a delightful experience from an exchange with the customer service team at Patagonia. The candidate was set to go on a trip when they realized their bag strap was broken. Patagonia didn’t make the bag anymore, but on a whim, the candidate reached out to Patagonia. What happened? New strap in two days! Unexpected, pure delight that’s led to continued customer loyalty. Strong lessons to apply to product: Customer service is the product. Deliver the unexpected.

Theme: Product Execution

Focus: Prioritization, planning, creativity, analysis, discovery, decision making, shipping, go-to-market, operating like a founder.

Questions here complement the section above — they are practical, tactical, and deep to understand what the candidate has done and why. The best strategy is nothing without brilliant execution.

Historically, I’ve found the most rich dialogue kicks off with just a single question:

• Pick a recent [product, feature, service, app] that you shipped. I’d like to go super deep — walk me through it, from start to finish.

Throughout that conversation, I expect to learn how the candidate:

• Aligned teams around a shared goal

• Connected the team with the customer

• Validated or experimented towards a V1

• Balanced driving the team vs burning them out

• Determined when to ignore the data

• Communicated progress vertically and horizontally

• Handled blockers and made the hard calls

• Measured success, ultimately to continue to invest vs divest

Pick a good example! The candidate needs to tell a story about a meaningful arc of work where they played a significant role that’s ripe with specific actions and outcomes.

1. Specificity matters. Get into the details, and use the Minto principle for a progressive conversation. “I wrote a user research plan” VS “Based on the riskiest assumptions for V1, I wrote a set of learning goals and partnered with Research to write a script that mapped to those learning goals to unlock our MVP. Would you like a few examples?”

2. Leave the team behind. In this moment, it’s all about the candidate and the impact they made through their actions. When I hear “we” did something, 100% of the time, I will interrupt with, “and what specifically was your role in that?” I admire the team mentality, but in this context, it dilutes the message.

3. Perfect projects don’t exist. At a minimum, projects always involve people — teammates and customers — and people aren’t perfect! Stories where everything goes perfectly = red flag. The job is adapting and overcoming, so tell that story.

4. Spurs or reins? I heard this saying from a friend recently, and it resonated. One of the focus areas mentioned above is, “operating like a founder,” which means to move with speed and ownership when it comes to product execution, from start to finish. If anything, the high agency product person might need reins, but never spurs.

Theme: Collaboration

Focus: Humility, design intuition, technical skills, conflict management, accountability.

This often is when the candidate might meet the extended team, like a UX and Eng Lead. The conversation here is geared towards understanding how the candidate works within a team, how they engage with other crafts, and their level of competence across those crafts.

You might get questions like:

• Engineers say your idea is impossible. Now what?

• When is consensus “good?”

• How technical does a PM need to be?

• What are you unwilling to tolerate from teammates?

• Can you share a bit about the tech stack your team is working across right now?

• Share an example of a time when you adapted your communication style to different audiences.

• Tell me about a teammate who you thought was challenging to work with. What would that teammate say about you?

• How do you know when a project is going off the rails? How do you get it back on track?

• Tell me about a time when you missed a deadline, and how you rallied the team.

• What products do you see taking a big swing around user experience?

The most successful conversations in this realm paint a picture of a product person who can listen with an open mind, lead with conviction, and prioritize the endless list of priorities with pragmatism and transparency.

High caliber PMs are, at a minimum, able to speak with authority on the tech stack and design decisions in their current role, as it relates to the customer or priorities that led to those decisions.

The questions and emphasis here varies widely across companies and roles.

Theme: Motivation & Self-Awareness

This theme might be woven throughout earlier sessions. The aim is to get an understanding of the candidate’s goals and gauge their self-awareness — easily one of the most crucial ingredients of a successful product person.

You might get questions like:

• What are you solving for in your next move?

• Looking back at the last 6 months, what are you most proud of?

• How do you go about gathering constructive feedback from teammates?

• Tell me about a time that you were asked to lead an arc of work that didn’t make sense.

• If you could reshape your current/last role, what would you change?

• What’s a common misconception your team might have about you professionally?

• What’s one thing you’ve learned about yourself at your current company?

• What’s the hardest piece of feedback you received? Why? What did you do?

• Describe a time that you had to advocate for an unpopular but necessary decision.

• What’s your biggest concern about this opportunity?

If there is a section to really invest in mock interviews, this is it.

I had the privilege of working with the great communication coach Nancy Graves many years ago. One of the many tools she’s emphasizes is “verbal drafting,” which is the practice of getting reps in out loud, rather than just thinking through a response. I do this constantly, and it’s become a habit. Get a few reps in out loud (maybe recorded, or with someone else), fine tune, edit, repeat. And then muscle memory kicks in during the actual interview. A particularly helpful tactic here because these questions all revolve around things the candidate knows already (rather than hypotheticals) — why they’re looking, their motivations, and how they’ve grown.

Wrapping Up

Challenges and Case Studies

I’ve done everything from writing exercises to live case studies. From what I can tell, companies are still all over the map here. Regardless of the specific exercise, showcase your process and how you think on your toes; worry less about getting it “right.”

And then get curious: What does their process tell you about the company?

Ask Hard Questions

Lastly — Please ask hard questions. Be ready! There’s nothing more baffling than a candidate who has no questions. It’s a part of the interview. A product person who isn’t curious has no business solving customer problems.

Thank you for reading. My hope is that this helps to spark some ideas on how you might shape your story.

Anchor in the fundamentals: Great product people think deeply, execute quickly, and communicate clearly.

Good luck. ✌️

As product managers, we often find ourselves caught in a delicate tug-of-war between focusing on our customers and keeping an eye on the competition.

This was crystallized for me a few years ago after a roadmap session, when an engineering leader posed a question that stopped me in my tracks: “Do we spend too much time talking about competitors?” This sparked reflection on my part; I needed to do some diagnosis and examine how much I was letting the competitive landscape drive my decision making.

As the famous Flannery O’Connor quote says, “I write because I don’t know what I think until I read what I say.”

With a few years of life behind me since I got that question, and through the clarity that writing provides, read on for lessons from the trenches — Principles and real life learnings on how to think about the competition.

1. Stay closer to your customers than your competitors

Because your toughest “competitor” is often just pen, paper, and process.

Before any deep conversation on competitors, it must be said out loud: For every glance towards a competitor, take two towards your customer.

When you do, you’ll often find your customers spend exponentially less time thinking about your product and competitors than you do — Typically, customers are just trying to get through their day with whatever tool works best. Refreshing dose of humility. 😉

As a product person, especially in SaaS, your competitor set is incomplete without alternatives. It’s easy to get myopic about the latest fundraise or press release. In most cases, the majority of the market is using the proverbial spreadsheet though — not the latest SaaS product.

When I co-founded a startup in the home remodeling market, we spent significantly more time studying the whiteboards in the contractors’ offices and riding with them in their trucks to job sites, than obsessing over (who we thought were) competitors. We built our apps around their human processes.

Particularly around the pre-MVP and pre-product market fit stage, don’t waste your energy on who you think might be a competitor (it will change ten times as you pivot towards PMF fit anyway); you’ll win by being a student of the problem and spending those calories on your future customers. As you sort product market fit, your competitor set will become more clear and you’ll need to address that — but earn your way there through the customer problem in that early stage, first.

2. Find Your Anchor in Crisis

Write down your product strategy. Share it often. Revisit the reasoning. Change when necessary.

The Mike Tyson quote is fitting: “Everybody has a plan until they get punched in the face.”

Have you been in situations where it’s felt like a punch…after punch after punch? Stress and anxiety grow with every lost sale or competitor announcement. Finger pointing, charged questions, and your conviction wanes.

Breathe. These are the moments where memories are short and emotions are high. Lean in. You must revisit The Why: The product strategy, which describes the path ahead. It should instill you and your team with calm confidence.

At sea, an anchor serves as stability. It prevents drift. And, an anchor isn’t permanent.

Therein lies the beauty of product leadership: Steadfast conviction anchored in sound strategy, blended with instinctual discernment to know when it’s time to pick up the anchor and change course. The former should be your default; the latter is an option that must be used smartly and sparingly — you have limited chances to change direction without your team losing trust.

Rewind all the way back to 2014. I had joined Atlassian and was focused on HipChat, the OG of workplace collaboration and chat.

During my time there, we witnessed a massive rise in competition. Chat was the battleground — Microsoft, Slack, Cisco, and loads of smaller players were all fighting for knowledge workers. Full page ads and billboards everywhere.

As we started on our journey to launch a new collaboration product, Stride, we stayed anchored in our strategy and our take on differentiation in a claustrophobic market:

1. A deep understanding of team workflows — discuss, decide, act

2. Video communication — nuances like raising your hand and seamlessly moving from chat to video

3. Focus mode — get back to actual work

4. The power and breadth of the Atlassian ecosystem

Our purpose and strategy was clear, which let the team focus on execution.

3. Stop Ruminating, Do Something

Funnel emotional reactions into productive strategic thinking.

Especially if you are in crisis mode, even the most measured, objective competitor observations can devolve into obsessive speculation — That’s when you land in dread (“They’re going to crush us!”), or envy (“Why didn’t we ship that?”), or even prideful dismissiveness (“That’s garbage — We’re better.”). All emotional reactions, all potentially quite dangerous.

Depending on your company stage, spend just enough time to get objective, measured awareness, and then find a productive outlet to take action, when necessary. Stop ruminating; Do something.

During my time at H-E-B (a $38B retailer and the best grocery store in the world), the leadership team set time aside each year for an exercise called “War Games.” It was a structured, proactive exercise that allowed us to think creatively and examine our strategy through different lenses by role playing across the market and competitive landscape. I don’t recommend an early stage SaaS company invests like this, but for a very mature retailer in highly competitive geographical markets operating on thin margins, it was time well spent. Lessons learned during those exercises were often referred to, and there was a playbook in place when competitors made moves.

4. Share with Context

Don’t be lazy; share news with your take.

In my early years as a PM, I’m a bit ashamed to admit that I was often guilty of racing to be the first to share a juicy press release about a competitor. Embarrassingly, I would share with no context, no hot take — just wanted to be the first to stir the pot. 🤦‍♂️

There’s no prize for First Person To Share Big News. The job as a product person is to synthesize, distill, and focus on signal — not create more noise.

Such a simple thing, but now, I never share a link without some framing and bulleted takeaways. Why?

1. It forces me to really crystalize how I think about the content — crisp writing is evident of clear thinking! I don’t want to share anything I have not digested and have at least half-formed thoughts opinions on — don’t be lazy; read it, have a take, and share it to open up dialogue.

2. And it helps my team understand how they should be thinking about it and keeps reactions and emotions within bumper lanes, rather than wandering into extreme dismissiveness or even depression.

5. UX Opportunities — Copycat vs Contrarian

As you examine competitors, discern UX opportunities to strategically align or boldly diverge.

Imagine a customer switching to your product from a competitor — Familiarity breeds comfort and unlocks quicker time to value, while uniqueness drives loyalty.

What should feel familiar and comfortable? What should feel unique? Your new customer might have a mental model; craft your experience with that context, strategically aligning where it makes sense.

During my time at FullStory, we invested heavily in expanding into product analytics — a very crowded and understood market. As our teams did discovery, one of the considerations was feature names. Things like “Heatmaps,” “Dashboards,” “Funnels,” “Retention Charting” were all relatively understood by the market, and we wanted to optimize time to value as new and existing customers expanded their usage of FullStory into the quantitative. We largely chose to align with standard words, while putting more mental calories into the unique execution of those features.

For your customer: What should feel unique and bold? Spend time leaning into impactful differentiation opportunities around UX, copy, and putting a unique twist on your product experience. The goal isn't to be different for the sake of being different, but to solve user problems in a familiar, yet unique way.

6. Positioning and Pricing Strategy

Map the landscape through the eyes of your customer.

Lastly — For growth-stage or mature SaaS products, you have a new challenge around positioning, pricing, and product strategy, and the competitor landscape plays a role.

Unfortunately, your more thorough analysis is only as good as your customer’s perception. Meaning, you’ll might find that the perfect quadrants in your slide deck don’t map to how a real human thinks!

Your own analysis of the space might be different than how a customer talks about it. Go listen. Ask them how they would describe your product to a co-worker, or what alternatives they were considering before using your product. Does the customer’s perception of the your competitors match your own?

Then, understand how customers perceive your product's value relative to competitors. Minimally, get clarity on what customers are paying and how they’re buying the product (sales-led, community-led, etc). Use this insight to craft pricing tiers and feature bundles that clearly communicate your unique value proposition. Remember, your goal isn't just to compete on price, but to create a compelling narrative about why your product is worth what you're charging — and for whom.

Go buy April Dunford’s book “Obviously Awesome,” and read her newsletter. Don’t stop reading until you have a strong grasp on positioning and what that should mean to you as a product person in the context of competitors.

Bonus tip: If you have a product marketing team, it goes without saying: Collaborate!

Bottom line: Depending on your product’s stage, take regular, objective glances to understand how a customer perceives your product to help guide your product strategy.

This communication superpower is born from empathy — understanding what their leaders and teams need, then editing and tailoring their message to get to the intended outcome.

Two of my favorite strategies — framing for focus and starting with the end — together pack a powerful punch. Level up by practicing these simple techniques in your next meeting.

1. Frame for Focus

The photographer composes their shot by framing: Showing the relationship between objects, highlighting the subject, and subtracting the unnecessary.

This is how the most effective product managers approach communication. Drawing the eye and ear in specific ways to influence how the information is processed. That first few minutes is your time to hold the camera up and bring the subject into clear focus.

Assuming everyone has the same shared understanding is the fastest way to torpedo your dialogue and drown your message. Your first job? Get everyone up to the same starting line in less than 60 seconds: Send a pre-read, rewind and remind, and help your audience understand where they should focus.

You’ll know this is an opportunity for you if you tend to get interrupted with questions like, “Uh, could we back up?” or “Before we get too far, remind me…”

• Stop assuming everyone is at the same starting line as you are. Remind yourself that you have thought about your topic more than anyone else. Often, the product manager forgets this and blazes ahead, leaving everyone confused.

• Start putting the most preparation into your first 60 seconds. Distill your message into succinct framing. This should feel hard. Because editing is hard. In 3-4 sentences, ground the dialogue. I had the privilege of working with Nancy Graves years ago — an absolute game-changing experience — and she uses a three-part framework that starts with, “As you know,” to remind the audience where you left off, “Since then…” to highlight what’s changed since that last touchpoint, concluding with “As a result,” which is often the recommended next step. (Nancy is an incredible coach, and I highly recommend her! This shorthand framework barely scratches the surface.) The similar framework Situation, Complication, Resolution (SCR) is similar and worth a look.

2. Start with the End

Watching a movie is a ride through story — The characters, the setting, the conflict, rising action, the climax, and ultimately, the resolution. But let’s face it; you’re not selling tickets to a movie, you’re sending invites to a meeting: You’re borrowing expensive time to create shared understanding and alignment as quickly as possible.

The experienced product manager knows to start with the conclusion, and then work backwards.

This is called the Minto Principle (or Pyramid Principle). It’s counter-intuitive; product managers often want to present information in the same way that the research was done: Bottoms up — sharing the data, research, arguments — before finally unveiling the conclusion and recommendation (to a standing ovation 😉).

Invert it — your argument becomes more structured, logical, and persuasive:

Don’t misunderstand this to mean that context doesn’t matter — it does. Context is important, but the order of operations is more important. Force feeding context first (especially detailed, pedantic context) is a certain way to overwhelm your audience.

I recall working with a product manager a while ago who was struggling with self-confidence. As a logical defense, they often aimed to win trust by presenting a mountain of data before revealing the recommended next steps. Unfortunately, this tactic had the opposite effect and rarely resulted in clarity.

Contrary to what your inner imposter syndrome whispers, your audience wants to trust you. And nothing screams confidence more than leading with a powerful, succinct conclusion, then talking through the key arguments and supporting details.

You’ll know if this is an opportunity for you if your meetings tend to go in circles or you get questions like, “Thanks for all the work, but what’s the bottom line?” or “Where’s all this leading?”

• Stop wasting words building an argument. Your meeting isn’t a monologue…or a movie. You don’t need to take everyone through all the background, but you do need to have it available.

• Start with the headline, then walk through the key arguments and detail, if necessary. Dive deeper into Barbara Minto’s Pyramid Principle and learn how to structure logical, persuasive arguments.

🌟 Bonus Tips

• Brevity wins. You aren’t getting paid by the word. Edit, then edit again. Offer more detail on request. If you’re anxious or excited, it can feel like words are tumbling out and gathering speed — just pause. Say. Fewer. Words.

• Anticipate the need. The best product managers abide by the “no surprises” mentality. Which means they intuit when to escalate and pre-wire.

• Questions are good. Success is not when you get through everything you wanted to say. Don’t be threatened by questions — follow the curiosity. Help connect the dots between their goals and your message. That’s success.

• Ask for feedback. Immediately following a meeting, reach out and ask specific questions to measure your progress.

In many ways, these strategies speak to the core of Words on Product. Because the best product managers know that products are built and bought on words.

Those teams know how powerful curiosity is — and how easy it is to lose. If you don’t fight for curiosity, it disintegrates. Your best people leave and your product drifts.

Product is the art of disciplined, intentional curiosity.

Four Zones of Operation

Intentional curiosity comes into focus when placed in contrast to the other three zones: Apathy, Wondering, Myopia.

🤷🏻‍♀️ Apathy. Danger zone. Though easy to drift into — do the meetings, answer the emails, pull the data. Rinse, repeat. All the sudden, it’s been a while since you’ve talked with a customer or asked a question from the data. You stop caring about the customer and the product.

🤔 Wondering. Diving deep into random rabbit holes. Learning in spurts and sprints without a step towards action. Perhaps even taking pride in “learning for the sake of learning.” Endless cycles of wondering that leave the customer stranded. Curiosity must translate to clarity and direction. The magic is on the follow through.

🔬Myopia. And in the bottom right corner, the product manager myopically focused on shipping That Feature — strong sense of purpose. Never late. But not curious enough to think critically or ask questions.

🧐 Intentional curiosity. Choosing your questions with precision and pragmatism, and finding the right way to ask them. It’s lifting your eyes while executing with speed. It’s caring enough to ask, “Why?” and pivoting where necessary. It’s a motion, a feeling that’s honed with experience. Curiosity and action = Consistently delivering on the right problem, faster than the competition.

Where are you operating from right now?

Curiosity in the Lifecycle

A Product person might even move through a few zones within a single arc of work.

At the start of research/discovery, you’re on fire! You’re talking with customers, combing through data, sizing up the competition.

But as you move into validation and delivery, your aperture narrows and shifts, especially under pressure — just like a camera lens: You’re letting less (or different) light in. Your sense of curiosity wanes to make space for an increased focus on delivering, primed to increase the chances of delivering the wrong thing.

Curiosity Cocktail

Product People — So much of our job feels like we must know the answers. What’s in the sprint? What are the biggest bets for this quarter? How does this fit into the annual strategy? Where are we going and what’s our vision?

You become an action-oriented answering machine. It’s habit forming, and can cause you to go off course into Apathy, Wondering, or Myopia. Interrupt the cycle; it’s our job to fight for curiosity.

Thanks to the incredible work of João Reis, we can visualize this as:

For now, a few quick tips. Stay curious about your customer, your product, your craft:

• Trust is an unlock and an outcome of a culture of curiosity. It’s a loop that builds and builds. When you have a team that feels safe, their minds aren’t consumed with calculating the risks of asking a question. Giving voice to curiosity carries risk — how safe is it to ask questions in your org?

• Look at your product portfolio: What new learning might cause you to stop something mid-flight? What would it take to over-power the inertia?

• Teams need access. Is the data accessible, usable? How much friction is there is getting time with a customer?

• Struggling to care enough to be curious? It’s easy to blame your environment, your leader, your projects. But look inwards first: Find something related that you do care about, and connect it back for motivation. Connect what you’re working (which is important, but might not be interesting) to something that interests you. Does it help tell a story for your career? Learning a new slice of technology? This is a tool that’s often recommended to neurodiverse folks who operate more with an interest-based nervous system rather than an importance-based nervous system — useful for anyone to consider.

• For those of you who use your own product each day, what a double edged sword! So easy to become numb to the papercuts and gloss over the opportunities. Don’t let a week go by without talking to a customer for their perspective.

• Curiosity is contagious. And when it spreads, it creates a culture of curiosity. Make a note of the questions you’re asking individually and publicly. Fan the flame.

• At FullStory, we use a simple exercise called One Number. Each PM brings one piece of data to our team meeting. It helps ensure we’re constantly in the data, and always generates rich dialogue: Each insight sparks a flurry of questions, and curiosity takes over!

• Curiosity requires trust and humility. An empowered org where teams can ask questions and prioritize the answers based on clear frameworks and goals. How would your team rate trust?

• When asking questions, pair curiosity with context. “I’m curious: Where can I find more data on X? Context: Was talking with a customer yesterday and…” Disarming. Brings others along, rather than, “What’s the engagement data on that feature?”

• As you interview, know that the interviewer is paying attention to the questions you’re asking, too. Curiosity is a key characteristic of product managers. Showcase your curiosity by digging in to understand the customer, the business, and the team.

Above all: Product work is a joy! Stay curious, friends.

The CEO of a successful SaaS startup recently posed this question to me as we talked product strategy. What we were getting at: What is a moat, practically? Do moats even exist in this modern age of SaaS?

The first two examples that popped into my mind in that moment: Getting online thanks to AOL’s trial CD-ROM in the mail, and signing up for AT&T as the exclusive, initial provider of the iPhone. In both, brilliant distribution opened up an opportunity for value, stickiness, and other advantages at scale.

🫢 Pause for gasps as readers contemplate my age, given those examples.

The mythical moat: When startups mistakenly believe that by digging a ditch, they create an impenetrable, long-lasting defense. They toil and toil, until they realize they’ve lost focus on the customer.

“Moat” is best understood as shorthand for an ever-changing cocktail of unfair or competitive advantages that are costly to copy.

The Literal Moat

Rewind to medieval times when a moat was part of a system to defend the castle against an attack. Dig a ditch, fill it with water (and sewage). Attacking infantries were faced with an immediate obstacle!

Moats worked perfectly until the introduction of firearms and artillery. And then, just like that, the game changed.

AOL and Apple both knew that novel distribution was not enough, and both delivered on product experiences that offered substantial value, switching costs, and network effects (RIP AIM!).

The Figurative Moat

In modern SaaS, the idea of a moat — an immutable, impenetrable defense that forms a barrier of protection — is a myth:

No castle relied on one single defense mechanism. A moat was one tactic (archers, gatehouse, traps, curtain walls, etc). Similarly, the myth of the moat is that one will be sufficient — singular. This is rarely, if ever, the case.

No castle’s moat stood the test of time as the playing field evolved. A moat was useful only against specific attacks (like an infantry). Similarly, the myth of the moat is that an advantage is permanent. But technology, capital, talent, and expertise is readily available for competent, aggressive founders. The playing field changes too rapidly.

Instead, Do This

What is the SaaS startup to do?

Instead of obsessing over a single ditch, think of a “moat” as a cocktail that evolves over time: A set of things that, together, form a defense that is costly to copy. (Hint: This is the launchpad for your product strategy, too!)

1) What are your “moats,” current and aspirational?

Where do you have an advantage? Pick a main ingredient, and mix a cocktail (e.g. intellectual property, economies of scale, regulatory barriers, network effects, partnerships, brand, culture, price, and even cost). This is the ethos of the startup — the entire reason for being. This should be a simple, quick exercise. (If it takes longer than an hour, you might have a different problem.) Together, the sum should be costly for the competition to copy. No startup conquers the category on one moat.

2) Reinvent by asking “What if?”

Regularly reassess that cocktail and proactively “war game” scenarios (a practice we used often at H-E-B). What if the hungrier, scrappier startup creates better tech? What if the larger competitor picks off the main value prop and rolls it under their umbrella? What if….? Then strategically choose which moat to deepen and where to dig the next ditch(s). It’s a race to reinvent yourself before the competition takes your lunch.

3) Who cares?

Most importantly, does the customer care as much as you do about that moat? If not, either it’s not as unique as you think, or you have positioning work to do. (The name of the game here is value — not “moat” — anyway.) This demands that everyone across the company can repeat the exact same message.

The Most Powerful “Moats”

If you read only one thing here, especially for earlier stage startups: Don’t take your eye off the customer, and keep shipping. Solve a problem in a unique way that no one else has addressed. Put your customers at the center of your product development process. Continuously gather feedback and engage with customers to understand their pain, challenges, and preferences.

That creates a loyal customer who will take your product to their next company.

And that ditch digs itself. 🚀

Now, excuse me while I dig through my box of memories for that AOL CD…

And now, as we sit almost halfway through 2023, with SaaS businesses facing continued headwinds, that creativity — the ability to consistently think in new and different ways through tough decisions — is more valuable than ever.

Though, as I talk with product managers across SaaS, there is a gnawing acknowledgment of burnout. It’s palpable.

And first casualty of burnout? Creativity.

First Round’s Practical Frameworks for Beating Burnout:

Burnout is not just…'I'm too tired...' It's the inability to think creatively.

Burnout simmers. Almost imperceptibly over time, your field of vision narrows — your curiosity wanes: You stop searching for the gray and surrender to the binary. Your creativity dries up and it shows, particularly in decision making.

This is the moment for the best product managers to grab the bull by the horns — SaaS businesses need product teams to think differently if they want to emerge winners.

1. Shared understanding of creativity in Product

2. Why creativity is a need for SaaS businesses in this moment

3. How the best product managers can remain creative, particularly in their decision making.

What is Creativity?

“Wait. Creativity is for creative people. I’m a product manager, not a painter.” The product manager and the painter are not that different: Both cast vision, set strategy, then execute to deliver something people want.

Creativity is often dramatized as the fantastical output of the wild and brazen genius — the brilliant lone wolf who single-handedly introduces new, world-altering creations. That’s a caricature. And perpetuates the myth that creativity cannot be taught (I disagree).

Creativity is the ability to consistently think in new and different ways. Brushes, bytes, and product briefs — all demand creativity.

State of SaaS

Many SaaS companies that were in growth mode are facing a fascinating challenge in this moment. After hiring deep benches of scalers, pioneers, and builders, the focus has flipped. For knowledge workers who entered the workforce after 2008 or so, this is an entirely new environment: Layoffs, operational execution, and financial prudence.

With companies facing continued headwinds, that creativity — the ability to think in new and different ways — is more valuable than ever.

It’s a perfect opportunity for the high performing product manager to tap into their creativity like never before to help SaaS businesses navigate new waters.

Creativity in Decision Making

The principle job of the product manager is to identify the right customer problem, connect it to business value, and deliver the right solution. The primary output? The quality and velocity of their decision making.

Decision making requires the ability to think outside the box, to see things from different perspectives, approach the problem from different angles and generate new, out-of-the-box ideas with their teams. In other words: Creativity.

When creativity dwindles, it often shows first in decision making.

Here’s how to stay creative in your decision making and move from burnout to breakthrough:

1. Think in threes. Stress, urgency, and pressure leads to binary framing: “We can either do this project or this other project.” Fire up creative decision making by introducing a third choice. Just like in comedy and copywriting, creative decisions come from thinking in threes. Often, just by ensuring there are three choices, you end up combining elements of each into a novel decision.

2. Collaborative brainstorming. Brainstorming is a powerful way to generate new ideas and encourage creativity. Collaborating with team members from different backgrounds and expertise can help to bring fresh perspectives to the table. Collaboration is where the magic happens and leads to better decision making. Check out Miro’s brainstorming templates to spark some ideas.

3. Encourage risk-taking. Sometimes the most innovative solutions require taking risks. And the appetite for risks right now is…low! When fighting burnout, product managers must be intentional and encourage team members to take calculated risks and explore new ideas. Often the risks appear larger than they really are — and remember, most decisions are reversible. Just do it.

4. Premortems. Atlassian has a simple template to follow. The power of a premortem is that gets you out of the “delivery rut” and explore twists and turns before they happen. Product managers can ask "what if" questions to challenge assumptions and explore new possibilities.

Product Managers: This is your moment to lean into a new chapter of your story — new challenges, new pressures, and new opportunities to exercise creativity in an entirely new way.

That creativity — the ability to think in new and different ways particularly through decision making — is more valuable than ever. Lean in!