Someone asked for my 1-pager in the middle of a networking call. Totally normal ask. And I said I'd send it after.

When I opened the file, I realized something. I just stared at it, it was too much.

The headline had a middling headline — who doesn’t want a strong and clear team? — and the subhed said, "Product strategy & design, workshop facilitation, team development & coaching." Three (3) big buckets of things, all equally weighted. No point of view.

I've been on the other side of the table for clients and customers, saying not to do this exact thing — if you're trying to talk to everyone, you're talking to no one, better to lead with one thing — and here it was. My mess, I did it. I just missed it.

AND I'd already found the one thing over a year ago. Feb 2025, Friday morning in Durham at Ali Heijmen's office in the old North Carolina Mutual Life Insurance building. Waiting for my turn, I asked myself, So what? Why does any of this matter? Really.

I thought to myself, Well, only humans buy anything. Dogs can't. Kids shouldn't. AI can't, not really. And forget about personas. If a product can solve one problem well for one kind of person, you've got something. Go talk to them, find out.

I said it out loud and the room responded. 20 people came up to me after.

But I didn't write it down. Not anywhere that counted. Yes, it lived in client conversations, in mentor sessions, in pitches for months. But I thought it was too obvious. Like something everyone already knew.

That's the thing about your own best idea. It seeps in through repetition — through saying it, hearing it land, seeing the reaction. Through 11 clients running the same sprint. Through the same question asked countless different ways.

You don't decide it's true. You just stop being able to say it any other way.

The lag between knowing something and trusting it on paper is real, and it can cost you. I was giving away the clearest version of my work in every conversation while my one-pager sat there collecting dust, still trying to cover all the bases, just in case. Without realizing it, I'd made an echo chamber that I was sending out after the meeting. Which was serving no one.

So I updated the cover. "Only humans buy anything — are you building for the right ones?" A single question with two offerings under one specific area of work.

Took less than 10 minutes once I realized it.

Open tabs in my browser right now

• Pushing the new Sony digital service paradigm on what used to be one of my favorite ways to watch a movie: https://www.indiewire.com/features/commentary/alamo-drafthouse-sucks-now-1235188253/

• AI might be good with many tasks, but less good with the time-intensive human work of building relationships, "arm-twisting,” and those hated meetings: https://www.nytimes.com/2026/04/15/business/ai-jobs-human-work.html

• Artist corporations (A-Corp) bill being considered in Colorado, could be live by 1 Jul 2027: https://www.artistcorporations.com/

• A how-finding session at Dave Gray’s School of the Possible around member use cases for Claude — members only

There's probably something you've been mentally rehearsing for weeks — maybe months. It’s the thing you say to someone else lands, but hasn't made it onto paper yet.

Worth writing it down somewhere you'll actually see it. Say it enough times until it stops being a choice. Or it doesn't. But at least you'll know.

Skipper Chong Warson

_{Only humans buy anything, stop building for the wrong customer}

_—

