changelog

NB: For a good, albeit risky, drinking game, take a drink every time you encounter the word ‘Taylorism’ in this post.

In 1911, Frederick Winslow Taylor published *The Principles of Scientific Management*, and the modern workplace was born. His insight was simple but revolutionary: break complex work into discrete, measurable tasks. Time each task. Optimize each task. Train workers to perform their specific tasks with maximum efficiency.

Taylorism gave us the assembly line, the org chart, the job description, and the task management system. It worked brilliantly for manufacturing. And when knowledge work emerged, we simply applied the same framework: break the work into tasks, assign the tasks, track the tasks, complete the tasks. And for a time, it was good.
 
Taylorism fit well the zeitgeist of Peak Software Engineering, especially the ZIRP Era of Software Engineering: hire expensive software engineers, and optimize, through product analysis, planning, and Taylorist work decomposition, the sets of tasks the engineers should work on. If software engineering is one of the paramount costs in a software organization, then it follows that engineers working the wrong task is the biggest avoidable cost such an organization can encounter.    

What happens though to all of this metering, when ‘intelligence becomes too cheap to meter?’

I’ll cut to the chase: we’ll still need task decomposition, prioritization, and metering, but it would be the height of folly to persist in human task decompositions for machine workers, waterfall constraints in the age of instant software, and time-to-completion estimates for one-shotting LLM agents.      

I don’t have a crystal ball, nor do you, but I increasingly think the future of software product management looks less like “discretize into tasks and select the core subset of tasks, in order to optimize time-to-delivery”, and more like “find and supply the right product context, in order to optimize accurate delivery”. (If I’m being candid, I think PMs were already doing this unsung ‘glue’ work to keep the corpse of Agile moving along).

Now AI is arriving, and everyone's first instinct is the same: which tasks can AI do? We build AI tools that write emails, summarize documents, schedule meetings—discrete, atomized tasks that fit neatly into a Taylor-shaped hole.

This is exactly backwards.

## The Taylorist Trap

The problem with task-based AI isn't that AI can't do tasks. It can, often better than humans. The problem is that **task decomposition destroys the very thing that makes knowledge work valuable: context.**

Consider what happens when you break "product management" into tasks:

- Write PRDs
- Prioritize backlog
- Run meetings
- Talk to customers
- Analyze metrics
- Coordinate with engineering

Each task, isolated, can be automated or assisted. But product management isn't a collection of tasks—it's the *synthesis* of information across all those activities into coherent judgment. The PM who just came from a customer call brings that context into the prioritization meeting. The insight from the metrics informs the PRD. The engineering constraints shape the customer conversation. 

**When you atomize the work, you atomize the context. And context is where the value lives.**

This is Taylorism's fundamental assumption: that work can be decomposed without loss. That the whole equals the sum of the parts. For physical labor moving pig iron (Taylor's favorite example), this is approximately true. For much of the knowledge work we’d seek to apply AI to, it's catastrophically false.

## The Context Revolution

As an AI builder, the criticism of LLM-based AI that resonates with me most is its data inefficiency relative to human learning. LLMs, in pretraining, get much larger amounts of data than children will in the course of their language acquisition.  I think this generalizes, very roughly, to LLMs performing at superhuman levels on many large context tasks and subhuman levels on many shallow context tasks. (As an empiricist from the ML/NLP tradition who relishes evaluating machine performance on simple tasks on hold-out datasets, this all pains me to say). 

So here's what's actually happening (I suspect) with companies struggling with AI adoption: because we’ve overly Taylorized human work (and it’s associated units of context), a lot of the actually useful work is that type of ‘glue’ work that PMs often do, and is off the books, so to speak. The set of official, Taylorist-approved tasks that live in JIRA and etc, and can give rise to AI POCs, are often too de-dimensionalized, too context-reduced, for LLM-based AI to do well and usefully.

So if the task is an artifact of human limitation—our inability to hold enough context in working memory, our need for checklists and procedures, our finite attention.

AI doesn't have those limitations. So why are we forcing it into task-shaped boxes?

If I extrapolate my hypothesis further: just like early 20th century factory managers unlocked gains from electricity only when they redesigned the factory floor with electricity in mind, the firms that redesign their data and worker infrastructure (or design it for the first time) with deep context in mind, will win the lion’s share of gains from AI. (Apologies if I sound like a sales rep circa 2023 for Big Vector Store).

## Cutline, an AI Product Context Manager

I built Cutline to embody this ‘deep context’ view of mitigating product risk. While there are definitely artifacts of ‘Taylorism’ (MoSCoW priority analysis, for instance), Cutline repurposes such tools as ‘context communication devices’, especially when they are plugged into coding agents via the Cutline MCP server. For example, the purpose of sending MoSCoW priorities to such an agent is less to instruct what to work on in which order, and more to inform the efficient frontier of possible all-at-once solutions.   

Because Cutline establishes product definition and injects it into via MCP into your favorite coding agent, the coding agent has direct visibility into what you are trying to build —the product context. That product context can help your coding agent decide the best technical approach for a given task, because the values assigned to trade-off criteria (call it ‘product sense’) are made explicit in the product context.

*Cutline is built on this principle: not task automation, but context synthesis. We don't complete product management tasks—we maintain comprehensive context and generate integrated judgment. [Try a pre-mortem](https://thecutline.ai/premium) and see what outcome-oriented AI looks like.*


AI, the Death of Taylorism, and the Rise of Context

Changelog

## Why I Built a Product Cofounder

As you know, I’ve been deep in the trenches building **TextGuardian**—a personal antiscam coach available over SMS. The core concept seems simple at first glance: users forward suspicious texts, and TextGuardian analyzes them to determine if they're scams.

