Most software projects do not fail because the code is bad. They fail because the requirements were vague, the scope expanded before anyone noticed, and critical risks surfaced only after significant investment. This is especially true for greenfield work — new products built from scratch by solo builders or small teams who are doing the product thinking and the engineering simultaneously.
Structured product discovery is not a new idea. Product teams at larger organizations have practiced it for decades. But for the solo builder spinning up a side project, or the two-person startup trying to ship an MVP, formal discovery often feels like overhead they cannot afford. The result is a familiar pattern: jump straight to code, realize the requirements are unclear, iterate in circles, and eventually lose momentum. Arness Spark is an attempt to make structured discovery accessible to exactly these teams. This post covers the plugin in detail. For the broader Arness ecosystem, see Arness: Structured AI Workflows for the Full Development Lifecycle.
The Blank Canvas Problem
Starting from nothing is harder than it looks. You have an idea, probably a good one, but the distance between “I want to build X” and “here is a clear specification of what X actually is” can be surprisingly large. What exactly does it do? Who is it for? What makes it different from the three existing tools that do something similar? What technology should it use? Which features are essential for a first version and which are distractions?
These questions are not optional. Skipping them does not save time — it defers the cost to later stages where changes are more expensive. Arness Spark tries to front-load this thinking by guiding you through a structured discovery pipeline, one conversation at a time.
The Discovery Pipeline
The pipeline begins with product discovery: a guided conversation where a product strategist agent probes your idea, challenges your assumptions, and helps you articulate a product concept. This is not a form to fill out. It is an iterative back-and-forth that captures your vision, the problem you are solving, who you are solving it for, what already exists in the space, and where you draw the scope boundary.
The output is a product concept document — a single Markdown file that becomes the source of truth for everything downstream. It includes a vision statement, target personas (generated from research, not templates), competitive landscape analysis, product pillars that define your non-negotiable qualities, and explicit scope boundaries.
From there, the pipeline moves through architecture exploration (choosing a technology stack aligned with your product pillars), use case definition (behavioral specifications in structured format), and eventually into scaffolding and prototyping. Each stage is optional. You can skip ahead or go deep at any point. The wizard handles sequencing so you do not need to remember what comes next.
Stress Testing Before Building
The part of Arness Spark that we find most valuable — and most humbling to build — is the stress-testing suite. Before you commit to architecture or write production code, the pipeline offers four independent methods to pressure-test your product concept.
Synthetic user interviews generate realistic personas and run them through a structured three-phase interview. The persona hears your problem description without knowing your product exists — does the problem resonate? Then the full concept is revealed — what clicks, what falls flat, what is missing? Finally, the weakest aspects are presented head-on to probe for dealbreakers. Each persona is given an adversarial lens: one focuses on practical adoption barriers, another on trust and risk concerns, a third on depth and scalability limits.
Competitive gap analysis goes beyond surface-level feature comparison. It researches each competitor’s full capabilities, pricing, and positioning, then maps where your product leads, where competitors have genuine advantages, and where uncovered market gaps exist.
The pre-mortem borrows Gary Klein’s methodology: assume the product has already launched and failed twelve months later. A forensic investigator works backward to identify root causes across three failure dimensions — a core experience flaw, a trust or security blind spot, and a target audience assumption error. Each root cause comes with early warning signals and mitigation strategies.
The PR/FAQ method, inspired by Amazon’s practice, drafts the best possible press release for your product and then adversarially critiques it in a separate pass. The draft and the critique happen in isolated invocations to prevent the natural tendency to rubber-stamp your own work. If the press release is unconvincing, the concept likely has clarity problems.
These stress tests are read-only on the product concept. They critique and recommend, but they never modify your vision directly. A separate concept review step consolidates all findings, presents them for your approval, and only then applies the changes you accept. This keeps you in control while still surfacing blind spots you might have missed on your own.
From Prototype to Feature Backlog
The second half of the pipeline bridges discovery and development. After your concept and architecture are defined, the pipeline can scaffold a working project skeleton, validate critical technical risks through focused spikes, explore visual directions, and build static or interactive prototypes with iterative review cycles.
The final step — feature extraction — walks through all upstream artifacts and produces a prioritized feature backlog. Each feature carries the context it needs: a description, the user journey it supports, UI behavior notes, and acceptance criteria. This backlog feeds directly into the Arness Code development plugin, creating a structured handoff with no manual translation required.
Conclusion
Not every project needs every step. The pipeline is opt-in at every stage, and many teams will skip stress testing entirely for their first pass. But having the option to rigorously test assumptions before writing production code can surface problems that are cheap to fix now and expensive to discover later. That is the modest goal: not to guarantee success, but to catch the avoidable failures early. Arness Spark is open source and available on GitHub.