_{If what you say in your best conversations isn’t how you’re talking to your customers yet — that's exactly what we figure out together. Book an intro call at: howthisworks.co/start}

Remember when I started an email newsletter last year and then stopped in January? And now it’s March. Yeah.

It went by the wayside because of a technical detail I’d glossed over when I was setting it up: in short, I'd used Beehiiv's own domain instead of my own. Images broke and I couldn’t track it to specific subscription forms. Small, annoying things — the kind that are easy to put off until putting it off becomes the habit.

But thanks to Claude, Gemini, and a few YouTube videos, I figured it out yesterday.

So, hi again.

As most of you know — about 18 months ago, I started How This Works co. But that's not the first change in my work, not by a long shot. For about the last 15 years, I’ve gone through a number of different kinds of work and modes. Let's count 'em:

1. web designer

2. UX designer

3. senior designer

4. service designer

5. design director

6. product strategist standing up a services practice with a signature offering, the Bullseye Customer Sprint

Of course, with stints of job hunting in between and some things on the side, freelancing and fractional work. But none of them were ever the same job, they don't have the same focus or the same parts. For instance, team management and budgeting matter when you're a design director overseeing $2M in billable work but it’s an unnecessary detail when you’re trying to reach a funded founder watching customers leave.

I knew this in theory but my LinkedIn profile had all sorts of deferred maintenance and leftover from previous works on it. Lots of stuff that I’d swept under the rug. Skills which were connected to recommendations and services.

Then last week, my friend Danita Delce — a fractional designer in Austin (LinkedIn) — mentioned she'd run her LinkedIn profile through an AI tool to optimize for LinkedIn's latest algorithm updates. Hm.

So I did the same. Pulled together LinkedIn's official announcements (starting with this one), found a few practitioners breaking down the practical side, dropped it all into a Claude thread, and pasted in my profile, my banner graphic, and a one-sheet on How This Works co, including my own Bullseye Customer framing.

And the thread had plenty of recommendations. Some landed, some didn't.

"Move product design out of your top three skills — it triggers 'freelancer' categorization." But I've been a designer for nearly 15 years. That's not noise. That's the foundation everything else is built on.

"List management consulting and business consulting as your service categories — that's where the retention budgets live." Maybe, but I'm not a management consultant persay. I’ve done most if not all of my work from the design swim lane. And currently, I'm someone who figured out how to run customer interviews in a way that actually changes what a team builds.

And then, at the end: "You are no longer a 'designer who does some strategy.' You are a strategic partner whose service is solving the $2M+ problem of customer churn." This statement is based on work that I did at Fjord for a healthcare company as a service designer.

The funny thing is I didn't ask it to rewrite who I am, I’d asked it to audit my profile.

True, Claude and Gemini were able to zero in on what the algorithm rewards. But it doesn’t know what I say on a call with a founder that gets head nods. It hasn’t lived my life or actually done my work.

And then I remembered something I hadn't thought about in months.

Last year, Brad Diderickson (LinkedIn) and I were comparing notes on our respective practices. He was testing his own positioning language in conversations around being a corporate dropout and making a big change — 150+ of them now, which you can follow on his Substack. At some point in our convo, I described customer interviews as detective work, following evidence for future product failure — looking for what customers actually meant versus what they said.

Brad reflected it back to me and so I reluctantly tried "product failure detective" in my headline for a while. It didn't quite fit and told Brad so back then, "I didn't like the nameplate. But I liked the scene of running a product failure detective agency. The feeling. I dunno.”

That's the thing about positioning language. You say it out loud. You say it over and over until you hear the gaps. Brad's been doing it for 150+ conversations. And then that’s what I did again when I recently revamped my LinkedIn profile with help from Claude.

Open tabs in my browser right now

• Daniele Catalanotto about how a shift to a "free" model for him has reduced overhead costs and technical complexity: https://store.swissinnovation.academy/blog/all-free-ripple-effects

• Mike Montiero’s new book is in my shopping cart: https://www.mulebooks.com/store/how-to-die-and-other-stories

• Rusty Foster and the urge to anthropomorphize AI: https://www.todayintabs.com/p/a-i-isn-t-people

What I realized this week: I've been running positioning experiments this whole time. The detective detour, the skills cleanup, all of it. I just didn't call them experiments. I was fixing things that felt off.

Which is, now that I think about it, exactly what I help founders do with their customers.

If your profile — or your positioning — has been through a few different jobs, I'd like to hear what you've kept and what you've cut.

Skipper Chong Warson

_{Only humans buy anything, stop building for the wrong customer}

_—

_{If you're not sure which customers are sticking around and why — that's exactly what we figure out together. Book an intro call at: howthisworks.co/start}

In 2021, I played Mother Ginger in a Marin County production of “The Nutcracker.” With a white beehive wig and gaudy French pancake makeup — a beauty mark to boot — it took 2-3 people to get me dressed backstage in a pink/red/cream dress with a giant hoop skirt.

I should say I'm not a trained dancer. Sure, I took the required theatre directing classes in university where I was part of the acting ensemble. Was I the most graceful? No. And, yes, I was the captain of the speech and debate team in high school so I'm capable of doing performative things under pressure. But I didn’t at all feel prepared.

When asked, my first instinct was no. Wave my hands, say, Thanks, I'm sure someone else could do it better than me. It’s fine. But then I thought: Why not? It could be fun. And I could do it with my kid.

Word got around quickly. Especially with my kid’s friends. One day during rehearsals dropping off at school, a cluster of them came up to me and asked, "Are you in Nutcracker?" Yeah, I said.

"Are you wearing a dress?" Totally, I nodded. "But I'm also wearing my own boots," I said. "And I'm going to be wearing makeup too. A lot of it. My face is going to be white white white."

The kids looked at me blankly and then ran off.

For a 4-5 minute scene in the whole production, it's a bit ridiculous. It's comic relief amidst the other dances in the land of sweets with a towering figure, often a man these days, with unruly children (called Polichinelles or Bon Bons) bursting out from under the enormous skirt.

Personally, I think it's also the Russians from 1890s poking fun at the French. The woman who did my makeup told me this.

But it was worth it. The months of rehearsals, the nerves beforehand, the awkwardness of being the least trained person on stage (most likely). All of it.

The thing about fear

Bravery isn't about doing something without fear, it's about doing the scary thing while you're scared. Fear, anxiousness, and other imposter monster feelings will always creep in. I appreciate the way that Glennon Doyle puts it: "Brave is not something you should wait to feel. Brave is a decision."

The glittering vision of success doesn't often bring in the character of fear. It's like Voldemort, we don't speak the villainous name. We hope that the fear will vanish. But it won't. It usually doesn’t.

In Susan Jeffers' book, "Feel the Fear... and Do It Anyway," she talks about how confidence doesn't show up first. You don't feel ready and then act. Rather: you act, then confidence builds gradually. The only way fear shrinks is by doing the thing repeatedly, not by thinking about it more and sitting with inaction.

Doyle's not telling you to ignore fear in “Carry On, Warrior.” She's saying the fear won't disappear, so you do the thing anyway. And as Jeffers says, the confidence comes after.

So how does this example being Mother Ginger in the Stapleton Ballet production play out elsewhere? Great question.

I’ve been in situations where someone might suggest some manner of talking to customers in product work. Sometimes, it's me. Sometimes, it’s someone on my team, in product or design.

Let's give it a name. Let's say we're working on a new unified dashboard or revamping an onboarding flow. And the question gets asked, How do we know our customers want this?

This is usually followed by an awkward silence.

You see where I'm going with this. It doesn't have to be customer interviews, which IMO work super well. It can be a customer support log. It can be call notes from the sales team. Hell, I'll even take a Net Promoter Score (NPS) survey. Sometimes, a set of dusty personas get trotted out with Maria the manager, Stephen the single dad, etc.

In my example, let's rewrite it and say that the team is open and they say, Yes. Let's do that. Everyone nods. It makes perfect sense. This happens about 25% of the time.

Then, a few weeks later, they haven't done it. The team has spent their time rewriting and reworking the product roadmap. And they knocked out a few key features "that'll really make a difference." And all sorts of other activities — backlog grooming, standups, maybe even a pre-mortem.

They've done everything except talk to an actual person. They've kicked the feature factory into high gear, just hoping that people will buy. No evidence.

When asked some version of why they didn’t talk to customers, the answer is always some version of the same thing: they're not ready yet. The timing isn't right. They need to understand their market better first, do some competitive analysis. The questions aren't perfect. Any number of reasons.

What they're really saying is: I'm scared of what I'll find out, so I'm waiting for that to go away.

But it won't. And while they wait, they're building on assumptions. Getting more attached to the idea, the idea that hasn’t been validated. Buying their own press.

Here's what I know from working with stuck teams

The fear isn't the real problem. The real problem is skipping the hard part because you already think you know the answer.

Staying curious is harder than being certain. Asking a question you don't know the answer to is scarier than pitching an idea you've been polishing for months. My friend Dave Gray talks about how no one likes a know-it-all, especially one that's right. And how they’re even worse when they are.

The only way through is to do it while you're still nervous. To talk to customers who might say something that breaks your plan.

That's when everything changes.

Here's what I'd ask you

For my Mother Ginger bit, it took a couple months of rehearsals for 15 min of fame, about. People laughed, they clapped along, they cheered, the kids loved it. Now, imagine what you could do with talking to just 10 customers.

Not to validate your idea. Not to check a box. But to actually understand what they need, what they want, their pains, and their goals.

What are you waiting for that you could do scared instead? Not recklessly. Not without thinking. Just while you're still nervous. What would it look like to talk to 1-2 customers a week for just 30m?

How does that sound? Hit reply.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Ready to understand when to trust your gut over your data? Book an intro call with us

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here

Last spring, I needed to recruit bullseye customers for a sprint. This was my second client and I wanted to move fast. So I posted a Google form to LinkedIn and a few Slack communities to find the bullseye customer we’d formulated over a few sessions, a narrow kind of ideal customer persona (ICP).

And within days, I received 82 responses. Among them, 12 perfect matches. What I didn't realize at the time was (but my current suspicion is) that most of these matches were AI-generated answers gleaned from parts of my LinkedIn post. Not to mention the fake profiles encountered and concocted credentials.

But I’m getting ahead of myself. I went ahead and scheduled the first five (5) interviews and felt good that things were moving along.

Then the interviews started. And everything fell apart.

The first person never showed up. No message, no response to my email, Do you want to reschedule?

The second person arrived 10 min late, claimed to be in Ohio. But his resume said New York City. I started by saying, it's pretty early for you. It was 9:30 AM on the east coast which meant it was 8:30 AM in Ohio. He shrugged it off. And his background felt off, specifically the lighting in his room — a bright white overhead light, clearly indoors, with closed curtains, which felt very different from somewhere it was morning. I should also point out that Sam’s resume (below) was flawless: five (5) years of Product Operations experience, names of companies, legitimate progression, every certification you'd want to see. But when I asked basic questions about KYC (Know Your Customer) compliance, what kinds of work he did for financial services clients working in GitHub (who said he wrote code even though we were looking for non-coders), and repositories he might be able to talk about, even show me, he had nothing but generic answers. No specifics. So we wrapped early, about 10-15 min in.

The third person sent an email about a medical emergency and wanted to reschedule. Which left me 3/5 and burning time. So I did what I should have done earlier: I called a timeout and said we should have a quick huddle.

We discussed what was happening. It felt off. The screener data looked perfect, but the actual humans on the other end didn't match the profiles. So I reached out to the remaining "perfect match" participants for quick video calls to confirm their experience and context for the upcoming interview. I also wanted to verify that they were real before the full interviews.

Not one of them responded. Plus, the couple who’d wanted to reschedule from the first set.

Then, I tried the seven (7) strong matches. 6/7, no response. And remember there was an incentive attached, $120 for an hour is what I recommend. Same thing as what Google Ventures does.

One person did respond from that group, but not in the way I’d expected. They didn't say no. They asked: "Are you racist?" No context. No explanation. Just that.

I don't know what prompted this response. Maybe they felt targeted, maybe they were testing something. Either way, this was a very clear sign for me that this was the wrong path.

Now, a week was gone. Client time (and my time) wasted. And I'd let people down because I'd convinced myself the data was enough.

Trust the feeling

Here's what I couldn't ignore: something felt off from the first interview, even though no one showed up. But I didn't trust that feeling because the screener told me everything should be fine. I had data, numbers, and matches. So I pushed forward.

The funny part? I know better. I've recruited for hundreds of projects. I've used User Interviews, Respondent, Dscout, a bunch of different tools. But I thought I could spot the problems ahead of time with a good screener. But in 2025, a Google form isn't vetting anymore — it's more like a sticky fly trap. It's a good start but it doesn't solve the whole problem.

Since then, we've run five (5) more sprints using userinterviews.com and done about 80 interviews. Almost zero problems. Sure, a couple of no-shows, but no Samuel Smiths with impossible lighting for that time of morning in Ohio.

But that week taught me something worth naming: when your gut says something's off, that's signal. Not noise. It might be overthinking — what isn’t right now — but it's worth paying attention to. I had 82 people who filled out a form and looked good on paper. Maybe some number of bots. I dunno. But the actual humans didn't match what they claimed. I ignored it because I thought volume plus my experience to back me up.

The bigger thing I'm sitting with

How do we keep the accessibility and speed of recruitment without drowning in noise? Paid platforms solve some of it, but they're not always an option for early-stage teams running their first sprint on a tight budget. And even when you use them, they don't solve for everything.

The real issue is that I had data telling me one story and then humans telling me another. I chose to believe the data because it felt more scientific. But my gut was already pointing at the gap.

One thing that I think’s changed is the sophistication of the fakes. The Samuel Smiths aren't just people who don't show up — they're fabricated to pass initial screening. They're pulling answers from your LinkedIn post, crafting resumes that match your requirements line by line. And the clarity I had in my screener? The funny thing is that it probably made it easier for them to match. Even with crystal clarity on your end, you've got to verify on theirs too.

The thinking mind can process 82 responses and find 12 almost perfect matches. But intuition catches what data misses — the lighting that doesn't match the timezone, the resume that's too polished, the silence when people should respond. Intuition says, "Look deeper here." The thinking mind then asks the right follow-up questions.

I had both. I just trusted the wrong one.

Hit reply. I'm curious what you're noticing.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Ready to understand when to trust your gut over your data? Book an intro call with us

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here

There's a low hum running through most conversations right now: The anxiety that if you're not mastering the latest AI tools, you're falling behind. Everyone else is getting ahead. You're slipping.

In my opinion, that is misdirected.

Confession time

I'll admit it, I use AI. I use Claude, I use Gemini; I’ve played around with Claude Code and Figma Make. But not for thinking. I do that myself.

I have a Notes file called "b-sides and rarities" — I make a new one every year to collect random bits and bobs. I’ve been doing this since 2021. That's where ideas live. I voice type into it, scribble on sticky notes to type in later, lots of ways to input. But mostly it’s I put something together, sit with it for a few days, and then do something next with it. My methods vary.

I might string together a quick note and ask Claude to summarize it. Or I'll request a few quick drafts in different directions and see what lands. I use Claude as a last-mile editor too — smoothing things I've already thought through, using a version of this prompt:

Don't rewrite significantly or add invented facts. Focus on improving format, grammar, clarity, flow, and removing redundancies. Keep it concise. It should feel human, not like fake rubbery AI.

My actual method: I think. I sit in that tension. I research some. I document that or I free write. Then, I might use AI to smooth over what I've already thought through. Or prompt it to critique — one of my most common requests. It can help me zoom out. I use it as an addition, not a handover.

Still, I keep hitting moments with clients where we’ve made something paired with AI — or even not with AI — and something feels off. Even for things that are straight ahead and tactical.

Two examples

A few weeks ago, I was reviewing 11 headline options Claude generated for the How This Works co page on the Bullseye Customer Sprint page. I'd started with five (5) I’d already written and requested 11 others. And they were fairly okay as outputs, logically sound. Hit the right points.

But I read through them and thought, “They don’t feel right.” Off somehow. Like a copy of a copy done too many times. Or like someone wearing clothes that don’t quite fit.

So I stopped playing the editor and evaluator. I didn't think about whether the structure was good or the logic worked. Instead, I took a minute and closed my eyes.

I pictured my actual customers. The ones I've worked with. Bootstrapped and funded early-stage founders, 6-12 months of runway, staring at conflicting user feedback. Exhausted.

They don't want a wild goose chase. They want to figure out their product with evidence, not hope, fingers crossed. They want relief.

That distinction — relief, not excitement — didn't come from analyzing AI outputs or refining prompts. It came from my working with actual humans who were referred to me by other humans who trust me. From talking to them about why they signed up for work. I heard their fatigue, overwhelm. The 57 browser tabs. The specific triggers that would make them receptive to what I offer.

So I rewrote the headline in a few minutes based on that. Then, fed it back to Claude for polish. Which felt right.

What your gut knows that text patterns don't

AI is great at pattern matching. It's learned what words tend to follow other words in what contexts. Your gut is great at pattern recognition that comes from “lived experience.” Those are different things.

AI can generate a user flow that follows logic. But it can't predict where users will feel confused because it's never experienced confusion. And it can’t feel the frustration in trying to tap a too small button on your phone with freezing fingers while walking a dog in a New York City winter.

AI can construct a positioning statement that most people think are the right parts. It's ingested many examples. But it's never felt the tension of actually speaking those words to another human. It's never needed to repair trust after making a mistake.

And it’s not just generating text. I'm working through this on a client project. Last month, my team built a high-level architecture document and workflow prototype for lawyers. We'd done preliminary interviews and workshops, pulled insights from them, and incorporated everything into the docs. But something was missing — the whole throughline between what we'd learned and what we'd built.

So I doubled back in our last meeting. Asked questions again. Because we needed to be sure. The built architecture was firm and the prototype thesis was clean. But it was dancing around the actual tension the lawyers had described — the specific moments where their current process breaks down and costs them time.

I asked:

• What do you do first thing on a Monday to start your week?

• Walk me through the last case where something went wrong. What happened? When did you realize it? What did you do?

• If you could wave a magic wand and change a single thing about how you work today, what would it be?

Yes, we'd asked questions like this before, but I needed a refresh. I needed specific scenarios. Now we're in the process of rejiggering the specification into a current state journey map and then a future state one. We want to show how the proposed prototype actually solves for the tension they described — not the idealized version buried in a mountain of text.

That shift didn't come from refining the architecture. It came from remembering what we'd heard, felt, and seen when we sat across from those lawyers the first time. Then, asking for a refresh.

So, we’ll connect the dots, shifting slightly what we'd built.

Stop treating tool adoption like a survival metric

You probably don't need to know Cursor better — sorry, Cursor. You don't need to master the latest prompt engineering technique. And you definitely don't need to feel anxious about what you're not doing with AI.

What you need is to trust this: when something feels off about an AI output, that feeling is signal. Not noise. Not overthinking. Follow the signal.

Use AI for what it's good for. Polish. Zoom out. Riff on directions. Play with options. Leverage its machine learning while also remembering the limitations.

But keep your thinking. Pay attention to your gut. Keep the moments where you close your eyes and actually imagine what it would feel like to be on the receiving end of what you're making please.

When something feels "right but not right," stop. Don't keep prompting. Don't fiddle with the output. Close your eyes. Go for a walk. What does your embodied experience tell you? Where does it snag? What would actually land?

Trust that. That's the work AI can't do.

My question

I want to know: Where have you felt this difference? Or the flip side — where have you trusted your embodied knowledge over the AI’d output and been right?

Hit reply. I'm curious what you're noticing.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Ready to help your team understand when to trust AI outputs and when to trust embodied judgment? Book an intro call with us

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here

I show the above slide because it gets a laugh — whether for a five-week sprint or an afternoon workshop. After all, Back to the Future is a good movie — often cited as one of the most perfect beat-by-beat screenplays in American filmmaking. But also because time is one of the few things humans cannot influence. Definitely can't control.

I tell them our time together is going to fly by. It's going to feel like there's not enough time and that's intentional. Because when time is constrained in this way, we don't have time to beat around the bush. We find what actually matters.

And here's what I've learned after running Bullseye Customer Sprints for the past year: the timeboxing isn't just about efficiency. It's a forcing function that prevents something much more expensive than wasted time.

The real cost of 182 1/2 days

Most founders spend six (6) months "validating their idea" or looking for product-market fit — which really means:

• Dreaming up a feature set that would be worth bragging about

• Building elaborate personas based on assumptions

• Analyzing competitor positioning instead of talking to actual humans

• Doing a variety of activities (often random) to confirm what you already believe

• Having long internal debates about who the customer might be

All while building, shipping, and growing. They may or may not discover that they built for themselves. Or for someone who doesn't exist.

Here's what those six (6) months actually cost:

• Wasted payroll: Your team spent half a year building features nobody asked for. At a small startup with 3-5 people, that's $150K-$300K in salary building in the dark.

• Scattered marketing: You can't clearly explain who you're for, so your messaging tries to appeal to everyone. Your customer acquisition cost (CAC) climbs because you're not speaking directly to anyone.

• Inconsistent sales: Pipeline is unpredictable. Some months you close deals, other months nothing. Sales/customer success can't articulate why someone should choose you over alternatives.

• Climbing churn: Customers who do buy often leave quickly because they misunderstood what you do. They bought for the wrong reasons.

• Stalled fundraising: Investors ask "who's your customer?" and everyone on your team gives a different answer. Or worse, you list a plethora of different types because you can't commit.

• Strategic risk: You're six (6) months closer to running out of runway with no validated direction. Every week without customer evidence compounds the risk of building the wrong thing.

The problem isn't that you don't want customer evidence. It's that without a forcing function of validating who the customer is plus their goals and pains, the business is essentially an endless hamster wheel.

The Bullseye Customer Sprint is five (5) weeks total:

• Wk 1: Hypothesis generation — align on who you think your bullseye customer is, what triggers their need, what disqualifies someone. Document your assumptions before you talk to anyone.

• Wk 2: Create prototypes — build 2-3 simple prototypes showing different value propositions. Just enough to test assumptions in conversations. Not production-ready. Not pixel-perfect. Good enough to learn.

• Wk 3: Five (5) customer interviews over Tue, Wed, and Thu — same week. Each interview is an hour-long: half customer context, half testing assumptions. Your whole team observes live and debriefs immediately while it's fresh.

• Wks 4-5: Document positioning — consolidate learnings. Refine your customer definition based on what you heard. Document why customers choose you over alternatives. Create your action plan.

Time commitment: 2-3 hours per week from core team, plus the five (5) interviews. About 40 hours total over five (5) weeks.

How time scarcity changes your thinking

Give a team a vague time horizon for some task, like defining their customer, and they'll spend a few months debating edge cases and building elaborate personas based on guesses. Each person on the team will have a different version of who the customer is in their head.

With five (5) weeks, you’re forcing a different kind of thinking. The constraint forces alignment twice: once before you talk to customers and once after.

In the first week, everyone documents what they believe. Your PM thinks the customer is technical. Your designer thinks they're working on-the-go. Your founder thinks the cost is most important thing. But you can't move forward until you write it down and agree on what you're testing.

Then, the third week reveals where you were all wrong. Your whole team watches the same bullseye customer interviews. Hears the same stories. Sees the same patterns. At the end of the third day of interviews, nobody's arguing about opinions anymore because you all witnessed the same evidence.

This is how constraint changes the quality of thinking, not just the speed:

• It forces prioritization — you can't ask everything, so you have to decide what questions actually matter. What will change your product roadmap? What will help you say no to the wrong customers?

• It forces observation over opinion — when you only have five (5) interviews, you can't afford to miss what people are actually saying. You stop filtering their words through your assumptions.

• It forces team alignment twice — wk1: everyone documents their hypothesis. Wk 3: everyone watches the evidence. The contrast between what you expected and what you heard creates clarity that months of internal debate never could.

• It limits the damage — five (5) weeks is short enough that if your first hypothesis is wrong, you haven't burned six (6) months of runway. You revise and run another sprint. Or run a month of additional customer interviews to get clear and find the evidence.

What you get

After the sprint, you have:

• A documented bullseye customer definition that's narrow and specific enough to make decisions

• Evidence about which value propositions in the prototype resonate and which fall flat

• Quotes from actual customers explaining their triggers and your competition

• Internal alignment because everyone heard the same five (5) conversations

• Confidence to make product, marketing, and sales decisions based on patterns, not guesses

You won't know everything about your market. But you'll know enough to make informed decisions about who adopts first and why — not guesses, evidence.

The five-week sprint doesn't just compress timeline. It forces you to name your assumptions in the first week, then test them in the third week before you've invested too much in being wrong. Every week you spend theorizing instead of observing is a week you're compounding potential rework.

And after the sprint? Teresa Torres advocates for shorter, more frequent customer interviews — 15-30 minute sessions conducted weekly — to maintain continuous discovery. The sprint gets you oriented quickly. Weekly conversations keep you oriented as you build.

There's no such thing as time management. Time just moves. What you actually manage is focus — and how much damage you allow before you check your thinking against reality.

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Book a 25-minute intro call with us — we'll discuss what you're trying to figure out, whether you have customer access, and if the sprint timeline works for your stage.

I was updating customer interview insights for a client on Miro last week and I realized I've run 80 customer interviews in the last year. Across seven (7) bullseye customer sprints plus several ongoing weekly interview series. And how I started running them isn't how I run them now.

The first 25-30? Pretty manual. No AI. Just me, Zoom transcripts, and lots of sticky notes on a Miro board.

The interviews themselves? Those haven't changed much. Still 60 minutes, half discovery and half prototype testing. Still streaming live to client teams. Still taking notes.

But what happens before and after everyone logs off Zoom? That process has gotten sharper with every sprint. Here's my process.

Before the interview: write down what you think they'll say

Before each interview, we jot down what we think the participant will say. Not elaborate predictions. Just a few bullets in the interview guide notes.

Things like:

• "Probably uses spreadsheets for this"

• "Might mention frustration with approval process"

• "Will likely prioritize speed over accuracy"

Takes a few minutes. But it changes how we listen. And how we’re able to talk plainly about what we thought we knew and what we learned. Because when someone says exactly what we predicted, that's validation. When they say something completely different, that's where insights live. The assumptions create contrast. Without them, everything just washes over you as "interesting info."

After the interview, the first thing we do in the debrief is pull up those assumptions. What did we get right? What surprised us? What did we completely miss?

The immediate aftermath

The debrief happens right after, while everything's fresh. Fifteen (15) minutes with my client team processing what we just heard.

"Did you catch that part where she said...?"

"I wasn't expecting them to mention..."

In addition to the notes I took during the call, I jot down quick takeaways — patterns I'm seeing, things that contradicted our assumptions. Just enough to jog my memory when I dig into the transcript later.

Getting into the transcript

I conduct the interviews through Zoom and they get recorded and transcribed. I run each transcript through Brian Greene's Redact app at https://redact-delta.vercel.app/ — which strips out personally identifiable information right in my browser. No cloud processing. Just clean transcripts with "Participant" or "Interviewer" or some other label where in the place of names. Same for company names or phone numbers or email addresses.

Before Redact, I'd have to spend 10-30 minutes manually finding and replacing every name and identifying piece of info. Across even 50 interviews? That could've been 25+ hours of find-and-replace.

Now it takes 30 seconds per transcript.

Time to Claude

Then I drop the transcript into a Claude project I’ve set up for customer research. The project includes:

• Best practices around interview analysis — cribbed from Erika Hall, Teresa Torres, Tomer Sharon, and Steve Portigal

• The current version of the bullseye customer sprint methodology, on version 2.0

• Context about what we're trying to learn

• The interview guide

• My debrief notes, also redacted

• Those assumptions we documented beforehand

I also paste the bullseye customer definition — that description of this person who for my client we think will say "just take my money" and why.

Before Claude, I'd read through each transcript, highlighting in Google Docs, pulling quotes that seemed important, trying to remember patterns from previous interviews, keeping a separate document of themes that may or may not connect.

This worked. But it was slow. And I'd miss connections between the second interview and the seventh one because the details from the previous one had faded.

Now, the analysis that used to take an hour or two per interview takes 30-45 minutes. And I catch more because I have my notes. And notes from a team of people who watched the interview live. And Claude has the transcript in tow — plus the context from all previous interviews in the project.

With all that context loaded, I can ask Claude to surface patterns across all transcripts. "What trigger events have come up repeatedly?" "Where do the value propositions diverge?" "What unstated context keeps appearing?"

Why I generate more insights than I present

The first insights spotted are usually the obvious ones. The customer said something directly. It got written down. Done. Moving on.

Breakthrough insights? Those emerge from patterns across multiple conversations, from what people didn't say, from the moment their energy shifted.

So I ask Claude for 10 insights knowing I'll present 3-4 to my client team. Claude's initial output becomes raw material — I throw most of it away as I dig deeper into what actually matters. And when I present the 3-4, I'm confident they're the most valuable, not just the most recent.

The 10-to-3 ratio also buffers for insights that seem important alone but don't connect to anything actionable. Sometimes customers mention fascinating things that don't help us make better product decisions. Those go in the archive.

What I'm hunting for

Trigger events — What changed in their world that made them receptive to a new solution? In one recent sprint, all Bullseye participants mentioned a regulatory change from a few months earlier. That timing mattered — explained why they were suddenly open to solutions they'd ignored for years.

Jobs-to-be-Done clarity — what are they hiring a solution to do? What job were they trying to accomplish when they fired their previous solution? I interviewed someone who'd fired three (3) project management tools in two (2) years. Wasn't about features — was about forcing their team to change workflows. The job wasn't "manage projects better," it was "get team buy-in without a fight."

Value proposition resonance — which approach got them leaning forward? "That's interesting" means nothing. "Oh, that would solve the problem where..." means everything. I watch for the shift when they stop being a research participant and start mentally using the tool.

Unstated context — this is the stuff so obvious to them they don't mention it. One client kept hearing "we need better reporting" until we learned that "reporting" meant "CYA documentation for compliance audits," not "insights for decision-making." Completely different problem.

Pattern breaks — when someone contradicts what the previous three people said, that's interesting. In one sprint, four (4) people said they'd pay for a solution. Then, the fifth said, "I'd just build it internally in a weekend." That outlier forced us to sharpen the bullseye definition — we were accidentally talking to people with in-house technical resources.

Synthesis happens in layers

After analyzing individual interviews, I start looking across the set. Usually after five (5) conversations, patterns become visible. By interview 10, I'm able to test hypotheses from earlier sessions.

This is why I adapted the Google Ventures model from all-interviews-in-one-day to 2-3 interviews twice in one week. That gap lets patterns surface. Gives my client team time to process and come back with sharper questions. It’s also a grueling day to do it in one shot.

Between sessions, I'm updating a working document that tracks:

• Emerging themes

• Quotes with timestamps

• Contradictions

• Questions for future guides

This becomes the foundation for the final deliverable. But it's messy, in-process, full of threads that don't connect yet.

What the client receives

After a bullseye customer sprint — typically five (5) interviews over two weeks — clients get:

Individual interview recordings — posted as unlisted YouTube videos with VTT transcripts. Team members who couldn't attend live can watch at their own pace. More importantly, they can search the transcript for specific topics or terms. While I encourage them not to look at the prepped materials so they can draw their own conclusions, I know some don’t.

Synthesis document — 3-4 key insights with supporting evidence from each interview. And no slide decks. Who needs one more slide deck? Each insight includes quotes from at least two (2) different interviews, the pattern it reveals, and why this matters for their specific bullseye customer. Right into a Google Doc.

Bullseye customer definition, to be updated — we started with assumptions and a working hypothesis. Something like: "Infrastructure ops manager at a mid-market financial services company. Manages a small team (3-5 people). Player-coach role. Reports to engineering leadership but measured on customer satisfaction."

After five (5) interviews, that definition gets sharper: "Infrastructure ops manager at a regional bank or mid-market fintech, promoted in the last 12 months. Been at the company five (5) years or less. Manages 3+ people but still doing 50%+ execution work. Reports to engineering, measured on CSAT scores and system uptime."

That specificity changes everything about positioning and messaging.

Recommended next steps — might be "run another sprint with a different segment" or "you have enough validation to move forward with prototype B" or "pivot to focus on this trigger event we discovered."

After the Bullseye Customer Sprint, there’s an end of sprint document with next steps. For weekly customer interview segments, I deliver a monthly summary that rolls up patterns across all conversations that month. Same format — key insights, why they matter, what to do about it.

What I've learned after 80 interviews

Most teams already suspect what they need to hear. They just need permission to act on it.

Customer interviews don't usually reveal completely unknown problems. They validate which problems actually matter versus which ones just make sense in conference rooms. They show you who will pull out a credit card versus who will nod politely and disappear.

When you can point to a full sprint where customers all said some version of the same thing, stakeholder opinions carry less weight. The customers became your evidence.

That's why I obsess over this process. It transforms "we think customers want this" into "we know customers will hire this solution, here's why."

The work between interviews — documenting assumptions, redacting, analyzing with Claude, finding patterns, cross-referencing — transforms individual stories into strategic clarity. Skip that work and you're just collecting anecdotes.

The interviews are the beginning. What you do before and after? That's what turns research into results.

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Ready to run your own bullseye customer sprint? Book an intro call with us

I've been doing something for the past few months. And I caught it last week as I was using Claude (which knows me as El Capitan, because I'm not volunteering all my info to AI companies) to help refine and reposition the Bullseye Customer Sprint landing page at howthisworks.co. Within a longer thread, I had typed: "Given that my bullseye customer for this service is a funded founder or bootstrapped founder, how might we frame the benefits section more directly?"

