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.

Zero reviews. Zero support tips. Zero feature requests. Zero emails asking “can you add this?”

Just App Store metrics showing downloads happened. No attribution data. No way to know who they were or why they showed up.

Users who won’t tell you what’s wrong, but also haven’t left. So how do you decide what to build next?

Your prioritization framework shifts entirely.

I learned this by rebuilding Leafed over the past month. No user panels. No A/B tests. Just App Store silence and decisions about what to build anyway.

Three phases emerged, not from a plan, but from reality forcing my hand.

When users won’t talk, build in three phases

Phase 1: Fix what you didn’t plan for

I built Leafed’s initial screens by looking at other apps, researching best practices, and letting Claude and ChatGPT help with implementation. The LLMs prioritized functionality over aesthetics, which meant I shipped something that worked but looked inconsistent.

The feedback I did get: “Doesn’t feel like modern design.”

Clean, yes. Cohesive, no.

I needed a design system. Not eventually. Now.

The rewrite meant touching 30+ active screens. I used ChatGPT to orchestrate the plan, then Cursor’s Claude Opus for detailed planning and Cursor Composer for fast execution. One week of work, including testing.

The most frustrating part wasn’t the initial fixes. It was regression testing every user flow to make sure nothing broke. Even with a plan, some elements, like headers, needed special focus to work right.

Planning infrastructure early: the difference between touching three files or 30.

If you’re building with AI and you think you might scale, research what a design system plan looks like before you build screen number one. Your future self will thank you.

Phase 2: Build mechanisms before you need them

I wanted to add payments for months, but couldn’t get it working. Then I found RevenueCat - widely used, relatively easy to integrate.

It took a couple of days, mostly because testing on both the Apple App Store and the Google Play Store was tricky. Set up the infrastructure. Verified it worked. Launched it.

Revenue generated so far: $0.

I’d be lying if I said that doesn’t sting a little. When something doesn’t explode - when you’re at 150 downloads and zero revenue - it’s tough to feel like the time is well spent.

But Leafed is a hobby project. A passion project about building, not just about shipping a successful app. The mechanism exists now. When someone finds Leafed sticky enough to support indie dev work, they can. Can’t get paid without the option to pay.

The expense is low. I’m learning database architecture, API design, and mobile development patterns. Skills that compound into other things I can build.

I’ll slowly reduce the time spent if no support comes in after a few months. But until then, while other things are in a holding pattern, I’m using Leafed to plan out what’s next with these new skill sets.

Phase 3: Match table stakes, then find your gap

Without feedback, you’re guessing at what matters. So I started with what users expect.

I added a bottom navigation bar. Took a couple of hours because I already had the infrastructure in place. It solved a data persistence problem I was having across screens. Most apps have a bottom nav. Users expect it. Makes the app feel legitimate.

Then I built my own database for indie books.

Why? No public database of indie-focused books exists. Sites that aggregate indie author submissions don’t share their data—they want you coming back to their platform. So I built from the ground up: database, APIs, and real-time mobile calls.

More work than using an existing book API. But I got feedback that focusing on indie author marketing would be huge. Plus, I learned database infrastructure I could potentially offer as an API service later.

Match users' expectations, then lean into what makes you different. For Leafed: indie book focus, no tracking, features built as learning experiments that benefit users.

AppScreens made creating App Store screenshots painless (click to check them out). Generating professional mockups without wrestling with Figma templates for hours was worth the cost alone.

Once feature-complete (mostly there now), marketing targets that gap.

Those three phases weren’t a strategy. They were responding to what broke.

Share

Prioritizing in silence

Fix what’s broken. Add what’s missing. Match what users expect.

But going through them revealed something: when users won’t talk, your prioritization criteria flip. You’re not optimizing for engagement signals or feature requests. You’re making calls about what infrastructure to build before you know if you’ll need it.

Four principles emerged from making those calls:

1. Infrastructure first if you plan to scale

Design systems, payment mechanisms, and data architecture.

The cost of doing it wrong: 30+ screens to fix later.

Rule: If you’ll touch it 10+ times, build it properly once.

2. Table stakes before differentiation

Bottom navigation bars, expected features, things users assume should exist.

You can’t win on gaps if you’re missing basics.

Rule: Users won’t tell you what they expect - they’ll bounce.

3. Mechanisms before you need them

