DEV Community: Sonu Goswami

The Demo Metric I Trust Less Every Month

Sonu Goswami — Fri, 17 Jul 2026 03:37:38 +0000

Why rising demo requests might mean curiosity about AI, not real buying intent — and what that shift means for sales and marketing.

A Number I Used to Actually Like Looking At

There's this one number on our dashboard, and for the longest time it was kind of my favorite thing to check. Lately though, every time it ticks up I just get suspicious instead of happy about it.

Demo requests.

On paper, they're up. Objectively, more people are booking time with us than they were a year ago. If you'd shown me this chart back then, I'd have assumed we were doing something right — better positioning, better content, maybe the product finally clicked for people. That's usually what a rising demo number means.

Except when I actually started sitting in on more of these calls myself, a pattern kept showing up that didn't fit the old story.

Not Everyone Booking a Demo Wants to Buy

A meaningful chunk of the people booking demos aren't evaluating us against a competitor, and they're not trying to solve a problem they're currently stuck on. They're evaluating AI, generally, as a category. They want to see what a tool like ours can actually do in practice — not because they have a budget approved or a project waiting, but because they're curious what's possible right now.

That's a genuinely different kind of visitor than the one this metric was built to measure.

Why This Metric Used to Mean Something

For most of the history of B2B software, a demo request was a fairly reliable signal. Someone doesn't usually block 30 minutes on their calendar unless they've got a real problem and they're seriously checking if you're the fix. The intent was baked into the action. Booking a demo meant something.

I don't think that's true anymore, at least not uniformly. AI has made "let's see what this thing can do" a socially normal, low-effort thing to do, even without a problem attached to it. People are exploring the category the way they might scroll through a new app's feature list — not because they need it today, but because it's interesting and it's moving fast and they don't want to fall behind on understanding it.

Two Audiences Hiding in One Number

None of that's really a bad thing, to be clear. Curiosity is probably part of how a market like this ends up growing in the first place. But it does mean that one number on the dashboard is secretly counting two totally different groups of people now, and mashing them together into a single line just makes everything harder to act on, not easier.

If your sales team is qualifying every demo the same way they qualified them two years ago, they're probably burning real hours on conversations that were never going to convert — not because the person was a bad fit, but because they were never actually shopping. And if your marketing team is optimizing content and campaigns purely to push that top-line demo number up, you might be getting really good at attracting curiosity traffic while your actual buying-intent traffic stays flat or even shrinks as a share of the total.

What We're Actually Trying

I don't have a clean fix for this yet. A few things we're trying:

We've started asking a soft qualifying question before the call even gets booked — something closer to "what are you hoping to walk away with" rather than the usual company-size and role fields. It's not perfect, but it at least gives the rep a hint about which conversation they're walking into.

We're also looking at this as its own funnel stage rather than noise to filter out. If curiosity traffic really is becoming a permanent category, it might deserve its own content, its own follow-up sequence, and its own definition of success — instead of trying to force it through the same pipeline built for people who already know they want to buy.

And honestly, we're just tracking it more explicitly now. Even a rough split between "exploring AI" and "solving a specific problem" on our intake form has already made our demo numbers a lot more legible month over month.

Is Anyone Else Seeing This?

I'm curious whether this is showing up for other people running demos or free trials right now, or if it's more specific to certain categories of tooling. Is anyone else seeing a rising share of visitors who are here for the category and not the specific problem you solve? And if so, has anything actually worked for separating the two before they hit a sales call?

B2B SaaS Positioning Specialist

https://sonusaaswriter.com//b2b-saas-positioning

sonusaaswriter.com

Security Awareness Training Was Designed for Rare Attacks. AI Just Made Manipulation Nonstop.

Sonu Goswami — Tue, 14 Jul 2026 03:55:17 +0000

Most security awareness programs were built assuming attacks show up now and then. AI is flipping that assumption — manipulation is becoming constant, tailored to the individual, and run like an operation.

Security awareness training wasn't designed for the threat landscape we're actually in now.