Yep, that's right, I was using 'design thinking’ language in my AI process. But it’s not for the AI's benefit. It was for me.

What I noticed

I've been using AI tools daily for months now and I started noticing a pattern in which prompts actually helped me think versus which ones just made me a receiver of whatever came back.

When I prompt with something like "how should I..." or "what's the best way to…," I'm more likely to take whatever comes back and just run with it. After all, the AI spit out an answer, so I'm following the instructions. Bee-boop.

But when I prompt with "how might we..." or "given X context, what are different ways to…," something else happens. I'm requesting options to evaluate, looking for multiple approaches that might work — things I need to think about and possibly adapt to this specific situation.

The AI isn't necessarily generating different quality output. I'm receiving it differently. (And sometimes, I am very explicit. I request three (3) versions back exploring different angles for these kinds of audiences.)

Lazy thinking

Here's what I've learned from working in product and design for almost 15 years: there are unlimited wrong options for any problem, but some undiscovered number of right ones, let’s say a thousand as an example. And most people and teams stop at the first right one. They find something that works, something that makes sense and checks the boxes. And they move on.

But that first answer that could work? It's rarely right. Nor is it the strongest option. It's just... fine.

This is exactly what happens when you prompt AI for "the best way" to do something. You get back a reasonable, middling answer from its machine-learned catacombs. It’ll probably work. You implement it. Done. You move on.