It sounds straightforward. It hasn't been.

I’ve been busy relearning a lesson I’ve encountered many times in my Trust & Safety AI/ML career: people love Safety as a concept but struggle to evaluate and price it as a good. We Security professionals know that while what we offer is relative risk reduction, most buyers want an absolute cure-all. Couple that with some other challenges in the space: going to market with an SMS app, selling primarily to seniors, selling AI to consumers; and I knew I had to uplevel my product and GTM game fast. 

So I turned to the Magic 8-Ball of these times: I asked ChatGPT what to do. In lieu of a product co-founder, I went deep with ChatGPT in many, many conversations, with such prompts as "Act as a skeptical product manager. Review this product idea and identify the top 5 risks that could kill it." and "What are the key assumptions we need to validate before building this feature?"

These prompts got the job done, but they were **fragmented and inconsistent**. Each conversation was isolated. I'd lose context between sessions. The outputs weren't structured in a way that made them actionable. And worse yet, it was optimistic to the point of being naive.

“You’re Absolutely Right!!!” probably boosts morale when you’re in the trenches (I suspect that phrase is in post-training data for the express purpose of keeping developers burning tokens longer) but it’s a rotten tenet for product vision. In the age of vibecoding, velocity has never been greater, but the direction of our vector has maybe never been more aimless.  Where is the Cambrian explosion of production apps we’ve all been vibecoding? I suspect the vast majority of them are getting desk-drawered between the prototype and production stage, partially due to productionalization challenges but probably more due to GTM & product realities.  
I needed special purpose AI that was more systematic, but above all, candid. Something that could:
- Maintain context across multiple product decisions
- Structure outputs in a consistent, actionable format
- Integrate with my workflow (not just a chat interface)
- Learn from previous analyses

## Cutline : An AI Product Manager that Says No

That's when I decided to build my product cofounder **CandidAI**—what would eventually become Cutline.

I migrated from ChatGPT to Gemini for a few reasons:

1. **Familiarity**: I’ve already built TextGuardian in Firebase and Gemini and at this point I am very familiar with the stack.
2. **Customizabaility**: Vertex AI features for customizing models came in very handy for segueing from ‘Absolutely Right! AI’ to Candid AI.
3. **Cost efficiency**: For the volume of analysis I needed, Gemini was more cost-effective.

I built the backend on **Firebase** because:
- **Real-time updates**: I could see analysis results as they were generated
- **Persistence**: All my product analyses were stored and searchable
- **Scalability**: Firebase handles the infrastructure so I can focus on the product logic
- **Authentication**: Built-in auth for sharing analyses easily

## What CandidAI Became

What started as a set of prompts became a full product management suite:

- **Pre-mortem analysis**: Systematic risk identification across demand, channel, unit economics, operations, legal, and competition
- **Assumption tracking**: Explicit assumptions with validation plans and deadlines
- **Market analysis**: TAM/SAM/SOM calculations with rationale
- **Decision framework**: Go/No-Go recommendations with quantified confidence levels
-**Feature prioritization**: Automatic MoSCoW type analysis based on conjoint analysis ion specifically how that feature will help you convert, retain, or price

And an exciting feature coming soon: Cutline User Personas — what if we took a user story and used AI to make it interactive? A Cutline Persona is anchored to a specific set of desires, viewpoints, and behaviors to provide live feedback on products and features. 

Most importantly, CutlineAI is **pessimistic by default**. While most AI tools are overly optimistic cheerleaders, Cutline is designed to help you "murder your darlings" before you invest too much time and money.

I’ve been having a bit of fun having Cutline evaluate joke companies (Aplets&Cotlets.com is my idea for a subscription box that will ship Aplets & Cotlets anywhere in the world or on the ISS for $1 a month) and busted startups of the past (Juicero was a company that tried to apply DRM for some reason to cold-pressed juice). 

## The TextGuardian Lesson

Cutline was, shall we say, ‘quick to the cut’ with TextGuardian — Cutline's pre-mortem analysis was sobering. The system identified risks I'd been aware of but hadn't fully quantified:

- **User behavior friction** (users not forwarding messages)
- **Platform risk** from telco blocking (I’ve encountered this and have some work arounds but it’s outright killed some features that could have added value)
- **Unsustainable unit economics** due to high/unknown CAC

The analysis recommended **No-Go** with specific kill criteria. It wasn't what I wanted to hear, but it was what I needed to hear.

This isn’t a full pivot of TextGuardian, but a ‘pause and ponder’: at present, I think TextGuardian might be too early in the 2025 market (especially for a solopreneur with little consumer experience like myself) and might be ripe with some tweaks and developments for 2027 or 2028.  For now, TextGuardian remains a going concern and the software will be in Keeping The Lights On Mode, while in the meantime I am focusing on building tools like Cutline that will enable solopreneurs, startups, and engineering teams to build the next wave of applications.  

## Why This Matters

As a solo developer or small team, you don't have the luxury of a full product team. You need to make good decisions quickly. You need to identify icebergs before they’ve emerged. You need someone to challenge your assumptions.

That's what Cutline is: **a product coach that helps you make better product decisions**.

It started as ChatGPT prompts. It evolved into a full product powered by Gemini and Firebase. And it's saved me from building products and features that would have been dead on arrival.

*If you need a new approach to product development for the AI age, go to thecutline.ai/premium and enroll as one of the first members of our heavily discounted Founder Member cohort ($9.99 monthly/$99 annual)*. 


AI

AI, the Death of Taylorism, and the Rise of Context

Cutline or: How I Learned to Stop Pivoting and Love the Slop or: Why I Built a Product Cofounder