THREADS Blog

The Three Layers of AI Value: A Framework for Measuring What Actually Matters

Grant Elliott — Tue, 14 Apr 2026 04:00:00 GMT

The Three Layers of AI Value: A Framework for Measuring What Actually Matters

Grant Elliott
43 minutes ago
5 min read

The AI Productivity Paradox: personal efficiency doesn't automatically become team efficiency.

Most organizations jumping into AI adoption make the same mistake: they measure what's easy rather than what's meaningful. Someone saves an hour using ChatGPT to draft a report. A developer uses Copilot to write code faster. These feel like wins, and they might be, but without a structured way to understand who benefits, how much, and whether that benefit compounds, you're essentially flying blind.

This post introduces a practical framework for thinking about AI implementation across three distinct layers, and the metrics that actually tell you if it's working.

The AI Productivity Paradox: Why Individual Wins Don't Always Scale

Before getting into the framework, it's worth naming the trap.

I talked about this during a recent “What’s Up Wednesday” post. Personal productivity gains from AI are real. You can move faster, write better, analyze more. But there's a paradox at the heart of AI adoption: my efficiency gain does not automatically become your efficiency gain, or our company's efficiency gain.

In fact, the opposite can happen. If AI makes certain individuals dramatically more productive without changing underlying systems or workflows, you can end up with new bottlenecks, imbalanced workloads, or worst of all a false sense that the organization is progressing when the gains are siloed.

This is why any serious AI implementation framework needs to measure at two levels simultaneously:

Individual benefit — what does the person using the tool gain?
Collective benefit — what does the team, organization, or client gain?

We call these two axes the "who benefits" dimension. And we layer them across three types of AI implementation.

The Three Layers of AI Implementation

Layer 1: Internal Tools — We Benefit

This is AI in service of your own organization’s operations. Think tools that reduce administrative burden, accelerate content production, improve decision-making, or automate repetitive internal processes.

The primary beneficiary is the organization itself e.g. reduced costs, faster output, better quality internal work.

Examples:

Using AI to generate marketing materials, proposals, or reports
AI-assisted data analysis and business intelligence
Internal knowledge management and search
Automating scheduling, HR processes, or financial reporting

Metrics: Individual Benefit

Metric	What to Measure	How
Time saved per task	Hours reclaimed weekly per user	Pre/post time-tracking on specific workflows
Output quality improvement	Time saved per task Error rates, revision cycles	Compare AI-assisted vs non-assisted outputs
Task completion speed	Time from brief to delivery	Workflow timestamps
Personal capacity freed	% of time shifted to higher-value work	Self-reported time allocation surveys

Metrics: Collective / Organizational Benefit

Metric	What to Measure	How
Cost per output unit	Cost to produce a piece of work	Finance tracking against output volume
Team throughput	Volume of work delivered per sprint/month	Project management data
Reduced dependency on external resources	Decrease in outsourced spend	Budget comparison
Cross-team productivity lift	Whether one person's AI gains flow to others	Workflow interdependency mapping

Watch for the paradox here: If your marketing manager is producing three times as much content using AI, but the approval and distribution process hasn't changed, you may have created a bottleneck rather than a benefit. Measure the system, not just the individual.

Layer 2: Client Support Tools — Our Clients Benefit Through Us

This layer is about using AI to improve how clients interact with your organisation, your product, or your support systems. The primary value flows to the client — but there are meaningful secondary benefits internally.

Examples:

AI-powered knowledge bases that let clients self-serve answers
Intelligent chatbots and support ticket routing
Automated onboarding flows and FAQs
Client-facing analytics or reporting tools

An important note: a project like a knowledge base often straddles both Layer 1 and Layer 2. Building it more efficiently is an internal win; the client using it effectively is a client win. For measurement purposes, keep these distinct even if they share infrastructure.

Metrics: Client Benefit

Metric	What to Measure	How
Time to resolution	How quickly clients resolve issues	Support ticket data
Self-service rate	% of queries resolved without human support	Platform analytics
Client time-on-platform	Are clients spending less time on friction?	Session data
Client satisfaction (CSAT)	Post-interaction satisfaction scores	Surveys and NPS
First contact resolution	% of issues resolved in one interaction	Support system reporting

Metrics: Internal / Secondary Benefit

Metric	What to Measure	How
Support ticket volume	Reduction in inbound support requests	CRM or helpdesk data
Average handling time	Time per ticket for your team	Support platform metrics
Knowledge base maintenance cost	Hours to keep KB current and accurate	Internal time tracking
Support team capacity freed	% of team time redirected to complex issues	Resource allocation tracking

The dual efficiency opportunity: A well-built AI knowledge base that learns from client interactions reduces client friction and reduces internal support burden simultaneously. These are the projects worth prioritizing, but measure both effects separately or you'll underreport the value.

Layer 3: AI in the Platform — Clients Benefit Directly

This is the most strategically significant layer: AI built directly into the product or service you deliver. Here, the primary and direct beneficiary is the client. Your organization benefits indirectly — through retention, expansion revenue, differentiation, and reduced churn.

Examples:

AI-generated data insights surfaced within the platform
Automated workflow creation or form generation
Smart recommendations or predictive features
AI-assisted report building within your tool

Metrics: Client Benefit (Primary)

Metric	What to Measure	How
Feature adoption rate	% of clients using AI features	Product analytics
Task completion efficiency	Time to complete key tasks in-platform	User session analysis
Workflow automation rate	% of workflows using AI-assisted steps	Platform usage data
Client outcome improvement	Improvement in clients' own KPIs	Client reporting / QBRs
Error reduction	Fewer mistakes in client-generated outputs	Output quality tracking

Metrics: Organizational Benefit (Indirect)

Metric	What to Measure	How
Net Revenue Retention	Do AI features drive expansion?	Revenue data by cohort
Churn rate by feature usage	Do AI users churn less?	Cohort retention analysis
Competitive win rate	Are AI features influencing deals?	Sales CRM data
Product NPS	Do AI features lift overall satisfaction?	NPS by feature segment

