Mike Carbone

June 14th marked the four month anniversary of incorporating Hermae.

So much has happened since my initial tweet back in January. I never would've predicted that this small experiment would lead to demos with Puma, Siemens, Carlsberg, Color.com, Jio, C.H. Robinson, ADT, Mercury, and so many more. Crazy!

All startups are bets. Our original bet was that an intelligent assistant trained on a company's design system would drive efficiency improvements and help design system teams improve adoption across their organization.

While this may or may not be true, the business opportunity around this bet has changed in substantial ways since January. Through our conversations with prospective customers, we've been witnessing first-hand the diminishing demand of such a product.

AI Has Changed

The landscape has evolved dramatically since January. AI has become mainstream and with that, we lost our edge of providing a new "wow" experience. The impressiveness of our demo has declined over time as people have become more familiar with the technology, and with this maturation, incumbent tools like GitHub Copilot have grown in market dominance.

Our posturing as a privacy-focused alternative has weakened as teams have become more comfortable using mainstream AI products in their workflows. Similarly, building tailored experiences like the ones we offer has also been made easier with OpenAI's Assistant API. As the accessibility to the technology improved, our defensibility weakened.

Designers Not Included

Selling to design system teams is difficult. They are notoriously under-invested and the persona of the team lead is inconsistent. Sometimes it's an engineer, sometimes it's a designer, and sometimes it's a PM who doesn't understand either. With our custom implementation approach, we'd usually need to talk to an engineer to learn more about their architecture so that we may perform the training and supply our product. If the team was led by a designer, this point would instantly fall flat and navigating these conversations would instantly stifle sales progress. At the same time, the product was not built for designers, and they would leave disappointed if they were on the call. As it turns out, if the product doesn't serve everyone on the team that's looking to buy, it won't convert to a sale.

No One-Click Solution

With the difficulty of navigating those conversations, it would be amazing if we could offer a one-click solution to teams with a self-serve model. Unfortunately, all design system documentation sources are different. Some use Storybook, some use Figma, and many build their own websites. This makes ingesting the documentation for training a tricky process that can't be fully automated. So, that leads us back to the custom experience sales process. Too much friction.

Through our sales conversations, those three points have made themselves clear as the primary blockers to continuing purchasing discussions. Those three points are unchangeable. But something has to change if Hermae is going to survive: the product or the business.

AKA, time for a pivot. That's what I'm exploring now.

I've met about a hundred different design system teams since starting in the industry. Through work, social outings, through Arcade selling design token management software and now through Hermae selling design system intelligence software.

Through selling, we have to start with a discovery phase, where we learn as much as we can about our potential customer. These are almost always design system teams, and even today, I'm shocked by how unique each of these teams are. Everyone has the same job titles, but each team is in a drastically different position than the next. Some are in a great position to succeed, but believe it or not, most aren't. Perhaps that's why they come to me.

After years of these discovery calls, I've noticed a few patterns that the most successful teams employ. They might not call it by the same term, but they express the same sentiments.

Below I outline a methodology derived from my learnings over the years, a methodology that I believe fosters a powerful design system team (or frontend infrastructure, frontend platform, foundations, whatever you call it...).

I present: EGOS. Efficiency, Guidance, Observability, and Synchronization. The very best teams exemplify these qualities. I believe by following these four pillars as closely as possible, any team, no matter what position they're in, can transform into a powerhouse unit within their organization.

Efficiency

A good system team remembers that their first priority is to enable organizational efficiency. They are the stewards of product craftsmanship, consistency, and speed, and they provide the tools to accomplish those goals. They avoid unnecessary complexity. They enable an organization to scale rapidly with confidence. They implement solutions and their work does not cause headaches for others.

Guidance

A good system team understands they're leaders in the organization. They implement foundational patterns and best practices to guide the rest of the team. They strive to deliver a remarkable experience for others using the system. This includes excellence in onboarding, instruction, documentation, peer-programming, supplemental material, and mentoring.

Observability

A good system team knows that their product is not perfect, and their work is never finished. They know what is being used and what is not being used. They have tools to know where and what to optimize, where the system succeeds and where the system fails. They collect data and generate reports on different metrics that define system health and performance. They quantitatively understand how their system impacts the business and organization as a whole, and understand how to use this information to improve the system.

Synchronization

