One of my vibe-coded apps, which has been on the market since February, has been slowly gaining paying customers.

Pricing has been something that is new to me, so I’ve been dabbling with different approaches - trying to find the sweet spot.

I doubled the price of my HVAC Load Calculator app a few weeks ago just to test the waters. Ten minutes in RevenueCat, a few updates in the app stores, and the changes were ready to go.

I half-expected trials to drop. But they did not - somehow they stayed consistent (#winning). The few weeks brought twice the revenue from the same paying customers.

The app now has 100 paid subscribers. And although I’m ecstatic about the wins here, what surprised me is that the whole test cost an afternoon of work.

Shipping a test that quickly isn't always possible, but doing the work to determine when a test is worth running is.

The HVAC pricing was one of three experiments this year. The other two went differently.

Another one of my vibe-coded apps (another calculator) raised a different question: was paid pricing even the right monetization shape for it?

I added a paid tier as a test. Twenty downloads a month wasn’t enough volume to read any pricing signal. So…I killed that test after a couple of weeks.

Which raised a smaller question: if pricing won’t tell me anything yet, what will? I pivoted the same app to subtle in-app advertising, using ad networks to track signals while generating a few dollars in revenue. The “Is this app worth pricing?” question can wait until I know what the Discovery Math looks like.

The work was in figuring out what to test, not in shipping it.

Leave a comment

Inside a company, the apparatus around a test exists for real reasons. Pricing changes affect real customers. Brand promises matter. Compliance is real.

But the engineering used to be the expensive line item. Once it stopped being expensive, the apparatus didn’t shrink to match. Where corporate testing slows down now has more to do with the apparatus than with how hard the work itself is.

Your expertise is the lever indies don’t have. Years of research sessions, pricing decisions, and competitor analysis. You already know what we have to learn the slow way.

Use it to remove apparatus where you can. Skip the precision that isn’t load-bearing.

A directional answer in a week beats a perfect one in a quarter. Most of a PM's credibility is spent justifying why a test needs more rigor.

The durable version is justifying why it needs less.

Design is half the work. The other half is getting the test approved.

Two moves when you can’t ship the test yourself:

1. Frame the test as a probe. “We don’t know if X will work. Let’s run a two-week experiment and see what we learn.” plays better than “We’re proposing a six-month strategy around X.”

2. Design the test before you propose it. Hand someone a clean brief with the cohort, the success metric, and the kill criteria set, and most of the friction is gone.

100 paid subscribers, no analytics, three tests this year. One worked. One died. One pivoted into something I didn't plan. That's testing when the apparatus goes to zero. Yours probably won't.

But the gap between what your tests cost and what they should cost is wider than you think. The expertise to close it is already in your head.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

Stack Overflow asked roughly 49,000 developers what frustrates them most about AI coding tools. The top answer, from 66 percent, was code that is almost right but not quite.

It compiles, runs, and looks correct, then does the wrong thing in a way you catch three weeks later.

You can name how AI fails. You probably can’t name how your spec invited the failure.

Product managers have done the reading on AI risk. Hallucination, bias, data leakage, and model drift. Everyone can recite the list.

That list is part of the curriculum that everyone studied. The spec problem is the part nobody assigned.

A controlled study this year put sixteen experienced developers on their own codebases, with and without AI. The work took 19 percent longer with AI.

The same developers were sure it had made them 20 percent faster. The slowdown is not the point. None of them could feel it.

This lands on product people for a reason that has nothing to do with the model.

Researchers studied how developers specify work for humans versus AI agents. For humans, they wrote a compass. The intent, the goal, and trust in the person to handle whatever nobody wrote down.

For AI, they wrote railway tracks. Every path laid is followed because the agent follows the letter of the instruction and ignores the intent behind it.

For fifteen years, the compass worked. You wrote “let users filter by date range,” and an engineer who knew the product asked what happens with an open-ended range, which time zone it uses, and what the empty state says.

Those gaps got closed by someone who cared how they closed. You were never the only person thinking about the product. It only felt that way.

The agent does not ask. It builds the open-ended range as a crash, picks UTC because it was first in the library, ships an empty state that reads “undefined,” and reports the task done.

It built exactly what you wrote. That is the problem.

A wrong build used to be cheap to catch because you had time. NASA’s old data put the cost of fixing a requirements error at the spec stage at 1 unit and, after release, at up to 1,500.

The gap between a written spec and running code used to be weeks of reviews and QA. With an agent, it is an afternoon, so the error lands in something deployable before anyone has looked at it.

Strip the tooling away. The product manager’s value was always some version of “I know what to build.”

That knowledge could live partly in your head, because the people building it interrogated it on the way down. The interrogation is gone.

What you know is now worth exactly as much as you can write precisely enough that a literal executor cannot get it wrong. The PMs with real clarity and loose documentation habits are about to learn which one was carrying them.

AI removed the people who were quietly covering for the gaps in your product thinking. The gaps were always there. You just never had to see them.

Leave a comment

You spent a career learning to write compasses. Track is a different skill, and it is the most fixable problem in this entire piece.

What follows is just the questions a good engineer used to ask you, written down before anyone has to ask them.

Five places to start this week:

1. Take your last spec to someone with zero product context and ask them to list every decision they’d have to make to build it. That list is what your agent is guessing at. Close the three biggest gaps now.

2. Add an out-of-scope section to your next spec. Write what you are deliberately not building. Every line you leave out is a line the agent fills for you.

3. Write the edge cases before the happy path. Empty state, the limit, the open-ended input, zero, and ten thousand. If you can’t name them, you don’t understand the feature yet, and neither will the agent.

4. For anything behind a flag or a gate, describe the off state in full sentences. Off is where agents improvise the worst. Spell it out, and you delete a class of bugs before it exists.

5. Keep a one-line log of every decision your agents got wrong. Read it before you write the next spec. Your habits are the pattern, not the model’s.

Subscribe now

Final Thoughts

Almost right but not quite is not a model problem. It is the sound of a spec that trusted someone to fill a gap, running on a system where nobody fills it anymore.

Those developers could not feel themselves slowing down. Most PMs cannot feel the holes in their specs because, for 15 years, someone downstream closed them first.

That person is gone. The job is split into two.

On one side, the PMs who can put what they know on the page precisely enough that a literal executor cannot get it wrong. On the other hand, the ones still waiting for someone to ask them the right question.

The spec is the bug. It has your name on it. The next one does not have to.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

Introducing Colette Molteni.

A few weeks ago, I wrote about my profession restructuring under me. One reader pulled out the question I hadn’t actually answered: when the floor plan keeps changing, how do you tell someone what you do in three sentences?

That reader is .

Colette is the founder of Empathy Elevated, a newsletter for engineers, data scientists, analysts, and PMs that bridges technical work and human skills. She works in Analytics as a Process Manager and has spent over a decade in tech, beginning her career in product management.

Her angle is specific. Empathy as a learnable craft. Curiosity as a tool. The kind of thing that doesn’t get written about much because it’s hard to write about without sounding soft.

The post below is her direct response to mine. She picked up the closing prompt and ran with it.

Three Sentences, No Title: What Actually Happens When You Try It.

Back in April, I reached out to Mike after reading his post, Your profession isn’t gone. It’s restructuring, and I’ve been thinking about what I actually do versus what my title says I do. He ended his piece with three behaviors.

The first one was to write what you do, but without your title, company, or level.

It shouldn’t have stumped me, but it did — and there’s a reason. Being conditioned to think of our titles can make it challenging to break past them. It is the prerequisite for the other two behaviors, yet it is the one most often skipped.

People often skip it because it exposes the weight that your title was carrying.

It’s worth the pause.

Here’s what actually happens when you try.

The Title Was Carrying More Weight Than You Thought.

Most professionals can describe what they do in twenty minutes.

They struggle to do so in three sentences. It’s not a writing problem, though.

The title, the company, and the level were not just decorative; they were doing the heavy lifting of explaining your work to you.

You remove them, and you find out how much of your identity was scaffolding versus structure.

I sat with this myself, deeply pondering what to write. What came out immediately was not “the right answer.” It was what survived three drafts of editing:

I work with technically minded people on the problems their training didn’t cover. The misread room. The rollout with perfect logic and no buy-in. The feedback that arrived without a framework. I do this inside sales operations, where I design the processes, data standards, and decision structures that make AI adoption actually land. What I’m best at is naming what’s happening in the gap between what got built and what gets used.

The first draft was all wrong. I included a job title and a company name, without much thought. I knew both would have to come out.

The middle sentence took the longest. The temptation was to list everything I touch. The constraint forced me to pick one container.

The third sentence was the one that did the real work in getting to this paragraph: I help people communicate better. The specific version: I name what’s happening in the gap.

One I could write on autopilot. The other I had to mean.

Leave a comment

When Your Three Sentences Don’t Match Your Title.

Just slightly over a year ago, my title was “Senior Process Analyst”. I was leading several aspects of a product deployment in one of our business verticals. People on and off the team referred to me as a team lead. The work was there, but the official title had not yet caught up.

If I’d had to answer “What do you do?” honestly in that period, Senior Process Analyst would’ve been technically accurate but substantively wrong.

The three-sentence exercise would have forced me to either underclaim the work or describe what I was actually doing. There is no third option. That’s the point.

When your three sentences don’t sound like your title, you are not doing the exercise wrong. You are doing the exercise with empathy for yourself, figuring out where the gap is rather than papering over it. The gap is the most useful information you have right now, especially in this rapidly restructuring job market, where container placements are rapidly changing.

You can’t help one specific person until you can describe what you do specifically enough for them to recognize they need it. You cannot build something on your own terms until you know what your terms are.

The three sentences are the prerequisite, not the alternative.

In a stable job market, you can skip this exercise, and your title will carry the work. In a restructuring market, the title follows the org chart. The three sentences stay with you and are yours.

Final thoughts

The title was the container. The three sentences are the contents. One of these is portable.

I’m grateful to Mike Watson for writing the post that pushed me into this. The instruction was small. The exercise wasn’t.

Mike’s instruction was simple: write it and keep editing it until it feels right. Most people will probably read that and not try. The ones who do find something will eventually be asked for it by the market anyway. Why not get ahead of it!

From Mike

Thank you for sharing your experience, Colette Molteni. I know Product Party readers will love reading about your experience as well as your Substack.

Find Colette at Empathy Elevated, where she publishes multiple times a week on emotional intelligence, stoicism, and human-AI partnership for engineers, data scientists, analysts, and PMs.

Subscribe to Empathy Elevated

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

I caught Cal Newport’s latest episode this week. His guest, David Epstein, started in on the Theory of Constraints. By the end, I was thinking about an old job, and a senior VP who had the same complaint every leadership meeting: why does it feel like we never get anything done?

Goldratt was a physicist who walked factory floors in the 1980s. The core idea is simple.

Every system has one bottleneck. Improving anywhere else doesn’t help. It just creates a bigger pile.

Newport’s blog post took it further. Productivity tools often speed up the wrong tasks, making us busier instead of better. That describes almost every product org I’ve worked in.

In product, this is harder to see than on a factory floor. We don’t have visible piles of unfinished work. We have backlogs, Jira tickets, and Slack threads, all looking about the same, whether they’re moving or not.

But the dynamic is the same. When leadership thinks the company is shipping too slowly, the reflex is to add capacity.

Hire more engineers. Or bring in a contracting firm. A second team gets stood up in parallel. More people, more output.

Goldratt would tell you the math is wrong. Adding capacity to a non-bottleneck doesn’t make you faster. It just adds pressure to the actual bottleneck, which, in most product orgs, is upstream of the code.

The time to decide what to build. How long does it take to lock specs that engineers can act on? Leadership’s reluctance to commit to a direction long enough for a team to finish anything.

Adding execution capacity to a system that can’t decide what to build is like installing a second oven in a kitchen out of recipes. You haven’t made it faster. You’ve made it more expensive.

Leave a comment

This isn’t theoretical for me. I lived it at an auto refinance startup a few years back. (PS I know I’ve referenced this gig a few times, but there were SO many great lessons. If you really want an adventure, try a start-up)

By the time I left, we had five contracting firms working in our codebase. Three teams in one repository, two in another. The strategy, per leadership, was to unlock speed without bloating internal headcount.

Every leadership meeting ended the same way. A senior VP would lean back, look around the room, and say it: " Why does it feel like we never get anything done?

He wasn’t wrong. We weren’t getting much done. But the diagnosis was upside down.

The assumption was that more teams meant more output, so the shortfall had to be a coordination problem, a contractor quality issue, or maybe a project management issue. Something downstream.

It wasn’t any of those things. The constraint was upstream.

Every team needed work prepared for them:

• Clear specs

• Prioritized stories

• Design assets

• Success criteria

Five teams didn’t multiply our output. They multiplied our preparation burden.

We had stacked five times the demand on a single expensive bottleneck: the work required to make work ready.

Even that wasn’t the whole story. The work-prep bottleneck was visible enough. The deeper one was harder to see.

Priorities at the company shifted constantly. Whoever spoke loudest in a meeting set the direction for the next sprint.

A new feature will surface on Monday from a customer call. By Wednesday, it was the most important thing we were building. By Friday, someone else had a louder idea, and we were redirecting again.

This is its own bottleneck, a nasty one because it disguises itself as urgency. Leadership thought they were being responsive. They were preventing any team from finishing anything.

Five contractor teams plus a moving target equals motion without progress.

It’s not a person, a team, or a tool. It’s a way of making decisions.

Bottlenecks like that are the hardest to fix because nobody owns them. They’re nobody’s job to solve and everybody’s job to live with.

Toward the end, I took direct oversight of three of the contractor teams. The first thing that changed wasn’t the teams themselves. It was the work going into them.

We invested upstream. Specs got tighter before reaching the teams, with acceptance criteria written before estimates. Designs were locked, not aspirational.

We protected them from the loudest voice by making it harder for new priorities to displace committed work mid-sprint.

The teams didn’t get faster, exactly. They started finishing things. The output looked different almost immediately, not because we’d added capacity but because we’d finally cleaned up the work going in.

This is the part Goldratt insisted on most. You don’t break a constraint by adding to it. You break it by feeding it well and refusing to dump work on it that should have happened upstream.

Subscribe now

Final Thoughts

The pattern outlives the story. The names change, the bottlenecks shift, but the failure mode stays. If you’re recognizing pieces of it in your own work, a few starting moves:

1. Identify the actual bottleneck before adding capacity. If your engineering team is idle while waiting for specs, decisions, or designs, capacity isn’t your problem.

2. Audit your work-preparation process. How long does a feature sit in “ready” status before someone realizes it isn’t actually ready? That delay is the constraint announcing itself.

3. Treat priority churn as a tax. Every mid-sprint pivot costs you. Track it.

4. Protect the bottleneck. Give it space, feed it good inputs, and stop asking it to do work that should happen elsewhere.

I think about that auto refinance company more than I should. The VP never figured out why nothing felt like it was getting done.

The answer sat in his calendar every week. The shifting priorities, the uncommitted directions, and five teams hired to solve a problem that wasn’t capacity.

The constraint was never engineering. It rarely is.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

WinZip is still on millions of computers even though Windows handles zip files natively now. People download it on instinct. It found a narrow problem, solved it well, and earned a place in muscle memory that’s lasted decades.

VLC plays every video you throw at it. The current version doesn’t look much different from the version I had on my college laptop. Nobody is asking VLC for an AI subtitle assistant. It plays videos. That’s the whole job.

The calculator on your phone hasn’t changed in any meaningful way since 2010. f.lux predates Night Shift and still has loyal users who prefer it. Notepad. Paint. Software that solved a narrow problem so well that adding to it would make it worse.

I’ve been thinking about this category a lot lately, because I accidentally joined it.

A few weeks ago, I sat down to plan the next update on my app and realized I didn’t have one.

No new features in the backlog. No bug reports waiting. The reviews kept landing at five stars. Subscribers kept showing up, slowly, on their own. The thing was just running.

That feeling caught me off guard. As a PM, I’ve spent fifteen years assuming the work is never done. Roadmaps stretch out forever. There’s always another quarter, another feature, another thing to add. The idea that a piece of software could just be finished felt almost inappropriate.

But it’s possible. It’s actually how some of the best software in our lives works.

This is possible inside companies, too, especially with internal tools. You can flip an app into bug-fix-only mode and let it run. It works.

But most companies don’t do this. They keep adding. And I think two failure modes explain why.

The first failure mode is weak product direction.

Without someone fighting for the next growth area, teams keep enhancing apps that don’t need enhancing. The roadmap fills with motion that doesn’t move anything. Ship something. Anything. Justify the team.

You can spot this when a feature ships and nobody can name the metric it moved. The release notes get longer. The product gets heavier. The user experience gets a little worse. And six months later, you’ve added forty new things, and nothing actually changed.

The second failure mode is sunk cost meeting risk aversion.

The team knows the app is mostly done. They can feel it. But upgrading it carries real risk. New features can break what works. Touching old code is dangerous. So instead of doing the harder thing, which is accepting that the app’s job is finished and building a roadmap to replace it, they pour money and time into marginal improvements.

This is the worst of both worlds. The app keeps consuming resources. The new thing never gets built. And the team can’t honestly answer the question every leader should be asking: why are we still working on this?

Leave a comment

I want to be careful here. Many of you reading this aren’t working on solo projects. You’re inside companies whose products absolutely need to keep moving. Slack can’t stop. Salesforce can’t stop. Your fintech app, your ecommerce platform, your B2B SaaS tool, none of those are WinZip.

The argument isn’t stopping. It’s time to be honest about which parts of your product are still earning their roadmap slots and which are just consuming them.

Most products aren’t done. But most teams act like done isn’t an option. So they keep adding even when the smarter play is to pause, replace, or kill.

The team that ships eight features in a quarter and can’t tell you what changed isn’t shipping. They’re in motion. There’s a difference.

If you want to run a version of this on your own work, here’s a five-step audit:

1. List every feature your team shipped in the last two quarters. Not the projects, the actual features that landed in production.

2. For each one, name the metric it moved. Not the metric it was supposed to move. The one that actually moved.

3. Mark every feature with no answer. Those features aren’t features. They’re maintenance dressed up as progress, or they’re bets that didn’t pay off and never got declared done.

4. Ask whether those features earned their cost. Engineering time, design time, PM time, the opportunity cost of everything you didn’t build instead. If the answer is no, that’s data.

5. Decide what the honest answer means. A roadmap full of unmoved metrics is either a roadmap problem or a leadership problem. Both are fixable. Pretending it’s fine is not.

Share Product Party

Final Thoughts

My app might break tomorrow. Apple might change something on its end. A subscriber might find an edge case I missed. If that happens, I’ll fix it.

But until then, it’s done. And I’m trying to let it be done without inventing a roadmap to justify keeping the project alive in my head.

The harder version of this question is the one I keep landing on: what would happen if you applied the same honesty to the work you’re doing right now? Not the indie side project. The real one. The thing you’re paid to ship.

Some of it is moving the business forward. Some of it is just motion. The job is to know the difference, and to have the courage to say so out loud.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

I was two years into a job once and we’d just finished rolling out the new intake process. Third time in four years.

Capital-P Process this time. There was a form. There was a triage meeting. There was a color-coded prioritization rubric that somebody’s new Product Ops hire had been very proud of.

Six weeks later, I was DMing the PM on another team to ask if we could squeeze in a thing for a VP.

I was the problem. So were you. So was most of the building.

For years, I thought this was a strategy problem. We didn’t have a clear enough vision. Or we hadn’t communicated it enough.

Or the slides were wrong, the deck needed illustrations, the exec team needed a better offsite. So we’d rewrite the strategy, I’d feel productive for about eleven days, and then we’d be right back in the same spot, shipping things that technically nobody had committed to, and that definitely weren’t on the poster in the kitchen.

Turns out I was rewriting the wrong document. The intake form was where decisions actually got made.

Your team has an intake process. If you didn’t design one, that doesn’t get you out of having one.

Whatever happens by default is your intake process: who asks, how, through what channel, who gets to say yes. All of it is quietly making strategic decisions on your behalf.

Every intake, designed or otherwise, answers the same five questions.

Who gets to submit? What does it cost them to submit? What criteria does the request get weighed against? Who can say no and have “no” actually mean no? What happens to the requester when the answer is no?

In almost every org I’ve worked at, the default answers looked the same.

Anyone could submit. The cost was a Slack message. Evaluation was based on gut feel or whoever was loudest at the last all-hands.

The PM was technically the decider, right up until someone at the VP level mentioned the thing in passing, at which point the prioritization framework folded like a card table.

(Side note: every time I’ve tried to explain this to a non-PM, they look at me like I’ve just admitted we don’t have a process. Which, yeah, basically.)

That’s a queue with feelings dressed up as a strategy.

Three or four times at different companies, I’ve watched a team install a real intake process from scratch. New forms, new meetings, new frameworks, sometimes a new tool.

The pattern was always the same. Somebody drove it hard for about a month. Things felt clean.

Then the sprint would tighten, an exec would grumble, and we’d quietly slip back into whatever shape the old thing had.

Every failed attempt died the same way. Nobody owned the decision by sprint.

There’s a difference between having a process and having a human whose job it is to look at the queue on Tuesday morning at 10 am and say yes or no. When the second one is missing, the first one is paperwork.

Leave a comment

For anyone who wants data before they buy this, Pendo analyzed feature usage across 615 customer subscriptions and found that 80% of features in the average software product are rarely or never used.

Their back-of-the-napkin math put that at around $29.5 billion a year, collectively spent by public cloud companies on features nobody meaningfully uses.

Eight out of ten features your team has ever built. Statistically. Sitting there doing nothing.

And the roadmap worked. Those features were on it. They got prioritized, sized, scoped, delivered, and probably celebrated with a pizza emoji in a release channel.

What broke was the thing that decides what gets onto the roadmap in the first place.

If you want to check whether this is happening at your place, pull the last ten things your team shipped.

For each one, ask three questions: where did the request actually come from, what did it go through before it became a committed item, and does it map to the strategy you’re telling the company you’re executing.

If more than three of those ten items flunk the last question, your intake is your strategy.

The deck is a comfort object, doing emotional work, which is probably why rewriting it never seems to help.

Final Thoughts

Strategy is a system of trade-offs. Saying yes to A means saying no to B.

Intake is where those no’s actually get said, or where they quietly don’t.

So the actual work is unglamorous. The form. The meeting. Whoever owns the answer on a given Tuesday.

I’ve been the guy DMing the PM. I’ve also been the PM getting DM’d. Neither seat feels great.

The fix has always been the same. Someone with the standing to say no, and the calendar space to say it on time.

Everything else is theater.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

My app, HVAC Load Calculator, went to market with a PDF feature. Contractors were generating reports and handing them to homeowners to close jobs. The PDF was generated quickly. The data was right. It just wasn’t good enough for what it was actually being used for - and I almost missed that entirely.

I started noticing the pattern through user conversations. People weren’t just running calculations. They were using the PDF as a sales tool. A contractor would size a system, generate the report, and walk into a homeowner’s kitchen with something that looked official, something that said: here’s what your house needs and here’s why.

That’s a different use case from the one I’d designed for. The contractor was my user. Their customer was reading my work.

When I actually sat with the PDF and thought about that second person - someone who doesn’t know what a load calculation is, who’s making a significant financial decision, who’s judging the contractor’s credibility partly based on this document - I realized the bar I’d been measuring against was wrong. Accurate wasn’t the same as trustworthy.

Functional wasn’t the same as professional. Some of the contrast and type weight needed attention. Small stuff. But small stuff that mattered when the document was doing a job I hadn’t fully accounted for.

I fixed it. Released an update. Moved on.

But I kept thinking about why I almost didn’t catch it.

Fifteen years in product. Large enterprise software companies, early-stage startups, everything in between. In all of that time, I was never the last line of defense between a mediocre experience and a lost customer. There was always someone else downstream.

A designer who’d catch the readability issue. A customer success team absorbing the friction. Users who’d keep using the product anyway because switching costs were high and the contract was already signed. Enterprise software has a thousand ways to insulate the PM from the actual consequences of the experience they shipped.

That insulation is so complete you stop noticing it. It starts feeling like the job. You get very good at describing user problems. Mapping journeys. Writing research briefs. Advocating for the user in planning meetings. All real skills. All practiced at a comfortable remove from the actual moment someone encounters the thing you built and decides whether it’s worth their time.

Building alone removes every buffer. There’s no designer downstream. No CSM to patch the relationship. No contract keeps users locked in. Someone searches the App Store, finds your thing, downloads it, and either keeps using it or doesn’t. That’s the entire feedback loop.

What changes isn’t your standards. It’s your attention. Suddenly, you’re looking at your own product the way a stranger would, because strangers are the only people you have.

This is what I think corporate PM experience actually trains poorly: the ability to feel the weight of a product decision in real time. Do not describe it. Do not advocate for it in a meeting. Feel it when the outcome is yours.

Most of the product people I know are excellent at process. They can run a discovery sprint, synthesize research, and write a crisp PRD. The craft is there. What’s missing is skin in the game, and it’s missing because the structure of most product roles makes it nearly impossible to have any.

If you’re somewhere in the early building phase, one thing is worth sitting with before anything else: trace the full value chain before you decide what “good” looks like. The person using your interface isn’t always the person your product is actually serving. I didn’t design the PDF for homeowners. I didn’t think about homeowners at all. That was the gap, and I only found it because I was paying close enough attention to notice how the tool was actually being used in the wild.

Nobody was complaining about the PDF. Downloads were steady. Absence of complaints is easy to mistake for things being right. It isn’t. When you own the outcome, you have to hold the quality bar yourself, because there’s no org structure to catch what you let slide.

Most product people reading this have strong skills and genuine experience. That’s not the gap.

The gap is having built something where the quality decision was entirely yours, the user was entirely a stranger, and the outcome was entirely on you. That experience changes how you see product work. It doesn’t make enterprise experience irrelevant. It just makes the distance visible.

Once you can see the distance, you can’t unsee it.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

Participation was low. Adoption numbers barely moved.

Leadership was frustrated. They’d invested in the tools, communicated the vision, and even added an incentive. What else could they do?

The question nobody asked: how many of the people they were asking to participate were already working at 100% capacity before the competition launched?

Most enterprise AI rollouts are designed as addition problems.

Take the existing workload. Add a new tool. Add a learning curve. Add documentation requirements for the competition. Add the cognitive overhead of remembering to use the new tool in the first place. Then wait for productivity gains.

That math doesn’t work.

AI gives time back. But first it takes some. There’s a ramp before there’s relief, and that ramp costs exactly what overextended people don’t have: available hours, mental bandwidth, the space to try something, fail at it, and try again.

The employees most buried in reactive work are the ones who need the efficiency gains most. They’re also the ones least positioned to invest in getting there.

Measuring adoption doesn’t surface this problem. It hides it.

When a company tracks logins, completion rates on training modules, or competition entries, they’re measuring activity. Compliance, really. Whether people showed up to the thing.

What they’re not measuring: whether the people who showed up had any capacity to actually change how they work. Whether the workflow even had room for something new. The intended outcome - actual time savings on real work - is a different question entirely, and most rollouts never ask it.

I’ve watched companies celebrate AI rollout numbers that were entirely disconnected from business outcomes. The adoption metric was intended to justify the contract, not to track change.

The gift card competition produced a handful of motivated early adopters who had the time and inclination to engage. Which is great. But it also confirmed for everyone else that AI was optional. Something extra you did if you had bandwidth. A nice-to-have.

That belief, once formed, is hard to undo.

Subscribe now

Nobody’s asking the harder question.

If the real constraint is capacity, adding an AI tool to an already full plate doesn’t solve it. Neither does a competition. The companies seeing real efficiency gains from AI tend to do one thing differently: they start by removing something before they add anything.

They identify specific tasks that AI can own, pull those out of someone’s workload, and let the time savings show up before asking for the adoption behavior. The tool doesn’t ask for trust up front. It earns it by visibly changing what a week looks like.

That’s a harder conversation to have internally than launching a rollout. It requires someone to make a call about what work stops, not just what tool gets added. Most AI adoption programs are funded by IT or operations. The authority to change workloads lies somewhere else entirely.

That’s probably the real problem.

Two things worth measuring instead of the adoption rate:

1. Time recovered on specific task categories. Pick three high-volume, low-judgment tasks. Measure hours spent before and 60 days after AI implementation. If the number didn’t move, the tool isn’t working or the workflow wasn’t designed to let it.

2. Capacity headroom. Ask the people you deployed AI to whether they feel less overwhelmed three months in. Not whether they’re using the tool. Whether anything changed about the amount of runway they have each week. That’s the outcome the business actually wants.

Neither of these is easy to track. That’s probably why the adoption rate won. It’s a simple number with a clear benchmark, and it feels like progress.

Simple numbers are fine until they’re measuring the wrong thing.

The company with the gift card competition had something real underneath it. There were genuine efficiency opportunities. The margin in their business meant even small gains in output per person could matter significantly.

But the path they took assumed the blocker was awareness or motivation. Get people to try it. Show them it works. Let enthusiasm spread.

The actual blocker was time. And you can’t gamify your way past that.

Final Thoughts

A more useful starting point:

1. Before deploying any AI tool, ask which task it replaces, not which task it augments. Addition doesn’t free up capacity. Substitution does.

2. Pilot with your least overloaded people first. They’ll actually use it. That generates the real proof of concept, not a competition leaderboard.

3. Measure outcomes at 60 days, not adoption at 30. One number tells you if people showed up. The other tells you if anything changed.

That company with the gift card competition wasn’t wrong to care about AI adoption. The efficiency opportunity was real. The margin pressure was real. They just picked a metric that told them what they wanted to hear instead of what was actually happening.

You can’t incentivize your way to capacity. You have to create it first.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

“Quick catch-up.” No context. Fifteen minutes.

I knew immediately. Most people do.

After the call, I laced up my Brooks and walked around the block. I wasn’t thinking about the market yet. I was thinking about my mortgage.

How much buffer did I have? What the next few months actually looked like.

Then I started thinking about the market. How long would this take? Whether the level I’d been at was even something companies were hiring for right now.

That last question is the one that didn’t go away.

Product and tech roles scaled in a way almost nothing else has in recent memory. Not just in salary - in sheer volume of need. Companies were creating roles faster than universities could produce people to fill them.

Mid-career professionals could lose a job on Friday and have real options by the following week. The landing zone always existed.

So most of us never had to think too hard about what we actually brought. The profession itself was stable ground. You didn’t need to define your value clearly when there was always somewhere to land.

That’s changed. Not because the work disappeared, but because the growth outran the foundation. Companies built org structures around a hiring environment that no longer exists the same way.

The roles got compressed, consolidated, and redefined. And AI is accelerating a restructuring that was probably coming regardless.

Nobody knows what the floor plan looks like on the other side yet.

So when someone asks, “What do you do?” the discomfort isn’t really about the title. It’s about confronting the honest answer: I’m in a profession that’s restructuring, and I can’t point to where I land when it’s done.

That’s uncomfortable. It’s also a more useful starting point than pretending the old answer still works.

For me, the footing started coming back when I stopped waiting for a role to give me the answer. Building all these mobile apps (aka my 2026 side quests), taking on consulting work, writing this newsletter - none of it came with a title. It just required me to be clear about what I actually do and who it actually helps.

That clarity was harder to find than I expected. Which told me something about how much work I’d been letting the credential do.

The skills didn’t change when the market did. The ability to figure out what’s worth building, to read what users actually need, to make the case for one thing over another - none of that was on the org chart.

It just lived there for a while. It needs a different container now. One you probably have to build yourself, at least for a while.

The profession is catching up with itself.

Leave a comment

Getting honest about what you actually bring - without a title to lean on - is harder than it sounds. Most of us haven’t had to do it seriously in years.

Here’s where to start:

1. Write what you do without using a title, a company, or a level. If it takes more than three sentences, keep editing.

2. Find one person you can help right now - a job seeker, a junior person, someone building something. Outward action rebuilds footing faster than introspection.

3. Build something on your own terms, even if it’s small. It forces the clarity that waiting for a role won’t.

You’ve never had to answer that seriously. The market let you skip it. That window closed.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

I downloaded six apps last week. All in the same interest space. All clearly built fast, probably with AI assist, probably shipped in under a month.

I deleted four of them within two minutes.

Not because they were broken. They worked fine. I deleted them because every single one hit me with a wall of stuff the moment I opened it. Tabs, toggles, onboarding carousels, feature callouts. My brain didn’t reject the apps. It just quietly ran out of room.

So I started reading about executive function. Not for product reasons. For personal ones. But the research kept describing exactly why those four apps lost me and why the two I kept felt effortless.

I wrote a few weeks ago about how building got cheap. AI collapsed the cost of shipping software to almost zero, and the bottleneck moved to customer acquisition. That’s still true. But there’s a second bottleneck I didn’t name in that post.

Getting someone to download your app is hard. Keeping their brain once they open it might be harder.

Miller’s Law Is Wrong: Working Memory Holds 4 Items, Not 7

Every product manager has heard of Miller’s Law. Seven plus or minus two. It’s in every onboarding deck, every UX textbook, every “design for simplicity” article you’ve ever skimmed.

It’s also wrong.

Nelson Cowan, a cognitive scientist at the University of Missouri, revisited Miller’s 1956 research and found the number was inflated. The original experiments allowed people to use rehearsal strategies and rely on long-term memory. Strip those aids away, and the raw capacity of human working memory drops to four. Plus or minus one. Here’s a link to nerd out on some of his work.

Your onboarding asks for a name, an email, a use case selection, a notification preference, and a theme choice. Five decisions before someone has done a single meaningful thing in your app. You’ve already exceeded their cognitive budget, and they haven’t even started.

Researchers found that choice overload explains 63% of the variance in decision fatigue. And 18-22% of users who abandon a flow cite “too long or too complicated” as the reason. Not too expensive. Not missing features. Too much.

How Duolingo Used Cognitive Science to Boost Learning Outcomes

Duolingo figured this out in 2022, buried under all the memes about their unhinged marketing.

They redesigned their entire learning path into a single linear sequence. Before the redesign, users opened the app and chose what to study. Sounds reasonable. User agency, right? Let people pick.

They killed it. One track. Next lesson. Go.

Reading and listening scores went up. Not because the content changed. Because Duolingo stopped asking users to spend one of their four brain slots on “what should I learn today?” and redirected that slot toward actually learning.

Fewer choices. Better outcomes. Every builder instinct says give people options, give them control, give them features. Cowan’s research says every option you add costs cognitive rent.

Leave a comment

Final Thoughts

Your roadmap isn’t a feature list. It’s a cognitive budget.

I didn’t find any of this in a product management book. I found it while reading cognitive science research about executive function. That’s probably the most useful product insight I’ve picked up this year: the stuff that makes you better at building rarely looks like product content.

You have four slots. Spend them on something that matters.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

PS: Ready to document before you schedule? I use ClickUp to keep decisions out of my calendar. Grab a free license here and see if it works for your workflow.

A company I worked at decided to implement an affiliate marketing platform. The president had used it at a previous company. It worked there. So, it would work here.

That was the entire thesis.

He pushed other priorities off the roadmap to make room. Gave high-level requirements. Asked for delivery dates. Engineers built the integrations within a couple of sprints. Fast work.

One problem. Nobody on the technical team had ever touched this platform. Nobody steering the implementation understood how affiliate marketing actually worked at a business-rules level. The president who did understand it wasn’t available to give field-level requirements. He just wanted to know when it would ship.

I was the PM with ties across the company’s tech stack, running CRM full-time but helping steer this alongside a handful of other projects. I could see the shape of the failure forming. Integrations getting built on top of assumptions nobody had validated. Business logic that lived entirely in one person’s head, and that person was in back-to-back meetings asking, “when is this done?” instead of “here’s how this should work.”

The platform launched. The integrations functioned. And the whole thing flopped, because no one could translate complex affiliate rules into a system that actually reflected how the business needed it to operate.

Nothing about that failure was inevitable. Every question that would have killed the bad assumptions was available from day one. Who on this team has domain expertise? Can we articulate the affiliate rules before we build? Is “it worked at my last company” sufficient evidence for a six-figure platform commitment?

Nobody asked. Everyone built.

That project didn’t fail because no one had the answers. It failed because no one had a reason to ask the hard questions out loud.

Product intuition was never about having good ideas

I keep thinking about that project because the failure mode is so common. Not bad ideas exactly, but untested ideas that accumulate momentum before anyone interrogates them. And I think LLMs are quietly changing how the best product folks prevent it.

Everyone thinks product intuition means you can spot a winner. Walk into a room, hear a pitch, and know. That’s movie stuff.

Real product intuition is knowing which ideas are fragile before you’ve invested in them. Strong PMs have always done this. They corner a sharp colleague and say, “poke holes in this for me.” They look for the kill shot early, because finding it at your desk on a Tuesday cost nothing. Finding it in front of leadership costs weeks of credibility. Or worse, it costs sprints of engineering time on something that was never going to work.

What’s changed is the colleague is available at 11pm. It doesn’t get tired of your questions. And it won’t politely nod along because the idea came from the president.

An LLM with the right framing will interrogate your idea the way a skeptical stakeholder would. It won’t know your company’s affiliate rules. But it will notice you haven’t mentioned them.

Who has domain expertise here? What’s the switching cost from the current solution? Where’s the evidence this problem is severe enough to change behavior? Can we articulate the business rules before we start building? These aren’t AI-generated insights.

They’re the questions you already know you should ask but skip because the room has momentum and nobody wants to slow it down.

Share Product Party

What this actually looks like

You have a half-formed idea. Instead of opening a slide deck, you open a conversation. You describe it raw and unpolished. Then you ask the model to be the skeptic.

Not to improve your idea. To find what’s wrong with it.

Over a series of exchanges, you build up context: market assumptions tested against pushback, user segments refined, business logic interrogated before a single integration gets scoped. By the time you pitch, you’re not presenting a deck. You’re presenting the residue of an argument you’ve already had.

I’ve started doing a version of this with my own projects. Before I build anything, the idea goes through a structured conversation that forces the uncomfortable questions first. Who specifically has this problem? What do they use today? Would they pay? Most ideas don’t survive. That’s the point.

Leave a comment

How to apply this to your next idea

Step 1: Stop yourself before the deck. The moment you feel ready to start building a proposal, that’s the moment to interrogate the idea instead. Excitement is the enemy of scrutiny.

Step 2: Describe the idea like you’d describe it at lunch. No frameworks. No positioning language. Just “I think we should do X because Y, and the people who’d care are Z.” Feed that to an LLM and tell it: “You are a skeptical Head of Product who thinks this is a waste of engineering resources. Find the three assumptions that will break this implementation.”

Step 3: Build a corpus, not a deliverable. Each conversation adds context. Objections you’ve handled, assumptions you’ve tested, business logic you’ve mapped. This becomes your pitch ammunition. Not a polished artifact but a body of evidence that shows your thinking.

Step 4: Separate what survived from what you’re attached to. Some ideas hold up under interrogation. Most don’t. The skill isn’t generating ideas. It’s recognizing which ones earned your time.

Final thoughts

If someone had fed that affiliate platform idea into an LLM on day one and asked, “what are the top five reasons this implementation fails,” domain expertise gap would have been near the top of the list. It wouldn’t have replaced the president’s knowledge. But it would have surfaced the question nobody was asking: does anyone else here actually understand this business well enough to build it?

A PM with weak instincts uses an LLM to generate a proposal and calls it done. A PM with strong instincts uses it to destroy three bad ideas before breakfast and walks into the office with the one that survived.

The difference isn’t the tool. It’s knowing what to do with the wreckage.

What’s your kill-shot question — the one that’s saved you from a bad bet? Reply and tell me. I’ll share the best ones next week.

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

She ordered the chicken gnocchi soup. When it was time to order, I casually said, “It’s time for the birthday girl to order,” to send a signal. She looked at the server and asked if they could put some extra gnocchi in her soup. She asked if it was a special treat for her birthday, and she had her birthday card as her receipt (just in case).

He didn’t push back.

Now, this isn’t on the menu. There is no “extra gnocchi” button in the Olive Garden POS system. Nobody wrote a user story for this. There’s probably a corporate policy somewhere about portion sizes, food costs, and consistency across 900 locations.

The waiter smiled and said, “I’ll see what kind of special magic I can work in the kitchen.” Came back with extra gnocchi in her soup. She lit up.

That moment cost Olive Garden almost nothing. It bought a family that keeps coming back.

We are all building software now, and I think most of us realize that no software would have handled that interaction the same way.

Not because the technology isn’t sophisticated enough. Because the decision itself requires something software doesn’t have: the ability to recognize that right now, in this specific moment, the rules don’t matter.

Rigidity is a feature, not a bug

We expect software to be consistent. That’s the whole point. When you open your banking app, you want it to behave exactly the same way every single time. Predictability is why we trust machines with our money, our health data, and our flight bookings.

Product managers spend entire careers making software more consistent. We write acceptance criteria to eliminate edge cases. We design systems that treat every user the same way because fairness at scale demands uniformity.

And most of the time, that’s exactly right.

But “most of the time” is doing a lot of heavy lifting in that sentence.

Leave a comment

When consistency breaks people

Picture this. A family is driving from Michigan to Florida. Bad weather rolls in somewhere in Tennessee. Flights are grounded. Highways are a mess. They pull into a hotel at 11 pm with two exhausted kids.

The booking system says check-in is closed at 10 pm. The rate jumped by $85 due to surge pricing driven by weather demand. The cancellation policy on their original reservation three states away? Non-refundable.

A human at the front desk looks at those kids asleep in the back seat and figures it out. Waives the late fee. Finds a rate that doesn’t punish someone for a snowstorm they didn’t plan. Maybe call the other hotel to work out the cancellation.

An algorithm sees a timestamp, a price curve, and a policy. It executes flawlessly. And the family sleeps in their car.

This isn’t a technology problem. It’s a product philosophy problem.

We’ve built systems that optimize for the 98% of transactions that are routine and then abandon the 2% where human judgment is the entire product.

Follow, Break, or Bend

AI is excellent at following rules. It can also accidentally break them. What it cannot do is intentionally bend them.

That’s three different things, and we keep collapsing them into two.

Following rules is what software does best. Every transaction is processed the same way, every time. Break rules and you get chaos. Gnocchi for everyone. Late check-ins with no rate at all. Systems that can’t hold a policy because they don’t understand why the policy exists.

Bending is something else entirely. Bending requires understanding the intent behind a rule, not just the rule itself. Portion sizes exist to manage food costs and keep the kitchen running. They don’t exist to deny an 11-year-old on her birthday. A human knows the difference. A system sees the rule.

This is where product teams have actual work to do. Not replacing human judgment with AI, but designing systems that create space for judgment to happen. What if the Olive Garden POS had a “server discretion” option for small modifications? What if the hotel booking system flagged weather events and auto-adjusted cancellation policies within a range that the front desk could approve?

Those features don’t write themselves. They require someone who has sat in the dining room. Someone who has been stranded on a highway. Someone who understands that the 2% of edge cases aren’t bugs in your system. They’re the moments your product is remembered for.

That’s product management. And no language model is going to sit across from your users and feel what they feel when your system fails them at the worst possible time.

Jobs evolve. Judgment doesn’t automate.

I’ve seen the discourse. AI is coming for PM jobs. AI can write PRDs now. AI can analyze user research. AI can prioritize backlogs.

Fine. Let it.

But the job that matters most for PMs isn’t writing documents or crunching data. It’s recognizing when the system you built needs to bend. It’s designed for the birthday gnocchi moment, the snowstorm hotel moment, and the thousand other scenarios where rigid consistency actively harms the people you’re serving.

AI will get better at pattern matching. It will get better at predicting common requests. It will probably learn to suggest “would you like extra gnocchi?” based on purchase history and demographic data.

But it won’t pick up on a dad’s casual signal about a birthday. It won’t say “special magic in the kitchen” to make an 11-year-old feel like she got away with something. And that feeling is where the best product decisions come from.

The products we remember aren’t the most consistent ones. They’re the ones that surprised us by being human when we didn’t expect it.

Your job as a product person isn’t going away. It’s shifting toward the thing that's always been the hardest part: building systems smart enough to know when to stop being systems.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

PS: Ready to document before you schedule? I use ClickUp to keep decisions out of my calendar. Grab a free license here and see if it works for your workflow.

My job was to connect them. By myself.

This is an auto parts distributor. Five people. Manufacturers with unique pricing schedules, custom workflows that never lived anywhere except in inboxes and institutional memory. They’d never had a CRM. Not because they didn’t need one. A project like this could easily become a one-to-two-month engagement with multiple consultants, configuration specialists, and a training team. For a five-seat operation, that math rarely works.

So I did it solo. And AI filled every seat that would’ve normally been a person.

I want to walk through what that actually looked like, because I think there’s a framework here that applies well beyond CRM work.

Seat one: proposal writer.

Before I touched a single configuration screen, I needed to scope the work. I’d taken pages of notes across discovery calls, capturing how they think about customers, how pricing actually flows, and which manufacturers have special schedules. I fed those conversation notes into Claude and got a clean, structured proposal back in hours. Not a generic template.

A document that reflected their specific business model, their pain points, and their language. I also used LLMs alongside manual research to pull together pricing for the different Zoho modules and licensing tiers. The output was a presentable breakdown that they could read and understand, showing what they’d be paying. That step alone would’ve taken me a full day of formatting and cross-referencing. It took about two hours.

Leave a comment

Seat two: data analyst.

Their customer and pricing data were scattered across random files. Different formats, inconsistent fields, duplicated entries. I used Claude’s Excel extension to clean and standardize fields, mapping everything to Zoho’s import structure.

Thirty years of email-based operations compressed into clean, importable datasets.

Seat three: solutions architect.

Zoho’s customization options are deep, but the documentation can be scattered. Instead of spending hours in forums and help articles, I used Claude’s browser extension to walk through settings, module configuration, and custom field mapping in real time.

I described what the business needed. Claude pointed me to the right settings. Configuration decisions that would normally require deep platform expertise happened at the speed of conversation.

Seat four: business modeler.

Before I started building anything in Zoho, I used Claude to generate a model of their business workflows, module structure, and data relationships. Something I could print out and walk through with the owner at a table.

That validation step saved weeks of rework. He could point at something and say, “No, that’s not how we handle manufacturer pricing,” before I’d configured a single field. Then once I started building, I iterated in real time until the team had the actual product in their hands and understood how it worked.

The model got me close. Hands-on iteration got me the rest of the way.

Seat five: training developer.

Every decision, workaround, and lesson from the build was already in my Claude conversation history. When it came time to train the team, I turned those threads into a PowerPoint walkthrough built from their specific implementation, their workflows, and their data.

And because the entire context was in one place, pivoting the training when questions came up took minutes rather than days of rework.

A caveat before you price your next project

I need to be upfront about something. I had the luxury of testing most of these tools before this engagement started. I’d already used Claude’s Excel extension on my own data. I’d already experimented with the browser extension for research tasks. I knew what worked, where the rough edges were, and roughly how long things would take. That matters.

If I’d committed to this engagement, assuming a brand-new tool would cut my data-cleaning time in half, and then it didn’t, I’d have been eating hours I couldn’t bill for. Or worse, delivering late.

Work within the tools you already know. Don’t sell your time based on efficiencies you haven’t validated yet. AI tools are powerful, but they’re not predictable until you’ve pressure-tested them on problems that look like yours. The extension that cleans one dataset beautifully might choke on the next one with different formatting quirks.

Test on your own time first. Build confidence in a tool before you build a client timeline around it. The five-seat model worked because I’d already done the homework. Not because I got lucky.

How to apply this to your own work

The five-seat framing isn’t just a CRM story. It’s a way to audit any project you’re scoping right now. Try this:

Step 1: List every role the project assumes. Most project plans bake in specialists without questioning why. Data migration person. Configuration person. Documentation person. Training person. Write them all down.

Step 2: For each role, ask what the actual work is. Not the job title. The tasks. “Data analyst” sounds like a person. “Clean 14 spreadsheets so the fields match an import template” sounds like a prompt.

Step 3: Sort into two buckets.

Bucket A is mechanical work that follows rules: data cleaning, format conversion, settings configuration, document formatting, and research synthesis. AI handles this well right now. Not perfectly, but fast enough that one person can cover multiple seats.

Bucket B is judgment work that requires context: understanding why the business operates the way it does, deciding which features actually fit a workflow versus which ones just demo well, reading stakeholder anxiety, and adjusting your approach. No tool handles this. It requires showing up, listening, and making calls that don’t have obvious right answers.

Step 4: Restructure your project around Bucket B. If you’re a PM scoping internal tooling, a consultant pitching an engagement, or a founder evaluating what to outsource, the question isn’t “can AI do this work?” It’s “which parts of this work require human judgment, and am I spending most of my time there?”

Final thoughts

Most of us are still staffing projects like it’s 2022. We assume every role needs a dedicated person because the mechanical work used to be slow. It’s not slow anymore.

What’s still slow is sitting on a discovery call with a business owner who’s run things on email for 30 years and understanding why. That’s the work that doesn’t compress. That’s the work worth protecting your time for.

Five seats. One consultant. And the real leverage wasn’t any single AI tool. It was knowing which questions to ask before opening any of them.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

Find a niche app idea in a growing industry. Something that solves a real problem. Something useful without requiring an account. Build it in under 48 hours. Ship it. See if strangers care.

I opened Gemini Deep Research and started feeding it that brief. What came back surprised me. HVAC load calculators. The kind of tool contractors use to size heating and cooling systems for homes.

I have never touched an HVAC system in my life.

Why HVAC?

Florida and Texas are booming. Construction is up. Every new build and renovation needs a load calculation. The existing software options? Desktop-first tools built in the Windows 95 era, costing $500-$1,000 per year. Or clunky apps that haven’t been updated since 2019.

Meanwhile, contractors are standing in someone’s living room trying to give a quote. They need something fast, accurate, and mobile. No login screen. No onboarding flow. Just open the app and calculate.

That gap was obvious. Not because I know HVAC. Because I know how to read a market.

Leave a comment

Building with a daisy chain of AI tools

This is where it got interesting. And honestly, harder than I expected.

HVAC load calculations aren’t simple math. Manual J (the industry standard methodology) accounts for insulation values, window orientation, climate zones, square footage, occupancy, and dozens of other variables. Get it wrong, and a contractor sizes equipment incorrectly. Real consequences.

So I built a validation loop across multiple AI models.

Gemini Deep Research handled the market analysis and regulatory landscape. It surfaced the Manual J methodology, pricing benchmarks, competitor gaps, and growth data I needed to make a go/no-go decision.

Google Stitch generated initial UI concepts that I fed into Cursor, running Claude to build the actual application. I layered in the calculation logic piece by piece, testing against real scenarios.

Then I did something that made the whole process work: I built test cases across multiple states, housing types, and climate zones. I’d run the calculations, export the results, and show them to Gemini.

Do these numbers make sense for a 2,000-square-foot home in Tampa with standard insulation?

What about a 1,400 square foot home in Dallas with upgraded windows?

Each model checked the other’s work. Claude built the logic. Gemini stress-tested the outputs. When the numbers didn’t pass the sniff test, I’d dig in, find the gap, fix it, and run it again.

No single AI tool could have done this alone. The value was in the loop.

Constraints as a feature

I gave myself two rules beyond the 48-hour window.

One: bare minimum features only. No account creation. No cloud sync. No premium tier. Just a calculator that works. If a contractor opens the app in someone’s basement with no cell signal, it should still function.

Two: be willing to walk away. If nobody downloads it, that’s an answer. A useful one. I’d rather learn that in 48 hours than in 4 months.

Compare this to Leafed, my book discovery app. I spent weeks building features before putting them in front of real users. I love that app. But the feedback loop was slow. I was polishing when I should have been validating.

With the HVAC calculator, I flipped it. Ship first. Polish only if the market says so.

150 downloads in two weeks

I released it on February 2nd. By day three, 32 downloads. By the two-week mark, 150. Completely organic. Zero marketing spend. Zero social posts. No Product Hunt launch.

150 might sound small. But these aren’t vanity downloads. These are HVAC professionals who searched the App Store for a load calculator, found mine, and chose it. People with a job to do who picked my app over tools that have been on the market for years.

My research suggests that 1,000 active users is the threshold at which monetization makes sense for a niche professional tool. I’m watching the numbers and listening to how people use it before I make any decisions about pricing.

I did test out some pricing after crossing over 150, and I’ve already had some success, so I’m in that “figure out what is the best way to handle” mode, which…I’ve never really priced apps before. So…it’s exciting.

Have some pricing tips? Leave me a message and let me know.

What this means if you’re a PM

We spend a lot of time talking about domain expertise. Years of experience in fintech. Deep knowledge of healthcare workflows. A background in whatever vertical your company operates in.

Domain expertise matters. I’m not dismissing it. But when building becomes this cheap and this fast, the bottleneck shifts.

The valuable skill isn’t knowing HVAC. It’s knowing how to find an underserved problem, set constraints that force speed, validate outputs even when you’re not the expert, and ship something real to see if the market responds.

I knew nothing about Manual J calculations two weeks ago. But I knew how to write a research brief. I knew how to evaluate market gaps. I knew how to build a multi-model workflow that caught errors I couldn’t catch on my own. And I knew when good enough was good enough to ship.

That’s product judgment. It doesn’t require domain expertise. It requires the willingness to look in markets you’ve never worked in and ask: Is there a problem here worth solving?

A shelf life on every experiment

The biggest shift in how I’m building now: every project gets a shelf life.

48 hours to build and ship. Two weeks to see if there’s traction. If the numbers say yes, invest more. If they say no, walk away clean.

No sunk cost. No “but I already built the premium features.” No weeks of polishing something nobody asked for.

This kind of rapid experimentation works best when you can actually track what you’re doing. I use Monday.com to manage my project pipeline across consulting, apps, and newsletter content. When you’re running multiple experiments at different stages, having one place to see what’s active, what’s waiting on data, and what’s ready to kill makes the “walk away clean” part a lot easier.

People don’t care if your app is sexy. They care if it does the job they need done, works consistently, and doesn’t ask for their email before they’ve gotten any value.

Sometimes the best product thinking happens in markets you’ve never set foot in. You just need the judgment to recognize a problem and the discipline to stop building before you fall in love with the solution.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

I’ll wait.

My algorithm has been feeding me the same thing for months. People building apps with Cursor, shipping MVPs in a weekend, solving problems that sound a lot like the problems I’m solving. Same tools. Same categories. Same “just launched, check it out” energy.

And almost nobody is talking about what happens after.

Because building is the part that feels like progress. You’re in the zone. Features are taking shape. The UI gets a little cleaner with every pass. You ship something, screenshot it, and post it, and people say “nice.” That dopamine is real.

Finding someone who actually wants the thing you built? That doesn’t feel like progress. It feels like begging.

I know because I avoided it for months.

I built Leafed, a book discovery app, earlier this year. React Native, Expo, all the modern tools. Building was genuinely fun. I could knock out a new feature in a few hours and feel a sense of accomplishment.

So I kept doing that. New filters. Better transitions. A more polished onboarding flow. Every feature I added was a feature nobody asked for, because I hadn’t really talked to anyone using it.

I need to name this for what it was. Perfectionism disguised as productivity. I told myself I was improving the app. I was actually avoiding the harder, scarier work of finding strangers who might care about it.

Posting on social media felt like marketing. But my posts were competing against hundreds of other “check out my app” posts from people using the same tools to solve similar problems. Standing out in that crowd takes real effort, strategy, and consistency. Not just a link drop with a screenshot.

350 downloads later, I got my first organic app store review.

One person. Out of 350. And it was a rush. Not because of the number, but because someone I’d never met used my app and took time to write actual feedback. They found a gap in my data architecture that I’d completely missed, something I turned into a real feature.

One stranger’s feedback was worth more than every feature I’d built on my own instincts.

Leave a comment

Vibe coding changed the wrong equation.

Building used to be the bottleneck. You had an idea, you needed months and money to make it real. That constraint was painful, but it did something useful. It forced you to validate first. When building costs three months of your life, you make damn sure somebody wants it before you start.

Now building costs a weekend. That’s incredible. It’s also dangerous.

Because when shipping is cheap, you skip the part where you sit across from someone and ask, “Would you use this?” You skip the part where you find out your idea doesn’t land the way you thought. You skip the uncomfortable work that actually determines whether your product has a future.

Instead, you just build another feature. And another. And another.

The saturation is already here. My feeds are full of people building similar apps in similar categories with similar tools. Most of them will have the same experience I had with Leafed. Weeks of building, a handful of downloads, silence.

Not because what they built is bad. Because the hard problem was never building. It was always getting someone to care.

What this means if you’re building right now.

Whether you’re shipping a side project, launching something for real, or trying to stand out in a job market that increasingly values “builder” credentials, the math has changed in a way most people haven’t caught up with.

Building signals effort. It used to signal commitment. Now that anyone can ship a working app in a weekend, the build itself isn’t the differentiator anymore. What you learned from real users is. What you changed in response to feedback is: Whether anyone came back a second time.

If you’re a PM trying to show you can build, that’s table stakes now. Show me you can get someone to use what you built. Show me you spoke with 20 people and adjusted your approach based on their feedback. That’s the skill that didn’t get cheaper.

I don’t want Leafed to make money. I want the people who try it to love it. That one review taught me more about what “love it” means than 50 features I built in isolation.

Before you ship your next thing, ask yourself three questions.

Who are the first ten people you’ll put this in front of, and do you know their names?

What will you do in week two when no one is downloading it and posting about it feels pointless?

Are you building because you validated something, or because building feels better than the alternative?

That last one is the hard one. I know because I got it wrong for months.

Building is free now. The market for attention, trust, and someone’s willingness to try your thing? That hasn’t dropped a cent.

Mike Watson

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

PS: Ready to document before you schedule? I use ClickUp to keep decisions out of my calendar. Grab a free license here and see if it works for your workflow.

McKinsey’s latest research shows demand for AI fluency has grown sevenfold in two years. It’s now the fastest-growing skill in US job postings. Seven million workers are in occupations where AI skills are explicitly required, up from one million in 2023.

So everyone’s scrambling to learn AI tools. Get good at prompting. Master Claude and ChatGPT. My LinkedIn feed is full of frameworks for writing better queries.

Makes sense, right?

Then I looked at what companies actually ask in PM interviews.

The Toronto Product Management Association partnered with recruiters to survey what hiring leaders at companies like GrubHub, Amazon, Facebook, and Axon are asking candidates right now. Eleven questions from CPOs and VPs of Product.

Not one question about AI tools. Not one about prompting.

Instead: “Tell me about a time you were wrong.” “What’s your biggest screw-up and what did you learn?” “Tell me about a time you had to say no to someone more senior than you.”

The job postings say AI fluency. The interviews test judgment.

I think I know what’s happening.

Prompting is already commoditizing. Cursor autocompletes your prompts. Claude projects remember context, so you don’t have to re-explain. Agent systems are starting to make decisions without you in the loop.

The same McKinsey report that shows AI fluency is exploding also says: “More than 70 percent of skills sought by employers are used in both automatable and non-automatable work.” The skills that endure are “judgment, relationship-building, critical thinking, and empathy.”

In other words: AI fluency gets you in the door. Judgment is what they’re actually hiring for.

I’ve started thinking about this differently. If AI can generate options instantly, what can’t it do?

It can’t identify the edge case that breaks everything. AI gives you the happy path. The weird user who’s going to do something nobody anticipated? That requires human paranoia built from watching things fail.

It can’t sequence strategically. AI can give you a roadmap. It can’t tell you which feature unlocks the next three versus which one is a dead end. That’s pattern recognition from shipping things and seeing what happens.

It can’t synthesize across contexts. AI works in the context you give it. Connecting the support ticket, the sales call, and the analytics spike into one coherent problem? You have to build that map yourself.

It can’t read the room. When the VP says this, the customer says that, and the data says something else, AI can summarize the disagreement. It can’t tell you who to believe.

The uncomfortable part: none of these are skills you learn from a course. They’re built from reps. From making decisions under uncertainty, being wrong, and noticing why.

Prompting, you can learn in a weekend. Judgment takes years.

That’s exactly why it’s valuable.

I’m not anti-AI. I use these tools constantly. But I’ve stopped optimizing for “get better at AI” and started optimizing for “get better at the parts AI can’t do.”

When I think about what to emphasize in interviews, I don’t practice my prompting stories. I practice my judgment stories. The messy decisions. The calls I made without enough information. The times I was wrong and what I learned.

That’s the bet I’m making. The skills that are hard to develop are the skills that will be hard to replace.

Everyone else can fight over who prompts better.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

I drove e-notary adoption from near-zero to a 3,000% increase within a homegrown CRM tool for an auto refinance business. That sentence took me four seconds to type. It takes a recruiter about two seconds to read.

In those two seconds, they learn almost nothing about what actually happened. They don’t know that the internal teams were barely using the system when I walked in. They don’t know about the months of figuring out why adoption was stalling, rebuilding workflows, and getting people to trust a process they’d already written off.

A bullet point is a compression algorithm. And like all compression, it’s lossy. The nuance, the judgment calls, the failures that led to the breakthroughs. Gone.

I’ve been exploring what’s next in my career, and the more I engage with the process, the more I see how the whole system runs on a format that can’t represent what experienced product people actually bring to the table.

250 Applications. 6 Interviews.

The average job posting receives up to 250 applications. Only 4 to 6 of those applicants get invited to interview. Roughly 88% of companies use AI for initial screening, and 40% of applications get filtered out before a human ever reads them.

Product School counted over 26,000 open product roles on LinkedIn each week at the start of 2025. Roles exist. But the funnel between “qualified candidate” and “actual conversation” is broken. If you’ve been doing this for 10+ years, you already know: interviews are where you win. You just have to get there first.

So I Built Something

Nate B. Jones, one of my favorite product and AI creators (shout out ), put out a video recently about building a portfolio that actually represents you. The question I kept circling was: how do I make someone actually want to spend time on my portfolio? How do I make the interaction feel like talking to me?

So I built an AI assistant for my portfolio site. Not a generic chatbot. An AI trained on my actual voice, my real career history, and my honest opinions. Something that lets a hiring manager ask “What was actually hard about that e-notary project?” and get an answer that sounds like me. Because it’s built by me.

Leave a comment

Exporting My Brain Into 38 Markdown Files

A chatbot is only as good as what it knows. And “what it knows” isn’t a resume.

I built a knowledge corpus of 38 markdown files across six categories. Professional narratives. Thought leadership distilled from 150+ Product Party posts. My builder portfolio. Frameworks and opinions. Practical FAQ. Voice calibration documents.

I used Claude to interview me about each role. One question at a time. I answered using speech-to-text in Word, then copy-pasted my responses into the conversation. Claude pushed back when my answers were vague. It asked follow-ups I wouldn’t have thought of. Then it synthesized each conversation into a structured narrative.

It felt like a real interview. The whole corpus took a couple of hours because I’d already done the work. Two years of writing, project documentation, and a voice guide built for this newsletter. If you’ve been writing, building, and documenting your work, you already have the raw material. You just haven’t assembled it yet.

Voice, Guardrails, and 45 Tests

Most portfolio chatbots hedge everything. No personality. No opinions. They sound like every other AI on the internet because they are every other AI on the internet.

My system prompt specifies: lead with failures before frameworks. Have actual opinions. When someone asks, “Should I become a product person?”, be honest about what the job actually looks like day to day. No chat bubble popups. No bouncing typing indicators. Starter questions that guide visitors toward where the AI is genuinely strong. Every one of those is a product decision.

Building the AI was step one. Proving it works was step two. Most people skip step two.

I used Promptfoo to build 45 automated test cases. Voice consistency. Guardrails. Knowledge accuracy. Edge cases. Differentiation tests that validate the AI can’t be confused with a default assistant. Any time I update the corpus or tweak the system prompt, I run all 45 tests. Shipping an AI feature without systematic validation is just hoping for the best.

What This Actually Means

I didn’t write this to convince you to build a portfolio AI.

Your resume can’t convey the judgment you used when two priorities collided. It can’t show how you rebuilt trust with a team that had been burned by your predecessor. It can’t demonstrate how you think when a stakeholder changes direction mid-sprint.

So the real question is: what are you doing to close the gap between what your bullet points say and what you’re actually capable of?

Maybe that’s a portfolio that works harder than a PDF. Maybe it’s writing publicly about your real experiences. Maybe it’s building something that demonstrates you can ship, not just strategize. For me, it was all three at once. The portfolio AI is trained on my writing. My writing is informed by my building. My building proves I can do more than manage a backlog.

I’m not a software engineer. I built this using Cursor with Claude as my development partner. If you’ve been reading Product Party, you know I think product people should be building. This is what that looks like.

Try it yourself →

Ask about the e-notary growth story. Ask it how I handle messy backlogs. Ask it something weird and see what happens.

Your resume is 47 bullet points. Your career is a thousand stories. Figure out how to tell them.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

Three months after these cuts, everything looks fine. Month four is when the wheels come off.

Meta cut 3,600 employees last January. Tidal eliminated its entire PM team. Microsoft shed 15,000 roles. Companies are betting that AI plus engineers can replace PMs.

They're about to discover Claude can write code but can't tell you why users churn.

Building in public forced me to play both roles. These roles aren't interchangeable.

Understanding why requires looking at the math.

Why this looks smart on paper

Product management became an expensive category. In recent years, Senior PMs at tech companies earn $180K-$250K. Multiply that across a team of eight, and you’re looking at $1.6M in annual comp.

Leadership runs the calculation: AI can write specs. Engineers understand technical trade-offs. Design tools prototype interactions. What’s left that justifies $200K per person?

The tasks look automatable. Write requirements. Run sprint planning. Update stakeholders. Collect user feedback. Prioritize the backlog.

ChatGPT handles requirements. Engineers can run their own standups. Product analytics tools surface user data. Jira manages priorities.

On a spreadsheet, cutting PMs while keeping engineers looks like pure efficiency. Maintain technical output while reducing overhead.

Zuckerberg’s memo to Meta employees spelled it out: “We’re moving out low performers faster.” Performance-based cuts sound reasonable until you notice entire PM teams getting eliminated while engineering stays intact.

The pattern repeats across companies. Tidal cut its entire product marketing and product management teams. One engineering leader I follow on LinkedIn posted: “Our PM org went from 12 to 3 in six months. Engineering team unchanged. Executives think AI fills the gap.”

What you’re actually eliminating

Not tasks. Three bridges that can’t be automated or delegated.

When companies cut PMs, they think they’re eliminating coordination overhead. “We don’t need someone to write specs and run meetings.” But PMs weren’t valuable because they scheduled standups.

PMs were valuable because they connected three things that don’t naturally talk to each other: what engineering can build, what customers actually need, and what the business requires to survive. These aren’t coordination tasks. These are translation problems.

AI can automate the documentation. It can’t replicate the judgment that comes from seeing all three perspectives simultaneously and knowing which one should win today.

Bridge one: Technical capability to business value

Engineers optimize for elegant solutions. Business teams optimize for revenue. Someone translates between these languages.

When an engineer proposes rebuilding the authentication system, someone asks: “Will customers pay for better auth? Or do they care about the two features we delayed to do this?”

Building Leafed, AI helped me write better code faster. But AI couldn’t tell me whether barcode scanning or AI-enhanced search deserved the first month of development. That decision required understanding book discovery behavior, competitive positioning, and what would actually get downloads in 2026.

Remove the translation layer, and engineers build technically sound features that don’t move business metrics.

Bridge two: What we can build to what users actually need

Your power users want advanced filtering. Your churning users can’t figure out basic navigation. Which problem do you solve first?

Bangaly Kaba wrote about this for Reforge when he joined Instagram in 2016. The product had 400 million users, but growth had flatlined. Power users loved Instagram. New users couldn’t cross the threshold to become engaged.

Product teams naturally become power users of their own products. This makes them the worst judges of what new users need. AI amplifies this by generating ideas based on existing user feedback. Existing users survived your current complexity.

Who identifies when you’re building for the wrong audience? The PM who can see both what you built and who isn’t using it.

Bridge three: Short-term execution to long-term strategy

Engineers ship code. Executives set vision. PMs connect today’s sprint to next quarter’s positioning.

AI doesn’t understand sequencing. It can’t tell you that Feature A needs to ship before Feature B because A validates the market assumption that makes B worth building.

I’ve seen this pattern on LinkedIn: the PM team is cut, and engineering self-organizes. The first three months look fine. Month four, the backlog runs dry. One engineering manager posted: “Velocity hasn’t dropped. Decision paralysis has quadrupled.”

Building Leafed: Ship barcode scanning first or AI search? Both are technically feasible. Both wanted. Only one could ship this month. That decision wasn’t technical -it was strategic. Which validates our unique value prop? Which builds momentum?

AI doesn’t understand momentum.

Position yourself as AI-augmented, not AI-replaceable

If you’re a PM watching this unfold, your positioning matters more now than your resume.

Generic PM equals replaceable PM. “I write specs and run standups” makes you vulnerable. Those tasks are automatable.

Build your value stack with three layers AI can’t replicate:

Domain expertise that took years to build

You understand SaaS pricing models viscerally. You’ve shipped healthcare products through regulatory approval. You know B2B sales cycles in enterprise software.

That context compounds. AI starts fresh every conversation. You pattern-match across seven years and three industries.

Technical capabilities most PMs don’t have

You can read code and spot architectural decisions that create product constraints. You’ve shipped apps and understand mobile distribution. You know enough SQL to query your own data.

These skills let you work with AI as a multiplier, not as a replacement. You ask better questions because you understand the constraints. You validate AI output because you know what good looks like.

I wouldn’t have shipped Leafed to both app stores without this. AI helped write React Native code. But I needed to understand mobile frameworks, app review guidelines, and distribution channels to know which AI suggestions were actually viable.

Unique perspective your career path created

You went from support to PM and understand customer pain differently. You coded before managing products and spotted technical debt early. You worked in three different industries and see patterns others miss.

Stack these together. You’re not “a product manager.”

You’re “a PM with seven years in fintech who codes and runs a newsletter teaching other PMs, currently building mobile apps to stay technical.”

That’s differentiated. That’s hard to replace with a prompt.

Skills that compound versus skills that commoditize

Commoditizing fast:

• Writing PRDs (AI does this now)

• Creating mockups (Figma plus AI)

• Running standups (async tools replace this)

• Stakeholder updates (automation handles this)

Compounding over time:

• Reading usage patterns across industries

• Recognizing when teams are optimizing local maxima

• Knowing which technical decisions create long-term constraints

• Understanding when to ignore customer requests

• Sequencing bets when everything seems important

Companies cutting PMs bet that the first list matters more than the second. They’re discovering the first list was never the job.

The job was always making better decisions faster than the competition. AI accelerates information gathering. It doesn’t replace judgment built through pattern recognition across hundreds of products and thousands of decisions.

Stop optimizing for task completion. Start demonstrating decision quality.

Final thoughts

Build something that proves you can identify the right problem, sequence the solution, and ship value that users actually want. Newsletter, side project, consulting, open source contribution.

Doesn’t matter which vehicle. What matters: evidence that you can connect technical capability to business outcomes.

Companies that flood LinkedIn with displaced PMs will learn this lesson the hard way over the next 12-18 months. You don’t have to.

Until next week,

Mike Watson

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

PS: Ready to document before you schedule? I use ClickUp to keep decisions out of my calendar. Grab a free license here and see if it works for your workflow.

My brain has always moved faster than my hands could type. ADHD does that. Ideas fire constantly. The bottleneck was always execution. Building took time, which meant friction, which meant only the ideas I really cared about survived long enough to become real.

AI closed that gap.

Now my tools move at the speed of my brain. I thought this was the fix. The superpower I’d been waiting for. Every idea could become a prototype. Every itch could get scratched.

You probably see where this is going.

I have a Google Keep note titled “App Ideas.” It has over 20 entries. Most of them I could build in a weekend. Some of them I’ve already started. A few of them technically work.

None of them are going anywhere.

The thing about doom scrolling is you know you’re doing it. The guilt is built in. But building feels productive. You’re making something. You’re learning. You’re shipping.

Except when you step back, it’s the same pattern. Reach for the phone. Reach for the terminal. Quick dopamine hit. Avoid the harder question of what actually deserves your focus.

I traded one scroll for another. This one just has better optics.

The market doesn’t help. Everyone with an API key is shipping right now. Whatever idea I have probably already exists in some form. Three other people are building it this weekend, too. The log jam is real.

And the economics are genuinely weird. Why would someone pay for an app when they can prompt one into existence? I don’t know what the future of paid software looks like. Neither does anyone else.

So if building fast isn’t the advantage, what is?

I keep coming back to depth. Actually understanding a problem before solving it. Going narrow instead of wide. Picking one thing and getting genuinely good at it rather than having 20 half-finished repos.

The question I’ve started asking myself mid-spiral: how is this going to help me? When I look back on this time, will I feel like it was well spent?

Sometimes the answer is yes. Learning a new tool. Exploring a domain. Building something small that teaches you something big.

But often the answer is that I’m scratching an itch that doesn’t need scratching. And I could be doing something harder. Something that actually compounds.

The irony is that prioritization was supposed to get easier when execution got cheap. Instead, it got more important. When you can build anything, the skill is knowing what not to build.

I’m still figuring this out. The ADHD brain doesn’t shut off. The ideas keep coming. The tools keep getting better.

But I’m trying to catch myself more often. Pause before starting. Ask the question before I’m three hours into a doombuilding session.

Not every idea deserves a weekend. Some of them just need to stay in the Keep note.

Until next week,

Mike Watson @ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.

Most of the prioritization was based on features leadership perceived would drive more sales. Quality of the feature? Didn’t matter as much as which sales leader was pushing for it.

The pattern was brutal. A feature would get built. If it drove adoption, great. But that adoption came from how hard the sales leader pushed their team to use it, not from how good the feature actually was.

If it didn’t drive a sales bump within a few weeks, we’d just move on. Leave it as technical debt. Next feature.

We were optimizing for the wrong success metric.

Subscribe now

Building for applause instead of adoption

The triage feature was supposed to be our big win.

Sales leaders wanted seamless lead routing. When a banker got a call from a customer they couldn’t help (wrong state license, wrong product specialty), they should be able to route that lead to the best-qualified person in the organization. Optimal conversion. Maximum revenue capture.

Makes total sense in the conference room.

We designed it to work seamlessly. The hand-off would be smooth. The customer wouldn’t know they’d been transferred. The lead would land in the best possible hands.

Sales leadership loved it. Approved the budget. We built it.

Nobody used it.

The bankers wanted their teams to get credit for the lead. They’d rather hand it to someone on their own team (even if that person was less qualified) than send it into some optimal routing system where another group would get the commission.

We built what leadership asked for. We solved the leadership’s problem. But the people who actually had to change their daily behavior had a completely different set of incentives.

So they just didn’t use it. Kept doing what they’d always done.

Why this keeps happening

This wasn’t unique to that feature.

We were moving so fast that there was never time for a post-mortem. No conversation about “did we build for the wrong user?” Just onto the next thing leadership wanted.

The early 2010s were all custom development for our org. Now there are off-the-shelf tools that handle team-based routing. They learned from failures like ours.

But the fundamental mistake wasn’t technical. It was strategic.

We kept confusing the person who approved the purchase with the person who had to use it daily. And nobody in the room had the incentive to point that out. Leadership got the feature they asked for.

Engineering has to ship something. The only people who lost were the bankers we never talked to.

What I’d do differently

In retrospect, I would have explored how to get that lead to the right people, closer to the team member, so their groups could get credit.

But here’s what we should have done before writing a single line of code: actually ask the bankers what they needed. Not in a conference room with their VP present. Not in a feedback session after we’d already built it.

A simple survey with a tool like Survey Monkey to the people who’d use it daily: “When you get a lead you can’t help, what would make handing it off easier for you while keeping your team’s numbers intact?”

The answer probably would have been obvious. We just never asked because we were too busy building what leadership assumed they wanted.

The question isn’t “what does leadership want?” It’s “what makes the daily user’s job easier?”

Leave a comment

Before you build for stakeholders

After enough of these failures, I started mapping stakeholder dynamics before any feature gets prioritized.

Four questions to surface misalignment early:

Who approves the purchase? This is who shows up in your roadmap meetings. The person with budget authority. The VP who says, “We need this feature.”

Who actually uses it daily? This is the person whose behavior has to change. The banker taking calls. The sales rep logging activities. The customer success manager updating tickets.

Whose behavior has to change? Be specific. What will they have to start doing? Stop doing? Do differently? If the answer involves extra steps or lost control, you’re in trouble.

What incentives exist that might block adoption? Commissions. Team metrics. Personal efficiency. Political capital. These invisible forces kill more features than technical limitations ever will.

If those answers point to different people with different goals, you could end up wasting engineering time if you’re not careful.

Where most products go wrong

The best products don’t just satisfy the buyer. They make the user’s actual job easier in ways their boss can measure.

That’s harder than building what leadership asks for. It requires saying, “before we build this, let me talk to the people who’ll actually use it.”

Most product teams skip that step. They build for the executive meeting instead of the daily grind.

Then they wonder why adoption is a sales leader pushing their team, not the feature pulling users toward it.

I built a technically seamless feature nobody wanted. You probably have one on your roadmap right now.

The difference is whether you catch it before shipping.

Until next week,

@ Product Party

P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.