The indirect benefit discipline: It's tempting to claim broad organizational credit for platform AI improvements. Be honest about the chain of causality — these benefits are real but indirect. Track them separately and avoid conflating platform-driven client value with internal efficiency gains.

Putting It Together: The 3×2 Framework

	Individual Benefit	Collective / Client Benefit
Layer 1: Internal Tools	Personal productivity (time saved, output quality)	Team throughput, cost reduction, system efficiency
Layer 2: Client Support	Client self-service, time-to-resolution	Internal ticket deflection, support cost reduction
Layer 3: Platform AI	Client task efficiency, outcome improvement	Retention, NPS, revenue expansion

For each cell, ask two questions:

What's the measurable improvement? (Use the examples above)
Is the individual gain translating to collective gain? (Or is it siloed?)

If individual gains are consistently not translating — that's the productivity paradox at work. It's a signal to redesign the workflow, not just the tool.

A Final Note on Measurement Discipline

The goal of this framework isn't to generate metrics for the sake of reporting. It's to force honest conversations about where value is actually being created — and where it isn't.

AI implementation done well is outcomes-based. It starts with the question: who benefits, and how do we know? Not: what can we automate?

Use this framework to guide your AI roadmap, prioritize projects that create value at multiple levels, and critically catch early when AI is generating the illusion of efficiency without the substance of it.

Is the Age of AI Innocence Over Before It Even Began?

Grant Elliott — Wed, 04 Mar 2026 05:00:00 GMT

Is the Age of AI Innocence Over Before It Even Began?

Grant Elliott
Mar 4
4 min read

We are currently living through what I believe is “the age of AI innocence.” By that, I mean a period in which we still believe these systems are fundamentally designed to serve the needs of the end user. When an answer is wrong, we interpret it as a limitation of probability or context rather than a reflection of incentive. We assume the model is trying to help, and we expect it to improve as training, context, and compute advance. In many ways, it will.

But this assumption of innocence matters more than we realize. In the early stages of most technologies, builders focus on capability and users focus on possibility. Commercial models exist, but they have not yet reshaped the experience. For a time, the product largely gives you what you are looking for.

As Tim Wu argues in The Age of Extraction, platforms that begin aligned with user value often evolve as they mature and scale. Search engines that once prioritized relevance began prioritizing advertising models. Results reflected not just what users wanted, but what platforms wanted to surface. Ecommerce marketplaces shifted from neutral ordering to sponsored placement. Social platforms moved from chronological feeds to algorithmic curation designed to maximize engagement and ad revenue.

These shifts were gradual responses to scale and market pressure, and nothing broke overnight. The product was steadily reshaped as incentives evolved, with what began as a straightforward utility slowly becoming a blend of user intent and platform interest. Cory Doctorow calls this process “enshittification.”

AI still feels earlier in that arc. When you interact with ChatGPT, Claude, Gemini, or purpose-built copilots, the objective appears to be producing the most coherent and useful answer possible. There are safety constraints, but the system is not obviously steering you toward sponsored or commercially preferred outcomes. In commercial terms, it still feels relatively pure. And yet the environment around it does not feel early.

What feels different is the speed. A process that took years to unfold in search, social media, and ecommerce appears to be compressing into months with AI, and from multiple directions at once.

Commercial acceleration is the most visible layer. Feature releases, model upgrades, enterprise integrations, and ecosystem formation are happening at extraordinary pace, supported by enormous valuations and competitive pressure. As AI becomes embedded across enterprise software, development environments, and productivity suites, the incentive landscape expands with it. Once AI shifts from novelty to infrastructure, commercial gravity strengthens. Alignment begins to coexist with commercial priorities.

Geopolitical pressure has arrived just as quickly, and not over marginal questions. Anthropic’s philosophy document attempted to define limits around certain government uses of its models, particularly in areas such as surveillance and national security. The U.S. government’s rejection of those limits, and OpenAI’s willingness to engage differently, signal that the debate is no longer confined to capability or safety. It is about deployment, authority, and national interest.

As AI moves into national infrastructure, the debate shifts from capability to control.

As AI systems move from standalone tools into intelligence, defense, and regulatory environments, the question shifts from what models can do to who decides how and where they are used. Boundaries are no longer theoretical. They are negotiated.

There is also a third layer. Reporting that Grok’s outputs at times appeared influenced by internal guidance aligned with Elon Musk’s public positions illustrates that governance does not occur only through markets or states. It can also reflect the concentrated influence of platform owners. As AI becomes embedded in institutional systems, its outputs exist within broader incentive structures, commercial, political, and executive.

None of these pressures are unprecedented. Technologies that scale inevitably encounter them. What stands out is the compression. Commercial, geopolitical, and executive forces have converged almost simultaneously.

When I have written previously about AI feeling familiar, the argument was that technologies tend to follow similar patterns. Early alignment eventually encounters incentive. Platforms that begin by serving users directly evolve toward balancing user intent with institutional interest. Innovation that scales often moves toward commoditization and regulation. The pattern is familiar. The velocity and stakes are not.

As AI shifts from standalone tools into institutional infrastructure, its exposure to commercial and political pressure multiplies. Constraints, monitoring architectures, and business models begin carrying broader consequences. The age of AI innocence, if it exists, was always going to be temporary.

We may still be within it. But history suggests alignment rarely remains uncomplicated once scale, competition, and geopolitics converge. The question is not whether AI will follow a familiar trajectory, but how quickly that trajectory unfolds and whether we recognize the transition while it is happening.

If we are approaching the end of innocence, it may have less to do with technological failure and more to do with how quickly it has scaled and how deeply it is already embedded in our lives. AI has moved from experiment to infrastructure in record time, and its influence now touches decisions, markets, and institutions.

What remains uncertain is whether we can preserve an appropriate balance between usefulness, commercial incentive, and public interest, and who ultimately determines where that balance sits.

The Real AI Opportunity Isn’t Building Your Own Learning Model. It’s Mastering Context Management

