What I'd Build Earlier: Design Lessons from Series B to Unicorn

In 2016 I joined a team in Palo Alto, CA, working on a smart home product: a new development in WiFi and an entire platform for new software, hardware and product experiences. I was there about eight years. In the back half I directed the design team across brand and product. The scope:

• Around eight web or mobile app products.
• Some hardware and industrial design.
• Users that eventually spanned homes and consumers, small business and office owners, and ISP and communications providers.

But we started with one major feature on one consumer product. Looking back, the first release set the foundation for years.

Growth moves like a river

Stand in a river moving only a few miles per hour and you feel the steady force of it. Drop something in and it floats away beyond your ability to undo it, so you'd better anchor into a footing that can handle the next surprise.

A venture-backed organization moves with that kind of power. Talented, motivated people working in parallel, constant milestones, lots of excitement and gratification. And like the river, if a solution wasn't tightened down the first time, there may not be a chance to fix it for years. Despite all the agile frameworks, there is simply too much new work to grab.

If a solution wasn't tightened down the first time, there may not be a chance to fix it for years.

User relationships grew in several ways

Beta group

Our beta testers stayed with us for years. Beta is where we shipped products that were ready for prime time in quality but benefited from soak time in real-world environments. We could also run user interviews, test prototypes and gather usage metrics with this group.

B2B clients

Our B2B clients could make requests more directly, for features that fixed their bottom line.

Product and brand

This was the most exciting touchpoint. It's less measurable, often more thrilling, and tied to the psychology of aesthetics, copy, user flows, and chances to participate and give feedback to our algorithms. It's the sum of every touchpoint, with emotional awareness, across a user's journey and daily life with our product and brand.

The brand functions mostly as our voice to the consumer, and the product should feel to the user like their communication back to us.

The way I think about it, the brand functions mostly as our voice to the consumer, and the product (app features, email CTAs, usage analytics, voting on features, support team communications) should feel to the user like their communication back to us, in response. Hopefully it reads as one continuous dialogue.

From a product design standpoint, that dialogue can give users a sense of participating in the progress of an ever-improving experience. It's a sense of being heard.

Nothing stays the same when you scale

All of these evolved constantly over months and years:

• Product requirements
• Team collaboration
• Team size
• Processes

The changes ranged from how you request a new vendor to how much influence I could have on change. Resistance comes from tasks diluted horizontally and, especially, from the structural hardening of front-end and back-end code, APIs and controllers. Developer time has to be fought for and defended.

The early days of an organization are a smash-and-lunge-forward effort, all hours of day and night. Once the company reaches the 1B/2B size (unicorn territory), the things built in those first few years become defined starting points for springboarding into strategic paths.

Build what you'll thank yourself for later

If I did it again, I'd mindfully build our springboard through that Series B to D phase: systems, processes, and insisting on quality for the first release. Those foundations barely budge, because of the physics of team capacity over time. Do yourself a lot of favors and build things you'll thank yourself for.

Do yourself a lot of favors and build things you'll thank yourself for.

The volume of deliverables rushing into the world was incredible. What had to ship in parallel:

• The product needs flows, specs, documentation, dependencies, and a UX and UI built on systems: color, accessibility, atomic modularity, type styles, and responsiveness across OS and device.
• The brand needs a voice in the product, visually and conversationally. We made brand guides covering color, tone, voice, inspiration and instruction for different audiences. All of it feeds consumer and B2B relationships through email, websites, social media, blogs, interviews, awards and community building.

Teams of people were eager to push these assets forward and do their roles. Swing, connect, and keep moving. That was the way.

The code base is your customer

Designers should treat the code base as a significant part of feature design. We design user experience and relationship, and indirectly we design the developers' code decisions. When designers think about atomic design components that stack, combine and scale, they should apply the same concept to the structures developers will build to deliver those UX and UI flows and content.

Designers should treat the code base as a significant part of feature design.

Two things that always change: the people and the strategy

The people change

This part can be a bummer. People on the team change, sometimes in heartwrenching ways. The bonds in this kind of work are hard-fought, like companions in battle. Changes in people also mean logistical and process evolution to keep up with.

The business finds new strategy and leadership adjusts focus

It takes the same adaptive demeanor as everything else as we adjust to scale in the right directions. As the organization scales, the team has to iron out code, process, documentation and planning wrinkles that can accumulate into a morass. It also means continuing to build layers of job titles and decisions.

Closing

These are a few of the themes from my eight-year journey with a venture-backed startup in the heart of Silicon Valley, riding, and helping build, the wave from Series B to a unicorn-level valuation. What a ride.

Next: if the code-base idea resonated, Designing for Product Opportunities shows how my team found quality gains in the work already in motion. For the thinking behind this, see Product thinking.