It was designed for a world where attacks showed up as isolated incidents.

A phishing email. A sketchy attachment. A fake login screen.

The whole discipline was built around teaching people to spot these things. That approach made sense back when creating a convincing attack took real effort and couldn't easily be personalized at volume.

That foundation is cracking.

Not because people got worse at spotting threats.

Because the attackers changed the game.

The economics behind manipulation shifted.

The most important development in cybersecurity right now isn't better AI-driven detection. It's how cheap trust has become to fake.

Putting together a convincing phishing email used to take work. A believable impersonation took planning. A targeted social engineering attempt took real research.

Those barriers are disappearing fast.

Cloned voices. Deepfake video. AI-written messages. Impersonation that adapts to context in real time.

The cost of faking a believable interaction is dropping faster than the cost of defending against one — and that mismatch is the actual problem.

Awareness Programs Were Built Around Isolated Incidents

Most training programs still run on an event-based model:

Quarterly sessions. Yearly certifications. Occasional phishing tests.

The underlying logic: train employees, track results, lower risk.

That logic only holds up if attacks are infrequent. That's not the environment anymore.

People are making hundreds of judgment calls every single week across:

Email
Chat and messaging tools
Collaboration platforms
Customer-facing communication
Approvals
Payment actions
Access requests

The danger isn't one phishing email slipping through. It's what happens when you add up thousands of small interactions, week after week.

The thing you're actually measuring has changed.

Security programs have traditionally organized themselves around:

Devices
Networks
Applications
Identities

Where humans were concerned, the answer was always "more awareness." But AI-driven social engineering changes what actually needs measuring.

The old question — did this person complete their training — doesn't tell you much anymore. What you actually need to know is which of the decisions people are making right now are likely to turn into real incidents. That's an operational question, not an educational one.

Human-focused security is turning into an operational function.

This is the shift a lot of security teams are starting to feel in real time.

The goal isn't to maximize how "aware" people are anymore. The goal is managing human risk as an ongoing operational problem.

That takes a different set of capabilities:

Spotting risky behavior patterns
Figuring out which users are most exposed
Understanding where attack surface actually sits with people
Stepping in before something becomes an incident
Continuously adjusting as attack methods evolve

What this starts to look like isn't training software anymore. It's closer to a security operations function — just aimed at people instead of infrastructure.

The Next Category Won't Just Be "Smarter Training"

A lot of vendors are going to market this as "AI-powered awareness training," and honestly, that's not wrong so much as it is incomplete — it undersells what's actually going on underneath.

The bigger shift is that human security is moving toward:

Risk operations
Threat operations
Ongoing, real-time intervention

The category itself is being redefined. Not because training became irrelevant — because training by itself was built for a threat model that no longer exists.

Wrapping Up

For most of the history of this industry, the human element got treated as a weakness you patch with education.

The next generation of security systems is likely to treat people differently — not as the weak point in the chain, but as an operational surface that deserves the same visibility, measurement, and active intervention as every other layer of the security stack.

The future of protecting the human element probably has less to do with teaching, and a lot more to do with helping organizations manage human risk continuously, in real time.

B2B SaaS Positioning Specialist

https://sonusaaswriter.com//b2b-saas-positioning

sonusaaswriter.com

Where the CISO Reports Isn't an Org Chart Question. It's a Buyer Signal.

Sonu Goswami — Thu, 09 Jul 2026 09:11:53 +0000

The CISO's reporting line isn't an org chart detail. It's a signal to buyers, boards, and investors about how a company actually treats risk.

"The CISO reports into IT." Fine. Just don't be surprised when cyber risk starts sounding like an IT ticket.

This is one of those topics people get oddly precious about. Some will tell you the CISO has to report to the CEO. Others say CIO, CTO, COO, CRO, Legal, Risk, Audit. Everyone's got a strong opinion, and it's usually based on whatever structure their own company already happens to have.