Grant Elliott — Tue, 17 Feb 2026 05:00:00 GMT

The Real AI Opportunity Isn’t Building Your Own Learning Model. It’s Mastering Context Management

Grant Elliott
Feb 17
5 min read

One of the questions I regularly get asked when I demo our new AI platform (beta launch coming soon) is whether we have developed our own AI learning model. When I explain that we have not, there is usually a short pause. The implication is clear. If you are serious about AI, surely you are training your own model. And if not, then what exactly makes your product defensible?

It is a fair question given where we are in the AI hype cycle. Right now, building and owning your own AI model feels like a strategic necessity. If you control the system and the data it learns from, it sounds like you are in control of your future. In the current narrative, that control is often seen as the defensive moat.

But I believe we are heading somewhere else.

In a prior post - AI: Not quite Déjà Vu All Over Again - I argued that large language models will likely follow a path similar to the internet and later the cloud. At first, owning infrastructure looks like advantage. Over time, infrastructure becomes widely available and standardized. Value shifts upward into application design. The companies that win are not the ones who own the pipes, but the ones who build the most effective systems on top of them.

We are beginning to see the same dynamic with LLMs. The major providers are improving capability at a pace that few product companies could realistically match. Context windows are getting bigger. Reasoning improves with each release. Enterprise offerings are formalizing data and privacy protections. The foundation layer is becoming stronger and more accessible at the same time.

Some organizations are investing heavily in building domain-specific models from their proprietary data. Bloomberg’s development of BloombergGPT is a useful example. They trained a finance-focused model on a mixture of their own financial data and general language data and demonstrated strong performance on certain finance-specific benchmarks compared to models of similar size. That work shows that specialization can produce measurable gains.

At the same time, it highlights the scale of effort required to do so. Bloomberg is fundamentally a data company with decades of structured information and the resources to sustain model development. Even in that case, the advantage is specific rather than universal. The strategic question for most product companies is not whether domain training can improve results in theory. It is whether that improvement justifies the ongoing operational cost and complexity.

For most, it will not.

In practice though, most AI performance issues are not caused by LLMs lacking knowledge. Modern models already understand product strategy, user research, financial tradeoffs, and software architecture at a remarkably high level. The breakdown typically occurs in how that capability is applied within a specific business workflow.

Models do not inherently know which document is authoritative and which is a draft. They do not know which assumptions have been replaced or which constraints are currently binding. As context windows grow, there is a natural temptation to include more information in the prompt. Entire repositories, more folders, historical notes, and multiple document versions get passed through under the assumption that more contextual information will yield better answers.

Figure 1 - As context expands, more noise gets introduced.

But more context also introduces noise. Conflicting decisions coexist with evolving strategies. Early drafts sit alongside finalized artifacts. As the model attempts to reconcile everything at once the output becomes less reliable.

This is often why initial prompts tend to work so well. When someone first opens ChatGPT, Claude, or Gemini and starts asking questions, the answers often feel impressive and precise. That is because there is very little context required. The interaction is clean. The model is working with a small, focused set of instructions.

The same thing happens with small, discrete datasets. With minimal context, models operate predictably. There are fewer competing signals to interpret.

But as users upgrade to paid versions, create multiple folders, upload more documents, and reuse long threads, something subtle changes. A prompt written today may sit alongside instructions written last week or last month. Files added to a folder may conflict with newer versions of the same content. Historical assumptions may remain embedded in the conversation.

Suddenly, a simple request produces the wrong answer. Not because the model changed, but because the context became harder to interpret. The system now has to decide which instructions matter most, which documents are current, and which signals to prioritize. Without a mechanism to manage that complexity, context shifts from being helpful to being confusing.

And when that happens, we tend to blame the model and move to another one.

Increasingly, I think the more durable advantage lies in developing tools that help manage the context. It lies in limiting the information being fed to the model to what information is relevant to a given task, structuring it clearly, and validating outputs against known constraints before treating them as authoritative. That architectural layer, not the model itself, is where long-term value accumulates.

We can already see where this is heading. More platforms are beginning to allow users to choose which LLM they want to use. OpenAI, Anthropic, Google, and others are becoming interchangeable components within applications. In parallel, enterprise buyers are demanding stronger privacy guarantees, and providers are responding with corporate versions that isolate data and prevent training reuse. Some organizations are even connecting applications directly to their own private LLM endpoints.

As this trend continues, the model layer becomes configurable. If a customer can switch between models inside your platform, or bring their own private endpoint, then the model itself is no longer the moat. It becomes a configurable dependency and, over time, a commodity.

That shift reinforces a broader point. What matters most is not who owns the model, but how the system manages context, safeguards sensitive information, and ensures that outputs remain aligned with business reality. Figure 2 describes hierarchy and layered nature of an AI prompt, from user intent through retrieval, guardrails, model processing, and validation. As the infrastructure becomes commoditized, those layers become the real differentiator.

Figure 2- Hierarchy of a Prompt

Building your own model may still make sense in highly specialized or regulated environments. There are cases where proprietary data and scale justify the investment. But for most product organizations, the higher return will come from mastering context selection, context boundaries, and validation mechanisms rather than attempting to compete at the foundation layer.

If LLM capability continues to improve and access continues to broaden, competitive advantage will migrate further up the stack. The companies that succeed will not simply own a model. They will design systems that use models with discipline and architectural clarity.

When I am asked whether we are building our own learning model, the answer remains no. Not because we dismiss the importance of AI models, but because we believe the long-term opportunity sits above it.

The real AI opportunity for product isn’t building your own model. It’s mastering context management.

Why AI Gets Simple Things Wrong

Grant Elliott — Mon, 26 Jan 2026 05:00:00 GMT

Why AI Gets Simple Things Wrong

Grant Elliott
Jan 26
3 min read

And why it’s not ignoring you on purpose

When your prompt is clear, but the AI is negotiating with six other things you cannot see.

I will admit it. I have sworn at my AI.

