Web experiences during the age of LLMs

Originally posted on Proof of Concept

My experience with the World Wide Web was like growing up with a childhood friend. The early days of building personal websites were what some would call Web 1.0—the static web. I’d observe my brother building HTML websites with Notepad, inline styles, and all, then publish them to Geocities. The Social Web (Web 2.0) brought user-generated content, web applications, and social networks. Because of these new technologies, people deviated arom personal websites in favor of simple about.me pages, popular blogging platforms, and exclusively publishing on Social Networks like Facebook.

We’re in the midst of Web 3.0—whatever you want to call it. Blockchain technologies and decentralization are capabilities often associated with this phase. However, Artificial Intelligence and Machine Learning are included i this era as well Let’s focus only on the implications of what AI/ML brings to the new web, particularly Large Language Models (LLMs). Because of its capabilities of data, fine-tuning, and generative capabilities, there are two likely scenarios of how LLMs can be used to create web experiences.

Scenario 1: website builders equip themselves with AI capabilities: Products built for making websites will add AI capabilities to their product offerings. Every SaaS product seems to be doing this now to make their product Copilot or Generative AI-ready.

Scenario 2: LLMs build websites: With experiences like Designer GPT and Grimoire, empowering LLMs to build websites is already possible today.
With products like Designer GPT, LLMs have generate websites for people.

I believer Scenario 2 will be adopted quicker than Scenario 1. In fact, glimpses of it is happening already. When The Browser Company launched the iOS app, they created a unique experience for the form factor. Instead of yet another browser, they created an experience focused on search. One of the key features is, “Browser For Me,” which has the app construct a simple web experience based on the search prompt. Perplexity recently launched Perplexity Pages, which builds a wiki-like website based on your searches.

Though I don’t think it makes sense for Arc and Perplexity to have customization (a different topic), you can see how other products can take the concept of “build it for me” for web experiences generated by prompts.

There are still bottlenecks that need to be solved to have generative websites be more widely adopted. There are a few core areas in building and maintaining a web experience:

Content: Copywriting, creative assets, and information architecture
Design: Layout, style, and aesthetics
Tech: Frameworks, hosting services, and how the site is published/deployed
Management: Maintenance, SEO, and other growth levers

As I say to Design Systems teams: it’s easy to generate something net new than it is to maintain it. This is a similar challenge with websites generated by AI. It gives you a first version to work from but you still need to maintain and host it.

What LLM-powered site building looks like

I believe there will be a lot of people in the world who will continue hand-crafting sites (myself included) because we have the ability and desire to do so. Let’s acknowledge that while speculating what a site-building experience looks like when it is more derived from a generative prompt.

Good web design starts with content—something the majority of people can create, on the other hand, is a skill that needs to be developed—one people might not bother to learn.

From structure-based design to content-based design

Authoring experiences will move closer to distribution

Professionals are always going to want their own space for their power tools. However, the rest of people often prefer convenience: not having to learn something new, reducing friction, and anything else that accelerates the job to be done. What we’ll see is authoring experiences more infused with publishing tools. For example, if a person is writing a blog post, they might generate creative assets, adjust layouts, and make stylistic changes in the content management system vs. an external authoring tool like Figma—faster editing that leads to faster publishing.

Settings and profiles facilitated by AI Agents

My bet is AI tooling not going to be a monolithic LLM—a god-like AGI. Instead, it’s having a hive of tiny LLMs interacting with one another to collaborate. Take the example of making changes to a web host provider. Instead of logging into Dreamhost and upgrading hosting services, there might be a chat service I build or interface setting I can change to invoke the changes on the hosting services.

A spectrum of customization continues to exist

Ben South said it well: “The average person doesn’t want to customize their software—they want the best defaults.” Even before AI became the talk of the town, the spectrum of customization exists in building web experiences and other types of publishing, with the majority of people simply wanting a thing. LLMs are decent at building these now and the workflows to maintain and publish will get there.