Payment infrastructure at $0 revenue.

Analytics before scale. Can’t optimize what you can’t measure.

Rule: Optionality has value even at zero usage.

4. Find your gap, then market it

Once you match competitors, your positioning highlights what you do differently.

For Leafed: indie book focus, no tracking, features built with user benefit in mind.

Rule: Differentiation without parity is just being different, not better.

Most product advice assumes feedback exists. User interviews. Analytics dashboards. Support tickets telling you what’s broken.

Early-stage building doesn’t work that way. You’re making infrastructure bets, matching invisible expectations, and building mechanisms for a future that might not come.

This is the gap between “build fast and learn” advice and the reality of building when learning requires users who won’t talk.

Subscribe now

Building before the tipping point

AI can analyze user feedback when it exists. It can’t make judgment calls when the feedback is 150 downloads and silence.

Product judgment under uncertainty compounds in ways execution skills don't. You’re reading signals in what users don’t do. Making bets on infrastructure before you need it. Choosing what not to build when every option feels equally valid.

This is the PM skill that matters before product-market fit: deciding what to build when nobody’s telling you what they want. The companies cutting product teams are betting AI can make those calls. They’re about to learn the difference between generating solutions and knowing which problems to solve.

Skills compound. Data doesn’t exist yet. Build anyway.

Until next week,

@ Product Party

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

Fifteen new AI tools to master. Three frameworks to memorize. Five certifications to earn. Two books on prompt engineering.

Everyone’s building the same skills. Which means everyone’s becoming equally replaceable.

Here’s what nobody’s saying: the gap between where you are and where you want to be isn’t a skills problem. It’s a positioning problem.

Subscribe now

We Keep Walking Into the Same Trap

You already know how to be a product manager. You’ve shipped products. Made trade-offs. Navigated stakeholders. Built roadmaps that actually worked.

But when January hits, we all do the same thing. We make lists of skills to acquire.

Learn Figma. Master SQL. Get better at A/B testing. Figured out how to use awesome tools/platforms like ElevenLabs. Understand machine learning. Read that book everyone’s talking about.

The logic seems solid: better skills equal better opportunities.

Except it doesn’t work that way anymore.

ChatGPT can write your BRD. Cursor can build your prototype. Perplexity can do your competitive research. The skills you’re planning to learn are the exact skills being commoditized fastest.

I’m not saying skills don’t matter. I’m saying they’re no longer the differentiator you think they are.

What Actually Makes You Valuable

A few months back, I got a call from a startup building developer tools.

They’d built something they believed solved a real problem - tools that help engineering teams maintain long-term knowledge about what was built and how it worked. The kind of thing that saves new senior engineers months of archaeological digging through codebases.

They had a roadmap packed with features. What they didn’t have was a way to prioritize which features would actually get them past the security reviews, procurement processes, and organizational skepticism that keep most dev tools out of enterprise environments.

They didn’t ask if I knew the latest prioritization framework. They didn’t care which AI tools I used. They never mentioned my product management certifications (which, for the record…I do not have).

They asked: “How do you figure out which features will actually get senior engineers to champion your tool internally?”

The answer came from living through both sides. Building Leafed taught me what developers actually care about versus what they say they care about. Ten years in corporate environments taught me how features get adopted when security teams, procurement cycles, and risk-averse engineering leaders are involved.

That specific combination - technical empathy plus enterprise navigation experience - that’s what they needed. And it’s something you can’t learn from a course.

I don’t know where they ultimately took it after that conversation. I’m watching from a distance to see if they succeed. But the point stands: they weren’t buying skills. They were buying perspective that only comes from doing the thing.

Your value isn’t what you can learn in 2026. It’s what you uniquely bring that can’t be replicated by someone spending three weeks with Claude.

Think about it: what combination of experiences, domain knowledge, and point of view could you never fake with six months of study?

That’s your positioning.

Ask a Different Question

Stop asking: “What skills should I develop?”

Start asking: “What unique value stack am I building?”

A value stack isn’t a resume. It’s the combination of things you’re doing that nobody else is doing quite the same way.

Mine looks like this:

• Newsletter writing every week (developing clear thinking, building an audience)

• Shipping Leafed to app stores (developer empathy, understanding constraints)

• Consulting with early-stage founders (pattern recognition across companies)

• 10+ years in both enterprise and startup environments (translating between worlds)