I'm less interested in the org chart argument itself. I'm interested in what the reporting line actually reveals — because it's not really an internal HR detail. In a regulated market, it's information a buyer, a board, or an investor can read from the outside.

What the Reporting Line Actually Signals

Where the CISO sits tells you what the business believes cyber is.

If cyber gets treated as a technology control function, it usually ends up buried inside technology. Patching. Blocking. Reviewing tools. Approving exceptions. Writing policy. Trying hard not to slow anything down.

That's real work. It's also incomplete.

Cyber frequently has to challenge the exact same delivery, budget, and risk decisions that technology leadership is trying to push through. Said with respect — CIOs and CTOs are paid to ship, modernize, simplify, cut cost, and keep momentum. Good ones do that well. But sometimes the CISO has to be the person in the room saying, "we can do that, here's the risk we'd be carrying if we do."

That message gets a lot harder to deliver cleanly when it has to travel through the very function it's challenging.

Hierarchy Isn't the Point. Proximity to the Decision Is.

Hierarchy for its own sake doesn't solve anything. What actually matters is how close the CISO sits to the decisions that create risk in the first place.

I've watched companies close acquisitions, sign new vendors, migrate platforms, and launch products with cyber looped in after the fact — sometimes weeks later, sometimes never. The person who understood the risk was simply too far from the table where the decision got made.

And late cyber advice is expensive advice. Retrofitting controls into something that's already live costs more, takes longer, and usually gets watered down somewhere along the way because ripping it out isn't really on the table anymore.

What Actually Works, in Practice

A few patterns show up consistently in companies that get this right:

→ The CISO has a direct line to whoever owns enterprise risk — CEO, CFO, or the board's risk committee, depending on the company

→ They're in the room while strategic decisions are still being shaped, not reviewing them after they've already been signed off

→ There's a clear escalation path that doesn't get filtered through whoever has competing priorities that week

→ The relationship with the CIO or CTO runs collaborative, not hierarchical — neither one is reporting up through the other

→ The reporting structure actually gets revisited when the business changes, instead of sitting on autopilot for five years

None of this is really about the box on the chart. It's about access and mandate.

The Real Test

If your CISO can pick up the phone to the CEO the moment something's genuinely wrong, the reporting line is probably fine — whatever it technically says on paper.

If they need three layers of approval just to get five minutes in front of the board, the structure itself is the vulnerability. Not a metaphorical one. An actual one, sitting quietly in the risk model, waiting for the wrong moment to matter.

Why This Matters Beyond the Org Chart

For companies selling into security, compliance, or any regulated market, this isn't just an internal governance question — it's diligence material. Buyers, investors, and enterprise procurement teams are increasingly asking not just "do you have a CISO," but "where do they sit, and who do they answer to when it counts."

A reporting line buried three layers deep inside IT tells a sophisticated buyer something, whether the company means to say it or not. A CISO with a direct line to the board tells them something completely different — and it shows up in how fast a deal moves through security review.

The title on the org chart was never really the point. The access behind it always was.

B2B SaaS Positioning Specialist

https://sonusaaswriter.com//b2b-saas-positioning

sonusaaswriter.com

Has anyone else noticed that customer requests get more expensive after product-market fit?

Sonu Goswami — Tue, 07 Jul 2026 08:50:55 +0000

This is something I've been thinking about while watching SaaS teams scale.

Early on, feature requests are mostly about missing functionality.

Later, they're often about fitting the product into someone else's workflow.

Same request on the surface ("can you add X?"), but completely different engineering cost.

You aren't building a feature anymore. You're making another company's process your responsibility.

That made me wonder if one sign of product-market fit is actually saying "no" more often, not less.

Curious how other founders think about this.

Have you found a way to separate requests that expand the product from requests that slowly turn you into custom software?

B2B SaaS Positioning Specialist

https://sonusaaswriter.com//b2b-saas-positioning

sonusaaswriter.com

Nobody's going to call the next control layer "security" — even though that's basically what it is

Sonu Goswami — Thu, 02 Jul 2026 03:59:00 +0000