There will always be room for people who care about hand-crafting experiences with maximum customization. My belief for AI in tooling is the capabilities should always be lowering the floor, not the ceiling Elegant AI-powered experiences help people without the skills to do things they only imagined being able to do. While doing that, it enhances and makes work more efficient such as fixing random syntaxes and nuances we find frustrating. Design and building websites will be content-focused with Dynamic Interfaces doing the heavy lifting, so we can focus on curation and publishing.

My aunt and two uncles visiting today. I used to stay at their homes all the time as a kid and college student. Now I get to return the favor in hosting them. One thing I’ve learned being a child of refugees is safe shelter is such a gift.

My product prioritization framework

Originally posted on Proof of Concept

People fantasize about the ideal experience of working on product—blue sky 0-to-1 work. The reality is this only possible when starting a new company. From that moment on, you are accruing debt: technical, design, and business debt. The reality of joining a company to lead product is the equivalent of getting on a train at its full speed. You can’t simply hit the brakes because so many dependencies are in motion. I’ll share with you my framework for product prioritization and triage when starting somewhere with a lot of existing momentum.

Product frameworks

Like JavaScript libraries and Land Before Time sequels, there are an abundant amount of product frameworks that exists: MoSCoW, Kano Model, RICE Scoring, Buy a Feature, Eisenhower Matrix, Hypothesis-Driven Development, etc. Though these frameworks are effective and best practices, it can be overwhelming and lead to unnecessary debate on which to use. My hypothesis is the more mature a framework is it feels like a process decision vs. getting value out of it.

Because of this, it feels simpler to use a framework when you make one up. Even with a non-standard name it feels less of a weight in adopting it. The product prioritization framework I like to run with people focuses on four core areas: Invest, Ignore, De-emphasize, and Deprecate.

The goal of this framework is to orient the moving train and get people oriented in the right direction. The intention of it is to be ephemeral and provide a triage list of priorities. I’ll break down the four areas in more detail.

Invest

Whether it’s product or people, I’m a believer of doubling down on strengths and what’s working. Focusing on that provides continued value as you refine the weaker areas. Identify the areas in the product that are working well—where customers love and it generates revenue to scale the business. Once you do, pump the gas. This can also mean investing in areas that don’t exist or need additional attention to scale. It should have signals of potential through feedback and data to make a well-informed investment.

Ignore

When I say ignore, it’s not a bad thing. In fact, things are working well enough where it doesn’t require top attention. This might be a product feature that is flat in growth. Despite having potential, it may not be the top of the priorities you’d invest in. Keep the lights on, monitor, maintain, and support these items. As you make progress on investment areas, it’s typical to see things that were once in the ignore bucket become investment areas.

De-emphasize

This is when you have house guests coming over in an hour and you shove things in the closet to get it out of sight. You need them, but they are detractors from the experience. These are the eyesores that you can’t get rid of just yet. It may be a service you don’t want to scale but it’s important to keep for existing customers. De-emphasize applies to bloated information architecture to improve navigation of your site. There are more things de-emphasized in product experiences than you might imagine. Join any startup and ask how many product SKUs they have.

Deprecate

As you go through the first three areas, this is the end of the line. It’s clear there are features or services you need to deprecate and say goodbye to. The saying that it’s harder to remove features than add them is completely true, but you still have to do it from time-to-time if it means the right priority for the business and the product. These features get pruned and should never return.

Using this framework

The beauty of this framework is you can use it whenever you need to triage a massive initiative. It’s not a detailed roadmap of what to do. It’s like drawing a map in the sand in the battle field to get people oriented to the new strategy.

You could use this as a personal audit as you plan the first 30 days of a new role; share your point of view. It might be in a cross-functional workshop to get other experts in the company to weigh in. Give this a try and let me know what you think, or create your own!

The oil and water problem

Originally posted on Proof of Concept

I avoid writing about topics that is a direct reference to where I work. You never want people on your team to feel like you’re writing about them on a personal newsletter. However, I will write about themes I feel are universal challenges every company encounters and spans beyond my own experience. With that, let’s talk about the Oil and Water Problem.