None of these individually makes me special. Product managers write. PMs learn to code. Plenty of people consult.

But together? That specific combination? That’s positioning.

The newsletter serves as a distribution channel for my consulting. Consulting surfaces insights for the newsletter. Building Leafed taught me what founders actually deal with. My corporate experience helps me translate startup chaos into frameworks that founders can actually use.

Each piece amplifies the others.

Your Actual 2026 Plan

Here’s what’s going to happen this week.

Most product people will save three “Top AI Tools for Product Managers” articles to read later. They’ll add “Learn Cursor” to their task list. They’ll buy that course on prompt engineering that’s been sitting in their cart.

They’ll feel productive. They’ll feel like they’re investing in themselves.

And six months from now, they’ll wonder why nothing changed.

Because skills aren’t strategy. Learning isn’t positioning.

Here’s what I would do instead.

Pick one thing you’re building in public. Pick one domain you’re going deeper into. Pick one point of view that’s actually yours.

Not all three at once. Just one. The thing that feels most natural to who you already are.

If you’re exploring healthcare SaaS, start writing about what you’re learning. Not generic “how to build in healthcare” content for healthcare. Your specific observations about what works and what doesn’t.

If you’re figuring out AI product integration, document the decisions you’re making. The trade-offs nobody talks about. The failures that taught you something.

If you’re navigating the corporate-to-startup transition, share what you’re discovering about how to translate your experience into startup currency.

Pick your angle. Go narrow. Get specific.

Because when someone needs exactly what you’ve been building, there’s no substitute.

What This Looks Like in Practice

Your 2026 goal shouldn’t be “learn Python.”

It should be: “Build credibility in [specific domain] by [specific method].”

Examples:

• “Become the go-to person for product-led growth in fintech by analyzing 50 PLG strategies and documenting what works.”

• “Develop expertise in AI tool integration by testing 30 tools in production and writing case studies.”

• “Position myself as the corporate-to-startup translator by documenting 12 real transitions and the patterns that predict success.”

Notice the difference?

Skills are inputs. Positioning is outcomes.

Skills are generic. Positioning is specific to you.

Skills can be learned. Positioning must be earned through doing.

Stop Planning, Start Positioning

If any other product person could copy your 2026 plan with access to the same courses, you’re not building positioning. You’re just keeping up.

Keeping up isn’t enough anymore.

The market doesn’t need more product managers who know the same frameworks. It needs people who’ve done specific things and can help others do them too.

Those LinkedIn posts you saw yesterday? The ones with the learning lists and course recommendations?

They’re all building the same skills. Which means they’re all competing for the same roles.

You don’t have to.

This week, pick one thing you’re building that you couldn’t fake with AI and three months of study time. Not eventually. This week.

Write one post about it. Ship one mini version of it. Tell one person about what you’re learning from doing it.

That’s your 2026 plan.

Everything else is just keeping up.

Until next week,

Mike Watson

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

You know that feeling when you’re working harder than you’ve ever worked, producing more than you’ve ever produced, and you can still see the writing on the wall? That was me for months leading into March 2025. No matter what I did, no matter how many wins I stacked up, it was just my time to go.

And when it finally happened? Relief.

Not excitement. Not fear. Just relief. Because the waiting was finally over, and I could stop pretending the outcome might be different.

But relief only lasts about two days when you don’t know how you’re going to pay your bills.

Fortunately, I have an incredible network. Within weeks, I landed a hybrid role (part program management, part product management). It wasn’t the pure product ownership I’d lost, but it let me lean into execution and delivery.

What I didn’t expect was how this shift would change my relationship with Product Party. My newsletter stopped being a side project. It became my laboratory. And as I started writing about career uncertainty and what happens when experienced tech professionals have to figure out what’s next, the audience responded because there are a lot of us navigating the same questions.

I wasn’t just writing for me anymore. I was writing for all of us.

So here’s how 2025 actually played out against what I said I’d do.

What I Said I’d Do (vs. What Actually Happened).

At the start of 2025, I set three clear goals:

Goal #1: Be more active in communities.

My Plan: Respond to comments thoughtfully, engage in product spaces, and maybe host a Q&A.

What Happened:

I definitely engaged more (sometimes a little too aggressively). I got banned from r/productmanagement for accidentally promoting my newsletter. Oops.

