Design systems result in tangible, often gorgeous outputs like a living style guide or array of design assets. When getting started, it feels like a project, evolving from early concepts to a celebrated (first) release of those assets for other people to use.

    <div class="escom-pull-quote escom-pull-quote--light">
        <div class="escom-pull-quote__the-quote">
            “We did it! We launched a guide. Mission accomplished.”
        </div>


    </div>

Celebration is justified, no doubt. You did achieve something, and making useful things for others feels great. However, be careful, because you’ve not yet realized actual business value. An enterprise realizes that value — actual cohesive experiences, realized efficiencies in development — when other teams pick up the system and ship it in their product.

    <div class="escom-pull-quote escom-pull-quote--light">
        <div class="escom-pull-quote__the-quote">
            A design system’s value is realized when products ship features using parts from the system.
        </div>


    </div>

In those quieting days following a system launch, a systems team starts to realize “What do we do now?” Worse, they (and those managing their time) think “Now we can go back to doing what we were doing before.” There’s no funded persistence. No ongoing commitment. Questions of “Will it last?” start to emerge in thoughts and conversations.

Changing from a Project to Product Mindset

Focusing on style guide delivery as the climax is the wrong story to tell. A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.

— Nathan Curtis (@nathanacurtis) October 21, 2015

Thinking as a product changes perspective: it’s now not about us, it’s about serving our customers. How do we do that? Applying well-established approaches for product management and product marketing is a great start. Once recognized, a system team can adopt familiar and predictable tools and terminology to help them succeed.

Additionally, the “system=product” model also helps team composed of product designers and developers to recognize:

    <div class="escom-pull-quote escom-pull-quote--light">
        <div class="escom-pull-quote__the-quote">
            Design systems isn’t just product design and development. There’s product management and marketing too. We’re not good at that, nor do we want to be.
        </div>


    </div>

They may lack the talent for “product management stuff” and may not have the taste for it. Now self aware, they can choose to learn and apply such skills to fill the gap or find someone else who can.

When I meet a design system team for the first time, I don’t start with “Can you show me your awesome living style guide?” It is awesome, they are very proud of it, and I love learning about it. But such demos rest in the shadow of a more essential understanding of their system’s – their PRODUCT’s – marketing and management approach.

Spreading Your System to Their Products = Product Marketing

To have a product means knowing and serving your market:

• What products use or may use your system? Regardless of your system’s reach, know your target market. You need a strong sense who you serve, their relative priority in influencing your work, and where each is headed.
• When will they ship using the system? It’s very rare for an entire enterprise to pause individual work in order to launch together using a system. Instead, discussing how a design system fits is a product-by-product endeavor that seeps into a their roadmaps, sprint planning, and story requirements.
• How will you align with them? You may get to know product managers just as much or more than developers. A system’s product manager (if you have one by name or responsibility) is knowledgable of or even participates in strategic activities like quarterly release planning across a portfolio. That said, effective alignment with product managers usually results in “alignment” meetings as well as coffees, lunches, and hallway conversations.
• How do you promote and sell to them? Your marketing, which often involve compelling demos and presentations, effective documentation, regular communications (such as email updates and blogs), onboarding activity, and training.
• What will each type of customer need from your system? There’s a way to disarm the tension adopters feel when intimidated by the system’s vast scale or imperfect goodness-of-fit. Most systems contain areas like color palettes, icons sets, certain UI patterns, and more (I call ’em subsystems) that aren’t universally relevant. Everything isn’t always meant for everybody. So how can you succinctly tell each what’s most helpful for them?

Sustaining Your System = Product Management

Imagine what your VP thinks:

    <div class="escom-pull-quote escom-pull-quote--light">
        <div class="escom-pull-quote__the-quote">
            Should I fund 2.5 full time resources to work on a style guide full time if they can’t tell me what they’ll do in the next three months? They can barely muster a coherent definition of what they’ll do in the next two weeks. It seems everyone is doing everything and nobody is responsible for anything.
        </div>


    </div>

For a design system to thrive and survive, it needs a sufficient level of management.

• Who’s making the decisions? Modern design systems have a product manager who’s driving decisions, assertively aligning with partners, and serving as the go-to person
• Who’s doing the work? Sustaining a design system can involve a significant amount of design, development, writing, and other work done by people committed (at least partially, > 4hr/week) to the endeavor.
• Who’s paying for it? It’s near impossible for a system to survive long term without a sponsor deliberately providing budget in the form of properly allocated time.
• What are each of you working on right now and where do you record and prioritize things you might work on later? Yup, time for task management, which many high-performing teams increasingly formalize into a backlog over sprints using tools like Github and Jira.
• What can your customers (products using the system) expect over the next 6–12 months? Don’t discount the power of an effective, concisely communicated system roadmap. It generates awareness, discussion, faith that you’ve got your act together, and trust that what you do provides for what they need.

Enterprises are waking up to this, forming permanent positions, with titles at Salesforce and hiring product managers specifically for systems teams at companies like Etsy and Google. If you don’t have thoughtful, reasoned answers for the questions above, how can you expect someone to fund your effort?