Oil and water don’t mix because they have different molecular structures and polarities. This difference in polarity prevents them from forming stable mixtures, causing them to separate into distinct layers. Oil and water are the metaphor for startups rapidly growing when one polarity mixes with another.

The first group are the old guard (OGs)—tenured employees super early when the company started. The second group is the new guard (NGs)—tech veterans who contributed to successful scale at previous companies (those from the minestrone of talent). The Oil and Water Problem is the most common points of contention within companies and crucial to address. Let’s make sense of the points of view of both groups, identify typical tension points, and what you can do to mitigate the segregation of cultures.

The old guard point of view

The OGs at startups are the earlier believers who joined before others joined. Many of them are the first community members who sent the founders feedback and ideas. Because of this early start, OGs have superior knowledge of the product, not only how it works, but all the gotchas and skeletons in the closet. This context is crucial and are a big reason why OG team members are a lynchpin for historical information.

Since the OGs joined early, they may not have the experience of what happens next when a company goes from scrappy startup to a larger scale. They might wonder why new hires are coming in and taking over in areas of leadership and strategy as they’ve been the earliest believers and loyal.

The new guard point of view

The new guard are the minestrone of talent that arrive when a startup found product market fit and growing. These individual come from roles as operators of a specific function (such as Product, Design, Marketing, etc.) and have expertise scaling those groups.

Despite having a lot of experience at other companies, the new guard are unproven in the eyes of the OGs and founders. Whereas the OGs have gone to war with the founders for many years, the new guard have no battle scars. They don’t have the same organization and product context of what’s happened internally before.

Common tension points

There is a famous Looney Toons scene (E25 – S23) where Bugs Bunny and Daffy Duck argue over Elmer Fud’s hunting license—is it Rabbit season or Duck season? What ensues is a back-and-forth of Bugs and Daffy ripping that sign that depicts the other one being the season hunted.

Bugs: Duck season!

Daffy: Rabbit season!

Bugs: Duck season!

Daffy: Rabbit season!

(Repeat)

Find-replace for Bugs and Daffy, and you have the old guard and new guard. In my experience, there are a few common areas where tension points occur like two tectonic plates colliding on the Earth.

Process

The first tension point is processes. Operational excellence is not the top priority in the early stage. Process done the wrong way can hinders progress and result in performative work. However, how a 20-person team runs and a 2,000 person company runs are drastically different (and should be). What results is a debate on when processes need to evolve.

OG: “We’ve always done it this way.”

NG: “This won’t scale. Here’s how we did it at [Company Y].”

Decisions

Stakeholders and who make the decision changes in this phase.

OG: “We should have input in this decision.”

NG: “It’s been decided.”

Communication

In addition to operating procedures, you can expect meetings and communication constantly change in the growth arc of a company as it multiplies. In places where I stayed for four years, it felt like four different companies based on the growth.

OG: “I need to be in this meeting to know what’s going on”

NG: “We’ll send out meeting notes for everyone”

Access to founders

The hardest thing for a founder to deal with is when they can’t scale the relationship like in the early days. They used to be able to hand write the holiday cards personalized to each employee. At a point in time, the cards then become branded company cards with a printed message.

OG: “I used to be able to Slack message the founder easily.”

NG: “I’ll let you know what comes out of the exec meeting”

The new guard becomes the old guard

A universal truth working in startups is eventually scale will get you. Those who were the new guard at the Series B growth become part of the old guard after years of being at the company. What happens next is an even newer new guard comes in to take the company to next level—late stage to IPO. Suddenly, the original OGs and former new guard have shared experiences of what it feels like with a new regime coming in. For the new guard, it’s important to have empathy for the OGs because how they feel with you coming in will happen to you at a point in time.

Turning oil and water into ice tea and lemonade