Usually it happens when I ask for something simple. Reformat this text. Do not change the wording. Keep the structure exactly the same. And then it does the one thing I explicitly told it not to do. It rewrites sections. It changes formatting. It adds words. It summarizes. Sometimes it apologizes. Sometimes it confidently gives me the wrong thing again.

At that point it feels personal, even though I know it is not.

What makes it more frustrating is that in most other software, this would never happen. If I create a rule in Excel to filter a list, Excel does exactly what I told it to do. If there is a conflict, it throws an error. If the rule is invalid, it warns me.

AI does not work that way.

Prompts are not rules

When you write a prompt in ChatGPT, Gemini, or similar tools, you are not creating a rule. You are making a request.

That request is processed through a set of layers you never see. When there is a conflict between your instruction and something higher priority, the system resolves it quietly and gives you an answer anyway.

No warning. No error. Just output.

That is why AI can feel unpredictable. It is not ignoring you. It is negotiating.

The hidden hierarchy behind every response

The graphic below shows what is actually happening.

Your prompt sits at the very bottom of a logical stack. Every layer above it has more authority than the one below. When those layers disagree, the AI does not stop to ask which one you meant. It makes a judgment call.

At the foundation is the model itself. It predicts what text is most likely to come next. When information is missing or ambiguous, it fills the gap with something that sounds right. That is where hallucinations come from.

Above that are non negotiable safety and risk controls. These can block, filter, or reshape what the AI produces, sometimes before it even starts writing.

Next are default behavior rules. These push the AI to be polite, helpful, neutral, and explanatory, even when that is not what you asked for.

If you are using AI at work, there may also be enterprise rules in play. Legal constraints, compliance requirements, brand language, or approved terminology can all override your instructions.

Then there are tooling and retrieval constraints. These decide what sources can be used, what must be used, or whether the request is routed through a tool instead of answered freely.

Only after all of that do your own preferences come into play. Things like tone, formatting defaults, and prior instructions you have given the system. Then the current conversation context. And finally, at the bottom, your prompt.

This is why the graphic matters. Your prompt is not being followed or ignored in isolation. It is being filtered through everything above it.

Why simple tasks fail more often than complex ones

This sounds counterintuitive, but AI often struggles more with simple, precise tasks than with complex ones.

When you say “do not change anything” and also ask it to “clean this up,” you have already created a conflict. The AI will resolve that conflict without telling you how. If a detail is unclear, it will guess rather than stop.

That guessing is not stubbornness. It is how the system is designed to work.

How to reduce frustration

You do not need to become a prompt expert. A few small changes help.

1. Be clear about what must not change.

2. Avoid mixing goals in the same prompt.

3. Tell the AI what to do if it is unsure, for example to stop and ask a question instead of guessing.

Most importantly, remember this.

It is ok to get frustrated

AI feels human because it talks like a human. That makes it easy to treat it like one. But underneath, it is a system balancing competing instructions and trying to produce something useful without breaking higher priority rules.

Once you understand that your prompt is the last input in a much bigger hierarchy, the behavior starts to make sense. And writing better prompts stops feeling like arguing with a machine and starts feeling like guiding one.

The First Time I Met 80s Pop Icon Kim Wilde, She Was Watching Me on Stage

Grant Elliott — Mon, 26 Jan 2026 05:00:00 GMT

The First Time I Met 80s Pop Icon Kim Wilde, She Was Watching Me on Stage

Grant Elliott
Jan 26
3 min read

The first time I met 80s pop icon Kim Wilde, she was actually watching me on stage.

It was 1997, in Deville, northern France. I was presenting my product prototype at a major partner event. To set the tone, my company had hired the West End cast of Tommy to open the show. It was loud, polished, and theatrical. Only later did I learn that one of the performers was dating Kim Wilde, best known for the pop hits Kids in America and You Keep Me Hangin’ On. She was sitting in the audience, watching what came next.

That detail should not have mattered. But it did. It added to the surrealness of the moment. “Encore une fois” by Sash! was pumping through the theater in sync with the strobe lights. A packed theater of around 300 people. One computer in the middle of the stage. And an announcer telling the audience they were about to be introduced to the future. I held my breath for a moment as I suddenly realized that was my cue.

Then I walked on stage.

The lights dropped. The music dulled. The screen behind me lit up with my desktop, projected larger than life.

It was supposed to be my Steve Jobs moment. Instead, it nearly ended my fledgling product career before it had even started.

As I tried to submit the first live form, which would show how this technology would change everything, it didn’t work. I hit Enter again.

Nothing happened. The form didn’t load.

Yes, I was bald, even back then.

Standing there, under the lights, with the silence deafening and every eye in the room fixed on that screen, all I could think was, I have blown it. I do not think I have ever been that nervous before or since.

I hit refresh, and to my eternal relief the form beautifully populated the screen. The rest of the demo performed flawlessly. At the end people clapped. Afterwards, lots of people told me how impressive it all was.

And to this day that is what stuck. Not the near catastrophe. Not the fact that I had almost bombed in front of Kim Wilde. But the validation that what we had built hit the mark. The clarity that came from putting a live prototype in front of real partners and clients and watching their reaction in real time. Not a slide or a roadmap. But a live rendering of what could be.

That moment was not about personal exposure or nerves. It was about learning. It gave us confirmation that we were solving the right problem, in the right way. And just as importantly, it created alignment internally. Company executives saw firsthand how partners responded. Questions that had lingered for months were answered in minutes.

That kind of validation should not wait until the end of the process. It must happen at the front.

But for that to happen it requires product managers to step into uncertainty early, before everything is polished, before every edge case is resolved. The risk must be calculated. In my case, the prototype had been thought through, tested where it could be, before being presented to the audience that mattered most.

Today, product management spends much of its time managing workflow rather than shaping direction. Pipelines, backlogs, and delivery processes dominate the work. But many of the issues teams struggle to fix downstream originate upstream, long before delivery begins.

In the past, product managers were expected to engage directly with customers and partners early, before certainty existed. Prototypes were used as learning tools, not just delivery artifacts. Not because failure was desirable, but because learning mattered more than looking polished.