The identity problem stopped being about humans a while ago. Most positioning in this space hasn't caught up.

There's a specific moment I keep coming back to: the first time an AI agent got handed real operational permissions inside a production system. Not "AI arrives in the enterprise" in the abstract — that's old news by now. The actual shift was narrower and easier to miss. It was the point where companies started granting access to things that don't have a face attached to them. No manager. No offboarding date. No HR record.

Service accounts. Ephemeral workloads. Agents calling other agents. Machine identities sitting inside regulated environments with the same reach as your most senior engineer, and none of the guardrails that come standard with hiring a human.

Most governance infrastructure was built assuming identity meant people. Slow-changing systems, ownership you could track in a spreadsheet without it going stale by Friday. That assumption is aging out faster than most security budgets have noticed.

Everyone's still solving for the wrong question

Ask most security or compliance teams what the hard problem is and you'll get some version of: catching threats, controlling human access. Not wrong. Just increasingly beside the point.

Here's the part that doesn't show up in enough conversations — the fastest-growing identity surface inside a modern enterprise isn't people anymore. It's the pile of AI agents, API keys, service accounts, and cloud resources spinning up faster than any governance team can log them, each one quietly inheriting permissions on its way.

"Who has access" used to be the whole question. It isn't anymore. Now you need to know what has access, what actually created it, who owns the fallout if something goes wrong, and — the part nobody wants to admit — whether any of that is still accurate today. Ask around and most companies can't answer that with a straight face. And the gap between what the tooling reports and what's operationally true widens every single quarter, quietly, in the background.

Calling this a "visibility" problem is the mistake

Security vendors have sold this category on visibility for years, and it's a fine word inside a security meeting. It just dies the moment it leaves the room. Audit doesn't respond to "visibility." Neither does the CFO. Neither does a board risk committee.

The actual cost isn't that security lacks a prettier dashboard. It's bigger than that. Audit prep, compliance validation, AI governance, cloud ops, incident response — every function that leans on accurate operational context is now navigating off a map that's quietly stopped matching the territory. Once that map can't be trusted, everything built on top of it slows down: review cycles stretch, audits turn into manual reconciliation projects run every quarter, and exposure analysis becomes an exercise in cross-checking systems that don't agree with each other.

None of that reads as a security line item on a budget spreadsheet. It reads as drag — spread across four or five teams simultaneously. Which, not coincidentally, is exactly where the real budget for this problem tends to sit.

What actually happened after Storm-0558

Summer of 2023: Microsoft disclosed that a state-sponsored group, tracked as Storm-0558, had gotten hold of a signing key and used it to forge authentication tokens across 25 organizations — several of them federal agencies.

The breach got the headlines. The part worth studying is what came after — the days spent trying to answer one deceptively simple question: what did this key actually touch?

That question took a genuinely long time to answer with confidence. Not because the tooling to figure it out didn't exist somewhere. Because the map connecting one machine credential to its downstream permissions, its runtime reach, and everywhere it had been — that map lived in pieces, spread across control planes that had never been asked to reconcile with each other. One credential. Murky runtime permissions. Ownership scattered across systems that don't talk. It took weeks to bound the actual blast radius, and it eventually pulled congressional oversight into the picture across multiple agencies.

This is the condition worth building a positioning story around — not the breach as an event, but the structural failure sitting underneath it. Companies that can't quickly answer what a piece of non-human infrastructure had access to, because that answer is fragmented across systems that were never designed to agree. That's not some edge case. For most enterprises in 2025, it's closer to the default state.

CAASM undersells what's actually happening here

Cyber Asset Attack Surface Management is a reasonable label, as far as it goes. It just doesn't capture the real size of the problem once non-human identities start acting like first-class operational actors instead of a footnote.

I think about it in three stages instead.

First is inventory — simply knowing what exists. That's the traditional CAASM pitch, and by now it's table stakes; you won't win a competitive deal on inventory alone anymore.