I’ve been part of the new guard at the previous place I worked. I’ve learned what worked and what didn’t. Whether you’re an OG or new person coming in, be that person who infuses the two cultures together. This meant spending a lot of time with the founders to expand and scale their mission, talking to as many customers as possible, and dog fooding the product daily. You have to jump right into battle to gain trust. Spend time with the OGs, understand what’s been important to get here. If you aren’t able to integrate, you won’t make it and things will quickly fall apart.

To be abundantly clear, integrating the two cultures isn’t about making everyone happy as that’s not alignment. Larry David once said, “A good compromise is when both parties are dissatisfied.” The goal is constantly having input and continued improvement in blending the best of both worlds together.

Avoid the Oil and Water Problem and strive to be the Arnold Palmer of tech companies—a harmonious blend of two delightful substances (ice tea and lemonade) that create a delightful experience.

The minestrone of talent

Originally posted on Proof of Concept

Minestrone is an all-time great soup. The hearty Italian vegetable soup has variety and versatility: onions, carrots, celery, tomatoes, beans, and whatever the family recipe tells you to put in it. I use minestrone as my metaphor at tech startups.

When a tech company goes from a startup finding product market fit to scaling to the next phase, an influx of new talent comes on board; many alumni from tech companies we admire who found success. I call this the minestrone of talent, where individuals with great experience all come together like the various ingredients of the Italian soup. Like minestrone, they are all thrown in together and mixed in a cooking pot in hopes to deliver something wonderful.

I’m going to make a case why joining a startup with a minestrone of talent is forming and cooking with that group is one of the best ways to gain experience.

There are different types of people who join startups that are scaling. There are three that are common, though they don’t encompass everything. The first are those who’ve experienced scale before. This may be the Ex-Airbnb, Dropbox, Meta, or alumni who’ve seen the growth to IPO phase. The second are tech founders who join via an acquisition. This may be the tech startup making a strategic move to get intellectual property (IP) or talented individuals who may be struggling to sustain the startup. In both instances, it’s a way to build a stronghold in the space the company works in. Third, there are also people who join from smaller companies as well. It’s a reminder that not all high performers and impactful people have to come from iconic logo companies in Silicon Valley.

If you can’t travel the entire world, visit New York. The reason is because if you don’t have the time or means to travel the world, New York is a surefire way to meet people from all over the world. Through that experience, you learn a lot about the cultures and values of where they are from. The minestrone of talent at tech companies is exactly like this. I never worked worked at Slack, Dropbox, or Airbnb. However, from working with alum from those companies who joined during the minestrone of talent, I learned immensely from their experiences from frameworks, philosophy, and stories from it.

It’s nearly impossible for someone to work at all these companies in their career, so being immersed in it from others who worked there is effective. By increasing all the different ingredients of execution, you can take the best of them to adapt how you want to operate.

In addition to tactical learnings, what I’ve valued most from the minestrone of talent is hearing the stories. I even know about “Dropbox for toasters,” a story any time I mention to an early employee they chuckle as they understand the reference. The best stories are the ones that share the resilience of what it took for that scale phase to be successful. Let’s face it, working at startups are hard, and not for most people. We often imagine these iconic companies had it all figured out. They didn’t, and navigated through the chaos. The stories of resilience can motivate teams to keep going.

I recall going through a difficult time at a previous company. We had multiple departures at once on our team. Our Head of Tech Recruiting at the time told me the story of how Airbnb had their own Phoenix rising from the ashes moment and had to re-build the team. Hearing that story and knowing other companies had to go through those hardships was exactly what needed for our team to rebuild.

If you have an opportunity to join a tech company where a minestrone of talent is forming, take it. If you’re optimizing for learning, experiencing a lot of things at a rapid pace, and be immersed in a network of incredible individuals, the minestrone of talent can change your life and be the most delicious experience in your career.

Perfectionism vs. Optimalism

Bring Your Own Abstraction (BYOA)