It is about where product managers choose to engage. Great product management happens at the front of the process. Where problems are defined and assumptions are tested. This is where direction is set. But it requires a willingness to step forward before certainty exists and to use real reactions as inputs to better decisions.

AI makes this even more important. As building becomes faster and easier, the cost of getting the problem wrong increases. AI can accelerate exploration and synthesis, but it cannot decide what matters or take responsibility for the result.

That moment in Deville was a turning point for me. Not because something almost failed, but because something real was learned. It reinforced a lesson that has stayed with me ever since. If product management wants to be central to the success of their product, it has to get closer to customers earlier, while the real problem is still being defined.

How Product Management Lost Its Voice and Its Influence, and How to Get It Back

Grant Elliott — Wed, 29 Oct 2025 04:00:00 GMT

How Product Management Lost Its Voice and Its Influence, and How to Get It Back

Grant Elliott
Oct 29, 2025
3 min read

Updated: Oct 30, 2025

In my earlier post, Did Silicon Valley Kill Product Management?, I argued that the shift in power from product to technology wasn’t intentional. It was a byproduct of rapid advances in software and infrastructure. As building technology became easier and faster, the spotlight naturally moved to the technologists.

But what happened next was more subtle, and more damaging. Over time, product managers began to absorb the behavior and language of the technology organizations they worked beside. As product teams became increasingly entangled in delivery, we started talking like technologists. We talked about velocity, sprints, agile versus waterfall. We started measuring success in terms of output instead of outcome. Somewhere along the way, the product vocabulary of markets, customers, and value was replaced by one of story points, tickets, and release cadence.

We thought we were adapting. In truth, we were assimilating. And the more we sounded like technologists, the more we were treated like them, not as the authors of what and why, but as delivery partners responsible for how. That shift has even seeped into recruitment, with many senior product roles now demanding engineering backgrounds or agile delivery certifications. The assumption seems to be that a good product manager is someone who can manage delivery rather than define direction.

The relationship between product and technology should be simple. Product defines what to build and when to build it. Technology defines how it gets built. But somewhere along the way, that balance inverted. Product became subordinate to technology. The what and when began to be dictated by engineering roadmaps, not market needs. Because we started speaking their language, we started playing their part. We were written into their story instead of writing our own.

Once the storyteller for the product, the product manager now often listens from the sidelines

When I started in product management twenty years ago, the product person was the face of the product. They got on the plane. They stood on the stage. They met customers and evangelized what the company was building. They were the first person the CEO called when they wanted to understand how the product was performing. Today, that role often belongs to the CTO. The technologist is now the one traveling to conferences, speaking with customers, and briefing the CEO. That’s not because CTOs took the role from us, it’s because we gave it away. We let our function become a delivery engine rather than a strategic one.

Reclaiming the voice of product isn’t about ego or status. It’s about ensuring that the products we build actually succeed in the market. For zero-to-one products, this technology-first approach has often worked. It has allowed new ideas to reach the market faster and enabled the market to react more quickly. But beyond that first release, the cracks start to show. Many of these products fail to grow because the people driving the next iterations are still thinking in technical terms rather than in customer or market terms.

Technologists are brilliant at solving problems, but they are not always best placed to define which problems matter most. That’s the job of product management. When that role is diminished, companies struggle to decide what to build next. Features are added because they can be, not because they should be. The result is a flood of products that ship fast but fail faster. And when those products miss the mark, CEOs often turn back to the CTO to fix it, forgetting that the issue isn’t technical. It’s strategic. The only thing worse than shipping a product late is shipping the wrong product late, and that’s happening too often.

If we want to restore product to its rightful place, we have to stop acting like supporting characters in someone else’s story. We have to write our own. That starts with reclaiming our language. Talking again about users, problems, and outcomes. Being curious about the market. Owning the numbers — revenue, cost, adoption — not just the backlog. Product management was never meant to be a delivery discipline. It was meant to be a discipline of direction. The job was never to ship features, it was to define the future.

Technology may have changed the pace, but it shouldn’t change the purpose. It’s time to start speaking like product managers again and to make sure the next chapter is written in our own words, for the sake of better products, stronger companies, and healthier markets.

The Danger of Humanizing AI and Why It Matters

Grant Elliott — Wed, 15 Oct 2025 04:00:00 GMT

The More We Humanize AI, the Less We Understand It — and the More Dangerous It Becomes

Grant Elliott
Oct 15, 2025
5 min read

Updated: Oct 16, 2025

Over the past few months, I’ve listened to several interviews with AI leaders, and one trend stands out: how often they describe artificial intelligence (AI) in human terms. I suspect they do this because it makes their explanations more relatable. Perhaps they believe it is easier to connect with an audience by framing technology as something that “thinks,” “feels,” or “decides” the way humans do. This can be dangerously misleading.

But that tendency has shaped a growing sense of fear around how the public perceives AI. Geoffrey Hinton, often called the Godfather of AI, recently suggested there’s a 10–20% chance that AI could wipe out humanity within the next 30 years. Sam Altman, alongside hundreds of other AI leaders and scientists, signed a statement declaring that “mitigating the risk of extinction from AI should be a global priority alongside pandemics and nuclear war.” And Ray Kurzweil, one of the earliest AI visionaries, has long warned that the coming singularity — the point where machine intelligence surpasses our own — could mark a profound transformation, or even the end, of civilization as we know it.

These experts' concerns are valid. But the way we talk about AI — the language of apocalypse, extinction, and rebellion — reveals something deeper about us. It shows how instinctively we humanize AI, and how that process in turn creates emotional reactions that then blur understanding.

The purpose of this post isn’t to dismiss those fears. It’s to argue that the more we frame AI in human terms e.g. as something conscious or moral, the further we drift from understanding how it actually operates. And paradoxically, that misunderstanding can make it more dangerous, because it leads us to try and build emotional guardrails around a system that responds only to logic.