Second is reconciliation — do the systems actually agree with each other about what exists? This is where most companies are genuinely stuck right now: overlapping inventories, conflicting ownership records, identity context that's disconnected across security, IT, and cloud teams that all swear their version is the correct one.

Third — and this is the stage that actually matters — is operational trust continuity. Not just "what exists," but whether the picture of who owns it, what has access, and what's changed is accurate enough, continuously, to make real governance calls on. That third stage is a genuinely different product category from the first one. Companies building for it aren't competing on feature checklists anymore. They're competing on organizational trust — a different buyer, a different sales motion, a wedge that has nothing to do with feature parity.

Three things worth checking before your next enterprise cycle

A few moves worth pressure-testing if you're building anywhere near this space.

Push the buyer conversation higher up the org chart. The CISO isn't the only accountable party anymore — AI oversight and audit defensibility are climbing toward board-level concerns, and the real pressure now sits with people accountable across multiple functions, not just security. Pitching this as a feature-level security tool undersells exactly who needs to say yes.

Put a number on the cross-functional drag, not just the security exposure. Fragmented operational truth doesn't just cost security time — it costs compliance, audit, and AI governance time too, all at once. A single figure that spans several cost centers tends to move through enterprise procurement a lot faster than an ROI case that only makes sense inside one department's budget.

Sell coordination, not detection. The platforms that actually win here won't just be good at flagging problems. They'll become the thing every other function coordinates around by default. That's a platform story — and platform stories support a very different pricing and expansion conversation than a point solution ever will.

Where this is probably going

My guess: enterprise inventories drift from device-centric to identity-centric over the next few years. Non-human entities start getting treated as governance objects in their own right, not an afterthought bolted onto human identity management. Runtime ownership starts mattering more than whatever's written down in a static record somewhere. And the competitive axis for security platforms shifts toward trust reconciliation, away from pure detection.

The companies that end up winning probably won't be the ones with the sharpest detection engine. They'll be whoever quietly became the operational source of truth for enterprises that no longer run on human identity alone.

Nobody's settled on a name for this category yet. Which means the positioning window is still wide open — and the actual economic wedge here, once you surface it properly in a deal conversation, tends to be a lot bigger than what most of these deals currently get closed around.

I work with funded B2B SaaS founders on positioning for security, compliance, and regulated markets — specifically on finding the economic wedge that moves complex deals forward.

If this maps to a deal that's stuck, or a positioning problem you haven't fully cracked — happy to dig into it. First conversation's simple: we find the wedge together.

Connect on LinkedIn · Follow for more on B2B positioning in regulated markets

The Gap Nobody's Talking About in Healthcare Compliance

Sonu Goswami — Tue, 30 Jun 2026 02:47:42 +0000

Why audit-ready isn't the same thing as defensible
Healthcare compliance teams aren't dealing with periodic regulation anymore. They're dealing with something closer to constant interpretation — new rules stacking on old ones, guidance that's vague enough to require judgment calls, and audits that no longer ask "did you do the work" so much as "can you prove how you got there."
That's a quiet but real shift. From managing documents to owning decisions.

When This Actually Becomes Urgent
Nobody panics the day a new regulation gets published. The urgency shows up later, in a much smaller moment — an auditor asking for the reasoning behind a specific call, a regulator wanting to know how a judgment was made, a leadership team asking "are we exposed here?" after something almost went wrong.

That's the moment compliance stops being a checklist and turns into something closer to a legal defense. The work was probably fine. The problem is nobody can show their reasoning.

Who Actually Feels This
The buyer isn't really "compliance" as a department. It's whoever has to personally answer for being wrong.

The Chief Risk or Compliance Officer carries the regulatory exposure. Legal carries the defensibility question. Operations has to actually execute whatever policy changed. Leadership eats the financial and reputational fallout if it goes badly.

None of them are measured on whether tasks got marked complete. They're measured on whether a decision can survive being questioned months after it was made.

Where the System Actually Breaks
Most compliance work today still lives scattered — regulations sitting in PDFs, tracking happening in spreadsheets, policies written up in internal docs that rarely get cross-referenced against each other in real time.

