•Weekly Learning

From Building a Solution to Validating a Product

I stopped building for a moment and applied Product Discovery to CAS. The biggest lesson: a working solution proves capability, not that a product matters.

I had spent considerable time building CAS (Continuous Architecture System) and had a reasonably clear view of what it could do. What I hadn’t done was systematically challenge something more fundamental:

“Do I actually know whether I’ve built a product that solves a meaningful problem for someone else?”

That question changed the nature of the work.

Instead of adding more capabilities, I stepped back and ran a Product Discovery exercise across the problem, value proposition, ideal customer profile (ICP), personas, buying centre, differentiation, narrative, and evidence.

The result wasn’t a finished validation. It was something far more useful: a much clearer product hypothesis, a better understanding of what I still don’t know, and a conscious decision about what not to build yet.

The Uncomfortable Question

When building something yourself, it is surprisingly easy to slide between three distinct statements without noticing:

  1. “This is technically possible.” (Demonstrated by working implementation)
  2. “This is useful.” (Requires understanding workflows and friction)
  3. “Someone would value this enough to adopt it.” (Requires evidence from outside your own context)

They are not the same thing.

Product Discovery forced me to disentangle them. The objective was not to make CAS sound better—it was to systematically challenge my own assumptions.

Starting with the Problem

The first step was to stop describing CAS as a solution and instead describe the problem independently of any tooling.

The underlying issue is a persistent gap between architectural knowledge and the workflows where technology is actually created and changed. Architecture guidance can exist in documents, repositories, architecture tools, and people’s heads, while implementation marches forward elsewhere.

That creates a familiar, reactive pattern:

Architecture Knowledge
        ↓
Documentation / Repositories / Conversations
        ↓
    [ THE GAP ]
        ↓
Development Workflows
        ↓
Architecture Drift
        ↓
Detection
        ↓
Correction

This reframing shifted the question from:

to:

That gave the rest of the discovery work a concrete baseline to test against.

Noticing What Was Missing: The Prevent Dimension

The most valuable moment in the discovery wasn’t uncovering a new capability—it was noticing that an existing one had disappeared from my own value assessment.

Initial discussions naturally concentrated on detecting and correcting architecture drift after code is written. But the original CAS premise had always included something earlier: preventing bad structure from being created in the first place.

I hadn’t carried that Prevent dimension strongly enough into the product-value assessment. Once I noticed the omission, I stopped and corrected the model:

┌────────────────────────────────────────────────────────┐
│ PREVENT                                                │
│ Known Rules + Patterns → AI-Assisted Implementation   │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ GOVERN                                                 │
│ Reuse (low friction) vs Novelty (human judgement)      │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ DETECT & CORRECT                                       │
│ Catch what still slips through                         │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ LEARN                                                  │
│ Reusable Architecture Knowledge ───► Feeds into PREVENT│
└────────────────────────────────────────────────────────┘

The key insight wasn’t simply that CAS has a Prevent capability. It was that Product Discovery exposed a gap between what I had built and how I was communicating its value.

Discovery isn’t just documenting what you already believe—it actively reshapes your understanding of the product.

Proportionate Governance: Automate the Known, Escalate the Novel

The Prevent flow led to another useful hypothesis around governance: not every implementation change requires the same amount of human intervention.

                  Implementation Intent
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
[ Existing Approved Pattern ]   [ Architectural Novelty ]
             │                           │
       Pattern Reuse                 ADR Path
             │                           │
             ▼                           ▼
  Automated / Low-Friction       Human Judgement &
         Governance                  Approval

This creates a proportionate approach: Automate known paths. Escalate meaningful novelty.

Whether organisations value this enough to adopt it remains a hypothesis—but discovery made the hypothesis explicit enough to test.

From Explaining Value to Proving Value

This led to another uncomfortable question:

But how would I actually prove it?

There is currently no real-world baseline for the Prevent flow: no before-and-after customer evidence and no validated set of metrics.

Peter Drucker’s famous adage came to mind: “If you can’t measure it, you can’t improve it.” But the lesson here wasn’t “rush to build a metrics subsystem.” It was the exact opposite: I don’t want to build measurement infrastructure around metrics I’ve invented in isolation.

The right sequence is:

1. Talk to Practitioners      → Understand what value matters in their workflow
2. Define Meaningful Outcomes  → Target observable, relevant results
3. Establish a Baseline        → Measure the status quo before intervention
4. Run a Proof-of-Value        → Exercise the flow in a real environment
5. Measure the Change          → Evaluate the observed difference

Current Prevent metrics are candidate measures, not validated evidence. That distinction matters.

Who Actually Matters? Mapping the Stakeholders

Another insight was that the word “customer” is too imprecise when planning validation. The person feeling the pain isn’t necessarily the person buying or championing the solution.

Role Perspective Core Question
Practitioner / User “I experience this problem daily.” Does this make my workflow smoother or more painful?
Champion / Influencer “This could improve how we operate.” Can this scale good architecture across our teams?
Economic Buyer “This is worth funding.” Does this reduce risk, rework, or delivery cost?

For initial validation, the most critical conversations are with external practitioners—engineers and architects who experience the drift problem first-hand.

The objective is not to ask: “Would you buy CAS?”
The objective is to ask:

“Do you recognise this problem in your day-to-day workflow, how do you handle it today, and would this approach make a meaningful difference?”

What I Deliberately Didn’t Build

One of the healthiest outcomes of this exercise was deciding what not to build.

There is no shortage of things I could add:

However, the biggest uncertainty is no longer “Can I build this?”—it is “Does this matter to people outside my own context?”

Adding more code doesn’t answer that question. In fact, it often serves as a comfortable distraction from answering it.

The next increment must be evidence, not expansion.

So what did all of this actually leave me with?

A clearer CAS hypothesis, but more importantly a much clearer distinction between what I know, what I believe, and what I still need to prove.

Where the Pieces Stand

Clarity should not be confused with validation. Recognizing what is still missing gives the next phase its exact focus.

Key Lessons Learned

  1. A working solution is not a validated product
    Building proves feasibility. It does not prove that the problem is urgent, that the proposed value is compelling, or that someone will adopt it.

  2. Product Discovery challenges the builder
    Discovery is not a post-hoc documentation exercise. Done honestly, it exposes blind spots in your own thinking (like the temporary disappearance of Prevent).

  3. Describe the problem before defending the solution
    Separating the problem from the tool makes it easier to evaluate whether you are solving a genuine point of friction.

  4. Don’t confuse polite interest with evidence
    “I like the idea” is weak feedback. “We deal with this every week, here is our current workaround, and I’d like to test this on our codebase” is actionable evidence.

  5. Don’t measure everything just because you can
    Discover what outcomes matter to practitioners first. Then instrument the metrics that reflect those outcomes.

  6. Know when to stop building
    When code provides diminishing learning returns, stop expanding functionality and start gathering external evidence.

Where This Leaves Me

CAS is in a much stronger position today than before the Product Discovery exercise—not because it has more features, but because the hypothesis is explicit, grounded, and testable.

The roadmap is straightforward:

Demonstrate → Validate → Baseline → Measure → Learn

The next step is to take this hypothesis outside my own context: talk to practitioners experiencing architecture drift, identify a suitable real-world use case, and run a Proof-of-Value.

Only then will the next round of product development begin.

Note:

← Back to Learnings