But I also discovered some incredible voices through Substack Notes, even if the sheer volume of automated content meant I had to actively hunt for the good stuff instead of algorithms surfacing it for me.

Grade: B (enthusiastic participation, minus points for the ban)

Goal #2: Focus on content strategy and consistency.

My Plan:

• Publish one post per week

• Complete at least 2 product deep dives

• Maybe have a viral moment

What Happened:

I kept the one post per week commitment all year. Fifty-two posts published without missing a week, even through job loss and role transition.

The deep dives? Didn’t really materialize fully. I dabbled in covering some products…but something better happened.

In late February (right as I was processing my impending job loss), I published back-to-back posts: “Finding your way: modern tools for the modern job search” and “Practical ways I am using AI daily.”

They took off.

Suddenly, I wasn’t averaging 400 views per post anymore. I was regularly hitting 2,000+. My highest post this year reached 4,500 views.

I got picked up by Pendo.io and other product management aggregators. My content was reaching people far beyond my subscriber base, and they were engaging with it in ways I hadn’t seen before.

By the numbers:

• Average views per post: 400 → 2,000+ (5x growth)

• Highest single post: 4,500 views

• Industry aggregator features: Multiple

I didn’t chase virality. I wrote from a place of genuine uncertainty about my own future, and thousands of others felt the same.

Grade: A (crushed consistency, exceeded reach goals, learned deep dives aren’t the only way to create impact)

Goal #3: Find my writing voice.

My Plan: Write like we’re sitting down for coffee, not delivering a presentation.

What Happened:

There’s a post I wrote called “Are you fulfilled by the work you are doing?”

I was expecting to get fired. I was questioning everything. And I wrote from that place of raw honesty about career crossroads and what it means to feel purposeful in your work.

That’s when I felt it click.

I stopped trying to sound like a product expert delivering insights and started writing like someone who’s been through some stuff and wants to share what I’ve learned.

Real examples from my own work. Frameworks I’ve actually tested. Honest reflections on what worked and what didn’t.

The engagement confirmed it. People replied with their own career anxieties. They shared the post with colleagues going through similar transitions. My content wasn’t just informative; it was engaging. It was connecting.

Grade: A (found the voice, and it resonated)

Unexpected Wins.

Some of the best things that happened in 2025 weren’t on my goal list at all.

I got my first sponsorship.

Chameleon reached out to test whether smaller, niche newsletters could drive traction for them. They gave me four sponsored posts to run, with complete control over duration and content.

It wasn’t life-changing money. But it was validation that what I was building had value beyond my own satisfaction. People were paying attention. Brands saw potential in this audience.

More importantly, it shifted how I thought about monetization. Product Party could actually generate revenue. Not enough to quit my day job, but enough to prove that sustained effort creates opportunities you can’t predict.

I shipped a production app.

In the middle of navigating job loss and a new role, I decided to finally tackle a 2025 goal I’d set for myself: understand mobile development by shipping something real.

I built Leafed (a book search app using React Native and Expo). It’s on both the Apple App Store and Google Play Store. Cost me about $175 and countless hours figuring out how to architect something that works across platforms.

The moment I got it live in production? That was the “oh sh*t, I actually know how to do this now” moment.

But the real learning wasn’t about code. It was about thinking at the right level of abstraction. When you’re both the product person AND the developer, you start appreciating the speed considerations and architectural decisions you used to take for granted.

I’ve always been able to design at scale and break down complex plans.

Now I can code them too. That changes everything about how I evaluate feasibility and scope.

I collaborated with people I respect.

- (who writes the outstanding Product Release Notes) invited me to contribute to her AI Advent Calendar project.

It was one collaboration, but it showed me how much more powerful content becomes when you work with other creators who share your values and audience.

I want more of that in 2026.

Leave a comment

What Didn’t Work.

Not everything was a win. Let’s be honest about what flopped.

LinkedIn and Bluesky engagement never materialized.

I started the year posting consistently across Substack, LinkedIn, and Bluesky. The hope was to meet readers where they already were and build engagement across platforms.

It didn’t work.

LinkedIn felt like shouting into a void of algorithm optimization and corporate speak. Bluesky was interesting, but never gained the traction I needed to justify the effort.

So I doubled down on Substack and put my energy where the audience was actually responding.

I rested on my laurels as a project manager.

