From Task Executor to Problem Solver
June 2, 2025
“Create an issue for dark mode.” That’s where we started. A simple command, a simple response. Click, boom, GitHub issue created. Useful? Sure. Game-changing? Hold your horses now, son.
But what if instead you could ask: “What’s the potential impact of adding dark mode based on our user segments?” Or “How does dark mode priority compare to the other UI improvements in our backlog?”
That’s the vision that made me burn down a working proof of concept and start over.
The limitations of task execution
The original Piper Morgan prototype was actually pretty good at what it did do. Give it a task, it executed. Need a GitHub issue? Done. Want to review a ticket? Helpful!
But this just scratches the surface. Even if it was able to handle all such tasks for me, the real PM work — the analysis, the strategy, the judgment calls — that was still all on me. And if I’m doing all the thinking anyway, how much time am I really saving?
On the other hand, I do want this thing to be able to get smarter and to play a more meaningful role in assisting me, so what to do? What to do?
“Successful prototype syndrome”
During those architectural reviews (remember those three AIs telling me to start over?), we discovered what I now call “successful prototype syndrome.” The POC worked so well that I kept extending it, patching features onto a foundation that was never designed for the building I wanted to construct.
The breakthrough insight: task execution and strategic thinking aren’t just different in degree — they’re different in kind. You can’t retrofit jazz improvisation onto a recipe-following system.
But, what if Piper Morgan could:
- Analyze patterns across hundreds of tickets to surface insights nobody saw coming
- Synthesize feedback from multiple channels into actionable recommendations
- Generate strategic alternatives, not just execute predetermined tasks
- Learn what works for your specific team and domain
Then my assistant would (someday be not just a task executor, but a thinking partner.
What strategic thinking actually demands
Task execution needs simple patterns: “create ticket” maps to GitHub API calls. Strategic thinking needs something fundamentally different:
- Understanding relationships between concepts
- Learning from patterns over time
- Reasoning about trade-offs and alternatives
- Orchestrating multiple types of analysis
The POC could handle the first one. The other three required starting over.
The philosophical shift
This isn’t just about making AI smarter — it’s about changing the relationship entirely. The POC approached every problem like this: “You tell me what to do, I’ll do it faster than you could.”
The platform approaches problems like this: “Let me understand what you’re trying to accomplish, consider what we know about similar situations, and help you think through the best approach.”
One is automation. The other is augmentation.
I’ve never loved the idea of replacing people with AI. Not just because it’s usually a bad idea in specific, but because it feels wasteful on both ends. What I do love is giving people superpowers that enable them to focus on the things people do best.
Comedy interlude: the environment wars
While planning this ambitious rebuild, I was still fighting with my development environment. Remember those Python path issues? They’d multiplied like rabbits in a particularly fertile warren.
At one point, I had Python 3.9 from macOS, Python 3.11 from Homebrew, Python 3.12 from somewhere I couldn’t identify. The command which python returned different results depending on which terminal I used, what time of day it was, and possibly the phase of the moon.
I considered keeping a notebook just for “which Python am I using now?” I imagined entries looked like archaeological field notes: “Terminal 2, Tuesday afternoon: Python 3.11. Same terminal, Wednesday morning: Python 3.9. Cause unknown. Recommend ritual cleansing.”
Building the new foundation
On June 2, we started fresh. Instead of patching the POC, I spent eight hours building Piper Morgan 1.0 from scratch with lessons learned.
The new architecture puts PM domain concepts — Products, Features, Stakeholders — at the center, not tool integrations. GitHub, Jira, and Slack become plugins in a system that understands product management workflows natively.
We prepared to build a proper infrastructure stack: PostgreSQL for relational data, Redis for caching, ChromaDB for vector embeddings, Temporal for workflow orchestration. All running in Docker Compose for a $0 software budget with clear upgrade paths.
The domain-first breakthrough
The key insight was starting with PM domain models instead of just hackin together API integrations willy-nilly. When you define Intent, Product, Feature, and Stakeholder as first-class entities, everything becomes clearer.
The system understands that creating a feature might involve GitHub issues, Slack notifications, and documentation updates — but those are implementation details, not the core workflow.
By June 2, we had working domain models, a FastAPI server with real intent classification, and an orchestration engine that could execute multi-step workflows. The AI was achieving 0.95 confidence scores on classifying EXECUTION, ANALYSIS, and STRATEGY intents.
(That’s good!)
The reality check
But let’s be honest about what actually works versus what we’re building toward. As of June 2:
✅ What actually works:
- Intent classification that understands PM language
- Multi-step workflow orchestration with context passing
- Database persistence of workflow results
- Plugin architecture foundation
🔄 What we’re still building:
- The strategic analysis capabilities I described above
- Cross-project pattern recognition
- Learning from outcomes over time
- The kind of insights that would actually surprise me
The foundation is solid, but we’re maybe 30% toward the thinking partner vision.
Making it real
Of course, vision is cheap. Implementation is expensive. The new architecture required components that could learn, reason, and connect insights across interactions.
Instead of simple request-response patterns, we needed systems that could:
- Maintain context across multiple conversation turns
- Connect current requests to historical patterns
- Reason about trade-offs using product management principles
- Learn from outcomes to improve future recommendations
Each component had to be built with learning in mind. The intent understanding system didn’t just categorize requests — it captured nuance and ambiguity. The workflow engine didn’t just execute steps — it recorded decision points and outcomes for future reference.
What strategic thinking actually means
Here’s an example of the difference in approaches. Instead of:
User: “Create a ticket for improving search performance”
Old Piper: Creates ticket with basic template
The new system is designed to engage like this:
User: “Create a ticket for improving search performance”
New Piper:
I’ve been analyzing recent user feedback and noticed search performance complaints have increased 40% since last sprint, primarily from mobile users. This correlates with the recent search index expansion.
I see three possible approaches:
Quick optimization of current algorithm (2 days, ~20% improvement)
Implement caching layer (1 week, ~60% improvement)
Full search infrastructure redesign (3 weeks, ~90% improvement)
Based on your Q3 roadmap and the mobile app launch timing, I’d recommend option 2. Should I create tickets for the caching implementation with specific subtasks for cache warming and invalidation strategies?
That’s not just faster execution. That’s strategic partnership.
What this enables (eventually)
With the new architecture, we can build toward that strategic thinking partner. We won’t get there in one hop, but the foundation can support it.
The domain models let us reason about PM concepts. The orchestration engine can chain together different types of analysis. The persistence layer captures enough context to enable learning over time.
But transforming “create a ticket for search performance” into a strategic conversation about user impact, resource allocation, and alternative approaches? That’s still ahead of us.
Looking forward
The task executor is dead — we buried it on June 2. The thinking partner is being born, but it’s still early days. Each week we add capabilities that move us closer to real strategic collaboration.
The difference is that now we have an architecture that can get us there, instead of one that was fighting us every step of the way.
Sometimes you have to burn down something good to build something great.