Teams can find the rule. They can update the policy. They can prepare a folder for an audit. What they usually can't do is show, cleanly, that a specific decision made on a specific date mapped to a specific requirement that existed at that time.
The work itself isn't the problem. Proving the reasoning behind it is.

The Repositioning That Matters
The framing that wins here isn't "we help you manage policies and prepare for audits." It's "every regulatory decision your team makes is traceable and can be explained later, to anyone who asks."

That distinction matters because nobody gets fired over a messy spreadsheet. People get fired when they're sitting across from a regulator and can't explain why a decision was made the way it was.

Why the Budget Moves Differently Here
This isn't competing against other compliance software for a line item. It's pulling from money that's already being spent elsewhere — external consultants brought in to interpret ambiguous regulation, internal hours burned on manual review, and the much larger cost of audit delays, fines, and remediation when something goes wrong.

It moves faster than typical software because it's tied to avoided downside, not efficiency gains. Fewer audit escalations. Faster readiness when an audit does land. Less dependence on outside experts who bill by the hour. Lower odds of a penalty that actually hurts.

This isn't a productivity story. It's a way of compressing risk.

What Should Happen If This Read Is Right
A few things should be visible if this framing actually holds. Deals should accelerate around real audit cycles and regulatory deadlines, not around feature comparisons in a sales deck. Legal and risk leadership should be pulled into the buying conversation early, not brought in after compliance has already picked a vendor. Whether a deal is won or lost should come down to whether the output can be defended and traced — not whether the AI is impressive.

And the clearest signal of all: the system stops being treated like a tool teams evaluate, and starts being the thing the organization quietly relies on every time it needs to explain itself.

That's not a better compliance workflow.

That's infrastructure.

Growth Isn't Always Good News in SaaS

Sonu Goswami — Thu, 25 Jun 2026 03:42:41 +0000

One thing that caught me off guard while learning about SaaS metrics is this: adding more customers doesn't automatically make the business healthier.

Everyone talks about ARR.

Very few people talk about how much it costs to create that ARR.

That's probably because ARR is exciting. Customer acquisition costs aren't.

Let's say you land a new customer after spending $10,000 on sales and marketing. They sign up for $700 a month.You're growing, but you won't recover that acquisition cost overnight—it takes months before the numbers start working in your favor.

Now repeat that with another hundred customers.

Revenue goes up.

Cash goes down.

Nothing is broken. That's simply how subscription businesses work.

This is one reason early SaaS companies can look healthier than they really are. The top line keeps moving, but underneath, the business is carrying a growing pile of acquisition costs that haven't paid for themselves yet.

That's why I find metrics like CAC payback or LTV/CAC more interesting than ARR in isolation.

ARR tells you that customers are signing.

Those other metrics tell you whether signing more customers is actually making the business stronger.

The companies people admire for "hypergrowth" usually didn't ignore these numbers. They fixed them first. Better retention. Lower churn. Faster payback. Only then did they pour more money into sales.

Growing quickly isn't difficult if capital is available.

Growing without creating a bigger financial headache is a different challenge altogether.

What Nobody Tells You About Compliance in a Listed Company

Sonu Goswami — Tue, 23 Jun 2026 03:36:47 +0000

Most people coming into compliance roles think the job is about knowing the rules. It is — but that's maybe 30% of it.

The rest you learn on the floor.

Walk into any listed company compliance function and count how many departments you're actually dependent on. Finance, legal, secretarial, HR, auditors — the work touches all of them, and none of them report to you. If those teams aren't talking to each other, something falls through. Compliance in a listed company is a coordination problem as much as a legal one.

Then there's the group structure. A listed company rarely operates as a single clean entity. There are subsidiaries, associates, joint ventures — each sitting in a different jurisdiction, each with its own filing requirements and risk profile. What works at the parent level doesn't automatically translate down. You figure that out fast.