A good system team knows that their work is not performed in a silo, but is a coordinated effort that supports multiple entities across an organization. They know their system will evolve over time, and it's their responsibility to keep people and output in sync with their system. They communicate regularly about system efforts and changes. Synchronization between design and engineering is a top priority, with neither outpacing the other.

Does your team follow these principles? Is there something important you think I'm missing? Let me know.

Before writing code, before shipping anything, before testing the market, it's crucial to find your "why."

This "why" will guide you to building a great product, it'll inform your marketing strategy, and it'll isolate the core product value that should be sold to prospective customers. And eventually, the why will help you ship new products and features.

Far too often, we start with "what". This is natural because ideas are almost always "what"s, and very rarely "why"s. Many times we fail to even consider why we're building the thing we're building.

So what's a good "why"? A why is the purpose your thing exists. It's the mission you're striving to accomplish, and the problem your "what" solves.

A good "why" is specific. A good "why" justifies your product's existence. And when you start with your "why", it grabs those who believe the same thing as you. It pulls them in. And it makes them believe that your "what" is the product manifestation for that "why". What's the point of your product? Your "why" is the point.

"We built ABC so that you can do XYZ" is a bad start. So is "XYZ innovation makes your life easier." The problem is the phrasing: starting with "what", and you're expecting your audience to implicitly understand the "why." In an age with novelty everywhere, people have become trained to dismiss new "what"s instinctively. We first need to tell them why they should care.

(By the way, "makes [your job, your life, etc.] easier" is not compelling. Who cares? Go deeper.)

Instead, start with "We believe..." This way you're forced to start with "why", and it pulls people in, ears open. It's captivating.

"We believe XYZ is true, so we built ABC."

Now, if someone else also believes XYZ is true, your "what" becomes an easy sell. You create evangelists for your "what." And if they don't believe XYZ is true, then they shouldn't care about your "what" anyways. They're not your target audience.

If you choose a good "why", it can guide your product roadmap, your marketing strategy, sales process, branding, and so much more about your "what." And, perhaps most importantly, it makes you stick out from the crowd. Few people find a good "why."

Start with "why" so that you have an opportunity to share your "what."

(If you haven't seen it, I highly recommend watching Simon Sinek's Golden Circle TED talk)

29 days ago, I launched Hermae.

To say those 29 days have been a light-speed roller coaster would be an understatement. I launched a new website (twice), conducted demos for billion-dollar companies, introduced conversational memory to the assistant, trained on a public design system, created a new demo page, talked to investors, developed sales processes, a pricing model, created new logos, and even began compliance certifications.

What started as a fun experiment blossomed into a fireball. I can't believe that it hasn't even been a full month since launch.

My favorite part about all of this isn't the tech or accolades, though. It's the people. Since launching this project, I've been able to meaningfully connect with so many old friends, past coworkers, and even strangers who I now consider friends. That, to me, is what makes this so much fun. The support has been incredible.

I can't wait to see what happens next month. Let's make some money.

I have a few active projects. I'm working on Deco, I'm tinkering on Cortelou (haven't talked about this one yet), as well as Interweave and this personal website. All while searching for a new job.

Yet, today I had a new idea. And I built a rough version of it.

It's tough working on so many different things concurrently. I'm extremely focused when I work, which means focus is a limited resource that I spend sparingly. That also means that projects not in the spotlight will not get the attention they deserve.

At the same time, new ideas are always flowing in, filled with all of the excitement that are inherent with new ideas: potential riches, respect, and regard. We see new ideas explode overnight all the time. Maybe this new one is the one?

Unsurprisingly, this creates a natural tension in my life between new ideas and old ideas. The prevailing question seems to be: how do we know when to switch focus from an old idea to a new one? Sometimes businesses take years to develop. Sometimes the business would never work, no matter how long we spent on it. And sometimes, maybe it was just passion-driven, and never was meant to be a business.

I don't have an answer to the question of when to switch. Before the ideas I'm working on now, it was all about BarHop, Gatsby, Arcade, Pluto, HotTub, and even more before that. Switching focus was not always easy, sometimes some are harder than others.

In the end, I do what feels right. I produce my best work when I enjoy it, and if it's a new idea, who cares? Nobody really uses what I build anyways, so might as well have fun building it.

I'm reminded of a post I wrote a few years ago: Living For The Journey. Achieving riches, respect and regard may not be all that it's cracked up to be.

Good advice, I think I'll take it.