🌏 閱讀中文版本
A Familiar Scene
A meeting room at a major restaurant chain.
“We’re building our own ordering platform. First step: research Uber Eats and DoorDash, then put together a comprehensive feature specification.”
This is the standard playbook for most teams—logical, structured, methodical.
But experienced project leaders usually ask one follow-up question: Do the assumptions behind this approach actually hold true for this project?
Spec-driven: A Proven Methodology
Let me be clear: Spec-driven development isn’t a bad approach.
The workflow is familiar to everyone: requirements gathering → competitive research → PRD → technical specifications → development → testing → launch.
This methodology has clear strengths:
- Reduces communication overhead: Spec documents serve as a shared language across teams
- Enables resource planning: Clear scope allows for accurate timeline and budget estimates
- Establishes accountability: Responsibilities are documented in black and white
For projects with stable requirements, this approach works extremely well.
But it carries a hidden assumption: the people writing the specs already have sufficient market signals.
The challenge is that for innovative projects, market signals often don’t emerge until the product meets real users.
This isn’t a competency issue—it’s a matter of when information becomes available.
Key Insight: Spec-driven development assumes that market signals are already clear enough. But for innovative projects, those signals often don’t emerge until the product meets real users.
Seasoned PMs are familiar with a common phenomenon: about 70% of initial project assumptions get adjusted after launch. This isn’t a failure—it’s the nature of how information unfolds.
This raises a worthwhile question: Is there a way to validate these assumptions at lower cost before committing significant resources?
The Evolving Role of Engineers
Let me take a brief detour to discuss how engineers fit into the Spec-driven workflow.
In highly structured development processes, engineering expertise lies in “precise implementation”—transforming requirements into stable, reliable systems. This represents solid technical craftsmanship and forms the foundation of product quality.
Interestingly, as AI tools begin to assist with portions of the implementation work, engineering value is extending in new directions.
I’ll come back to this topic shortly.
Intent-driven: Validate Direction Before Committing Resources
After using Claude Code for a while, I noticed a fundamental shift in how I approach development.
Before: Think through what to build → Write detailed specs → Start implementation
Now: Describe the goal I want to achieve → Rapidly produce prototypes → Validate direction → Then decide whether to invest further
This is Intent-driven Development: shifting from “telling the machine how to do it” to “telling the machine what I want to accomplish.”
The core difference isn’t that coding becomes faster—it’s that the cost of validating assumptions drops dramatically.
Case Study: A Restaurant Chain’s Ordering Platform
Let’s return to the opening scenario.
The project was originally planned using the standard approach: 4 weeks for research, 4 weeks for planning, then into development. The pre-development phase alone would take over 8 weeks.
We decided to add a “direction validation” phase upfront:
| Phase | Activities | Duration |
|---|---|---|
| Define Intent | “Enable customers to complete an order in 30 seconds” | 2 days |
| Rapid Prototyping | Use Claude Code to produce 3 different prototype approaches | 5 days |
| User Validation | Test with 20 real customers, collect feedback | 5 days |
| Direction Confirmation | Decide development direction based on feedback | 2 days |
| Total | 2 weeks |
These two weeks weren’t meant to replace the full development process. They were meant to confirm that the direction was worth the investment before committing significant resources.
The result: we made three important discoveries.
Three Layers of Discovery
Layer 1: Confirming Industry Standards
Through user testing, we confirmed which features were “baseline expectations”: online payment, order tracking, order history.
These don’t need to be reinvented—following established patterns makes sense. This is where learning from competitors is appropriate.
Layer 2: Identifying False Requirements
The original plan included extensive “customization” features—letting customers adjust ingredients, set preferences.
But testing revealed: 80% of users just repeatedly order the same two or three items.
Complex customization features would be noise, not value, for most users. This discovery saved us roughly two months of development time.
Layer 3: Discovering Market Gaps
The most surprising finding: users’ biggest pain point wasn’t “ordering”—it was “pickup.”
“The app can look beautiful, but when I get to the store, I still have to wait, and orders still get mixed up.”
This is a problem that neither Uber Eats nor DoorDash has solved well—because their focus is delivery, not in-store pickup.
This is where the real differentiation opportunity lies.
Key Insight: “Should we follow competitors or forge our own path?” is the wrong question. The real question is: What do your users actually care about?
The Expanding Value of Engineers
Let’s return to the earlier topic: As AI assists with more implementation-level work, where is engineering expertise extending?
From my observations, the answer is: from “precise implementation” to “participating in definition.”
In the Intent-driven workflow, engineers aren’t just people who receive requirements—they’re participants in exploring “what problem are we actually trying to solve?”
This means an expansion of the skill set:
- Translating ambiguous business goals into testable technical hypotheses
- Rapidly building prototypes to test ideas
- Iterating direction based on feedback
This is a natural extension of technical expertise, and an opportunity for engineers to expand their influence.
Key Insight: As AI assists with implementation-level work, engineering value is extending—from “precise implementation” to “participating in defining what problem we’re solving.”
This Isn’t Black and White
At this point, I want to address a common misconception.
Intent-driven isn’t meant to replace Spec-driven—it’s about using the right approach at the right time.
| Scenario | Recommended Approach |
|---|---|
| Clear requirements, low change | Spec-driven |
| High compliance/regulatory requirements | Spec-driven |
| Multi-team collaboration requiring contracts | Spec-driven |
| Ambiguous requirements, exploration needed | Intent-driven |
| Uncertain market signals | Intent-driven |
| Need to validate assumptions quickly | Intent-driven |
The best practice: Use Intent-driven to validate direction first, then use Spec-driven for scaled development once direction is confirmed.
The two approaches are a relay, not a rivalry.
Introducing This to Your Team
If you believe in this approach and want to try it with your team, how should you go about it?
The key: Build trust through results.
Most organizations, when evaluating new methods, prioritize “predictability”—clear timelines, complete specifications, measurable outputs. This is a fundamental requirement of professional management.
So when introducing new methods, working within this framework makes gaining support easier.
Three-Step Introduction:
1. Start with a Pilot
Choose a small project as a pilot. Let the team experience the new workflow within a controlled scope and accumulate firsthand experience.
2. Let Results Speak
After the pilot is complete, share concrete outcomes: how much validation time was shortened, what insights were discovered early, what valuable adjustments were made.
Numbers and case studies are the best communication language.
3. Let It Spread Naturally
When colleagues start asking “How did your project go so smoothly?”—that’s the perfect moment to share.
Go with the flow. Let momentum build naturally.
Key Insight: When introducing new methods, the best advocacy is letting results speak for themselves.
Final Thoughts
The shift from Spec-driven to Intent-driven appears to be about tool evolution, but it’s actually about a change in mindset.
In the past, we assumed: humans understand details better than machines, so think it through before starting.
That assumption is now being challenged: when AI can rapidly produce prototypes, “thinking it through” and “trying it out” can happen in parallel.
This doesn’t make us faster at writing code.
It lets us confirm we’re heading in the right direction before committing significant resources.
In a market environment with ever-increasing uncertainty, this capability will only become more valuable.
Sources
- Anthropic. “Claude Code Documentation.” 2025.
- Author’s practical project experience