Documentation is the one lesson that sounds obvious until you've actually had to defend a position without it. If the decision was made verbally, if the approval happened over WhatsApp, if the rationale never made it into writing — it effectively didn't happen. Good records aren't bureaucracy. They're your only evidence when it counts.

Governance is the piece most people underestimate when they start. Filing the annual return is the easy part. The real work is board process, stakeholder disclosures, risk oversight, ethics frameworks — the structures that actually determine how decisions get made and who's accountable for them. That's where governance either holds or doesn't.

And none of it works well if you don't understand the business itself. The compliance professional who knows the law but doesn't understand the business model, the industry dynamics, or where the real risks sit — they're always a step behind. The ones who do understand the business are the ones who actually get things done.

The best in this field aren't just people who know regulations. They're people who understand how business, finance, and governance intersect — and can work across all three at once.

The weirdest part of solo SaaS is realizing nobody is waiting for

Sonu Goswami — Sat, 20 Jun 2026 12:36:02 +0000

When I first started building, I secretly assumed there was a queue.

Not a literal queue.

Just a belief that if I built something useful, people would eventually discover it.

That there were customers out there actively waiting for a solution.

Over time I realized something uncomfortable:

Most people aren't waiting for a better tool.

They're busy working around the problem.

The spreadsheet exists.

The manual process exists.

The annoying workaround exists.

The problem hurts, but not enough to stop everything.

That's why so many founders feel confused.

You improve the product.

Add features.

Fix bugs.

Make onboarding better.

Yet nothing dramatic happens.

Not because the product is bad.

Because the customer already has a way to survive.

The biggest competitor for many SaaS products isn't another startup.

It's an imperfect process that people have learned to tolerate.

That realization changed how I think about building.

I stopped asking:

"How do I make this product better?"

And started asking:

"What would make someone abandon the workaround they already trust?"

What workaround did your customers use before your product? And was it harder to replace than you expected?

Healthcare Compliance Doesn't Have a Documentation Problem

Sonu Goswami — Tue, 16 Jun 2026 11:40:51 +0000

Healthcare organizations aren't drowning in missing documents. They're drowning in decisions nobody remembers making. That's a different problem entirely.

Most healthcare organizations don't have a shortage of documentation.

They have policies. They have evidence repositories. They have training records, trackers, spreadsheets, and shared folders full of material collected over years of audits and reviews.

If the problem were simply storing information, we'd have solved it by now.

The harder problem shows up somewhere else.

Ask a team this question:

Why did you decide this was the right interpretation of the requirement?
That's where the pause happens.

Not because nobody thought about it. Quite the opposite.

Someone did think about it. Legal reviewed it. Compliance weighed the options. Operations figured out how to implement it. People discussed trade-offs and made a call based on the information they had at the time.

The problem is that the decision-making process rarely survives the decision itself.

What remains is the output. The updated policy. The completed checklist. The audit evidence.

What disappears is the reasoning.

Healthcare regulation is not a fixed set of instructions you follow once and file away. Requirements sit on top of each other. Guidance shifts. A clarification issued two years ago quietly changes how an obligation written a decade earlier is now being read. Two experienced professionals can look at the same source material and arrive at genuinely different conclusions — and both have defensible arguments.

Eventually someone has to choose a path forward.

Months later, that's the part organizations struggle to reconstruct.

The questions that arrive later

An auditor asks how a requirement was interpreted.

A regulator wants to understand the basis for a decision.

Leadership asks whether the organization can defend its position if challenged.

The answer can't be, "The person who knew retired," or "I think it was discussed in an email somewhere."

That's not a documentation issue. That's a decision problem.

Most compliance technology was built to manage artifacts. Store the policy. Track the task. Collect the evidence. Prepare for the audit.

Those capabilities matter. But they were designed around a version of the problem where the document is the most valuable thing in the room.

In practice, the most valuable thing is what connected the regulation to the action taken. The logic underneath. The path the team actually walked before they landed on an answer.