Here’s the thing nobody tells you: your skills aren’t as portable as you think.

I’ve always been able to walk into any organization and get teams to deliver. It’s my superpower. But when I landed in my new hybrid role, I took for granted how much of that success came from context, relationships, and organizational knowledge.

You can’t just show up and expect people to follow you. You have to rebuild trust. You have to understand the new system. And you have to be way more detailed in how you communicate, both to appease stakeholders and to get the most out of teams who don’t yet know you.

It was humbling. But it made me better.

Numbers That Matter.

Let’s talk growth.

Subscribers:

• January 1, 2025: 710

• November 17, 2025: 1,398

• Projected end of year: 1,420+ (100% growth)

Engagement:

• Average views per post: 400 → 2,000+ (5x growth)

• Highest single post: 4,500 views

• Open rates: Consistently 29-31% (well above industry average)

Posts published: 52 (maintained 1 per week for the entire year)

Revenue generated: First sponsorship partnership (Chameleon, four posts)

Apps shipped: 1 (Leafed, available on iOS and Android)

What 2025 Taught Me.

I started this year thinking I needed to be more active, more consistent, more strategic.

What I learned is that the best content comes from lived experience. From writing through uncertainty instead of waiting until you have all the answers.

I learned that technical skills compound faster than you expect when you commit to actually building something.

I learned that losing a job doesn’t mean losing momentum. It can actually force you to clarify what matters and where you want to invest your energy.

And I learned that there’s an entire community of mid-career tech professionals navigating the same questions I am. We’re not looking for generic startup advice. We’re looking for honest reflections from people who’ve been through it.

That’s what Product Party became in 2025. Not just a newsletter about product management frameworks, but a space for honest conversations about navigating careers in flux.

What’s Next for Product Party in 2026.

I’m not interested in setting goals to check boxes anymore. 2025 taught me that the most meaningful progress comes from committing to things that actually matter.

Here’s what I’m building toward:

1. Content Evolution: “How I’d Solve This.”

I’ve spent enough time analyzing what other companies do. In 2026, I want to shift to showing how I’d actually approach specific product challenges.

Less observation. More applications.

Measurable targets:

• Hit at least one post with 10,000+ views

• Average 4,000 views per post

2. Strategic Collaborations.

The collaboration taught me that creating in isolation has a ceiling. When I contributed to her AI Advent Calendar, I wasn’t just writing for my audience. I was part of something bigger, and it forced me to think differently.

Target: Partner with 3 product creators in 2026 for guest posts, co-created content, or joint analysis.

Not transactional follower swaps. Real collaborations where we’re wrestling with a problem together and the combined output is meaningfully better than what either of us would produce alone.

3. Technical Impact: Build for Good.

I proved I can ship a production app. Now I want to use those skills for something beyond personal learning projects.

Dual-track approach:

• Ship an app (mobile or web) that generates at least $1 in revenue

• Contribute software to the non-profit community

I see many non-profits seeking help understanding how to use AI effectively. Maybe I can build a platform that levels them up quickly. Perhaps it’s something else. Either way, I want to use my skills for mission-driven work.

4. Sustainable Monetization.

The Chameleon sponsorship proved that people are willing to pay to reach this audience. Now I want to build recurring revenue streams.

Target: Average $100/month from combined sources

• Affiliate links (ClickUp, Monday.com, productivity tools)

• Sponsorships

• Potential paid offerings (templates, toolkits, deep-dives)

This isn’t about quitting my day job. It’s about validating that Product Party creates real, sustainable value.

5. Growth Targets.

Numbers matter, but only when they represent real people finding value in what you’re building.

• Subscribers: 1,420 → 3,000 (111% growth, ~132 new subscribers per month)

• Engagement: Maintain 29-31% open rates while growing reach

I’m not chasing vanity metrics. I want 3,000 people who actually open these emails, who reply with their own career questions, who forward posts to colleagues facing similar challenges.

Growth that reflects genuine connection, not just algorithmic luck.

Closing Thoughts.

If you’d told me in January that I’d lose my job, ship a production app, double my subscriber base, get my first sponsorship, and completely redefine what Product Party means to me, I would’ve thought you were describing someone else’s year.

But that’s exactly what happened.

2025 was the year I learned what happens when the floor drops out, and you build something anyway.