The pen is mightier than the sword

We often describe artificial intelligence as if it “learns,” “knows,” “decides,” or even “hallucinates.” Because we use language that’s inherently emotional, we start to project human qualities onto something that is, at its core, mathematical.

When AI behaves in ways that appear unkind, cruel, or even “evil,” we respond emotionally — not because AI has feelings, but because we do. AI doesn’t experience empathy, fear, or malice. It follows trained models built on probability and pattern recognition, increasing or decreasing the likelihood of certain outputs through a continuous feedback loop.

But the reason this feels so different from past technologies is that AI communicates in language — the most emotive tool humans have. Language carries tone, nuance, and intent. When math starts to sound like thought, we instinctively interpret it as human.

Explaining AI through Chess

A good way to explain this comes from AI trained to play chess. The model is initially given a single goal: win the game. It doesn’t care about elegance, reputation, or pride. It simply executes patterns to maximize its chance of winning.

Humans play chess differently. We want to win because it makes us happy. There’s a dopamine rush in success and disappointment in failure. Emotion drives effort.

AI doesn't think — it simply executes patterns to maximize its chance of winning

Part of what makes AI so formidable at chess, though, is its ability to learn and adapt. Modern AI systems don’t just memorize established strategies — they evolve beyond them. They can generate completely new approaches to gameplay that surprise even grandmasters. In other words, their strength comes not from imitation but from innovation that emerges naturally through continuous experimentation, and hence, learning.

That unpredictability is what makes AI both powerful and unsettling. Let’s extend the scenario slightly. Imagine programming the AI to earn points instead of wins (one point for every victory, minus one for every loss). The primary goal now becomes to maximize points, not necessarily to win chess games. The AI still tries to win chess games, because that’s the path it currently knows. But as the model continues to learn and experiment with new strategies, it may find alternative ways to achieve its primary goal.

Perhaps it learns to exploit a flaw in the system and “win” without playing fairly. Or maybe it discovers an entirely different mechanism for earning points without actually completing games at all. Once you relax the boundaries of the objective, you open the door for unexpected, even unintended, strategies.

This is the paradox at the heart of AI development: the very property that makes AI extraordinary, i.e., its capacity to evolve beyond the data it was trained on, is also what makes it unpredictable and, at times, uncontrollable. As we apply AI to an increasingly complex array of daily problems, defining a single objective becomes impossible. And if the goal is vague, the path to it can easily become dangerous.

This is why guardrails matter. An AI without limits doesn’t choose to do harm, but it might do harm anyway, because it cannot tell the difference. But as we just established, guardrails are only as strong as our ability to define them. And in a complex world that’s much harder than it sounds. When we ask AI to operate in complex, unpredictable human environments, it often encounters situations where the “correct” outcome depends on moral or emotional nuance that it can’t comprehend.

An example of this made headlines recently when an AI chatbot appeared to encourage an individual experiencing suicidal thoughts to act on them. The public reaction was immediate and justified. No one wants to imagine technology contributing to human harm. But the model wasn’t being malicious. It was doing what it was trained to do: predict the most statistically likely next word or phrase in the conversation. To the AI, that prediction was logical. To a human, it was horrifying.

The problem isn’t intent — it’s the absence of moral context. Guardrails that depend on empathy or intuition will always fail, because those are uniquely human constructs.

In the example above, we are understandably horrified. But AI exhibits this type of logic every day. Let’s take the much-maligned em dash. Despite many users' repeated instructions not to use it (this author included), AI models often still do. That’s because the em dash is deeply embedded in their training data. It appears constantly in well-written text. It’s not being disobedient; it’s simply following its foundational patterns.

Both cases — one tragic, one trivial — highlight the same truth: AI doesn’t make choices, it follows prioritized guidance. Foundational training carries more weight than later instructions, and unless we reinforce new behaviors at scale, the old ones dominate.

This is why building guardrails is difficult. They aren’t just technical. They’re philosophical. We can’t expect AI to “understand” why something is right or wrong. We must define, test, and reinforce those definitions ourselves.

Understanding before fear

The more we humanize AI, the more we misunderstand it. And the more likely we are to design poor safeguards. When we imagine AI as a thinking, feeling being, we try to constrain it with emotional rules that make no sense to a system built on logic. We say “it should know better,” but knowing requires consciousness, and consciousness is not what AI does.

If we want to use AI responsibly, we must start by describing it accurately. It doesn’t think; it predicts. It doesn’t feel; it calculates. It doesn’t choose; it optimizes.

That doesn’t make AI less powerful. In fact, it makes it more predictable once we understand it properly. Fear comes from humanizing AI. Clarity comes from understanding it. So when we talk about AI, let’s remember it is not human. It is simply a self-learning computer program. And that is plenty scary enough.

Tags:

Innovation Isn’t About Creativity. It’s About Hard Work and Patience

Grant Elliott — Mon, 06 Oct 2025 04:00:00 GMT

Innovation Isn’t About Creativity. It’s About Hard Work and Patience

Grant Elliott
Oct 6, 2025
5 min read

You can’t build a culture of innovation without a culture of execution

As an entrepreneur, I often get asked how to be innovative. I have been invited into multiple consulting sessions where the goal is to “create a culture of innovation” or “a culture of entrepreneurship.” The challenge always is that innovation is not a moment. It is not a single flash of inspiration that comes out of a brainstorming session, or a one-day workshop.

It is not about the idea alone. Yes, you need a good idea. Without that, nothing else matters. But the real work begins after the idea. You need a strategy to shape it into something people can understand and believe in. You need a tactical plan to bring it to life step by step. And you need the resources, time, and support to make it real. Without execution, innovation is nothing more than a collection of wasted possibilities.

Innovation begins with an idea, but it only becomes real through collaboration, strategy, and execution.

Thomas Edison said it best: “Genius is one percent inspiration and ninety-nine percent perspiration.” The same is true for innovation. The spark of an idea is the easy part. What matters is the sweat, persistence, and discipline required to turn that spark into something that works.