And this is what most people do when they’re searching for something online. Got it, found it. Except you just picked from thousands of potentially good solutions without exploring which one actually fits your specific context best. Even a speedy evaluation.

In practice

In working on that Bullseye Customer Sprint positioning example from the opening, I could've prompted: "Generate a benefits section for this customer research sprint as a service aimed at founders." And that would've given me something reasonable. Something that could’ve worked. First right answer, maybe even refined it a bit, and done.

Instead I prompted with specific context and framing: "Given that my bullseye customer for the current version of the bullseye customer sprint is a funded founder or bootstrapped founder, how might we frame the benefits section to speak directly to their specific contextual pressures around runway and product-market fit?"

I also dropped in a few conversation details from notes with previous and current clients. What came back was a set of strategic directions I could evaluate:

• Lead with clarity over ambiguity — know exactly who adopts first vs. hedging with "well, it could be for several types of users"

• Frame around evidence-based decisions — shift from "I think users want this" to actual things customers say

• Position against guessing and hope — validate assumptions in weeks instead of months, run the numbers here

• Emphasize tactical outcomes over theory — concrete next steps, not vague advice from people who've never built companies

• Connect to what founders actually worry about — investor pitches, team alignment, not stumbling around in the dark

Five (5) directions. All of them could work. But none were the "best." I needed to consider which angle actually resonated with the founders I've been working with and talking to. So, I ended up weaving elements from all the options into four (4) benefits currently on the page, plus adding details the AI hadn't suggested but that the initial outputs made me think of.

Therein lies the difference. I was coordinating and staying curious.

(As I often do, I also had my writing project inside of Claude critique the page against my howthisworks.co homepage and design sprint page. "Critique this" is one of my most used prompts. Whether it’s against something the AI’s just generated or something I’ve written or spoken.)

The thing I don't hear much about

Everyone's (still) obsessing over prompt engineering — the perfect phrasing to get the AI to generate better output. Well, this works better on Sonnet 4.5. Or this works better on Gemini. But I don't think this is the biggest tension. Better output doesn't guarantee better outcomes. I think it's more important to think about what comes back. Whether you treat it as instructions to follow or options to evaluate. Whether you stay engaged with your own judgment or outsource your thinking.