Not because you have a perfect plan. Not because you’re sure it’ll work. But because you’re committed to showing up, trying things, and sharing what you learn along the way.

I’m incredibly grateful you’ve been part of this journey. Whether you’ve been here since the beginning or you just subscribed yesterday, thank you for reading, engaging, and being part of this community.

Here’s to 2026 (the year we turn consistency into impact, voice into value, and skills into solutions).

Until next year,

(pictured with my daughter and the real MVP, Leah)

Also - I made a new logo and color scheme. Let me know what you think!

PS: What are you building toward in 2026? I’d love to hear what you’re working on. Drop a comment below or send me a note.

Thanks for reading! If you haven’t already, please like, comment, share, and subscribe. You can also show your support by buying me a coffee.

Leave a comment

I’m excited to round out 2025 with you all and look forward to building more in public and sharing along the way. If you want to consider a collaboration (building, writing), please feel free to reach out to me - mike@productparty.us

On to the good stuff…

Your carefully crafted roadmap is probably fiction within weeks of creating it. Priorities shift. Leadership changes direction. That feature everyone agreed on in Q1 planning feels irrelevant by April.

I learned this while launching a massive CRM overhaul at one of my previous employers. It wasn’t the plan that saved us. It was the planning.

We needed to replace our aging Oracle CRM, but getting any change approved meant navigating multiple levels of sign-off. So we built what I came to think of as “the plan behind the plan” - not just development milestones, but our organizational strategy for getting clearance and building credibility.

We created pilot groups of actual salespeople who tested and provided real-time feedback. By the time we asked for full rollout approval, leadership had been watching it work for months. Regional releases went live within three months with strong adoption.

The original plan changed constantly. We reprioritized features, adjusted timelines, and shifted our rollout sequence. But we shipped successfully because everyone shared the same mental model of what we were trying to accomplish.

That’s the paradox: the plan became obsolete, but the act of planning together made us capable of executing even as everything changed.

What planning actually does (that plans don’t).

I learned this lesson the hard way on one of my first projects with that same CRM system.

Leadership wanted better data collection, so we built two dropdown fields on the customer profile. Simple enough, right? Except those dropdowns became the center of three full senior sales leader meetings (plus countless pre-calls) just to decide what options should appear in each dropdown.

We debated categories. We argued about terminology. We revised the options multiple times based on who had spoken to leadership most recently. And you know what happened when we finally launched it?

No one used them.

The salespeople didn’t want to fill out more fields. The data we collected wasn’t actionable. The whole feature became a monument to wasted effort, and I couldn’t understand why we’d spent so much time on something that delivered so little value.

The problem wasn’t the dropdown design. We never planned the fundamentals. We skipped straight to implementation details without establishing a shared understanding of what problem we were solving, whether users actually wanted this, or how success would be measured.

Planning creates three things that individual plans can’t capture.

1. Shared vocabulary

When teams plan together, they build a common language. The CRM project team could say “like we discussed in our pilot testing strategy” and everyone immediately understood the trade-offs we’d already considered.

With the dropdown project, we had no shared foundation. Every meeting started from scratch, rehashing the same debates because we’d never established what we were collectively trying to achieve.

2. Decision scaffolding

Good planning names your assumptions explicitly. For the CRM rollout, we knew our plan depended on getting regional leadership buy-in early and maintaining pilot group enthusiasm. When technical delays threatened our timeline, we knew exactly which assumption was at risk and could adjust our approach accordingly.

The dropdown project had no scaffolding. When adoption tanked, we had no framework for understanding why or what to do differently. We’d never articulated what had to be true for this to succeed, so failure just felt like generic disappointment rather than a specific lesson.

3. Forcing functions for hard conversations

This is the one people underestimate most. Planning surfaces conflicts before you’re mid-sprint with no time to resolve them. The CRM project forced us to have uncomfortable conversations about organizational politics, user resistance, and technical constraints before we were too deep to pivot.

With the dropdowns, we avoided the hard conversation (”Will salespeople actually use this?”) and instead debated the easy one: “What should the dropdown options be?” We spent meeting after meeting on implementation details because we’d never done the planning work to question the premise.

So…the kicker? Both projects were within the same organization, using the same product, and faced similar bureaucratic challenges. The difference wasn’t the plan’s accuracy. Both plans changed constantly.

The difference was that one team did the hard work of planning together, while the other team just scheduled meetings to argue about details.