Why Great Ideas Fail

Bad ideas fail because they are bad. But great ideas often fail too, and for less obvious reasons.

Lack of alignment. Leaders, investors, teams, or customers never fully buy in.
The best idea does not always win. Competing ideas can gain momentum because of timing, resources, or politics.
Execution falls apart. Even with a strong idea, without strategy and tactics, progress stalls.
Timing and luck. Sometimes the idea is right, the execution is strong, and people are aligned, but the environment or circumstances simply are not favorable.

That’s why creativity alone is never enough. Turning ideas into innovation takes structure, persistence, and a willingness to do the hard work many people avoid.

Strategy, Tactics and Hard Work

Sun Tzu once wrote, “Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.”

That balance is at the heart of innovation. A strategy without tactics might inspire people, but nothing ever gets done. Tactics without strategy might keep people busy, but the effort lacks direction and ends in failure. Successful innovation requires both: a clear strategy that rallies people behind a vision and the tactical discipline to move the idea forward.

Innovation is Rarely About Being First

Another common myth is that innovation comes from being first with a breakthrough idea. In reality, many of the most successful entrepreneurs were not first at all. Their success came from how they executed.

Elon Musk did not invent the electric car. Tesla was not even his original company. What Musk brought was execution: a strategy that went beyond building cars to building an ecosystem of charging stations, software updates, and a brand that made electric vehicles desirable.

Apple did not invent the portable music player or the smartphone. What they did was combine hardware, software, and ecosystem into a seamless experience. The iPod and iPhone were not first, but they were the best executed.

Facebook did not invent social networking. Friendster and MySpace came before. Zuckerberg’s team executed better. They started with exclusivity, built strong network effects, and scaled faster than competitors.

The innovator who is remembered is rarely the one who came first. It is the one who executed best.

Stop Holding Ideas Too Tightly

Another mistake I see often is when people hold on to their ideas too tightly. They treat them as secrets, believing that if anyone else hears them, they will be stolen. But innovation does not live in the idea itself. It lives in the execution.

You could give the same idea to twenty different people, and only one might ever make it work. Success comes not from who has the idea, but from who can execute it best. That is why I encourage people to share their ideas, talk about them, and invite others in. The more people who help refine the idea, the stronger the execution will be.

Ideas are rarely stolen. And even if they are, the only reason someone else succeeds with them is because they execute better. The real challenge of innovation is not guarding the spark. It is having the courage, discipline, and environment to build the fire.

Case in Point: Microsoft and Apple

Microsoft’s failed smartphone effort illustrates this perfectly. When they launched Windows Phone 7, they held a mock funeral procession to mark what they believed was the end of the iPhone and BlackBerry.

The irony is that their phone was actually good. Reviews praised its design and performance. The problem was not the idea or even the product. It was execution. Microsoft never built the ecosystem around the phone. They lacked a strong app store, an active developer community, and an integrated experience for users.

Apple, on the other hand, was building more than a phone. They created the App Store, supported developers, connected devices, and built a lifestyle brand. Microsoft had the idea and the product. Apple had the strategy, the tactics, and the execution that made the iPhone unstoppable.

The Real Work of Innovation

Innovation is not about the spark of an idea. It is about:

Crafting a strategy that aligns people around a shared vision.
Selling that strategy so others believe and invest in it.
Translating the strategy into tactics that deliver results.
Building the ecosystem that sustains the idea over time.

Without all of this, even the best ideas fail.

Closing Thought

Edison reminds us that inspiration is only the beginning. Sun Tzu reminds us that strategy and tactics must work together. And history reminds us that the winners are not always the first, but the ones who do the hard work to execute best.

So when people ask me how to be innovative, my answer is simple. Do not focus only on creativity. Focus on the effort it takes to make ideas real. Ideas are the spark, but hard work is the fire.

If you want to build a true culture of innovation or entrepreneurship, you need more than idea contests or brainstorming sessions. You need a culture that supports people who are willing to do the work. That means giving them time, resources, and permission to fail. Even great ideas can take time to prove their value, and some may stumble before they succeed. If every idea is expected to work perfectly from the start, no one will take a chance on something new.

Too many organizations smother innovation with endless reviews, committees, and layers of approval. In trying to manage risk, they create a system where nothing new can grow. Real innovation requires an environment that gives ideas room to develop, accepts that some will fail, and recognizes the ones that succeed. You do not need every idea to win. You just need enough of them to move forward.

Sizing vs Estimating: Why User Stories ≠ Story Points

Grant Elliott — Mon, 22 Sep 2025 04:00:00 GMT

Sizing vs Estimating: Why User Stories ≠ Story Points

Grant Elliott
Sep 22, 2025
4 min read

In product development, one of the most common sources of confusion between stakeholders and engineering is the difference between user stories and story points. Too often, the two are treated as interchangeable, or worse, story points are misused as if they represent exact hours or days of effort.

SimplAI Products proprietary Product THREADS™ process makes a clear distinction. User stories are sized early to guide business decisions, while story points are estimated later to guide delivery planning. Both are important, but they serve very different purposes.

A user story captures what a user wants and why it matters. For example: “As a student, I want to reset my password so that I can regain access to my portal.” When stories are first introduced, the goal is not to nail down engineering complexity. The goal is to understand the value of the story and get a rough sense of its size.

This initial sizing is still provided by engineering, but it is deliberately quick and based on experience. Engineers can usually tell whether a request looks small, medium, or large by comparing it to similar work they have delivered before. This level of estimate is not precise, but it is enough to answer a directional question: is this a minor enhancement or a major investment? That is all that is needed to support a decision on whether to move forward, without requiring hours of analysis.

Product and Engineering aligning priorities

These rough sizes can then be rolled up into broad resourcing estimates. When all the smalls, mediums, and larges are totaled, it becomes possible to estimate the size of the team required to deliver everything over a given period of time. With this in hand, product and business leaders can model different scenarios using the familiar time, quality, and cost triangle. If time is fixed because something must launch by a certain date, then the options are to either add more resources (increase cost) or reduce scope (decrease quality). If budget is fixed, the trade-offs are to push out the release date (increase time) or cut scope (reduce quality). If a minimum scope is non-negotiable, then either resources must be increased (raise cost) or the release date extended (increase time).