I've seen people generate ace AI output and then implement it poorly because they never questioned whether it actually fit their context. They found a right answer and stopped thinking.

I've also seen people take mediocre AI output and use it well because they stayed in conversation with it — pushing back, adapting, and combining it with their own experience.

The quality of your thinking matters more than the quality of the prompt.

Try this

Next time you're about to prompt an AI tool with "What's the best way to..." or "How should I..." pause for a moment. Try rephrasing it as exploration: "What might work here?" or "What are different approaches to..." or "Given [your specific context], how might we..."

Even better? Talk it through with another human being first. Someone who knows your context, your constraints, your customers. AI can generate options, but another person can push back, ask clarifying questions, and help you think — not just respond.

See if it changes how you receive what comes back. See if it keeps you more engaged with your own judgment instead of deferring to the AI's authority.

See if you push past that first reasonable answer to find something that works better.

Because these tools are powerful. But they're most powerful when they enhance your thinking, not replace it. When they help you find better outcomes, not just faster outputs.

My question to you: How are you prompting AI tools? Are you asking for answers or exploring options? Hit reply and tell me about how the framing changes how you use what comes back. I’m curious. Also, do you have a library of prompts? Or are you writing from memory each time?

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

I’ve been trying to write this for almost six (6) months.

Back in April and May, I'd just crossed from “I don’t know about writing a newsletter” to “well, okay, maybe.” Then Memorial Day weekend happened, and I was standing on a rock in a creek right outside the house we'd rented outside of Boone, NC, and I caught my first real fish.

I came home thinking: I must write about this. This would be a great newsletter article.

Now, it’s October. And I still can’t stop thinking about the fish.

The morning

This was maybe the fifth time I'd held a fishing rod in my entire life. The previous times had been mostly social affairs — standing around with friends, rod in one hand, sometimes a beverage in the other, talking about all sorts of things while occasionally remembering to check if anything had happened with the line. Some nibbles, I'd hear the line pull, but I never caught anything. And no one I was ever with caught anything. I thought this was how fishing went.

That morning was cold enough for a light puffy jacket — though it was late May — and I was fishing with my friend Eldon and his young son in a medium-sized creek that ran right past the house we were sharing with three (3) other families. No waders, no fancy fly fishing gear — just me standing on a rock above the water with a worm (bought from a cooler at the nearby Walmart) on a hook, casting into pools I could see the bottom of.

I mention worms because one of the other dads was into fly fishing. Had all the gear. And he got made fun of that trip. Quite a bit. Which goes back to the first time I met Eldon. When I found out he fished, I asked, "Oh, do you fly fish?" He replied back in a deadpan, "No. I like to catch fish."

So when the line went tight, Eldon appeared at my elbow, coaching me through it. The pole was bending so much I thought it would snap. When we finally got the fish close enough to see, I was genuinely surprised at the size. About a foot long. In a creek I could practically jump across, right outside a house full of families on vacation.

The fish

We reeled it in and Eldon netted it quickly, cut the line and pulled the hook out with the efficiency of someone who’d done this a million times. “Hold it like this,” he said. “Get your finger under the gill. Support it.”

The trout felt solid yet completely alien, wiggling hard. It was maybe 11 inches/28 cm long, with spots along its flank. “Okay, bring it up so I can take a picture,” Eldon said. “Quick. Give me your phone.”

I held it up. The fish seemed to be getting heavier. Eldon snapped the photo. The whole thing took maybe ten (10) seconds. The trout was moving a lot less now.

“Now get it back in the water. Hold it facing upstream.”

I knelt down and lowered my hands back into the creek. The water was icy cold. The current stronger than I expected. The trout’s body was limp in my hands.

“Let the water flow over its gills” Eldon said. “Try to touch it as little as possible. Your hands — the bacteria and whatnot — are poison to it. Move it forward and back. Hold just the tail.”

I did as I was told. I held the trout’s tail with one hand like a flashlight, moving it side to side. I kept my left hand underneath but away from the fish, as though I was offering moral support. And I waited.

At first, nothing changed. My fingers and hands were tingling with the creeping numbness. I thought I saw the gills flutter but I wasn’t sure. I started to worry we’d done something wrong, that I’d kept the fish out too long, that this fish was going to die because I didn’t know what I was doing. It felt like forever.

And then I felt it. A slight tensing in the muscles — from nothing to rigid and waking up.

I could feel its tail flex against my palm. “You’ll know,” Eldon said. Once, then again, harder. I looked at him. He nodded. I loosened my grip and I let go

The trout hung there for a half-second, as if deciding whether to trust this status quo, this freedom in the same water. Then a flick of its tail. A thrash and it shot downstream into a deeper pool, disappearing so suddenly that I actually gasped.

After

“Pretty good size,” Eldon said.

“We just let it go,” I said.

“Yeah, man. We don’t keep what we catch out here. We don’t need it. The planet needs that fish more than we do.”

I stayed kneeling there for a few moments, hands still in the water, watching the spot where the trout had vanished. The sleeves of my jacket were completely soaked through. My hands were numb. It’d take me about an hour to warm them up fully. And I couldn’t believe that that trout — something so large and alive — was in a creek right outside a rental house, and I would have never known if I had hung back for another cup of coffee.

That fish is still out there, I hope.

Want to share your own moment of discovery? Hit reply and tell me about a time something made you stop and actually pay attention. I read every response.

If someone forwarded this to you and you want more of these thoughts on the regular, subscribe here.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

I've been writing and talking about human-centric product strategy and design for a while now — on Medium, LinkedIn, the How This Works show, and in this newsletter — but I haven’t really explained what this newsletter is about. Then this conversation happened that got under the bigger why.

So I was chatting with a startup founder last week who'd just closed his seed round of funding. We met at a coworking mixer and this was our first 1:1 conversation. We joked about his AI notetaker — I was taking notes manually and he wondered if it was slacking off. "I can't live without it," he said.

I agreed, saying how important it was to have notes.

"I use ChatGPT for everything," he continued, explaining that he had taken an advanced prompt engineering course from Sander Schulhoff. “I have the Pro version (of ChatGPT),” he declared.

“Did you build the app in ChatGPT,” I asked.

“No,” he said. “Used Bolt. Hired a friend of a friend who’s an engineer. Took about three weeks.”

"Sounds like you've got it together," I said. "You mentioned before that you all have more than a thousand users. That's great."

"1,250 now," he said. "Over 1,250."

"What can you tell me about them?" I asked.

"Well, they want to be more productive," he said. "Looking for efficiency." A pause. One, two, three, four, five. "We did some research early on, but you know, customers don't know what they want."

I've heard so many versions of this. ‘Customers say one thing and do another.’ Or ‘you can't just ask customers what they want.’ This isn't a singular problem to him. And it's not specifically even a founder issue either. It happens when you have really powerful tools/frameworks and get busy with process with pent up bias, but no clear picture of who they’re building for.

The pattern

I've been seeing this pattern for a while: clients would come in with a variety of different asks — dashboards, chatbots, a website overhaul, making complex customer processes, etc. We’d sign the work, then we’d level set, establishing the current state, interviewing stakeholders and team members, looking at previous work. All this to get to some success state.

But when I'd ask about their customers, they'd get vague. Sometimes, defensive. "Well, they're professionals in their 30s who are really focused on doubling their output.” Or even worse, say nothing. Or they’d produce outdated customer surveys, a stack of NPS documentation, or personas made without being based on any kind of user research.

Here's an experiment: think about your last three customer conversations. Not surveys or analytics dashboards — actual conversations where you asked someone about their day-to-day problems. Can you remember specific quotes? Specific pain points they described?

Now think about your last three conversations about AI tools or new features. I’ll bet those are easier to recall.

I had a conversation last fall with a startup CTO who worked for a company with a few months of operational runway left. They’d closed a series A worth $5M a couple of years before, but had squandered it with shiny demos and pet projects but never once moved their core metrics or had business growth not related to ad spend. Turns out their customer hypotheses were not only wrong but also so expensive.

They'd gotten really good at what looked like product work — using the most current tools, making pitch decks, workshops, etc. Like product theater. They had no idea what problem they were actually solving and burned through so much cash in about 30 months.

(In case you’re wondering, the CTO joined a new company in Jan. He’s okay. The new company has a robust customer experience practice who has a rotating board of customer advisors along with other best in class practices. Coincidence?)

Why I started this

We've got all these new capabilities now, but we're still making the same old mistake of building first and asking questions later — if ever.

The companies I see thriving aren't necessarily the ones with the most advanced tech. They're the ones who understand what job their customers are hiring them to do. Then they figure out how to do that job better than anyone else.

Most of the conversation splits into camps. You've got the tool enthusiasts talking about what's possible. You've got the research folks talking about what customers want. And there's this gap in the middle where the actual building happens.

That's what this newsletter is about — connecting what you learn about people to what you build for people. Connecting our product and design work to business outcomes.

What you'll get here

Every week or so, I'll share something I'm seeing around this. Maybe it's a technique that gets a team aligned on who they're serving. Maybe it's a case study about something that worked. Or maybe it's just me thinking out loud about how understanding people and building for people fit together.

No frameworks disguised as wisdom.

Just curiosity about how this stuff actually works in practice.

Looking ahead

Most teams I work with are building things for people they've never talked to. But the moment you start connecting what people actually need with what you're building (or capable of building), everything gets clearer.

When you solve a real problem for a specific group of people so well that they're eager to pay for it, you haven't just built a product. You've built something that sustains itself. Assuming, of course, it's a sizable market and the business fundamentals work.

I wonder, What would be different if you knew exactly who you were building for and what they were really trying to accomplish?

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

If you're wrestling with any of this stuff or tired of building features based on assumptions instead of real customer understanding, just hit reply. Let’s have a talk.

And if someone forwarded this to you and you want more of these thoughts on the regular, subscribe here.

The insight killing problem

Teams think customer interviews are for validating solutions or collecting feature ideas. This leads to questions like "Do you like my idea?" or "Would you use a product that...?"