Planning for obsolescence.

If plans become obsolete but planning matters, what kind of planning actually works?

I’ve developed what I call the “Plan to Pivot” approach. It’s not about predicting the future better. It’s about building the foundation that lets you respond quickly when the future inevitably surprises you.

Name your assumptions explicitly.

This is the practice that saved us most often with the CRM rollout. We wrote down what had to be true for our plan to work: Regional leaders needed to see value in the pilots. IT security would approve our Oracle implementation. Salespeople would engage with testing groups rather than treating it like extra work.

When technical delays threatened our timeline, we didn’t panic about the schedule. We asked, “Which assumption is this threatening?” It turned out the delay risked pilot group enthusiasm (our third assumption), so we focused our energy there.

We kept the testing groups engaged with regular updates and made sure they felt heard even when we couldn’t deliver new features immediately.

Without those named assumptions, that delay would’ve just felt like generic project stress. With them, we knew exactly where to focus.

Try this Monday: Take your current project and write down three things that have to be true for it to succeed. Not hopeful things, but actual dependencies. When something changes, you’ll know which domino fell.

Set decision points, not deadlines.

The dropdown project failed partly because we had a deadline (ship by end of quarter) but no decision points (when do we validate whether salespeople actually want this?).

The CRM project worked because we built in specific moments to reassess: after the first pilot group feedback, after regional leadership reviews, after the initial security audit. These weren’t gates that slowed us down. They were checkpoints that told us whether our assumptions still held.

“We’ll reassess after the first 50 users have tested this for two weeks” is more valuable than “Launch by Q3.” One gives you information. The other gives you pressure.

Plan in chunks, not marathons.

The biggest shift in my planning approach came from realizing I don’t need the same level of detail for everything. I need specificity for the next hill I’m climbing, and direction for the mountain range beyond it.

For the CRM rollout, we planned the first pilot group in detail. Which departments? Which regions? What feedback mechanisms? How would we incorporate their input? That planning was concrete and specific.

But we kept the full rollout plan deliberately fuzzy. We knew roughly which regions would go next, but we didn’t lock in the sequence until we’d learned from the pilots. That flexibility let us adjust based on what we discovered rather than forcing us to stick to assumptions we’d made months earlier.

Planning everything in equal detail is a trap. It creates the illusion of control while actually making you less adaptable.

Leave a comment

Final thoughts.

Your plan will be wrong. The market will shift, priorities will change. That’s not pessimism - it’s just product work.

But planning gives you a team that can pivot quickly because they’ve already wrestled with the hard questions together. Both the dropdown project and CRM rollout faced unexpected challenges. One team adapted. The other scheduled more meetings.

The plan is your map, but planning is learning to navigate. The map becomes outdated. The navigation skills stick around - and they’re what separate teams that ship from teams that schedule three senior leader meetings to debate what goes in a dropdown.

Until next week,

Mike Watson

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

P.S. Are you a founder looking for some direction on what to build next? Check out Product Party - The Founder Starter Pack. It’s free and perfect for first-time founders who want frameworks over philosophy, evidence over gut feelings, and practical templates over theoretical advice.

P.P.S. ElevenLabs converts docs to audio so I can actually get through research instead of bookmarking it to die in a tab graveyard. Free tier’s generous. Worth testing if listening beats reading for your brain.

This week - Both apps are live. Apple approved in 48 hours after I fixed their feedback. Google approved two days after I submitted. You can find your download for either version at leafed.app (which… was also vibe-coded of course).

But the story doesn’t end with approval. It starts there.

Apple moves fast when you listen to their feedback.

Sunday night: Submitted to Apple. Monday night: Rejected.

Apple flagged my “Buy Me a Coffee” button because it looked like it should be an in-app purchase. They were right. From a UX consistency standpoint, a donation button in that placement creates user confusion across their platform.

I removed it. Resubmitted Tuesday night. Approved Wednesday afternoon.

Total turnaround from rejection to approval: 48 hours.

That’s the thing about Apple’s process. It’s fast, but they’re incredibly particular about user perception and platform consistency.

Not arbitrary pickiness. Thoughtful curation.

Leave a comment

Google’s process is thorough but straightforward.

After the 14-day testing window closed, I submitted my production request on Wednesday morning. Approved Friday.