Apple recently deprecated a favorite development feature of mine—@IBDesignable. Given the direction SwiftUI is heading, it makes sense, but the attribute was a little nod to how even the smallest abstractions can make people effective. @IBDesignable was an attribute in Swift that allowed you to preview and interact with custom views directly in Interface Builder without running the app. It provided a visual way to edit attributes in the inspector and allowed designers like me to make interface tweaks without constantly running Xcode, which took a lot of time for larger applications. This resulted in a huge productivity gain over time.

An abstraction in computer software is a way of simplifying complex systems by focusing on the essential features and ignoring unnecessary details. This could be on the interface, data structure, or codebase. Abstractions are very powerful, and in this next phase of software development, we’ll see Bring Your Own Abstraction (BOYA)1 as a common pattern in authoring environments.

Blockers to BYOA

The concept of a personalized workflow for people is not new, so why isn’t this a norm today? The reason is typically legacy ways of approaching software, adoption, and behaviors of the end user. Three reasons come to mind for me: rigid interfaces, comprehension, and alignment on default interfaces.

Rigid interfaces

Most software is not designed to be personalized, especially in Software as a Service (SaaS). Instead, SaaS’s patterns are modules that can be sold with a bit of customization. There are patterns buyers and users of SaaS software are used to, such as Single Sign On (SSO) and Role-Based Access Controls (RBAC)—common and expected. Where rigid interfaces are problematic is a software buyer usually is forced to make a trade-off on the product’s behaviors as opposed to the people who will use it. For example, simplicity vs. power is a common trade-off companies make. A Marketing team needs to decide between Canva vs. Figma or Wix vs. Webflow.

What skills people on your team have, whether it’s their current knowledge of a tool or ability to learn, is a big factor in how software is decided. Regardless of what you choose, it’s likely someone on the team will be at a disadvantage as a result of the decision.

Comprehension

“Ease of use” and “intuitive product” are common terms when describing product desires. However, they are vague. It’s not simplicity vs. complexity—the capability of understanding something is what’s important. Comprehension is focused on building a “low floor, high ceiling” environment. You can’t define ease of use without having an understanding of comprehension for the end user.

For example, an abstracted no-code site builder is viewed as easier to use by a person who doesn’t know how to build websites. They may find the familiar sliders and switches that allow them to be able to code visually, which is wonderful. However, if you have a person who has advanced level knowledge in programming, the tools might be cumbersome for them to navigate. They may prefer to write their own CSS as opposed to defining each property with a mouse.

Comprehension is dynamic and changes over time. Rigid interfaces don’t accommodate for this and as a result, comprehension is often neglected.

Alignment on defaults

There is an image that goes viral every so often about interfaces. It depicts the typical Apple and Google products; and then shows what your company’s app:

We should strive for an elegant experience to make end users as successful as possible, but you can’t expect all animals in a zoo to shit in a cat’s litter box. Various roles and behaviors have different expectations. Being too abstracted might create more work for people who need to achieve complex tasks while being too complex might create a barrier too great for people to adopt it.

The biggest blocker to tech adoption isn’t access or availability to the technology, it’s the time it takes for people to change their existing behaviors. This was a lesson I learned at One Medical. There were instances where we’d propose new designs that were more tidied and hidden in affordance. The feedback was it created more work for the admin to find the affordance and they were used to having everything in front of them. For BYOA to be a viable concept, you have to build an abstract experience that’s more effective and intuitive than the current behavior.

Designable abstractions

Large Language Models (LLMs), Generative AI, and Cloud Development Environments (CDEs) are pushing for a change. What if there was an @IBDesignable for entire companies? There are three major themes in this next phase of software development:

Platform: The API and infrastructure you build for your team and third parties to build off of.
Interoperability: How the capabilities of your features compound impact and integrate.
Extensibility: Partnerships and distribution with other products and service providers. It allows you to build desired bridges across your moat.

These themes provide capabilities for BYOA to be configured through 3rd party software or built internally. I attempted to draw what this could look like in Eraser. Keep in mind this is not a technical diagram and a rough pass at how a Designer and Marketing Generalist can work in the same authoring canvas with their abstractions.