I my experience, this gets you polite, useless feedback. Rob Fitzpatrick calls these "Mom Test" failures.

I've seen this happen dozens of times. A product team schedules a number of customer interviews, asks about their work-in-progress solution, gets enthusiastic responses, and walks away confident they're building the right thing. And then, some months later, they wonder why nobody's buying.

The goal shouldn’t be validation. It's discovery. You're there to uncover the customer's problems, context, and motivation through their past behavior. You want facts about what they've actually done, not opinions about what they might do with your product in some future version.

So, the two biggest mistakes teams make are:

• Seeking validation, not facts — asking about their solution rather than the customer's life. "Do you think this feature would be useful?" instead of "Tell me about the last time you tried to solve this problem."

• Asking for opinions or hypothetical situations — "How much would you pay for this?" instead of "Walk me through how you decided to buy your current solution."

People are terrible at predicting their future behavior. We also tend to be polite when giving feedback on someone else's idea. Past behavior is the only reliable predictor of future behavior.

Why bullseye customer interviews should be different

Traditional user interviews cast a wide net. Bullseye customer interviews focus on those customers that will say some version of “just take my money” — hopefully a sizable market.

This isn't about demographics. It's about finding people who've experienced specific trigger events that make them key for your solution. Someone who just got promoted to VP of Sales has different needs than someone who's been in the role for five years.

The 1.0 approach of the bullseye customer sprint was basically a copied version of the the Google Ventures "Learn More Faster" model with a change or two. Keep in mind the original GV method focused on discovering customer problems. Bullseye Customer Sprint 2.0 builds on that, pulling from April Dunford's positioning work and Jobs-to-be-Done principles. It's about understanding not just what customers do, but why they hire solutions and fire them.

The key differences:

• Laser focus on trigger events — recent changes that prime people to be receptive

• Comparing value propositions, not just features — using prototypes to understand positioning and messaging

• Live team observation with side-channel influence on the conversation

• Discovery-first structure — understanding their world before testing any assumptions

When prep misses the point

Here's where teams usually go wrong: they think preparation means writing better questions. Questions matter, but what matters happens before you ever talk to a customer.

At this point, I've conducted hundreds of these interviews across healthcare, travel, fintech, and B2B tools. The quality of your prep determines whether you get breakthrough insights or polite nods.

Interview guide development

For a 30-minute section, I usually keep it to 7-9 questions with a few backup questions. Lots of notes on the side. And the 60-minute structure is always the same, 30 minutes of discovery first (past behavior and context), then 30 minutes for assumption testing with prototypes.

But here's what most people miss — the questions aren't just what you ask. They're your roadmap for staying curious instead of falling into validation-seeking mode. Each question has backup options because real conversations don't follow scripts.

The guide keeps me focused on their world, not my assumptions about what matters to them. It’s a guide, not a script.

Looking at the right kinds and numbers of prototypes

Typically, I’m looking at two prototypes with slightly different value propositions. Sometimes it's a standalone web app, sometimes rough wireframes, sometimes a Figma prototype. The format matters less than having two distinct approaches to compare.

Why two instead of looking at one more in-depth? The comparison is key. And in a 25-minute prototype section, two gives you enough contrast without overwhelming people. I've tried three in shorter sessions and that works okay but I find that two is the sweet spot to avoid surface-level feedback.

Keep in mind, the prototypes aren't about testing usability. They're conversation starters that reveal what customers actually value versus what they say they value.

Often, after the prototypes, something else will come up that got skated over in the first 30 minutes. Best to keep the space to retread previous ground to get a deeper picture of their context.

Pre-interview research

This is where I probably spend more time than most people expect because it's where the real insights start forming.

For each participant, I:

• Scan their LinkedIn for patterns — how long they've been in their last few roles, the types of accomplishments they highlight, industry context that might shape their perspective

• Review their screener responses, especially their answer about their biggest challenge right now

• Look for conversation hooks — shared connections, recent job changes, company news that might affect their priorities

This isn't stalking. It's prep. When you understand someone's professional context, you can ask better follow-up questions and connect their responses to their actual world.

The streaming setup

Here's something that sets my approach apart: while I'm conducting 1:1 interviews, my clients observe live through a stream. I get permission to record before we start, but I don't mention the live audience to keep the conversation natural.

My current setup: sharing Zoom screen through Google Meet to the client team. I previously used a more complex Zoom → OBS → Restream → YouTube Live chain, but the simpler approach works better. 95% reliability versus 80%. Even with the double video encoding.

But than the how, is the why around live streaming — the client team can send me real-time follow-up questions through a side channel (Slack, Discord, Messages). This directly influences the conversation in real-time without breaking the intimate 1:1 dynamic.

After the interview, I post the recording as an unlisted YouTube video with the VTT transcript for team members who couldn't attend live.

The reality check around scheduling

I've adapted the GV model from doing all interviews in one day to 2-3 interviews twice in the same week.

Google Ventures has leverage I don't have. When GV says "we're doing research," portfolio companies clear their calendars. When an external facilitator like me says it, teams need more flexibility.

The modified schedule works better anyway. Teams can process insights between sessions and come back with sharper questions. And frankly, watching five hours of customer interviews in a row is mentally exhausting. Breaking it up keeps everyone more engaged.

Why external facilitation isn't a “nice to have”

Teams often ask why they need someone external to do customer interviews. The answer comes down to objectivity that it’s hard for internal teams to achieve.

• You bring baggage. When you're building something, you want it to succeed. That desire subtly influences how you ask questions and interpret answers. Customers pick up on this energy and adjust their responses to be more helpful, which means less honest.

• They want to help you. When customers know you built something, they become co-conspirators in your success. They'll soften criticism and amplify praise. An external facilitator doesn't trigger this dynamic.

• You miss the subtext. Internal teams focus on what customers say about their product. I focus on what customers reveal about their world — the context that determines whether your solution actually fits their life.

I've seen product teams convinced they had strong product-market fit because customers said positive things about their prototype. But it was guilt or misguided information. And when I dug into the discovery conversation, those same customers revealed they'd tried similar solutions before and abandoned them. Or that my client’s competition was doing nothing, it just wasn’t dire enough. That context changes everything.

What clients experience in real-time

Observing live creates something that recorded sessions can't: immediate team alignment around what matters to customers.

I watch product teams have real-time "aha" moments when they see their assumptions challenged by actual human behavior. A product manager discovers the feature they've been debating for months solves the wrong problem. A founder realizes their key differentiator isn't what customers care about.

The side-channel messaging lets the team dig deeper on surprising responses. If a customer mentions something unexpected, the team can ask me to follow up immediately rather than waiting weeks to schedule another interview.

Most importantly, teams leave these sessions with shared understanding. No one can later claim "that's not what the customer meant" because everyone witnessed the same conversation.

The six week ROI

Why dedicate six weeks to this process instead of just building and learning from real usage data?

Because the cost of building the wrong thing grows exponentially. It costs 10x more to fix a problem in development than in design, and 100x more to fix it after launch with real customers.

But here's the deeper value: six weeks of customer discovery creates clarity on priorities that cuts through all the noise. Stakeholder requests, competitor feature envy, internal opinions about what users "obviously" want — it all becomes secondary to what you've learned about your bullseye customers.

When teams understand their bullseye customer deeply — their triggers, context, and real motivations — they stop building features that seem logical and start building solutions that customers actually hire.

The prep work isn't just helpful. It's what separates actionable insights from polite lies.

In a world where most product decisions are still based on internal opinions rather than customer evidence, that difference determines who builds products that actually matter versus products that make sense in conference rooms.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Next time, I'll walk through what happens after the interview — how to pull insights from hours of conversation and turn them into product decisions that stick.

Need outside thinking on a tough business challenge? Book an intro call with How This Works co

Okay, you're 45 minutes into the weekly project meeting when someone asks, "Wait, what did we decide about the pricing and features comparison table?" Three people give three different answers. Sofiia, she's running the meeting, looks confused. Everyone else shrugs and is wondering if they missed something.

This isn't a meeting failure. I mean it is a failure, but not strictly because of the meeting. It’s your brain working exactly as designed.

Here's what most people don't realize about meetings — they're cognitive minefields. We pack them with so much more information and points of action than our brains can actually handle, but then we’re surprised when nothing sticks.

The research

A few years back, I was nerding out on the notion of context switching and I stumbled across Nelson Cowan's 2007 work on working memory. It turns out humans can really only hold 3-4 chunks of information at once, not what I’d always heard as the 7±2 from George Miller's 1956 research. But then, I dug deeper into what Miller actually said. Turns out it only applied to very specific memory tasks, not the complex discussions happening in your conference room with all of our modern distractions.

Once I’d learned it, I began seeing it everywhere. I'd notice this in workshops, meetings, and check-ins. Often, in a list of about 10 things, people would remember so few of them. Maybe 3-5 and usually the ones at the beginning and end. The stuff in the middle? Flat gone.

Sound familiar? How often do you remember the middle part of a long meeting?

Then there are the other cognitive realities we ignore:

• Your mental resources actually deplete as the day (and night) goes on

• Context switching creates up to 40% efficiency loss

• All sorts of biases play here, like authority bias means people give disproportionate weight to whoever has the most seniority or recency bias makes the last thing discussed feel most important, etc.

No wonder we end up having meetings about meetings, to clarify what happened in the original meeting. And we’re exhausted by it all.

What actually works

The solution isn't to give up on meetings.

It's to work with our human brains, not against it.

Start with your most important decision when people are freshest. Break complex topics into smaller, digestible chunks. Give people time to process individually before jumping into group discussion. Write key points down in a place where everyone can see them and they don't disappear into the ether.

Most importantly — limit the number of outcomes you're trying to achieve. If your agenda has seven bullet points, your team's working memory is already overloaded before you even start. Cut it in half.

I started applying these insights with clients and teams I work with. Instead of cramming everything into one "strategic planning session," I recommend tackling one decision at a time. Instead of talking through problems in real-time, we'd start with individual thinking, then build up to group discussion. Focus in before flaring out.

