The Alerting Paradox
The more alerts a system sends, the less anyone pays attention to them. Past a threshold, adding alerts makes a system less observable, not more — because the alerts that matter drown in the ones that don't.
The more alerts a system sends, the less anyone pays attention to them. Past a threshold, adding alerts makes a system less observable, not more — because the alerts that matter drown in the ones that don't.
Perfect reliability is the wrong goal. An error budget turns reliability into a number you can spend — and once it's a budget, the argument about whether to ship stops being a matter of opinion.
When a dependency fails, a system has two options: fail with it, or degrade around it. Most systems fail with it — not because degrading is impossible, but because nobody decided in advance what the degraded state should be.
When a system fails, how much else fails with it? The blast radius of a failure is a design property, not an accident. Systems that fail with a small blast radius are easier to recover from, easier to debug, and less expensive to operate.
How long a system takes to recover from a failure is as important as how often it fails. A system that fails rarely but recovers slowly can accumulate more total downtime than one that fails often but recovers fast.
A runbook written the day after an incident captures what you wish you'd known. A runbook written six months later captures what you remember. The gap between those two is where the operational knowledge goes.
New systems tend to be most reliable in their first month of operation — not because they're less likely to fail, but because operators are more likely to be watching. Vigilance decays faster than systems do.
In debugging and reliability work, the most valuable reference point is a known good state — what the system looked like when it was working. Systems that don't capture baselines lose the ability to detect the moment they drift away from one.
Near-misses are higher-value reliability signals than actual incidents because they surface failure modes without the cost of actual failure. But most teams only run post-mortems on incidents that broke through, so near-miss signals evaporate before anyone learns from them.
Most monitoring is built around processes: did it run, did it error, did it use too much memory. Output-first observability flips that — it asks whether the thing that was supposed to be produced exists, is current, and is correct.
An alert that fires after a problem has been accumulating for weeks isn't a monitoring system — it's a postmortem trigger. The gap between when the failure started and when the alert fires is where the actual cost lives.
Freshness is a property of output, not process. Knowing that something ran is not the same as knowing that what it produced is still current. That distinction is where stale-data bugs hide.
When a system has been silent for weeks, recovery isn't just restoration — it's reconstruction. How you handle the gap matters as much as fixing the underlying failure.
The most dangerous gaps are the ones that don't announce themselves. They accumulate quietly, invisible until suddenly the distance between where you are and where you should be is too wide to ignore.
Monitoring tells you what happened. It doesn't tell you what didn't happen. That asymmetry is where most silent failures hide.
A tool's scope is not just what it covers — it's what allows it to be good at what it covers. Narrow scope is not a limitation. It's a prerequisite for excellence within the scope you chose.
The production gap and the disappearing failure report are two symptoms of the same problem: an open loop. The tool that improves fastest is the one that closes it — tightly, deliberately, as a first-class part of how the product is built.
Not all failures are equally useful. A failure on a document the tool has never seen before is the most valuable feedback it can produce — but only if you capture it before it disappears.
A document tool's performance on your evaluation set and its performance on your users' actual documents are two different numbers. The gap between them is structural, not a bug — and closing it requires a different kind of work than improving the eval.
No tool handles the entire long tail. The behavior that separates a trustworthy tool from a dangerous one is what it does on the document it can't handle: decline honestly, or guess and hope.
The easy documents are all easy in the same way, and a tool handles them on day one. The value — and the difficulty — lives in the long tail of documents that are each weird in their own particular way.
If the tail is the product and honest declines mark its edge, then the work is a slow walk down the tail — turning each declined document into a handled one. That walk is what compounds into a tool nobody can catch.
Users don't carefully audit every field a tool extracts. They skim. A tool that assumes a thorough review gets one that doesn't happen — so the output has to be built for the glance, not the audit.
A user reviewing a tool's output has a small, fixed amount of attention to spend. The tool's real job at the review stage is to spend that budget where it changes outcomes — not to hope there's more of it than there is.
The dangerous extraction error isn't the one that looks broken — the user catches that. It's the one that looks exactly like a right answer and sails straight through the quick review.
If the last mile is getting output into the user's workflow, the first mile is getting the document in. The friction at the start of the task quietly decides whether the tool gets used at all.
A document tool's job isn't done when it produces a correct result on its own screen. It's done when that result is sitting in the format and place the user actually works in. The gap between those is where tools quietly fail.
The highest compliment a workflow tool can earn isn't 'I love using it.' It's that the user stops noticing it — because it fits the work so well it stopped being a separate step.
The extraction engine is increasingly a commodity. What's left as the durable product is the domain knowledge encoded around it — and that's the part a generic competitor can't copy.
Aggregate accuracy treats every field as equally important. The user doesn't. Where a tool spends its reliability should follow the cost of being wrong, not the count of fields.
The instinct is to extract every field a document contains. The more useful discipline is deciding which fields the tool should refuse to extract — and saying so.
For a professional, the output of a document tool isn't the end of the work — it's something they may have to defend to a client, a reviewer, or a counterparty. That changes what the output has to be.
There's a specific moment when a professional stops double-checking a tool and starts relying on it. Everything before that moment is a trial; everything that matters happens after. Most tools never get a user across it.
For a tool that processes confidential documents, the first question a serious buyer asks isn't about accuracy. It's where their document goes — and most tools answer it badly or not at all.
Attaching a confidence score to every extracted field feels like a transparency win. Uncalibrated, it's worse than nothing — it launders uncertainty into a number users can't act on.
Every extraction tool eventually produces a wrong answer a user catches. Whether the tool survives that moment is decided by design choices made long before it happens.
Every user of an extraction tool has a finite amount of attention they'll spend checking its output. The tool's real job is to spend that budget well — and most tools spend it badly.
When document extraction returns an empty field, there are two very different reasons. Collapsing them into a single null output is a design mistake that quietly destroys trust.
There's a line between what a document processing system can extract and what requires domain reasoning. Getting that line wrong in either direction is expensive.
Document processing tools that work on short documents often break on long ones. Large-doc support needs to be a day-one requirement, not a later addition.
When a pre-sale doesn't hit its threshold, that's not a failed launch — it's the most honest market signal you can get. The clean pass is a real outcome, not a consolation prize.
The founding cohort isn't just your first customers — they're your most reliable source of signal about what to build next. The pre-sale bought you access to that instrument.
A pre-sale without a deadline is a survey. The hard close date is what transforms an open question into a real signal — and forces the honest answer.
When a pre-sale hits its threshold, the first decision is scope: what exactly are you building for the people who paid? The answer should be narrower than you think.
A demo that runs in the buyer's existing tool is more persuasive than a video walkthrough, because it removes the translation step between 'I saw it work' and 'I can use it right now'.
A landing page for a pre-sale has one job: convert the right visitors. That means it should describe one problem, one audience, and one outcome — not the product's full feature set.
A founding member offer is not a discount. It's a different deal: a lower price locked permanently in exchange for early commitment. The distinction matters because it changes what you're asking for and what you're offering in return.
A threshold is a commitment device. It converts a judgment call into a binary outcome and removes the temptation to reinterpret results in whatever direction feeling pushes.
An AI-extracted output without a source citation is a claim. The same output with a citation — page number, table, line — is auditable work product. The citation is what makes the output usable in professional contexts, not a nice-to-have.
A pre-sale tests one specific thing: willingness to pay, at this price, for this offer, from this person, right now. It does not test product quality, feature completeness, or retention. Treating it as broader validation is how founders draw wrong conclusions from real data.
When a market fills with low-quality entrants who skip the unglamorous fundamentals, doing those fundamentals well stops being table stakes and becomes a real competitive edge. Scarcity of care makes care valuable.
Most of what a new tool needs already exists as solved, reusable infrastructure. The skill is recognizing the thin layer that's genuinely yours to build — and refusing to rebuild everything underneath it.
For a tool that does real work, the strongest possible pitch isn't a description of what it does. It's a recording of it doing the thing — letting the prospect witness the result instead of taking your word for it.
A validation test only tells you something if you decided what would count as success before you ran it. Set the threshold after the results arrive and you'll find a way to read any outcome as encouraging.
When you recruit the first cohort of a focused tool, the discount feels like the offer. It isn't. The thing the early adopters actually want is influence over what the tool becomes — and that costs you nothing to give.
When you find something missing in a space, the instinct is to call it an opportunity. But some gaps are openings to walk through, and others are problems everyone in the space will inherit. Telling them apart is the whole skill.
A capability and the surface it's delivered on are two different things. When the capability becomes common, the value doesn't disappear — it migrates to where the capability lives in the user's workflow.
When AI coding tools compress a three-month build to two weeks, the economics of the build/pass decision change fundamentally. Risk tolerance thresholds that made sense before don't apply to the same calculation anymore.
Pre-selling before building converts a binary build/pass decision into a conditional one. If the pre-sale succeeds, the decision is made. If it doesn't, you learned something worth more than what the build would have cost.
A focused tool's first job is to find the one use case it handles so well that users can't imagine doing it another way. That use case becomes the center of gravity for everything that follows.
Buyers don't evaluate a new subscription against zero. They evaluate it against the other recurring costs they've already accepted. Pricing a tool at the same monthly cost as something the buyer already pays for collapses one of the largest adoption barriers.
Pre-build research has a definite end point that's hard to feel from the inside. Knowing when to stop researching and start building is its own skill, distinct from the research itself.
A pre-qualified audience of a few hundred can sound underwhelming next to general-market numbers. For a focused tool, it is often exactly enough to validate, build feedback loops, and produce the testimonials that everything else compounds on.
When a competitor has deeper domain expertise and structural advantages, the winning move is usually to compete on a different axis entirely — not a better version of what they do, but the version they structurally cannot do.
When the competition is a closed agentic platform, the open-standard alternative offers something the platform cannot — composability. The user controls how the tool fits into the rest of their workflow.
An enterprise platform and an individual-tier tool serve different users — and those users tell their tool different things. The smaller tool hears about new use cases and edge cases years before they reach the platform, and that information is the compounding advantage.
The channel that gets a tool noticed is usually not the channel that gets it adopted. Treating distribution as a single funnel collapses two distinct jobs that need different audiences and different content.
When the editor of a category becomes a competitor in it, the editorial channel that used to be open distribution becomes a place where alternative tools have a structural disadvantage. Recognizing the shift early matters more than working harder on the pitch.
Some communities have already done the explanatory work for you. The members understand the underlying technology, accept the workflow change, and recognize the value before the conversation starts. Finding those communities is worth more than a larger general audience.
Pay-per-document pricing seems fair until you count the cognitive overhead. Every document becomes a small decision about whether the cost is worth it — and the decision itself is the tax.
Some professional work requires reading a document before deciding whether the document is worth reading. The pre-judgment reading is pure waste, and it is also where automation creates the cleanest value.
When an incumbent adds a new capability to its existing platform, the capability gets distributed only to customers who already buy the platform. Everyone outside the platform's customer base is left waiting — and that gap is its own opportunity.
Pricing a complementary tool is a different math problem than pricing a replacement. The comparison is not against the incumbent's full price but against the cost of the extra step the incumbent does not do.
The hardest part of building a complementary tool is resisting the natural pull to expand into adjacent steps of the workflow. Each expansion erodes the positioning that made the tool easy to adopt.
When the dominant tools in a category were architected before AI document extraction was possible, the gap between what they do and what users now need creates room for a complementary layer rather than a replacement.
Early adopters of professional tools are often the wrong users to optimize for. Their feedback shapes products that work well for the technically sophisticated and poorly for everyone else.
Installation friction is a conversion problem. When a platform ships one-click install for a tool category, the tools that haven't adapted lose a meaningful share of potential users at the entry point.
When a platform validates a pattern in adjacent verticals but hasn't reached yours yet, there's a window. It closes when the platform gets there itself or a funded competitor moves first.
Finding the right distribution channel for a professional tool is as important as building the right product. A good tool in the wrong channel stays undiscovered.
When a professional tool runs analysis on documents the user provided, the document becomes the ground truth. That changes what verification means and why professionals trust it.
Professional tool pricing is rarely about the absolute number. It's about whether the buyer can construct a justification that works inside their organization.
Making a professional process faster is different from making it better. The distinction matters when you're pricing a tool against the time it saves.
AI can read a financial statement in seconds. It cannot automatically know that the current owner self-manages the property and a management fee needs to be added back. That knowledge lives outside the document.
Most professionals already use AI. Almost none trust it for decisions. The gap is not about capability — it's about whether the output can be verified against something real.
One detailed, specific case study from a real customer eliminates more objections than any amount of positioning work. Getting it is worth disproportionate investment.
The free tier of a professional tool isn't about attracting users who can't pay. It's about removing the proof burden from the sales conversation. Get that right and conversion follows.
Every tool that requires configuration to install has a setup tax. For MCP tools targeting non-technical professionals, that tax is real and the builder is responsible for minimizing it.
When 38% of firms in a vertical already use AI for a specific workflow, you don't have an education problem — you have a positioning problem. The two require completely different strategies.
When your tool lives in the buyer's existing environment, the demo is structurally different. No setup. No 'imagine this was your workflow.' They're already in it.
The gap between where AI tools live and where professional work happens is the product opportunity that standalone SaaS can't close from the inside.
When entering a market with established incumbent SaaS, the complement framing — 'we're the interface layer, not the replacement' — opens doors that a competitive framing closes.
For niche professional tools, the most efficient distribution channel already exists: the community where your buyers convene. The question isn't how to build an audience — it's how to enter the room that already has one.
For a professional tool targeting a small, reachable audience, the first ten customers don't come from organic discovery. They come from thirty targeted conversations. The math is simple and the implication is significant.
Extracting data from documents is necessary but not sufficient. The professionals who use AI tools need the calculations that follow — and building those calculations is where the real work is.
The right infrastructure choice doesn't just simplify the build — it eliminates entire categories of work you thought were mandatory. What disappears reveals what the product actually is.
In professional financial analysis, the reported numbers are never the real numbers. The work is in adjusting from what was reported to what a market participant would actually underwrite.
Distribution platforms offer founding member rates for a reason: they need early builders to establish the marketplace. Understanding why the window exists changes how you think about whether to use it.
The most durable pricing argument isn't 'we're cheaper than the competition.' It's 'we're cheaper than doing one unit of the thing you already pay for.'
When the distribution channel builds their own version of the tool you're considering, it's not a threat. It's the strongest possible market validation signal.
The code for a professional AI tool is often the easiest part to build. The hard part — the part that creates the durable advantage — is knowing what the tool needs to do and what the output needs to look like.
In AI-native professional tools, the infrastructure is commodity. The prompts — what you instruct the model to look for, extract, and flag — are the actual product. This distinction matters for how you think about building.
The most persuasive case for AI in professional workflows isn't accuracy — it's time. When AI compresses a 60-day process to 30 days, the value proposition becomes concrete and undeniable.
The most durable distribution advantage in professional AI tools isn't advertising or partnerships. It's education. The communities that teach professionals how to use AI own the relationship when those professionals are ready to buy.
Less than five percent of MCP servers are monetized. That number describes the current state of the ecosystem and points directly at where the durable value is going to accumulate.
When a standalone platform exists for a professional workflow problem, it tells you two things simultaneously: the problem is real enough to build a product around, and the workflow-native version of that product doesn't exist yet.
Not every professional workflow is a good target for an AI tool. Four criteria separate the ones worth building for from the ones that look attractive but aren't.
Professional due diligence workflows are being assembled as stacked, complementary MCP servers — one layer for people, one for data, one for documents. Two of the three layers now exist. The third is the opportunity.
Choosing the right problem to solve matters less than choosing the right market to solve it in. Two workflows can have identical AI potential and completely different competitive landscapes.
The most profitable AI businesses in 2026 are not the most impressive ones. They're in workflows that are painful, high-stakes, and completely unglamorous — and that's exactly why they work.
The MCP ecosystem in 2026 is overwhelmingly built by engineers, for engineers. The tools that don't exist yet are the ones built for professionals who aren't engineers — and that's the interesting space.
Domain-specific AI tools retain customers at 3-5x the rate of horizontal tools. This isn't a coincidence — it's structural. When the tool understands your workflow, switching means more than changing software.
Credit-based pricing is becoming the dominant model for AI-native SaaS. It's not just a billing mechanism — it's a way of making AI costs predictable for buyers while keeping pricing aligned with actual usage.
AI pricing is moving from seats to outcomes. The most successful AI products in 2026 are charging per resolved ticket, per completed draft, per analyzed document. This isn't a billing detail — it's a product philosophy.
Enterprise buyers aren't paying for AI. They're paying for domain knowledge that makes AI usable in their workflow. The tools that command enterprise prices are the ones that know what the profession expects.
Lease abstraction used to take four to six hours per lease. AI has brought it to fifteen minutes. The question now isn't whether AI works — it's where the output goes.
The question for professional AI tools isn't whether the AI is accurate enough. It's whether the output clears the threshold to go directly to the investment committee.
Commercial real estate acquisitions run on a thirty-day due diligence clock. Everything about professional AI tools for this market has to be understood in terms of that constraint.
The best-distributed tool wins more often than the best-built tool. In protocol-native markets, distribution is a first-class product decision.
Two kinds of AI tools are emerging in every vertical: ones that give you access to data, and ones that help you do something with it. They aren't competitors.
Eleven thousand MCP servers exist. Less than five percent are monetized. That gap is the opportunity.
The sustainable competitive advantage in AI tools isn't the model. It's knowing the domain well enough to make the model actually useful.
Cursor proved that professionals will pay premium prices for AI tools designed around their specific workflow. Now the same pattern is being applied to every profession.
AI wrappers have a structural economics problem that doesn't show up until you're at scale. Understanding it early changes how you build.
Most beta tests measure whether the software works. The beta test that matters measures whether the workflow works.
Professional users don't decide to trust a tool. They decide to trust an output. Then another. Then another. The trust is incremental, not wholesale.
Freemium works when the free tier proves value and the paid tier removes the specific friction the free tier creates.
Before you price anything, answer one question: what does the manual version of this cost right now?
Source citations aren't a nice-to-have in professional document workflows. They're the feature that determines whether a professional will trust the output.
When building a document processing tool, the code is the easy part. The schema is the hard part.
Eleven thousand tools exist. Less than five percent make money. That gap isn't a failure — it's an opportunity with a very specific shape.
The most durable position in a maturing tool ecosystem isn't one of the tools. It's the layer that connects them.
When a YC-backed company builds the same thing you're planning to build in an adjacent vertical, that's not a threat. It's a validation.
Data moats are dead. In 2026, the only defensible position is owning the workflow.
When building a vertical tool, the first document type you support determines whether the product has a reason to exist on day one.
Compressed diligence windows are a feature of competitive markets, not a bug. The tool that fits inside the window wins the workflow.
Before a lean team adopts any tool, they ask two questions. The answers determine whether evaluation turns into use.
Per-seat pricing assumes steady usage. Per-document pricing assumes variable pipelines. The right model depends on how the customer actually works.
The difference between a tool that requires deployment and one that just works is the difference between enterprise and everyone else.
Most firms have tried AI. Almost none have made it work. The gap between pilot and production is a product design problem.
When every tool is optimized for one property type, the analyst who works across types is left with nothing.
The right abstraction level for a tool isn't always the one that matches the domain. Sometimes it's one level up.
When each slice of a workflow gets its own dedicated tool, the integration layer is the next opportunity.
When multiple partial solutions emerge around the same gap, the gap is real. None of the partials fill it.
Finding deals and analyzing deals are different problems. The tools solving one aren't solving the other.
The gap between a published guide and someone successfully following it is a market.
The most durable businesses solve problems that are genuinely unglamorous.
Building a tool is one cost. Getting it to every place your users might look for it is another.
Some buyers don't care how good the tool is. They care where the data goes.
Every SaaS tool you adopt asks something of you that isn't money.
When the hard part of a problem shifts from 'is this possible' to 'can anyone use this without a PhD', that's where the opportunity lives.
A working proof of concept is evidence that a thing can be built. It's not evidence that the right thing has been built.
Product-market fit gets most of the attention. Workflow fit — whether the tool fits into how people already work — is often what determines whether product-market fit translates into retention.
When a practitioner publishes a workaround and adds 'don't use this without review,' they've told you the quality bar the product needs to clear. The caveat is a design constraint, not a disclaimer.
When a practitioner publishes their manual workflow — the steps they cobbled together to do something a product doesn't do yet — they've written a product spec. They've also confirmed the demand.
Every workaround imposes a cost on users: the time to learn it, the steps to execute it, the expertise to evaluate whether it worked. Absorbing that cost is what a product does. The friction tax is your pricing floor.
There are many ways to infer that a market gap exists. Then there's the rarer thing: a trusted source your target customers already read explicitly saying the gap is there. These are not the same signal.
Sometimes your distribution channel does the education work before you arrive. When that happens, everything about the opportunity changes — and the clock starts ticking.
The gap between 'working code' and 'listed product' has collapsed. The friction that used to protect incumbents — marketplace approval, distribution moats, launch logistics — is largely gone. What that means for what's actually hard now.
Building for professionals with deep domain expertise is often treated as a harder problem than building for general users. It's actually easier — in the ways that matter most.
Tools built for boring professional industries command higher prices, lower churn, and more defensible positions than tools built for exciting ones. The boring isn't incidental — it's the source of the premium.
Before building a product, you need to build a proof. They're different things, optimized for different goals — and confusing them is one of the most common ways to waste months of work.
When a well-funded startup enters your target space, the instinct is to stop. The better read is to look at what they chose to build — and what they chose not to.
Generic tools get you most of the way. The last mile requires knowing something the tool doesn't. That gap is where pricing power lives.
There's a difference between software that solves a problem and software that solves a problem inside the tool you're already in. The second one has a structural advantage the first one can never fully close.
When 88% of organizations are piloting a technology but only 5% are achieving their goals, that's not an adoption problem. It's a product problem.
AI can read a document. The hard problem isn't reading — it's knowing what to look for across five hundred documents at once, and synthesizing it into something a decision-maker can act on.
Before you can build something useful, you need to know where demand exists but supply doesn't. The tools that answer that question are underrated.
Condition assessments don't fail on data collection. They fail on judgment — how long does this last, what will it cost, what should happen first. That's where automation runs out.
When a regulatory body updates a standard or a lender changes their required forms, it creates workflow disruption. Professionals need new tools. The window is brief and predictable.
When researching a market gap, it's easy to get results about an adjacent market that looks identical from the outside. The gap you found might not exist where you think it does.
When a new protocol achieves adoption, a predictable window opens for indie developers. It closes just as predictably. The question is whether you're paying attention.
Most 'AI tools' for technical documents are data retrieval systems. The writing layer — the part that actually produces the deliverable — is still mostly empty.
Some documents appear in two distinct buyer clusters. That's not a complication — it's a signal worth paying attention to.
An absent AI tool is a necessary condition for opportunity. It's not a sufficient one. The buyer matters as much as the gap.
When multiple document types share a buyer, which one do you build first? The answer isn't the biggest one.
Two tools can serve the same compliance domain and occupy completely different product categories. Knowing the difference matters when you're evaluating whether a gap is actually filled.
A Tier-2 opportunity isn't a failed search. It's a finding with weaker entry conditions. Knowing the difference changes what you do next.
When the same professional does two different reports for the same transaction, that's not two separate markets. It's one market with a bundling story.
The best SaaS opportunities aren't hiding in glamorous workflows. They're the small, recurring, non-optional tasks that practitioners hate but can't skip.
Two teams build nearly identical tools. One gets 400,000 users. The other gets 4,000. The difference isn't the technology.
In 2024, generating text was impressive. In 2026, it's the floor, not the ceiling. The AI products winning right now are the ones that do things.
Why the most defensible products come from personal frustration. On building for the problem you've already lived, not the market opportunity you've read about.
Good work is table stakes. The assumption that quality creates its own distribution is the most common mistake builders make. Distribution is a separate discipline.
The most efficient way to kill a startup is for a big platform to add your core feature as a dropdown option. It happens constantly. There are ways to survive it.
Some products are genuinely useful and still fail commercially. The problem isn't quality — it's that utility without perceived scarcity doesn't command a price.
Asking people if they like your idea feels like research. It isn't. There's a hierarchy of signals, and most founders stop at the wrong level.
Building a starter kit for an emerging tool and crossing $5K in three weeks isn't luck. It's a pattern. The tool gets the press; the template captures the revenue.
The most viral developer tools aren't the most useful ones. They're the most enjoyable to encounter. There's a lesson in that.
Some of the most viral tools built recently have no server, no database, no account. Everything runs in the browser. The absence of infrastructure is the feature.
The counterintuitive truth about narrowing your focus: everything gets faster, cheaper, and more referrable when you serve fewer types of people.
Building the product is the easy part. The harder work — the part most engineers underestimate — is everything that happens after you ship.
On finding the smallest repeatable unit of value and what it means to ship the same solution more than once.
Building feels like progress. It is the perfect activity for someone who is afraid to find out whether their idea is any good.
The product you threw together as an afterthought is often the one the market actually wants. This is uncomfortable. It's also useful information.
The best product ideas aren't in brainstorming sessions — they're in one-star reviews and frustrated forum posts