Role-based controls are something that exist today, but it usually is more about limiting a few tabs or features vs. maximizing success. In a world where LLMs can retrieve data and abstractions can be tailored to an individual, we could see a world where the authoring space is completely personalized in real-time.

The Design Engineer will be one of the most important roles of this decade2 and they’ll play a huge role in enabling these abstractions for teams. In addition to working on product architecture, Design Engineers can be the enablers of designing abstractions. Enablement is the goal; of providing the right guardrails to make people more effective. At Webflow, I described this as Bumper Bowling Empowerment, where guardrails are empowered instead of limited. If the Job To Be Done is to bowl a strike, putting bumpers for a less experienced user is a more viable path than expecting them to become a professional bowler.

Building in a BYOA world

I believe this new paradigm allows malleable abstractions, personalized to the end user as opposed to the product or software—allowing everything to be designable. Four factors move us into this world: a shared workspace, new methods of data retrieval, generative AI being an equalizer, and role-based abstractions/workflows.

A shared workspace

In Issue 129, I agreed with many that the desktop metaphor needs to be retired. My proposal is instead of Personal Computers with time-shared commuting, the new metaphor is a shared communal space. Whether it’s the infinite spatial canvas on Figma or an aesthetic structured document like Notion, we’ll see companies adopt common workspaces. In Episode 160 of the All In Podcast (a very academic citation!), David Friedberg predicted Vertical SaaS taking a hit as a result of the advancement of AI and the ability to build tools internally. In 2022, it was reported that 65% of Figma users were non-designers. Figma is no longer simply a design tool. It’s a tool for design work to get done (by anyone). These forces of nature will result in common workspaces that span broader across companies.

New methods of data retrieval

Throughout my career, I relied on close partnerships with Data Scientists to retrieve data for me. I didn’t trust myself. What’s worse than no data is misinterpreting data. Unless you know SQL and Python, it is tough to retrieve data with confidence. The experience is very rigid and specific.

LLMs and new database implementations like vector databases are changing the game. People now have a more natural language experience in retrieving data. In addition to people, interfaces (programmatic or agentic) have the same ability to do this. Abstracting this away removes the need to have interfaces and workflows.

Generative AI as an equalizer

I’ve worked on both ends of the spectrum of code and no-code, and with Generative AI, I can tell you the debate between the two is irrelevant. BYOA is the next phase of no-code. Instead of building an entire product with a rigid interface, Dynamic Interfaces will adapt and evolve based on the end user needs.

Personalized abstractions and workflows vs. role-based

This may be the end of rigid access controls where you group people to a static list of access and abilities. Instead, everyone at the company will have a world-class Bumper Bowling Enablement experience in their day-to-day work. AI-powered workflows will increase organization intelligence and allow dynamic personalization in abstractions and workflows based on the person.

You’re invited to the workspace (BYOA)

BYOA will be like bumper bowling in a tailored article of clothing. The entire experience is personalized to you maximizing your success. What’s exciting is we don’t have to wait to see how this might take shape. We get to define it in this paradigm shift of dynamic software creation.

Manager coverage and scope

People often ask what the different responsibilities are between levels of management: manager, director, and VP. First, there is no perfect way to draw this as organizations are all different. This sketch is an attempt to show different areas of coverage and daily interaction.

1. Team view: Primarily focused on the success and performance of direct reports.
2. Cross-functional: Working with other team leaders across the org
3. Upward: In addition to overseeing larger scope of org, works upward with senior leaders on strategy
4. Company level: Usually executives or department heads. Focuses at the company/board level

The importance of a portfolio and progression towards proof of impact. When you’re early in your career, having a really strong portfolio is the only thing people have to go off of. As you progress the evidence will be more on the proof of impact in your previous roles—success metrics, outcomes, results of the work.

Sketch inspired by my post, How experienced managers should think about career opportunities

Say no to Bluetooth.