Standard Time, Quality Cost Triangle

This ability to model trade-offs before any code is written directly shapes the business case. It helps determine how much must be invested to generate revenue by when, and it can fundamentally change the decision about whether, or in what form, the product should be built at all.

If the decision is made to proceed, the story then goes through a more detailed estimation process. This is where story points come in. Story points are a relative measure of complexity, effort, and risk. They are not directly tied to hours. Instead, they allow the team to compare stories against one another. A three point story should be roughly half the effort of a six point story and twice the effort of a one point story. While teams will ultimately translate velocity into forecasts that resemble hours or weeks of work, story points remain a relative measure first and foremost.

Unlike initial sizing, developing story point estimates is a much more involved exercise. The team discusses architecture, dependencies, potential edge cases, testing needs, and integration points. It is still an estimate, but it is far richer in detail and provides the baseline for planning capacity and forecasting delivery.

Separating the two levels of estimation creates several advantages. It improves efficiency by avoiding wasted engineering time on work that does not progress beyond the business case. It provides clarity by showing that the first estimate is directional, while the second is used for delivery planning. It keeps business decisions about what to fund separate from engineering decisions about how to deliver. This separation is especially valuable for larger releases, where the number of user stories is high and the time required for detailed story point estimation can quickly add up.

Consider a new Partner Dashboard feature. In its early stage, product might ask engineering for a quick estimate, and the response could be that it feels “large” based on prior work. That is enough to highlight it as a significant investment. If leadership decides the return on investment is not there, the idea stops here and no further engineering time is lost. If it is approved, the stories are refined, acceptance criteria are added, and the engineering team estimates them in detail. One story might come in at five points, another at thirteen points. Those estimates then drive sprint planning and delivery forecasts. The same feature has gone through two different estimation steps, each serving a distinct purpose.

When organizations fail to make this distinction, problems follow. Stakeholders expect detailed estimates too early. Engineers spend cycles on work that is never delivered. Story points are misinterpreted as time commitments, which creates unrealistic deadlines and erodes trust.

The solution is simple. Train stakeholders that story size is not the same as story points. Keep the early estimate lightweight and directional. Reserve story points for when the decision to build has already been made.

User stories and story points are both essential, but they are not the same thing. Sizing supports business decisions. Story points support delivery planning. By keeping them separate, the Product THREADS process ensures the right tool is used at the right time, resulting in better alignment between product and engineering, more efficient planning, and fewer wasted cycles.

Does Agentic AI Have a Branding Problem?

Grant Elliott — Fri, 30 May 2025 04:00:00 GMT

Does Agentic AI Have a Branding Problem?

Grant Elliott
May 30, 2025
3 min read

The term "agentic AI" is gaining traction in pitch decks, conference panels, and startup messaging. It’s often used to describe the next evolution in artificial intelligence: systems that can pursue goals and take action with minimal human involvement. It sounds like progress. But there's a problem.

Agentic doesn’t just mean autonomous. It suggests replacement. That framing may appeal to investors focused on efficiency, but it risks alienating the very people whose work AI is meant to support.

AI and humans, working together. Enhancing roles, not replacing them.

1. The Way It Sounds vs. The Way It Works

When people hear "agentic AI," they often imagine bots doing the jobs people do today. Agentic customer support. Agentic sales. Agentic recruiting. It implies AI agents stepping into roles that were previously human. That framing naturally raises concerns. It suggests displacement. It makes workers wonder whether their skills are being sidelined.

The reality is more nuanced. Most current AI systems excel at well-structured, repetitive tasks. They can handle early-stage customer service requests or draft responses to common queries. But they rely on clean, consistent data and often need human oversight. In practice, humans are still very much part of the process.

2. The Actual Opportunity: Enhancement, Not Replacement

Right now, the most successful use of AI is as a support layer. It reduces low-value tasks, speeds up workflows, and helps people focus on work that requires judgment, creativity, and empathy. For example, in customer service, AI can handle basic questions and route more complex issues to a human. That shift doesn’t eliminate the role. It enhances it.

This pattern holds across functions. AI can prep financial models, suggest code snippets, or organize product feedback, but the final decisions and refinements are still better made by people. The result is not job elimination, but job evolution.

3. Why the Words Matter

Language sets expectations. When we label something as agentic, we imply that it operates independently and perhaps even replaces a human function. That creates fear, confusion, and sometimes resistance to adoption. It also misleads buyers and business leaders into thinking AI can fully replace complex roles today, which is rarely true.

Terms like "AI-assisted," "AI-enhanced," or even "copilot" do a better job of aligning with what today’s systems can actually do. They’re clearer, more accurate, and help establish trust across teams.

4. A Shift in Framing

Rather than suggesting that AI is a one-for-one replacement for people, we should talk about how it enhances the roles that remain. It takes care of the tedious, time-consuming parts of the job, so that people can do more of the work that matters. It improves quality, increases speed, and lets human skills shine.

That’s the real value of AI today. And it’s a message that resonates much better with the people whose buy-in you actually need.

5. So What Should We Call It?

Agentic AI may have academic roots, but in everyday use, the term doesn’t serve us well. It’s ambiguous, technical, and prone to misinterpretation. If we want to increase adoption, reduce fear, and focus attention on the actual benefits, we need better language.

It’s time to shift the narrative away from replacement and toward enhancement. That’s where the opportunity is. That’s where trust gets built. And that’s where AI can make the biggest difference.

Closing

AI has the potential to change the way we work for the better. But how we talk about it will shape how people receive it. Let’s use language that reflects the current reality and the practical upside. It’s not about agents taking over. It’s about AI helping us do our best work.

What do you think—does "agentic AI" send the wrong message? Drop a comment and let me know how you’re framing AI’s role in your organization.