The difference has been noticeable. People seem to remember what we'd discussed. Decisions stuck. Follow-up meetings became less necessary because we'd actually covered the ground fully and less of it.

Looking back

Most teams I work with are fighting their own cognitive architecture without realizing it. But once you understand how the brain and its working memory actually functions, the path forward becomes clear.

What would change if we started designing meetings around how people actually think and process information?

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Tired of meetings where nothing sticks and decisions disappear into the ether? Let's make something better together. Book an intro call with How This Works co

We've all been there. Fifteen minutes to your next meeting, the monthly strategic review one you hate — the same one that everyone hates. In these meetings, there are two modes: either everyone’s talking over one another, René (she owns the meeting) is frantically trying to stay on schedule, or it's dead silent, with people clicking around on their phones and computers.

Sound familiar?

I've been in thousands of meetings over the last nearly 15 years — pitches, workshops, lectures, and countless other formats. But, in a way, it’s the same. The loudest person sets the direction. Quiet team members check out. Someone takes notes that few people ever look at. We leave with vague "next steps" that never quite get done.

But here’s what I realized recently: most meetings aren't broken because people don't care. It’s because we're treating them all the same. We default to the same format every time: one person talks, everyone else listens (or pretends to), and hopefully, something actionable emerges. It’s like using a hammer for every job, whether you're hanging a picture or performing surgery.

What changed my perspective

When I started How This Works co last year, I realized it was to my benefit (and whoever I was meeting with) to actively spell out the purpose of every encounter. Was this a sales pitch? A kick off? A workshop debrief? Or something else entirely? So, I started approaching meetings as I approach product design. I asked: Who's the user? (Read: your team or my client.) What job are they trying to accomplish? (Brainstorming, making a decision, aligning on next steps.) And what's getting in their way? I’d sign post it verbally and away we’d go.

When you look at meetings through this lens, the problems become obvious. We're asking people to absorb a ton of information, generate ideas, make decisions, and coordinate follow-ups — all in the same 60-minute block, often after they've run from a series of other back-to-back meetings, context-switching the whole way.

Cognitive research backs this up. Nelson Cowan's work shows we can really only hold 3-4 chunks of information at once, yet we overpack meetings — we’ll talk about that in the next article. Add in context switching, decision fatigue, and authority bias, and it's no wonder people leave feeling confused and drained.

What happened

So, I started small — the aforementioned stated purpose. And then instead of jumping straight into discussion, we might spend five minutes writing down individual thoughts first (working alone together). This way, instead of one person frantically taking notes, everyone was their own secretary. Many fewer bottlenecks. And instead of trying to solve everything at once, we'd tackle one decision at a time.

The results began to show up. That wallflower engineer in the first three meetings who seemed like they were completely checked out? He started contributing ideas we'd never heard before. Not because he suddenly cared more, but because the structure finally gave him space to think.

Looking back

This isn’t perfect. Being aware and upfront doesn’t make all meetings instantly better. But meetings also aren't inherently bad — they're just poorly designed and badly managed for how people actually think and collaborate.

What would change if we started treating meetings like any other design problem? With users (read: your team) who have real constraints and real needs?

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Do you have a chaotic spot in your business that could benefit from outside support and thinking? Book an intro call with How This Works co

When I joined Sesame as founding designer in Oct 2018, we had a big goal — launch our web app in three (3) months. Yep, you read right. About 90 days. No pressure to launch a two-sided healthcare marketplace from scratch that didn't yet exist in Kansas City from New York City.

Simple, right?

I'd just spent 5+ years working at Fjord where user/customer research was more formalized — scheduled interviews, vetted processes, and statements of work (SOWs). At Sesame, we didn't have time for formal anything.

So I proposed that every other Friday afternoon, we'd take three (3) $20 Amazon gift cards and head downstairs to the WeWork common area in Brooklyn Heights. Then, approach random people working on laptops or eating and ask if they had 45 minutes to look at something we were building.

The conversations I remember

There was the guy who clicked through our first set of Figma wireframes and said, "I don't get it. Why can’t I use the map to search?” Okay. Fair.

Or the woman who spent 10 min looking for doctor ratings and reviews. Partly, it ended up being an issue having to do with touch target size, poor color contrast, and buried under too many clicks. We thought it was clear. But it wasn't.

And the programmer who was all in on the Hotel Tonight concept but got confused during the signup flow, asking, "Wait, am I done?"

These weren’t polished research sessions, by no means. We’d scribble out paper sketches. Once, we taped one to each of our phones. We scraped together minimal Figma prototypes. Sometimes, we were talking through ideas with a static PDF.

What actually mattered

Our director of product, Priya, and co-founder Mike would join the sessions after the third week. Watching people struggle with the date picker we’d been working on for weeks was painful but got us to fix it. We ripped it apart and rebuilt it from the ground-up. Not because I told them about it later, but because they saw it and heard it themselves.

The conversations weren't necessarily revealing earth-shattering insights. They were preventing obvious mistakes. The kind of mistakes you make when you assume people think like you do, when you build and test everything inside your office bubble without ever venturing out.

We'd capture what we learned immediately — right after each conversation, writing down what surprised us, what confirmed our thinking, and what we needed to change. Nothing fancy. Just a shared doc that grew to 35 tests by launch.

Looking back

Most teams I work with now have way more resources than we did. Bigger budgets, research teams, proper tools. But they talk to customers less frequently than we did with gift cards and a laptop in a co-working space.

I can't figure out why the barrier still feels so high. We were desperate and had no choice. Maybe that's what it takes — running out of time to do research "properly" so you just start talking to people.

Five conversations a month. Start there. The perfect research plan you never execute isn't better than the imperfect conversations that actually happen.

What's your team's excuse for not talking to customers this week?

I’m sure I’ve heard it before.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Do you have a chaotic spot in your business that could benefit from outside support and thinking? Book an intro call with How This Works co

Making strategic choices when the playbook isn’t written

While researching early aviation claims last week, I kept running into mentions of Gustave Whitehead's aircraft engine work. Sure, controversy surrounds Whitehead's claims that he flew a powered machine successfully in 1901 and 1902, predating the Wright brothers' 1903 flights. But whether or not you think he flew first, he was well known and sought out for his ability to make aircraft engines.

George Lawrence, another pioneer in the field, specifically sought him out for several engine projects. Other inventors bought his engines too. There was actual documented demand for what Whitehead could and did build.

And yet, Whitehead kept splitting his attention between what people would pay for and what might make him famous. This isn't about poor business strategy — I think it's about the challenge of making strategic choices when you're operating in a market that barely exists.

Sound like anything else going on right now?

cough, cough AI cough, cough biotech cough, cough crypto cough, cough.

The market that was starting to exist

Early 1900s: Aviation was totally experimental. Most inventors built their own engines or modified existing ones. But there were signals that a separate engine market might emerge. Whitehead's lightweight engines attracted attention from other inventors.

Charles Wittemann installed one of Whitehead's engines in a helicopter attempt. The craft didn't fly, but the engine worked well enough that people noticed. Whitehead displayed engines at aviation exhibitions and got orders.

1908: This is when Whitehead partners with George Lawrence to form Whitehead Motor Works. They built engines in three sizes: 25, 40, and 75 horsepower. Real products with real specifications for a market that was tiny but starting to take shape.

But this wasn't like entering an established industry. The entire field was being invented in real time. Literally, like building the plane while it’s flying.

Thanks, folks. I’m here all week.

Where the constraints apply

Whitehead was an immigrant inventor with limited business connections — and faced lots of inherent challenges that made business difficult. Especially in the burgeoning field of aviation as he lacked access to capital and distribution networks. His business practices were unsophisticated — he was sued many times by customers and often hid his equipment to avoid seizure.

All the while, he kept diverting resources back to aircraft experiments. Part persistence, part necessity — proving he could fly might have been seen as his best shot at attracting serious backing. This is me speculating, not sure if this is true.

Personal challenges

Whitehead lost an eye in a factory accident and suffered chest injuries that contributed to ongoing health problems. By 1915, he was working factory jobs, possibly as much from physical limitations as business failure.

1927: Whitehead died of a heart attack while trying to lift an engine out of a car he was repairing.

The pre-market problem

While it's unclear whether focusing solely on engines would have saved Whitehead's business, the early aviation market was essentially inventors commissioning custom work from one other. Most successful aviation companies of the era — Wright, Curtiss, others — did both engines and the aircraft structure work. Specialization wasn't viable when your total addressable market was as small as it was then.

Whitehead was essentially trying to build developer tools before there were enough developers to sell to. Or much of anything to develop. Compare this to any inventor working in a field that barely exists. You're not just building a product — you're trying to figure out if there’ll be a market at all.

What this teaches us about focus in pre-markets

The quip about focus — "do one thing really well" — assumes there's a sizable market for that one thing. When you're creating the market itself, the rules are different and how institutions shape which stories survive and how they get told.

The positioning lesson: When markets barely exist, the "right" strategic choice often isn't clear until years later. Whitehead's split focus might have been rational given that neither engines nor aircraft had proven commercial viability in 1905.

This matters when building in emerging fields today. Sometimes you need to pursue multiple opportunities until one proves the market exists. The risk of premature focus can be as dangerous as spreading too thin when you're not sure there's a market to focus on.

The stories we tell about innovation often assume markets existed when they didn't. Or maybe that’s the wrong tense — markets exist when they don’t. Whitehead's challenge might have been about timing and access to capital as much as strategic focus.

Worth remembering when you're making strategic choices before markets form. Strategic choices in one light, bets in another.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Does your business have a messy, complex challenge that could benefit from someone else? Book an intro call with How This Works co

A Fortune 100 healthcare financing company once told my team and I that they knew everything about their customers. They had surveys, focus groups, personas, and a data lake of information to prove it.

But when we dug deeper, what they called "research" was demographics and market segments. Not customer insights.

There's a difference between knowing who your customers are and understanding what they actually need.

What we discovered

We ran two workshop sessions to figure out their business context and ideate, then dove into 10 customer interviews over two weeks.

The prevailing belief inside the company was clear: customers weren't using their healthcare financing because of affordability concerns. They thought people wanted longer payment terms or were avoiding services entirely because of costs.

