Codes & Standards Programs as Products?

Rethinking How We Design Public Programs

Since the last CPUC EM&V stakeholder meeting, something has been quietly marinating in my brain from the Codes & Standards presentation— and now it’s all I can see. What I remembered someone said:

What if Codes & Standards programs should be designed more like products?

At first, I tried to simplify the distinction. A product has a beginning and an end. A program doesn’t.

Easy enough.

But the more I think about it. It doesn’t quite feel enough or clicked it for me yet. And so, I went down the usual rabbit hole — searching, reading, thinking — and landed on a more useful distinction:

• Product design focuses on user experience
• Program design focuses on systems of coordinated interventions

A program provides levers and doesn’t try to control the entire ecosystem. A product is how people actually experience that system.

Think of it this way:

• In a transportation system, a program may incentivize riders to use public transit than individual cars by taking the funds from parking passes revenue and support the public transit system.
• An easy-to-use train app or ticketing system is a product.

One tries to influence the ecosystem. The other determines whether anyone can actually use it.

POV: Program Managers be like…

What Do Strong Programs Look Like?

When I think about strong programs in the last 10–20 years, a few stand out:

• Energy Star
• Apple App Store
• Open Government Data initiatives

These programs feel very different on the surface — but structurally, they share something important. A strong program:

1. Creates the conditions for many products to emerge
2. Maintains a strong gravitational center (clear governance, consistent rules)
3. Enables feedback loops that actually influence behavior

That last point is a bonus.

With the accessibility and abundance of data in our modern world, most programs collect data. Strong programs use data to adapt themselves. They don’t just report metrics — they feed insights back into the system, shaping future products, decisions, and behaviors. This helps them to autocorrect or to scale without falling apart.

Where Does the Energy Codes Programs Fit?

Now let’s bring this back to something more concrete: California’s Title 24 Energy Code.

Is it a program or a product?

At a high level, the Energy Codes ecosystem looks like this:

• The California Energy Commission (CEC) sets new standards every 3 years, often adding stringency via new measures or optimizing how compliance occurs
• Local jurisdictions (AHJs) enforce compliance
• Designers, contractors, and verifiers implement requirements

Compliance is demonstrated through:

• Prescriptive or performance paths
• Documentation (forms)
• Third-party verification

Support comes from multiple layers:

• Training and outreach (e.g., EnergyCodeACE, CPUC funds programs through IOUs, RENs, CCAs for C&S support)
• Some Outreach & Education, Software Support (Vendors, CEC)
• Market actors executing in practice
• Manufacturers provide products that meet minimum code requirements

This is a decentralized system. Like how our cities and local governments are built from.

The Products of the Energy Code

If you zoom in, the Energy Code ecosystem isn’t just regulations because it’s not like “you shall do this”. It’s also “you shall do what performs well”. To determine that and to verify that, you need products. It produces products.

It isn’t just an intervention that forces the masses to do the right thing because it becomes the products that touches many market actors to interact with and utilize in order to produce an acceptable building to California’s society.

Some of the most important ones:

• Energy modeling tools or compliance software
• Verification protocols like forms

And especially… forms. Yes — forms. Everyone hates them because they do feel intimidating or even overwhelming to the untrained eyes.

Digression — Much of the efforts of compliance software in standardizing many inputs is to enable streamlining, but it also creates by product where “compliance modeling doesn’t mean performance modeling”. To a normal person, that doesn’t mean anything. To an energy modeler, it means you prove to your client that they have or are or are going to buy the best design because true performance lies in another energy model — completely separate from the compliance model. Sometimes, it’s a necessary evil that you’d do both.

Back to forms. Yes — forms. Forms are not just paperwork. They are data products that:

• Touch nearly every market actor
• Structure how compliance is demonstrated
• Influence design decisions (especially if you have a target of x% above code)
• Create entire workflows (and industries) for design team who works on California projects

In many ways, these products are the interface to the program. From ongoing conversations with building departments and other market actors — and from my own time working within the system— I question how you can design any program if the program performance is largely a function of how well these primary products perform in practice.

Which raises a deeper question:

Could the system survive without the core products?

And if not —

Are we designing critical “programs” that are more like products intentionally as products?

If the core products are weak, then implementation of external programs will compensate by adding more training, more guidance, more oversight, and more documentation. This doesn’t fix the issue — it shifts the cognitive and operational burden onto the end users. Overtime, this creates fatigue, workarounds, and inconsistent compliance.

We’re staying Positive Pancy.

Dare I ask, have we put the appropriate resources toward the core products?

The Cost Problem (and Why It Matters)

At some point, every product and program conversation lands in the same place:

Cost.

Right now, across both federal and state conversations, two themes dominate:

• Streamlining
• Affordability

In Codes & Standards, cost is not straightforward.

Incremental cost:

• Isn’t static
• Isn’t uniform across the State
• Isn’t fully observable or transparent

It’s a distribution hidden inside a competitive market. There’s an entire discipline in construction just to estimate it.

So, when we ask:

“Is this cost-effective?”

It’s easy to disclaim that we are working with a lot of incomplete data and a lot of assumptions. It’s easy to assume people make mistakes.

To prove anything or to do this right, it rigorously takes a lot of resources and time — not a natural investment. Sometimes, we trust the experts to take the risks and determine what is good enough. And when time isn’t available, we fall back on something else: what’s mostly agreeable. Until you have to prove it to someone new.

Therefore, I’m not sure really sure how entirely productive it is to argue about cost scientifically before it becomes a political debate. I can be wrong. You can be wrong. We can both be wrong. Does it matter because the public good value doesn’t make it to the consumer while we’re busy trying to prove a point?

The technical debts got interests! In the form of fatigue and debates.

Beyond the Textbook

This is where I think Codes & Standards programs hit a wall.

If we rely only on textbook methods:

• We move too slowly
• We oversimplify complex systems

But if we abandon rigor:

• We lose credibility

We lose either way. So, the real challenge is: How do we operate scientifically in a system full of ambiguity?

This is where a product mindset might help.

Because product design:

• embraces iteration
• relies on feedback loops
• prioritizes real-world usage over theoretical completeness

It doesn’t wait for perfect information. It learns by doing. So, I get it. Why product design thinking makes sense as the next step. However, every program should really evaluate whether they behave more like a program or a product. Even if you have a program in your name — that doesn’t mean you’re not a product.

Beyond that, there are scale and equity considerations. To me, equity means not unintentionally creating hardship for even a small group. We need to really stand by the tradeoffs that we accept today because they become the conditions people inherit tomorrow.

I’ve seen this across different countries:

• Some optimize purely for cost
• Others invest in durability and long-term livability

And the difference shows — not just in buildings, but in communities.

Final Thoughts: A Different Kind of Question

Maybe the real question isn’t: How do we make compliance cheaper or faster with product thinking vice program thinking?

But: What kind of world are we trying to build — and are our programs (interventions) and products (user experience) designed to support that?

Because even after a disaster — even after a tsunami — some buildings will still stand. And those structures will define what’s possible next for the generation that remains.

— — —

Thanks for reading this far. I hope it was slightly entertaining. I’ve been leaning a bit philosophical lately, but more practical posts are coming — things like mini vibe code projects, explore, and learn from, especially in data analytics arena (where I also count my-end-user-experience-with-AI). Aiming for a post a month.

If you’d like to see that, clap, comment, and/or subscribe!