Google’s information release is more tedious than Apple’s, but once you have your testing evidence documented (which you should after living through 14 days of coordinated human engagement), the process is straightforward.

Different philosophy than Apple. Not better or worse. Just different.

Both apps went live within the same week. Different approaches. Same outcome.

Share Product Party

The feature I cut in Part 1 is back (and I’m nervous about it).

Remember the bookshelf scanner I built and cut because ML Kit couldn’t handle inconsistent book cover formatting?

I kept thinking about it.

Used Perplexity to dig through alternative approaches. Researched how other apps solved this problem. Found different implementations. Tested a few solutions.

Eventually got it working. Not with the original approach, but something different that handles the formatting inconsistencies better. I’m not sharing the specific tech yet, but the point is: cutting a feature doesn’t mean giving up on it.

Now it’s live in the app. And I’m watching usage carefully.

I added per-user caps to manage usage costs while I figure out if people actually want this feature. Right now, I’m focused on getting users to try it rather than optimizing for monetization. But if this thing gets real traction, those caps give me room to add paid tiers later without eating costs I can’t sustain.

That’s product thinking, not just building.

My workflow made this possible.

People keep asking how I built this as a non-developer. The answer isn’t “AI writes code for you.” It’s more nuanced.

Research deeply. When stuck, I used Perplexity to dig through obscure GitHub repos, alternative libraries, and how other developers solved similar problems.

Feed context to Cursor. Not just “build this feature” but “here’s what I found, here’s the approach, here’s what didn’t work before.”

Experiment in isolation. I’d spin up 3 versions of the same feature using different approaches. Push each one. Test them. See which works best. Remove the rest. Easy to do with vibe coding, impossible with traditional development.

Test fast. Expo Go for quick iteration, TestFlight for Apple-specific testing.

Make product decisions. When something worked, I decided if it should ship.

The combination of research tools (Perplexity), implementation tools (Cursor), near-instant testing for most features (Expo Go), rapid experimentation, and product judgment made this possible. Not any single tool. The workflow.

What this taught me about product work that I couldn’t learn any other way.

Building Leafed changed how I think about product conversations.

When someone says, “Can we add this feature quickly?” I now think about deployment pipelines, platform reviews, and usage costs instead of just saying “probably.” When developers call something hard, I believe them because I’ve watched “simple” fixes take a week of research and multiple failed attempts.

When stakeholders ask about A/B testing post-launch, I understand why mobile platforms make that nearly impossible. When someone says “API costs should be minimal,” I think about the per-user caps I set before I had any users, because unit economics matter from day one.

I’m not a developer and don’t want to become one, but I understand their constraints differently now. When they push back on timelines or talk about technical debt, I get it because I’ve made those same tradeoff decisions.

This isn’t about learning to code. It’s about understanding constraints firsthand by building something real, shipping it to actual platforms, and managing real costs.

Tools like Cursor and Perplexity make building accessible, but they don’t replace developers. They close the gap enough that product people can experience the process viscerally and develop the skills that actually matter: research, synthesis, pattern recognition, and product judgment.

AI can’t decide what to build, when to cut, when to iterate, or when to ship. That’s still human work.

Share Product Party

What’s next for Leafed?

Both apps are live. I’m just starting to market it. No real traction data yet because I literally just launched.

I’ll keep iterating based on what I learn from actual users (if I get any). The bookshelf scanner is the feature I’m most excited about, but it’s also the one I’m most nervous about because of usage costs.

Maybe people will love it. Maybe they’ll never use it. Maybe I’ll need to add paid tiers. Maybe it’ll just sit there as a free app that a few people find useful.

Either way, I accomplished what I set out to do: understand mobile development end-to-end by actually shipping something real.

The goal wasn’t downloads. It was education. And that goal is complete.

Subscribe now

Why you should build something.

If you’re a product person who wants to better understand technical constraints, build something real, and ship it. Not to become a developer, but to become a better product person.

The tools exist. Cursor can help you build, Perplexity can help you research, React Native and Expo let you target multiple platforms. The barrier isn’t technical skill, but deciding to start and committing to finish.

I spent around $175 in year-one costs. What I got back was worth more: understanding that changes every technical conversation I’ll have for the rest of my career.

Download Leafed at leafed.app. Try the bookshelf scanner. See what’s possible when product people stop theorizing and start shipping.

Until next week,

Mike Watson

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