What the record is missing
Why was this interpretation selected over the alternatives? What other approaches were considered? Who weighed in and what did they say? What piece of guidance tipped the decision? That layer is almost never captured. And it is almost always the layer an auditor eventually asks about.
Without it, organizations end up reverse-engineering their own thinking after the fact. Anyone who has sat through that kind of audit knows exactly how uncomfortable that is.

The next generation of healthcare compliance platforms will get evaluated on something most current tools don't even try to address.

Not whether they can organize more documents. Not whether they can automate another workflow. Those problems are mostly solved and the market knows it.

The question will be whether a platform can hold onto the rationale behind high-stakes decisions. Whether it can make the judgment that produced an outcome visible alongside the outcome itself. Whether it can give an organization something to point to when scrutiny arrives — not just what they decided, but how they got there and why that path made sense at the time.

Healthcare organizations don't lose sleep because they misplaced a spreadsheet.
They lose sleep because they may one day have to justify a decision that nobody remembers making.
The systems that solve that won't feel like administrative tools. They'll feel like something closer to institutional memory — the kind that stays even after the people who built it have moved on.

Because the question that actually matters when a regulator walks in the door isn't whether the policy is filed correctly.

It's: how did we arrive at this decision?

Right now, very few organizations can answer that well. And very few platforms are built to help them.

SOC 2 Is a Starting Point, Not a Security Guarantee

Sonu Goswami — Fri, 12 Jun 2026 15:25:09 +0000

The amount of confidence organizations place in SOC 2 reports continues to surprise me.

Not because SOC 2 lacks value. It doesn't.

What surprises me is how often the existence of the report becomes the assessment.

During vendor reviews, I regularly hear questions such as:

"Do they have a current SOC 2?"

Far less common is:

"What does the report actually tell us?"

Those are very different questions.

A SOC 2 report is an auditor's assessment of controls within a defined scope and period. It is not a declaration that a company is secure, nor is it a substitute for understanding how a vendor's environment aligns with your own risk profile.

The most informative sections are rarely the ones people focus on. System boundaries, control limitations, complementary user entity controls, exceptions, and scope exclusions often provide more insight than the auditor's opinion itself.

This becomes particularly important when organizations treat SOC 2 as a universal security benchmark. Security is the only mandatory Trust Services Criterion. Availability, Confidentiality, Privacy, and Processing Integrity may or may not be included. Two vendors can both claim to be SOC 2 compliant while undergoing assessments of very different depth and scope.

None of this diminishes the value of SOC 2.

I'm not arguing against SOC 2 reports. I just think too many organizations stop asking questions once they receive one.

That's usually where the review should start, not end.

Product-Market Fit Isn't Enough. You Need Explanation-Market Fit.

Sonu Goswami — Tue, 09 Jun 2026 02:18:31 +0000

One pattern I've noticed in enterprise software:

The product that wins isn't always the product buyers understand best.

It's the product buyers can explain internally.

Those are different things.

A security lead might fully understand your platform.

A compliance manager might love the workflow.

An operations team might see immediate value.

None of that guarantees a purchase.

Because eventually someone has to explain the purchase to people who weren't part of the evaluation.

Procurement.

Finance.

Legal.

An executive sponsor.

The products that move fastest often reduce the amount of explanation required.

Not because they're simpler.

Because their story survives handoffs.

The team evaluating the product is rarely the team approving the budget.

Every internal conversation introduces distortion.

Every handoff creates interpretation risk.

Many deals slow down because the product became harder to explain than the problem it solved.

Founders usually focus on product-market fit.

Far fewer think about explanation-market fit.

Can somebody who wasn't in the demo still understand why this purchase matters?

That's often where deal velocity is decided.

The handoff between evaluator and approver is one of the least visible parts of enterprise sales. Buyers spend weeks learning the product, then have to compress that understanding into a few slides, an email, or a procurement meeting. A surprising amount of deal friction appears in that translation layer.

Many teams assume a stalled deal means the value wasn't compelling. Sometimes the value was clear to the evaluator but never became clear to the people carrying the accountability for the purchase. Those are very different failure modes.