Their data supported this theory. Survey responses about price sensitivity. Focus group discussions about payment preferences. Personas that highlighted budget constraints.

But that wasn't it at all.

Like every time customers are actually talked to, we learned something fundamental. Customers weren't hesitating because of costs. They didn't know where to begin. It was uncertainty, not affordability.

I remember one of the interviews — a woman was waiting in her car for the paycheck casher to open, wondering if we'd agree to pay $15 or $50. You can't learn that from surveys or spreadsheets.

The gap nobody saw coming

Market research had told them who their customers were - demographics, income levels, geographic distribution. All accurate. All useful for targeting and segmentation.

But none of it revealed why customers hesitated at the moment of decision. The surveys asked about affordability because that's what the company assumed mattered. The focus groups discussed payment terms because that's what seemed logical.

Real customer conversations revealed the actual barrier: process confusion. Customers didn't understand when payments would start, how approval worked, or what would happen if their situation changed.

What $2M looks like

With 10 conversations, we ended up streamlining their application workflow and created clear timelines. The projected impact? A 10% increase in service signups — that would've been about $2M retained annually.

Time invested: About 20 hours of interviews and analysis. Potential annual return: $2M in additional revenue. All from conversations that took less than two days total.

If a Fortune 100 company with massive budgets and dedicated research teams can be this wrong about their customers, what does that say about smaller teams operating on assumptions?

The difference that matters

Subject matter expertise tells you how your product works. Market research tells you who might buy it. But customer insights tell you why they make the decisions they do in the moment that matters most.

You can't get that from demographic data or survey responses. You get it from watching how people actually work, listening to their language, understanding their real context.

What truths might just five (5) focused customer conversations unlock for your business each month? It's a small investment with potentially massive returns.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Feeling like you're too close to a problem to see it clearly? Let's explore how an outside perspective might unlock what's next. Book an intro call with us

I keep running into the same weird pattern.

Nearly every team I work with tells me they "know exactly what customers want." But when I ask when was the last time they talked to one, not for tech support or testing something out, there's this pause. And usually a guilty look. It might be weeks. Often, months. And a few times, it's been almost never.

And when I say knowing what customers want, I mean more than that. What these real humans want, need, their goals, their pains. When did we stop talking to the people who should be buying our services, experiences, and goods?

The drift happens gradually. You started with real customer insights (hopefully), then slowly replace them with support ticket summaries, competitor feature lists, and conference room assumptions. Maybe your company ponied up for some personas work/map — now you're asking 'What would Tatiana the team lead do?' instead of talking to actual Tatianas. Each slide/substitution feels reasonable.

But the real problem is that you’re having fewer and fewer conversations with actual human beings. And soon, you're building features based on pure guesswork. And that feels normal.

Note: the image at the top of this piece is from Giff Constable’s ‘Talking to Humans’ (www.talkingtohumans.com), illustrated by Tom-Fishburne.

_________ isn’t the problem

A while back, I worked with a healthcare staffing company that spent two hours every week onboarding new customers. Two hours. A week. Then another hour every six months for updates.

They’d come on for dashboard redesign work in a web app. General updates of existing patterns, needed to be responsive. When asked what was their biggest problem? They said, “Simple. We need a better dashboard. You know, better UX/UI design.”

But as we started talking to their customer support team, alarm bells went off left and right. And we were able to talk to two of their customers, it seemed more and more like the interface wasn’t the main culprit here. It was that they'd built out their entire staffing process in a way that made sense internally but very little to the people who had to use it. And completely backwards to their bosses who paid for it. So, companies were churning out, looking for other solutions. Or, with one, to make their own processes baked on top of existing tools.

And in some ways, this was obvious to most everyone on the team. But leadership had identified this other problem. Confidently to the point where no other opinions or input was possible. Proving, once again, that the most elegant solution to the wrong problem is still wrong.

What I can't figure out

Why do some people become so confident about customer needs without actually having customer conversations? You don't need to talk to hundreds or thousands of people. According to most user research experts, talking to 5-15 people in qualitative research typically uncovers the same core insights as talking to 100s.

If you only talk to five (5), it’s better than none. And if you have a regular cadence and you talk to one weekly, over the course of three (3) months talking to a customer a week, you'll have 12 real data points instead of a bunch of assumptions.

I think there's something about being close to a product that creates false certainty. You know the features inside and out. You understand the intended user flow. You've thought through edge cases.

But your customers don't live in your head. There's a gap between your mental model and their reality.

And the fix is simpler than it may seem. Schedule five (5) customer conversations this month. Just five (5). Do one a week.

You'll be amazed what you learn when you stop guessing and start asking.

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Do you have a hairy problem in your business that could benefit from outside thinking and support? Book an intro call with How This Works co

What I ended up learning as a result of an offhand comment about Orville Wright not having a pilot's license

This week's "what I learned" started with someone saying offhandedly, "You know, Orville Wright didn't have a pilot's license." The underlying point being that expertise often follows innovation rather than preceding it.

Which lead me to Samuel Langley and the Smithsonian. Which I knew a bit about. And then, Gustave Whitehead and other claims of powered flight before 1903. Suddenly I'm looking at an example of how truth can be stranger than fiction, some about institutional influence, and then fashioning what gets written up in textbooks and laid down as true history.

Okay, let's go back in time.

The original venture-backed moonshot

1898: The U.S. War Department funds Langley's aviation project with $50K (nearly $2 million in today's money). The Smithsonian puts in $20K. This makes it essentially the first government aerospace R&D program. So, Langley, the third secretary of the Smithsonian, is running what we'd recognize today as a venture-backed moonshot with heavyweight institutional backing for human-powered flight.

Think about the advantages: substantial funding, skilled machinists and instrument makers, the full resources of a government department and major institution, plus an experienced leader with scientific credibility. Everything you'd want for a breakthrough project.

1903: Langley's expensive aircraft crashes into the Potomac River. Twice. The pilot has to be rescued from the water both times. Then, the same week, two former bicycle mechanics succeed at Kitty Hawk with no outside funding, no institutional support, just methodical trial and error along with grit.

The government-funded effort with every advantage fails. The bootstrap effort succeeds.

The institutional response

Rather than acknowledge the failure and move on, the Smithsonian doubled down.

1914: Eleven years later, the Smithsonian secretly rebuilds Langley's crashed plane. They make major structural modifications — reducing wing area, strengthening the frame, upgrading the power train, adding floats, modifying the tail. They fly it for a few seconds and display it in their museum as the "first heavier-than-air machine capable of sustained flight."

This wasn't what happened in 1903. It was engineering a new aircraft and claiming the original could have flown.

1928: Orville Wright finds out about the deception and is furious. Instead of donating the original Wright Flyer to the Smithsonian, he sends it to the Science Museum in London in protest.

This is how one of the most important artifacts in American aviation history leaves the country because its logical home institution lied about who flew first.

The cascade effect

1942: After 14 years of public embarrassment, the Smithsonian admits to the modifications and retracts the story about Langley.

1948: To be able to display the Wright Flyer, the Smithsonian signs a legal agreement with Orville Wright's estate. The terms: if they ever recognize anyone else as achieving first powered flight, they lose the plane. The agreement is still in effect.

So a single moment of institutional face-saving in 1914 created a legal framework that still affects the way aviation history is told.

The Whitehead problem

Multiple people have claimed powered flight before 1903, including Gustave Whitehead in Connecticut (1901). There were witnesses. Newspaper coverage. The evidence isn't definitive — no clear photographs exist, witness accounts came later and sometimes contradict each other. Even Whitehead's wife said she never saw him fly, though she quoted him saying "Mama, we went up!" after his purported August 1901 flight.

Many mainstream aviation historians have reasons to dismiss the Whitehead claims. But the state of Connecticut officially recognizes Whitehead as first in flight. And the Smithsonian legally cannot, regardless of what evidence might surface. Unless they want the Wright Flyer to go elsewhere.

What this teaches us about positioning and innovation history

This isn't really a story about who flew first. It's about how institutions shape which stories survive and how they get told.

The Smithsonian's 1914 lie was meant to protect their reputation after a failed project. It created a 30-year legal battle that ended with a contract that may prevent objective evaluation of historical evidence. Each attempt to fix the previous mistake created new constraints that were harder to escape. Since 1982, the most popular North Carolina license plates have said, "First in flight" with a blue outline of the Wright Flyer in the background.

I think this says something crucial about how innovation gets positioned in history. Institutions have the resources to shape narratives long after the fact. The Wright brothers succeeded, but they also benefited from having their story validated by the very institution that initially backed their competitor. Langley's failure got buried, then artificially resurrected, then buried again. And Whitehead's claims are largely unknown outside of Connecticut or aviation circles — along with many others.

Meanwhile, countless other innovators — particularly women and people of color — operated outside institutional frameworks entirely and often disappeared from the historical record altogether. For instance, Madam C.J. Walker built her cosmetics empire around the same time as these aviation experiments, becoming America's first self-made female millionaire through bootstrap entrepreneurship. But her innovations in chemistry and business rarely get mentioned alongside the "great inventors" of the time.

The positioning lesson: proximity to institutional power often determines which innovations get remembered, not just their objective merit. To circle back to the initial quote, the Wright brothers weren't aviation experts who got certified to fly. They were curious problem-solvers who created the field that eventually created the credentials.

Expertise follows innovation more often than it precedes it. But institutions can have massive impact on how that sequence gets remembered and taught.

This matters when we're building today's innovation narratives. Who gets credit? Which failures get acknowledged versus buried? Because the stories we tell about past innovation influence how we think about present opportunities.

Worth remembering when we're positioning the breakthroughs that will become tomorrow's "established facts."

Expertise follows innovation more often than it precedes it. But institutions can have massive impact on how that sequence gets remembered and taught.

This matters when we're building today's innovation narratives. Who gets credit? Which failures get acknowledged versus buried? Because the stories we tell about past innovation influence how we think about present opportunities.

Worth remembering when we're positioning the breakthroughs that will become tomorrow's "established facts."

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

Do you have a hairy problem in your business that could benefit from outside thinking and support? Book an intro call with How This Works co