The problem is that your prospective customers are busy doing their actual jobs. Most of them don’t know your product exists, and even if somebody sends them a link, investigating a new piece of software is just another thing on an already long list.

Their existing software might be annoying, but it probably works. Maybe your product genuinely is 10–20% better. But is it 20% better after I’ve moved all our data across, rebuilt the integrations, changed our processes, retrained the team and spent the next three months answering questions about where the button everybody used to click has gone?

There are also years of accumulated knowledge wrapped around the current system. Sarah in Ops knows the workaround for one problem. Somebody built a spreadsheet that fixes another. There’s a slightly ridiculous process everybody complains about but has been using for four years. Everyone knows which bits are broken, what to avoid and who to ask when something goes wrong.

The old software may be crap, but it’s known crap. That familiarity has value.

Then there’s the problem of working out whether your new product is actually as good as you say it is.

I visit your website and you tell me it’s faster, smarter and easier to use. Great. So does every other vendor in the category, including the people I already buy from. There are a couple of carefully cropped screenshots, some sweeping promises and perhaps an AI-generated photo of a smiling user, but surprisingly little that helps me work out what the product actually does differently.

What I really want is evidence. Show me the product properly. Let me play with it. Give me a sandbox. Or, at the very least, show me a ten-minute video of somebody using it to solve the problem I actually have.

Instead, there’s a big Book a demo button.

Now evaluating your product means finding 30 minutes in my diary, getting on a Zoom call with a salesperson, answering a bunch of qualification questions and sitting through their preferred version of the story before I’m allowed to see whether the bloody thing does what I need. I’m busy, I don’t particularly like being sold to, and the fact that you’re being so coy about the product makes me wonder whether there’s actually much there.

And even if the product looks good, I’ve still got another problem: your company.

You launched six months ago. You’ve raised a small seed round. You have seven employees and a handful of customers I’ve never heard of. You might go on to become the category leader, but you might also be gone in 18 months.

If I persuade 40 people at my company to move onto your platform and you disappear next year, I’m the person who gets to explain why we now need to migrate everything again. From my perspective, adopting your product isn’t just a question of whether it’s better. I’m taking a bet on your company as well.

So waiting suddenly looks pretty sensible. Let somebody else discover the bugs, find out whether your support is any good and see whether you can actually build a sustainable business. If you’re still around in three years and a few people I trust are using you, perhaps I’ll take another look.

This is the bit I think a lot of founders underestimate. They compare their product with the incumbent and think: ours is clearly better. The customer is making a different calculation: is this better enough to justify all the hassle and risk of changing?

That is a much higher bar.

And this is where building a startup can start to become quite dispiriting. Founders often assume that once they’ve built something significantly better, the hardest part is behind them. In reality, once the fun product-shaping bit is done, a different kind of work starts.

You have to get strangers to care. You have to explain the problem repeatedly without becoming boring, show the product, make videos, write posts, go to events, ask customers for introductions and follow up with people who didn’t reply. You have to sit through sales calls where somebody spends 25 minutes explaining their procurement process, and hear “this looks great, come back next year” over and over again.

For a lot of founders, this is almost the opposite of why they started the company. They wanted to build the product they believed should exist. They enjoy talking to users, puzzling over workflows, shaping features and watching an idea slowly become something real. They didn’t necessarily sign up because they wanted to spend the next five years writing marketing posts, recording webinars, chasing leads and making sales calls.

So they retreat to where they feel useful.

They decide the onboarding needs improving. They rebuild the dashboard. They add the feature three prospects mentioned. They convince themselves that sales are slow because the product isn’t quite good enough yet and that one more release will finally make the market pay attention.

Sometimes they’re right. But often they’re polishing the product because polishing the product feels like progress, while trying to persuade people to change deeply embedded behaviour mostly gives you rejection, indifference and unanswered emails.

Over time, that can wear people down. Progress feels slower than it did when they were shipping every week. Customers care less than expected. The founder starts to lose some of the energy they had at the beginning. Some adapt and get good at the commercial side of the job. Others keep hiding in the product. Some simply get jaded, run out of steam and quietly start going through the motions.

“If you build it, they will come” is a lovely idea. But nobody owes you their attention simply because you built something better.

And, in many startups, learning how to overcome that indifference turns out to be a much bigger job than building the product in the first place.

We want to slow things down, look at the problem from several angles, do some research and test a few models before committing. We often wait until we feel 90 per cent sure before pulling the trigger. Partly because we know that, despite all the talk of agile development and continuous iteration, many decisions are effectively permanent. The team moves on, the backlog fills up, and the promised second pass never comes.

Our business and product partners often work differently. They are dealing with growing backlogs, limited attention and a steady stream of opportunities. Decisions are made through pattern recognition and instinct: this sounds plausible, a competitor is already doing it, the downside seems limited, and there are another dozen bets waiting behind it.

The result is a kind of fire-and-forget product development. Ship the idea, see what happens, move on.

Designers usually respond by trying to pull everyone into System 2. We ask for more evidence, more time, more clarity and a better understanding of the problem before committing resources.

Sometimes this works. It is more likely to work in larger, successful companies, where the cost of a mistake has risen and institutional caution has started to set in. But in many organisations, those objections fall on deaf ears. Worse, design starts to be seen as an organisational handbrake: the team that always needs another workshop, another round of research and another week to think.

That perception is not entirely fair. But it is not entirely invented either.

I often describe the difference as a chess-versus-poker mindset.

Designers tend to treat product decisions like moves in a game of chess. Each move changes the board, closes down future options and may be difficult to undo. One sufficiently bad decision can compromise the whole game. It therefore makes sense to study the position carefully before moving.

Many business leaders think more like poker players. They expect to lose plenty of hands. The aim is not to avoid every bad outcome, but to place enough sensible bets that the winners more than cover the losses. From that perspective, spending too long protecting against failure may be more dangerous than failure itself.

Neither position is inherently irrational. The disagreement is really about how mistakes are priced.

Designers assume that a poor decision will become embedded in the product. It will create inconsistency, technical debt, support costs and awkward constraints that the team will be living with for years. Business leaders are more likely to see the same decision as a relatively cheap experiment. If it fails, they will stop investing in it and move on.

The problem is that many organisations talk as though they are playing poker while building products as though they are playing chess. They describe decisions as experiments, but rarely remove the failed ones. They promise to iterate, but almost never return. Each supposedly temporary bet leaves another permanent mark on the board.

Under those conditions, design’s caution starts to look less like perfectionism and more like experience.

But designers also need to recognise when they really are looking at a cheap, reversible bet. Not every decision deserves a month of research. Not every imperfect release creates lasting damage. Sometimes the cost of waiting is greater than the cost of being wrong.

The useful question is not whether the organisation should think fast or slow. It is whether this particular decision is genuinely reversible, what failure would actually cost, and whether anyone will come back to fix it if the bet does not pay off.

The problem is that words like research, hypothesis and testing do not sound decisive. They sound slow. They sound like someone has interrupted a moment of agreement to reopen the question.

From the designer’s point of view, this is sensible. We do not want to attach certainty to something we do not yet know to be true. We want to check. We want to understand the edge cases. We want enough evidence that we will not have to reverse course six months later.

To everyone else, it can look like a lack of conviction.

This is one of the recurring tensions between designers and their business partners. Designers are often trying to establish what is true. Their colleagues may be trying to get an idea through the gears of the organisation.

Those are not always the same job.

A surprising amount of business runs on truthiness: something that feels true, sounds plausible and can be repeated convincingly enough to create momentum. Once an idea has acquired senior sponsorship and a confident narrative, the burden of proof shifts. The person asking questions starts to look obstructive, while the person making the unsupported claim looks like a leader.

Designers sometimes make this worse through the way we speak. We hedge. We qualify. We add caveats. We say “it depends” when it genuinely does depend. All of this may be intellectually honest, but it rarely carries much weight against someone willing to say, “This is what customers want.”

AI has made this dynamic more obvious.

AI is the ultimate confident business partner. It states things cleanly, quickly and with very little visible doubt. Even when we know it can be wrong, the fluency is persuasive. A well-structured answer feels researched, even when it is not.

And because the reason we are using AI is usually speed, we are not especially inclined to check its work. If it includes a source, we may glance at the link. We probably will not read the underlying paper, inspect the methodology or check whether the source says what the summary claims it says.

We accept the answer because it sounds like an answer.

This is not limited to design or technology. It is increasingly what people seem to want from politicians too. Complexity is interpreted as weakness. Caution sounds evasive. Nobody wants to hear that the situation is difficult, that the evidence is mixed, or that several experts need to spend six months working through the consequences.

They want someone who says they understand the problem and knows exactly what to do.

Simple answers feel reassuring. They are also often wrong.

Designers should not respond by becoming equally careless with the truth. The answer is not to replace uncertainty with bluster. But we do need to get better at expressing uncertainty without sounding paralysed by it.

There is a difference between saying, “We don’t really know, so perhaps we should do some research,” and saying, “We are about to make an expensive decision based on an untested assumption. Here is the fastest way to find out whether it is true.”

The second statement contains no more certainty than the first. It simply makes the cost of being wrong more visible.

That may be the real communication problem. Designers often explain why they are uncertain, but not why everyone else should care.

As more of our colleagues begin to rely on AI, the ability to distinguish confidence from evidence will become more useful, not less. The world is filling up with systems and people that can produce a convincing answer on demand.

Our job is not to be the least confident voice in the room.

It is to make doubt harder to dismiss.

While founders are rarely visited by apparitions, they often have a vision of a better world, and believe that customers who share that vision will simply turn up. However, experience has shown that even the best products can struggle to find an audience on their own. So founders need to quickly switch focus from building a valuable product to connecting the value the product delivers with prospective customers. There are essentially three ways to do this. However, before you choose a path, you need to think about who these early adopters are. 

Finding your early adopters

Founders will often have a picture in their mind of their Ideal Customer Profile. The people who will get most value out of their product. However, these ICPs are often fairly sophisticated users in well established tech companies who typically have an extensive list of requirements. This can lead founders to spend the next 12-18 months chasing feature parity in order to tempt these clients over. However, feature parity is an ever moving target, and you're in danger of building a “me too” product if the best you can say about your products is it does everything the competitor does. 

Instead, you need to hone in on a “beachhead” customer. Somebody who is unhappy with the current competitive offering—usually because it falls down in one significant area that they really care about—and are willing to switch to a product which solves that problem elegantly, even if it doesn’t have all the bells and whistles. 

If you’re casting a wide net, these sorts of customers are hard to find. You’ll have plenty of customers who assure you they’ll sign up if it does A, B and C. You’ll speak to other customers who tell you it really needs to do X, Y and Z. This feedback is super helpful and should definitely inform your roadmap largely because you want to be able to add features over the next 6-12 months that will allow you to onboard those more sophisticated customers. However, the real trick is to find people who “need” your solution so much that they’ll put up with its lack of features. And if you’re not finding people who are willing to take such a leap of faith, it’s either an indication that you either haven’t found the right USP yet, or you might be fishing in the wrong place. 

Having an early adopter mind set is rare. In fact, I’d imagine that less than 10% of the people you speak to will be willing to give a new and untested product a try. As such, you’ll probably need to talk to 100 people in order to find 10 who are willing to kick the tires; and with activation rates often hovering around 5-20%, of those 10 calls, only 1 or 2 might sign up. As such, early stage acquisition is very much a numbers game, and you shouldn’t feel too disheartened if those early conversations go nowhere. 

Founder Led Sales

Most founders feel like they are bad at sales. Because of this, they have a natural tendency to want to spend more time in the area they are comfortable with — namely, product. However, in my experience, I’d say the majority of early customers come from direct founder outreach, so sales is something that founders need to get good at. 

The good news is that founders are generally much better at sales than they think. They’ve managed to convince a bunch of early teammates to join them on an incredibly risky journey, often for much less money than they’d be able to get elsewhere. They’ve also managed to convince a group of angel investors and VCs to part with often sizable amounts of money. Both of these activities are sales activities.

In my experience, founders are actually surprisingly good salespeople because they really understand the problem they are trying to solve, are able to empathize with prospective customers, and outline their vision for a better world. Also being frank, it feels much nicer being pitched an idea by a founder than some junior sales executive. As such, I generally find that founders are able to close more deals than a professional salesperson, while only spending half as much time. 

This generally means that in the early stages of a product's launch, the best leverage you can have is to spend time on sales, and you might end up needing to hire two or three sales executives to close the same number of deals as a founder. 

Your Early Sales Motion

While founders often feel shy when it comes to sales, they usually have no problem reaching out to people for a “customer discovery” call. As such, I generally recommend founders build their early sales motion off the back of these calls.

In a typical customer discovery call, you want to try and understand your prospective customer’s problems in order to create a meaningful solution. So you ask people about their role, their work, what they find challenging, and what tools or processes they use to solve these problems already, and what it would mean to them if there was a better solution. You then take notes, thank them for their help and let them know that you’ll be in touch when the product is ready. 

With a “sales discovery” call, you still follow the same approach. However, you now have a possible solution to their problem, so you add one more thing, which is to ask whether they’d like to try the solution. If the people you are talking to are keen, you might very well be able to land a sale right there. However, if you’re shy about asking for money—something you really need to get over—you could try to land them as a “Design Partner” or Beta Customer on a free or discounted package for a few months. Once they’ve used the product for a while and started receiving value, asking them to start paying will be a lot easier. And if, after a few months, they’ve not been getting enough value to pay, you’ve learnt something super important about the product in the process. So how do you find these early customers?

Prospecting and Outreach 

Customer prospecting is an article in its own right. However, most founders start by building up a picture of their target prospect. Things like their job title, the sector they work in, the size of their company, where it’s headquartered and maybe their revenue or funding level. You can then use tools like LinkedIn to hone in on these people and start building your sales sequence. 

A sales sequence is usually the series of steps you’re going to take in order to reach out to somebody. On LinkedIn, this might be visiting their profile, reading or liking a few articles, following them, verifying some skills, reaching out to connect, sending an initial message, and some follow up messages if that doesn’t work. 

Doing all these actions can be quite time consuming, so early founders will often hire some sort of junior to do this prospecting for them. There are also an increasing number of tools like dripify which will automate this process for you. This allows founders to focus on the highest leverage tasks; hopping on a call with prospecting customers and closing the deal. 

One thing to note is that the way you craft your outreach can have a significant effect on hit rate. If you send a fairly generic sales email introducing your product, the response rate is likely to be low. Instead, it’s usually better to open with a personal message that shows you’ve actually connected with that person, ask a question relating to a problem you think they might have (and you know your product can help with) and then share some useful or intriguing offer. 

For instance:

Hi [name], I really liked the [article you wrote/comment you made] on [location] the other day. As an [insert role] I was curious what you’re currently doing about [problem]. I’ve [just started a new company/written an article about this subject] and I was wondering [if you’d be up for giving me some feedback/taking a look]?

This is obviously a super basic script, so I’d expect you to write something a little more sophisticated, but you get the basic idea. Be human, show interest, ask questions and if possible, have something useful to offer beyond your wonderful new product. 

Like most sales motions, you’ll get a lot of rejections. I think this is one reason why founders generally shy away from sales. However, if you’re not willing to experience this, why should anybody else on your team? One way to get around this blocker is to set explicit targets for the number of contacts you’re going to make each week, and carve out specific blocks of time when you’re going to focus on this. Otherwise, the tendency is to let this slide in favor of the more fun product stuff.

Once you know that every 100 LinkedIn connections leads to 5 discovery calls and 1 conversion, you know that doubling the outreach and calls you can do, will double the number of sales you make. This allows you to manage your time (and growth) better, as well as know when you need to bring other folks in to help out. 

While sales can be off-putting for many founders, the good news is that sales is actually a brilliant way to learn about how to position your product; what objections customers come up with and how to tackle them, and what features and functions really are deal breakers. As such, founder sales really is the natural extension to discovery. In the early days, it’s also something that can drive a lot of value, because if you don’t have people using your product, you can’t really learn what you’re doing right or wrong.

Founder Led Marketing

In some regards, founder-led marketing is very similar to founder-led sales, in that you’re trying to connect the value your product delivers with your early adopters. The main difference is that you’re doing this by broadcasting rather than narrowcasting. Or to put it another way, rather than finding individual prospects, you’re finding the places where your prospects hang out, and sharing messages on those channels in the hope it will resonate with prospective customers and draw them to you. 

Early-stage founder-led marketing generally works best if the founder already has clear channels they’re comfortable with. Maybe they have a bunch of followers on X or LinkedIn. Maybe they speak at conferences or have a popular blog?  Or maybe they are members of an existing community. Either way, your first job is to start telling people what you're doing, which generally means creating content. 

If you don’t have any existing channels, you obviously have to find one first. This generally requires having a good knowledge of your customers and where they hang out. Finding channels that work can be a challenge. Especially cost-effective ones. So rather than spreading yourself too thin, your goal should really be to find a single channel that works best for you, your users, your product and your team, and then build out from there. This requires a lot of experimentation and it might take months before you find a channel and message which lands. 

Sadly, I see a lot of early-stage companies producing a tonne of low value ”background radiation” type content which is frankly a waste of time and energy. This is often because they don’t really know what resonates with prospective customers, so end up just throwing things against the wall in the hope that something will stick. Much better to have a strong understanding of your user needs and create content that really connects on a deeper level. Often, this content will come from the conversations happening on the channels and communities you’re exploring, and the discovery and sales calls you’re having.

So what are the things that keep your customers up at night, but nobody else is talking about? What do they hate about existing solutions, and the companies that provide them? What are the industry “sacred cows” which are ripe for being turned over? In order to cut through the noise you need to have a strong position and something important or meaningful to say. So why did you start down this journey in the first place, and how can you connect those feelings of frustration and anger with the status quo with your early adopters. Content creation is another thing that founders like to outsource to junior team members. However, they probably don’t have the same burning vision as you do, so the best early content usually stems from the founders themselves. 

One of the great things about content marketing is that good content is easy to repurpose. So even if you are primarily focusing on a sales led approach, having one or two high quality pieces of content you can offer up during your sales outreach is a great way of connecting with prospective customers, reconnecting if you haven’t spoke to them in a while, or as a way of getting permission to contact them back in the future. 

Paid Ads

This brings us nicely onto the topic of paid acquisition — essentially ads. Ads can be a super attractive way for founders to acquire customers if they don’t want to put the effort into sales, or don’t want to wait for their marketing activities to take off. You can select a channel like search or social ads, define specific characteristics you’re looking to target, define how much you’re willing to pay per click, and have the campaign running in the background. 

The big problem with paid advertising is that it’s costly, meaning you can burn through a tonne of money fairly quickly. This is especially true in highly contested areas where bigger and better funded companies are able to outcompete you. Setting up a good advertising campaign also takes a reasonable amount of skill; and not having these skills on your team can often mean you spending much more to acquire customers than is strictly necessary. Advertising is also addictive, so that once you start relying on paid acquisition, it becomes much harder to wean yourself off. As such, while advertising might seem like a great “turbo boost” in the early days, it can quickly become a rod for your own back. 

With that in mind, I generally think it’s better to start with either a founder-led sales or founder-led marketing approach, and use advertising as a back up. The one caveat I would add is that paid advertising can be a cost-effective way to test your positioning, as it allows you to try numerous different versions of your value prop, to see which lands. You can also use advertising as a crude form of multivariate testing, driving different groups of people to different landing pages in order to see which performs best.  However, as Jeff Bezos allegedly once said “Advertising is the price you pay for having an unremarkable product or service.”

Conclusions

While it’s tempting for founders to delegate sales and marketing to junior team members in order to focus on product, building a customer acquisition engine is going to be key to your success. As such, this is something that founders should place a great deal of focus on, only passing this on to somebody else once the core pieces are in place. Getting those first 100 users is vital to the success of your startup, and the learning you’ll gain through doing this will be invaluable. This is probably one of the reasons why “First time founders are obsessed with product. Second time founders are obsessed with distribution.”

For more ideas on finding your first 100 users, check out The Growth Equation

Step 1: Stop Cold Emailing. Start Building Relationships.

Imagine you get an email from a stranger saying, “Hey, I just launched something! Write about me!” Would you drop everything and do it? No? Neither would a journalist.

Journalists are bombarded with pitches every day. If you want to stand out, start by engaging with them before you need something. Follow them on Twitter, comment on their LinkedIn posts, and actually read their articles. Share their work, add thoughtful insights, and be a part of the conversation.

It’s a marathon, not a sprint. When the time comes to pitch your story, they’ll already know your name—and that’s half the battle.

Action item: Identify three journalists who cover your industry. Follow them, engage with their content, and build a rapport over the next few months.

Step 2: Be a Source, Not a Salesperson

Here’s a secret: journalists love experts. If you position yourself as a knowledgeable, helpful resource, they’ll start coming to you for insights.

If you’re in fintech, don’t just pitch your startup—offer commentary on industry trends. If you run a SaaS company, share data-driven insights that could make for an interesting story. The goal is to be useful, not self-promotional.

Need proof? Ever wonder why the same people are always quoted in articles? It’s because they’ve made themselves easy to reach and valuable to journalists.

Action item: Create a short, friendly message offering your expertise in your industry. Send it to journalists you’ve built a relationship with and let them know you’re available as a source.

Step 3: Make Your Story Actually Interesting

Let’s be real—raising a funding round isn’t news. Startups do it every day. Hiring a new CTO? Not exactly front-page material. Launching a product? Unless it’s curing diseases or flying to Mars, you need a better angle.

A great story isn’t about you—it’s about what’s happening in the world and how your company fits into that narrative. Think about:

• Big industry shifts: Is your startup capitalizing on a major trend?

• Surprising data: Have you discovered something that challenges conventional wisdom?

• Unique growth strategies: Did you scale in a way that’s never been done before?

Your news needs to be something their audience will care about, not just your investors.

🚫 Not interesting:

• “We raised $5M.”

• “We launched our new app.”

• “We hired a CMO.”

🤩 Interesting:

• “Our data shows consumer spending habits are shifting in unexpected ways.”

• “This industry was tiny when we launched, but it’s booming now—here’s why.”

• “We grew 10x by doing the opposite of what everyone else said.”

Action item: Take a step back and think: Would I read an article about this if it weren’t my company? If the answer is no, it’s not a story.

Step 4: Pitch Like a Pro

Even with the right relationship and a great story, the way you pitch matters. Journalists don’t have time to wade through a five-paragraph email full of buzzwords. Keep it short, clear, and compelling.

Your pitch should include: 

✅ A subject line that grabs attention.
✅ A quick reminder of who you are (if you’ve engaged with them before).
✅ The core of your story in two sentences.
✅ Why their readers will care.
✅ An offer for an exclusive, if applicable.

Example pitch:

Subject: Exclusive: Data Shows Gen Z is Spending 40% Less on Subscriptions
Hi [Journalist’s Name],
I saw your recent piece on changing consumer spending habits—great insights! We’ve been tracking new data at [Your Startup] and found that Gen Z spending on subscriptions has dropped 40% in the past year.
Happy to share the full dataset if you’re interested—this could make for a great follow-up story. Let me know!
Best,
[Your Name]

See how that’s more compelling than “We launched a product. Please write about us.”?

Action item: Before hitting send, ask yourself: Would this email make me excited if I were a journalist?

PR is a Long Game

The biggest mistake startups make is treating PR like a one-off event. The best coverage happens when you’ve put in the time to build relationships, establish yourself as a credible source, and craft stories that are genuinely interesting.

Think of it this way: The more valuable you are to journalists, the more they’ll want to feature your startup—without you even having to ask.

So start planting those seeds now. By the time you have big news, you won’t just be another pitch in their inbox—you’ll be a trusted voice they actually want to hear from.

One way around this is to spend some time in the company of a good designer. Get them to explain what good looks like to them; so what should you look for in a portfolio; what questions should you ask at the interview; and what characteristics and attributes should you be trying to ascertain? Maybe ask them to walk through a couple of CVs or portfolios and tell you what they like. Or maybe have them point out a couple of designers they think are operating at a high level, and explain why.

Of course, if you’re already struggling to know what good looks like, you probably don’t have somebody like this in your network already, so reach out to friends, advisors or investors for introductions.  This is essentially my role as Seedcamp, so don’t hesitate to drop me a line if you’d like to chat. 

While talking to a talented designer can be super enlightening, you’ll get even more mileage by asking them to help out with the actual recruitment process. This could be taking a look at your job listing, or helping you understand the best places to advertise. Or you could go deeper and ask them to take a look at resumes, review portfolios, or sit in on interviews. The more external perspective you can get, the better. 

This is a little like asking a knowledgeable friend or family member to come with you to the dealership to help pick out your first car.  They’ll be able to check out the vehicle, know what questions to ask, and let you know if they think the dealer is laying it on a bit thick; all in order to make sure you don’t end up buying a lemon. 

How to Keep Good Designers Once You’ve Got Them

As I’ve mentioned in previous articles in this series, that first design hire can be critical. However designers often struggle when working in a silo, so it’s important to build a culture that understands and values the role of design. I’ve seen many tech firms lose amazingly talented designers because they didn't quite understand what they were getting themselves into, or how to best use them. 

It’s safe to say that good designers work best when they’re actively involved in shaping the product. This is because they need to understand the context they’re working in to be effective. Architect Eero Saarinen sums this up best in his famous quote — “Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

As such, the best designers will want to understand your strategy, talk to customers, look at your analytics, and wrap their heads around why certain decisions have been made. Good designers are naturally curious and will ask a ton of questions. In fact this can become slightly irritating at times—like your niece or nephew asking why the sky is blue or why ducks quack. They’ll also want to explore a range of options before landing on the one they think is the best fit. Even if it’s exactly the one you were suggesting in the first place.  

This may feel wasteful, so it’s tempting for founders to try and shortcut the process and simply tell the designers what to build. However this is like telling somebody what your holiday was like in the hope that they’ll somehow absorb the benefits of your week in the sun. It’s a natural part of the designer's process and difficult to short-cut. 

As such, hiring your first designer can bring up all sorts of challenges around the decision making process. Challenges you’ve not had to think about before. However with it comes a tonne of benefits, like looking at your product from a user's perspective, and with a beginners mind; one of the reasons I think having a founding designer on the team can be invaluable.

Check out my past blog posts in this Hiring for Design series:

Part 1 Hiring for Design Part 1: Why A Good Designer Should be One of Your First Hires
Part 2 Hiring for Design Part 2: Hiring Your First Designer
Part 3 Hiring for Design Part 3: Interviewing Your First Designer
Part 4: Hiring for Design Part 4: What a High Performing Designer Looks Like
Part 5: Hiring for Design Part 5: Scaling your Design Team

The gathering brought to life that old, slightly overused William Gibson line: “The future is already here — it’s just not evenly distributed.” It gets quoted so often that it can feel a bit tired, but sitting in that room, it felt unusually apt. Not because everyone there had the answers. Quite the opposite. It felt like an early warning from the part of the industry where AI is already changing the day-to-day mechanics of design work.

I have no doubt we’ll start to see more gatherings like this over the next year. In fact, I’m helping organise something similar in Brighton in a few months’ time. Maybe not with the same concentration of people from Californian AI labs and design tool companies, but with the same underlying questions. The conversations happening in that room will start spreading through the rest of the tech world soon enough, because the same pressures are coming for everyone: faster tools, blurrier roles, more people able to generate plausible product work, and design leaders trying to work out what quality means when making the thing is no longer the main bottleneck.

Most design teams are not working this way yet. AI only really seemed to reach the right level of sophistication for product teams over the past year or so, and the current window of opportunity still feels relatively small. But I suspect many of these conversations will feel familiar within the next 12 months.

Who gets to design when everyone has access to design tools? Who gets to ship when the distance between prototype and production collapses? What happens to product quality when more people can generate something plausible? And what is the job of a design leader when making the thing is no longer the main bottleneck?

What I found was not a room full of leaders confidently pitching a brave new world. Instead we had a room full of thoughtful practitioners comparing notes on what had changed for them over the past six months, and speculating about what changes were yet to come.

The sessions had a strange mix of excitement, opportunity and anxiety. People talked about AI speeding things up, giving them capabilities they had never had before, and getting them closer to decision-making, or at least shipping. There was a renewed sense of making in the room. But people also talked about feeling tired and discombobulated by the pace of change. So while there was plenty of quiet optimism, there wasn’t much certainty.

One of the post-event write-ups captured the mood nicely. Even in a room full of people working close to the edge of design and AI, almost everyone seemed to be saying some version of “I feel behind.” That felt a lot more honest than most public commentary on AI, which still swings between “design is about to be automated away” and “none of this stuff works, it’s just a parlour trick burning through GPUs.”

The borders are getting blurry

One of the most obvious tensions was the slow collapse of role boundaries.

PMs can now generate decent-looking interface ideas. Engineers can produce usable screens from a prompt and an existing component library. Founders can create landing pages, brand routes and prototypes over a weekend. Domain experts can describe a workflow and get something that looks quite a lot like software.

You can see why this makes designers nervous. The defensive version of the conversation asks: if everyone can do design, what are designers for?

Except that wasn’t really the vibe I got from the people in the room. If anything, several of the speakers seemed to have the opposite problem. Demand for design had gone through the roof. Teams were scaling up fast and shipping faster than before.

The bottleneck that once existed between product, design and engineering seemed to have evaporated, at least for the time being. Design teams were building their own internal tools and releasing them themselves, rather than pleading with an executive for budget or fighting for a slot in the backlog. Things that once would have sat on the backlog for years were now getting shipped. Design teams were no longer asking for permission, but forgiveness.

One of the write-ups after the event described designers being “unleashed” by the ability to work in code, ship their own pull requests and solve customer problems that would never normally make it onto the roadmap. This points to a real shift in the politics of design. A designer with good product judgement, a bit of technical curiosity and access to the right AI tools can now do more than describe the opportunity. They can build enough of it to see whether the opportunity is real.

So does this mean we all need to become design engineers now?

I’m not sure. But the question cuts both ways. If designers can ship, PMs and engineers can also create more of the interface work that designers used to own. Some designers will find that uncomfortable, especially if their confidence comes from being the only person in the room who can operate Figma.

And if engineers are starting to get annoyed with designers shipping half-baked code into production, we’re definitely going to see designers get frustrated with executives, product managers and engineers shipping “designs” that only have a cursory relationship to the brand, break common paradigms, and push the product in a thousand different directions at once.

In a world where everybody can and does ship design, design leaders are about to get very busy thinking about product quality. Do we empower everybody to become a designer, or do we end up becoming the arbiters of quality and taste?

Taste is not a magic shield

At some point during the event, a friend in the audience mentioned that I had strong views about the role of taste, and asked me to speak up. While I appreciated the shout-out, I honestly wasn’t sure what they were referring to. As you probably know, I have strong views about a lot of things, so I was sitting there trying to remember whether I’d written something about taste recently.

I also wasn’t sure if it was a bit of a set-up, because “taste” feels unusually polarising at the moment. It reminds me a little of the way empathy was treated in design circles ten years ago. First there were endless posts about how empathy was the designer’s secret weapon. Then, a few months later, there were endless counter-posts calling bullshit on the whole thing and accusing designers of gatekeeping. As if only designers were empathetic. Now we seem to be doing something similar with taste.

So I decided to proceed with some caution in a room full of my peers.

The reason taste matters at the moment is that our current crop of AI design tools are still basically slot machines. You pull the lever and something plops out. Sometimes it is good. Quite often the results are mixed.

Current AI-driven designs might have the right spacing, the right gradients, the right soft shadows, the right empty-state illustration, the right slightly over-polished AI product look. If you’re lucky, they might even be drawing from an existing design system.

For somebody creating a design for the first time, this can feel magical. If you’re not a trained designer, you may not notice that the gradients are a bit of a cliché, the typography is subtly off, or the images don’t match the current brand guidelines. Instead you proudly admire the piece of design you just magicked out of the air and hit merge.

But plausible is not the same as good. A generated interface can look competent while being strategically wrong, behaviourally confused or completely forgettable. It can satisfy the visual grammar of a modern product without understanding the context it is meant to serve. Often the result is all UI with no UX: the aesthetic-usability effect writ large.

One speaker demoed a browser plug-in they had created that could detect whether a design was using common generative AI tropes. The talk was both funny and telling. We are already at the point where AI-generated design has its own vibe. First we shape our tools and then our tools shape everything else. Or as one friend is prone to say, “You can almost smell the LLM on that interface.”

So yes, taste matters. Someone needs to be able to look at the output and say, “This looks fine on the surface, but it is not good enough.” And if engineers are allowed to look at the code an AI tool produces and say, “This doesn’t meet our coding standards,” then designers should have the same authority when it comes to design quality.

However, I think taste starts to matter even more when we move beyond pulling a lever, judging the output, and writing a new prompt to tighten something up. It starts to matter when the tools produce multiple viable directions and ask us to choose. Not one answer, but one hundred. All technically acceptable. All stretching the product in different directions.

At that point, somebody versed in design needs to be able to make a reasoned argument about why one direction is better than another. This reminds me of Cayce Pollard, the character from William Gibson’s Pattern Recognition, who would get physically ill when exposed to bad, aggressive or overly commercial design. A slightly extreme reference point, perhaps, but there is something useful in the idea that taste is not just liking nice things. It is sensitivity to what feels off before you can fully explain why.

This is why taste has become the design world’s latest hot potato. Everybody thinks they have good taste. And while it is relatively easy for an engineer to explain why a piece of code is not up to standard, it can feel very personal when a designer tries to explain to an executive why their vibe-coded prototype is a good start, but doesn’t work as a piece of product design.

This is where taste becomes stewardship. Not taste as personal preference. Not taste as “I know good when I see it.” Taste as the ability to protect coherence across a system.

What belongs in the design system? What should be reused? What should be retired? Where should teams be allowed to diverge? When is inconsistency a reasonable cost of speed? When is a small exception actually the beginning of product decay?

Design systems become more important in this world, but also less sufficient. A design system is not just a library of components. It is a set of product decisions. It encodes behaviour, hierarchy, brand, judgement and restraint. If everyone can generate interface work from that system, the quality of the system matters more than ever.

However, this is also one of the risks for design. In a world where everybody can and will design, do designers get relegated to creating, managing and policing the design system?

Because that would be a pretty grim outcome. The irony of AI making design more widely available is that it could leave professional designers doing less design and more quality control.

The tool stack is not really a stack

Another theme that kept coming up was the search for the “right” AI tool stack.

You can understand why. Senior leaders want to know what to buy, what to standardise on, what to train their teams in and what to ban. They want a clean answer because clean answers are easier to put into a plan.

But the people doing the most interesting work didn’t seem to have a neat stack. They had a shifting collection of tools, workflows, scripts, agents, prototypes and internal experiments. Some were using public tools. Some were using internal tools. Some were building their own. The stack, if you can even call it that, looked less like a stack and more like a messy workbench.

So the leadership question is less “which tool should we adopt?” and more “how do we keep learning as the tools change?”

Companies are going to need people who can try things without turning every experiment into a procurement process. They will need shared standards, but not so much process that nobody can move. They will need to let designers, PMs and engineers explore the edges of what the tools can do, while still keeping an eye on privacy, security, quality and product coherence.

The hard part is not adopting AI tools. The hard part is creating a culture where experimentation does not immediately become either chaos or theatre.

A lot of organisations are bad at this. They either lock everything down until the interesting people give up, or they encourage everyone to play with tools without giving them any meaningful way to connect the experiments back to the product. Neither approach feels likely to work.

I’m already seeing problems emerge. Companies that tried to codify their AI design practice six months ago, only to realise their new process is now holding them back. Companies that fired half their engineering team, went hard on token-maxxing, only to be forced to cut their spending and hire half the team back. Sometimes being an early adopter gives you an advantage. Other times you become a cautionary tale for somebody else.

So when is the right time to move, and how fast and how far should you go?

Coherence is the real leadership problem

The visible parts of design are getting cheaper. Not free. Not necessarily good. But cheaper.

Generating a screen is cheaper. Creating five versions of a landing page is cheaper. Turning a rough thought into a prototype is cheaper. Producing something that looks enough like software to fool a busy executive is definitely cheaper.

That forces the less visible parts of design to prove their worth: the framing, the judgement, the critique, the decision about which problem deserves attention, the ability to notice when something is technically correct but experientially wrong, the discipline to reject plausible work, and the capacity to hold a product together when more people are able to contribute to it.

When everyone can ship, someone has to hold the product together.

This is not really a craft problem. It is an operating model problem.

How do design leaders create space for designers to experiment without creating chaos? How do they encourage PMs and engineers to work with design systems without reducing design to component assembly? How do they preserve quality when production speeds up? How do they evaluate design contribution when the work no longer lives neatly inside Figma files?

How do they stop design becoming either a bottleneck or a decorative service?

I don’t think many organisations have good answers yet. Most are still trying to pour new capabilities into old role definitions. The incentives are lagging behind the tools. Designers are being encouraged to code, prototype, generate, ship and automate, while still being assessed through job descriptions written for a slower, more separated world.

That tension is going to break something. It might break the design function in some companies. It might break the old product trio model in others. It might also break the habit of treating design as the team that makes ideas presentable once the real decisions have already been made.

One of the more useful frames from the Assembly was that AI does not simply automate design. It exposes what design was responsible for all along. In a healthy organisation, it can amplify judgement, taste and craft. In an unhealthy one, it can amplify confusion, inconsistency and weak decision-making.

I’d add something slightly more uncomfortable. AI also removes some of design’s excuses.

If designers can prototype, test, generate, ship and learn faster than before, then the discipline has to stop defining itself mainly through critique from the sidelines. It has to get closer to the material of product work again.

That will be good for some designers and deeply uncomfortable for others.

The value of coming together

The thing I found most useful about the event was the sense that I wasn’t alone. The ethical, creative and process challenges I’d been thinking about were on everybody’s radar. Some people were slightly further along than others, but nobody had a definitive answer. Not yet. Just thoughts, questions, ideas and experiences to share.

I think this is why one of the recurring sentiments was that the event felt a little like the early days of SXSW. Not in terms of size, obviously, but in terms of experience density and community. There was a feeling that the rules were being rewritten while we were in the room. That turned out to be a great leveller. You can no longer rely entirely on 20 years of tool and process experience if the tools and processes are suddenly changing.

For some people this might rightly be scary. But for the people in the room, I think there was also a real sense of excitement.

Design has felt pretty stale for the past 10 years. Essentially since the industry went from shaping products to shipping PRDs, and we moved from using a wide toolbox of skills — mental models, personas, wireframes, journey mapping, service blueprints, workshop facilitation — to becoming Figma operators.

AI is blowing that world open. Figma is still an important design tool, but the best designers are using it 20% of the time rather than 90%. The work is starting to sprawl again. Tools, processes and skillsets are all changing at once.

If you’re the kind of person who relishes the chance to learn a new thing, it’s a great time to be a designer, even if we don’t yet know where this eventually lands.

That uncertainty is also why I think we need more rooms like this. Not because a handful of people in San Francisco have cracked the future of design, but because the questions are going to spread much faster than the answers. The same conversations will soon show up in quarterly planning meetings, design critiques, roadmap debates, hiring conversations and slightly awkward Slack threads where somebody has shipped something they probably shouldn’t have.

Maybe the real question is not whether everyone can design.

It is what happens when everyone can ship.

---

Andy is helping to curate the new design + ai summit taking place in Brighton on the 25th Sep. The day before he'll be hosing an invite only leadership forum at Soho House Brighton. Apply here.

The quality varies wildly. Some teams do this with real thought and care. Others do a kind of product-development theatre, where everyone knows the big decisions were made before the kickoff. But the choreography is familiar.

Figma sits at the centre of this world. It became the shared room where product ideas were made visible. That was a big step forward. It pulled design out of static files and into a place where teams could comment, collaborate and maintain something resembling a shared source of truth.

But it also had a flattening effect. After a while, every team started to look like it was doing design in roughly the same way. The same boards. The same sticky-note clusters. The same components. The same slightly over-polished prototypes. The same awkward handoff ritual where design pretends the work is finished and engineering gently reveals that it is not.

For a discipline that talks so much about change, design has been running on a surprisingly settled operating model.

AI is starting to break that model.

Designer Fund’s latest AI in Design 2026 report gives some numbers to what has been obvious in the hallways, group chats and demo calls for the past year. AI use among designers is no longer a side experiment. Weekly AI usage for design tasks has jumped from 54% to 91% in a year, with 75% of designers now using AI daily.

That alone would be enough to make the report worth reading. But the more interesting story is not that designers are using AI tools more often. It is that the shape of design work is changing.

One of the report’s more striking findings is that half of the designers surveyed say they have shipped AI-generated code to production. Not just design engineers. Not just technical specialists. Designers across product and brand roles.

That feels like a line being crossed.

For years, the “should designers code?” debate had a faintly religious quality. Some people believed coding was an essential part of the craft. Others argued that designers should focus on understanding people, systems, behaviour and interaction, rather than pretending to be second-rate engineers. Most teams found a practical middle ground. Designers learned enough to understand constraints, engineers learned enough design to care about the details, and everyone carried on.

AI makes that debate feel strangely dated.

The more relevant question is no longer whether designers should become engineers. It is what happens when designers can make working software without becoming engineers in the traditional sense. What happens when they can test a flow in a real browser instead of faking it in a prototype? What happens when they can spin up variants, wire together data, simulate edge cases, or build something small enough to put in front of users?

And, just as importantly, what happens when everyone else can do the same?

Product managers can now create credible prototypes without waiting for design. Engineers can generate interfaces that no longer look like internal tooling from a decade ago. Founders can describe a product idea and have something clickable before the meeting ends. None of this means the work is good. A lot of it will be mediocre. Some of it will be actively misleading. But it will look finished enough to travel around an organisation.

That changes the politics of design.

For a long time, one of design’s sources of power was that designers could make ideas visible. They could take an abstract strategy, a customer problem, a messy product requirement or a founder’s half-formed thought and turn it into something people could react to. That still matters. But it is no longer the preserve of the design team.

When visualisation becomes cheap, the value shifts elsewhere. Taste matters more. Judgment matters more. The ability to spot a shallow answer dressed up as a polished interface matters more. So does the ability to understand whether the thing being made is worth making in the first place.

This is where the Designer Fund report gets especially interesting. It isn’t saying designers are being squeezed out. It suggests almost the opposite. Designers are owning more and shipping more. But they are also moving up a level of abstraction. They are not just producing deliverables. They are building tools, workflows and systems that change how design gets done.

That is a very different story from the lazy “AI replaces designers” narrative. It suggests the role is stretching rather than simply shrinking.

The report found that 65% of designers are taking on more product or engineering responsibilities, while 40% say PMs and engineers are contributing more to design work. Traditional role boundaries are blurring, not because somebody ran a reorg and updated a competency framework, but because the tools are making old handoffs feel slower and less necessary.

That sounds exciting if you are the sort of designer who has always wanted more agency. It sounds threatening if your sense of value is tied too closely to ownership of the mockup.

Both reactions are understandable.

There is a real opportunity here. Designers have spent years complaining that they are brought in too late, asked to decorate decisions, blocked by engineering capacity, or reduced to producing artefacts for someone else’s roadmap. AI gives designers a chance to get closer to the material of the product. Not just to imagine, but to make. Not just to propose, but to test. Not just to hand over, but to learn from what happens next.

But that opportunity will not distribute itself evenly. The designers who wait for a settled best practice to emerge may find that the practice has already moved on without them.

This is the uncomfortable bit. The tool stack is no longer obvious.

For the last decade, a design leader could make one fairly safe assumption: the team would probably use Figma. There would be other tools around it, of course. Research repositories, whiteboarding tools, analytics platforms, prototyping tools, design system documentation, ticketing systems. But Figma was the centre of gravity.

Now the centre is moving.

The Designer Fund report says the average designer now uses seven off-the-shelf AI tools regularly, more than double last year’s average of three. That does not include the internal tools many teams are building themselves.

This is the bit I think a lot of leaders are underestimating. We are not seeing one new design tool replacing the old one. We are seeing the stack fragment.

Some designers are working in Figma with AI features layered on top. Some are moving into code-first tools. Some are using AI-assisted prototyping environments. Some are building internal workflows with Claude, ChatGPT, Cursor, v0, Framer, Lovable, Replit or whatever tool appeared last Tuesday and suddenly seems to be in every group chat. Some are stitching together messy little workflows that would horrify an operations team but let them learn three times faster.

A lot of this will shake out. Some tools will disappear. Some will get bought. Some will become features inside bigger platforms. Some will turn out to be demo candy. But waiting for the dust to settle is not much of a strategy when the dust is the thing you need to understand.

Designers now have to become much more intentional about their stack. Not in a breathless “ten tools that will change your life” way. More practically: what do we use for exploration? What do we use for prototyping? What do we use when we need real code? Where does our design system live? How do we stop people generating off-brand mush? Which tools help us think, and which ones simply produce more stuff?

That last question matters more than most teams want to admit.

AI is very good at increasing the volume of plausible output. More screens. More variants. More concepts. More copy. More prototypes. More things to review, compare, tidy, rationalise and explain. For teams already drowning in product surface area, this is not an obvious win. It may simply create more design-shaped debt.

The danger is not that AI makes everything terrible. The danger is that it makes mediocrity faster and more convincing.

This is why execution quality does not become less important in an AI-heavy design process. If anything, the bar goes up. When anyone can generate something that looks good enough in a screenshot, the designer’s job shifts towards knowing what is actually good. Where the interaction is wrong. Where the flow hides a business problem. Where the visual polish is masking a weak product decision. Because AI is great at copying. But what it can't do yet is sit inside of the mind of an average user and experience an interface for the first time. 

That kind of judgment is (currently) hard to outsource.

The best designers I know were never just screen producers anyway. They were pattern spotters, translators, editors, product thinkers, quality filters and organisational irritants in the best sense of the word. They noticed when the team was solving the wrong problem. They spotted when a roadmap item was really a customer support issue, or when a requested feature was compensating for a broken onboarding flow. They knew when to make something, when to question it, and when to leave it alone.

AI does not make that less useful. It makes it easier to see who had it in the first place.

The problem is that many companies are still managing design as if the old model were intact.

The report suggests designers are already feeling rising expectations around speed, quality and output, while relatively few companies have updated evaluation, compensation, hiring or performance metrics to match. In plain English: people are being asked to work in a new way while still being judged by the old rules.

That rarely ends well.

It creates a familiar kind of organisational nonsense. Designers are expected to use AI to move faster, but there is no shared view of what “better” looks like. Leaders want more output, but have not decided how to measure quality. Teams encourage experimentation, but treat every mistake as evidence that the new tools are risky. Hiring managers say they want AI fluency, but are not sure whether that means prompting, prototyping, coding, systems thinking, taste, or simply having used whatever tool is currently trending.

So the learning is happening sideways.

One of the most telling findings in the report is that peer learning has more than tripled year over year, while designers taking recommendations from leadership has dropped sharply. That rings true. Most of the useful learning I see is happening in small groups, private Slacks, shared demos, messy experiments, whispered tool recommendations, internal hack days and “you need to see what I made this morning” conversations.

People are not waiting for an official playbook. They are trying to work it out from each other.

That is healthy, up to a point. Bottom-up experimentation is often where the best practice starts. But if leadership does not catch up, you end up with pockets of invention rather than organisational learning. One team quietly transforms how it works while another carries on producing static mockups and wondering why it feels slow. One designer builds internal tools that save days of effort while another is still asking permission to try Cursor. One manager encourages tinkering while another mistakes it for distraction. Like a flock of starlings, this can look like co-ordination from a distance, but up close it's just lots of people bashing into other people in slightly annoying ways. 

This is a big part of why I’m helping curate the new Design + AI summit. 

Not because I think the design industry needs another round of abstract predictions. Most designers have heard enough about AI being “the future” to last them several futures. What feels more useful now is a room full of practitioners, design leaders, product people and technologists comparing notes on what is actually changing.

How are teams using AI in real product development? What happens to the design process when prototypes become cheaper than decks? How do you critique work that came out of a prompt chain? How do you stop non-designers creating plausible but incoherent interfaces? What should sit in the design stack, and what should stay as an occasional experiment? How should design leaders hire, train and manage teams when expectations around speed and output have shifted but company processes have not?

These are not theoretical questions. They are showing up in product teams right now.

A PM generates a prototype before design has framed the problem. An engineer ships an interface that looks acceptable but quietly breaks the design system. A designer builds a working tool that changes the conversation with leadership because it feels less like a proposal and more like a product. A team suddenly has ten times more output and no better way to decide what deserves attention. A design leader is asked whether AI should make the team smaller, faster, more technical, more strategic, or all of the above.

Those are the conversations I want to have in the room.

Some design teams will respond to this moment by trying to protect the old boundaries. They will argue that design should remain the owner of design work, that PMs and engineers should stay in their lanes, that quality will suffer if everyone starts generating interfaces. They will be partly right. Quality probably will suffer in many places.

But “please stop using the new tools” is not going to be a durable position.

A better response is to become more fluent than the people moving into your territory. To understand the tools well enough to critique them. To use them well enough to know where they break. To develop new rituals around review, taste, prototyping, research and production. To help your organisation move faster without filling the product with plausible junk.

This is not about designers becoming prompt jockeys or junior full-stack developers. It is about design becoming less dependent on a narrow set of artefacts and more involved in the full act of making. That should be good news. It returns design to something closer to its real purpose: shaping what gets built, how it behaves and whether it deserves to exist.

But it does mean the comfortable version of the job is going away.

If your value as a designer is mainly that you can produce neat Figma files, the next few years may be rough. If your value is that you can understand people, frame problems, make judgment calls, explore possibilities, build enough to learn, and protect the quality of the experience as the organisation speeds up, this could be a very good moment.

The hard part is that nobody has the new playbook yet.

That is what makes this moment interesting. Also irritating. Also slightly exhausting. The tools are changing too quickly, the case studies are uneven, the incentives are confused, and the best examples are often hidden inside teams who are making it up as they go along.

So the choice is fairly simple. You can watch this happen through LinkedIn posts, product launches and second-hand takes. Or you can get in a room with people wrestling with the same questions and start forming your own view.

Design has been too settled for too long. The process is breaking open again.

I’d rather be part of the conversation while it is still being shaped.

Nobody needs more of that.

But I think there’s much more to AI-assisted writing than this comment suggests.

I’ve been pretty lucky when it comes to writing. When I ran Clearleft, one of my jobs was to be visible in the market. So I wrote articles, gave talks, and tried to share what I believed about design, product and the web.

Back then, I could afford to spend a day or two turning an idea into a carefully crafted article. I was also lucky enough to have people around me who could check my drafts and make them better. Not just fixing typos, but improving the structure, rewriting sections that didn’t quite land, and occasionally removing the odd spiky comment.

As somebody with mild dyslexia, it was also incredibly useful to have another pair of eyes on a piece before publication. Getting other people’s input didn’t diminish the article. The ideas were still mine. The argument was still mine. The experience behind it was still mine.

It just helped strengthen the prose.

I don’t have that same setup now. As a solo operator, I’m no longer inside a company where I can casually ask one of my teammates to edit a draft. I also can’t justify spending a day or two every time I want to turn an idea into something publishable. I have client work, coaching calls, investment work, events, admin, life.

So what’s the right answer?

Keep more of my ideas as rough drafts in my notes app?

Lose a day of paid work every time I want to say something properly?

Or just write less?

When you dig into it, this feels like a hard position to defend. Senior leaders have comms teams. Politicians have speechwriters. Founders have ghostwriters. Executives have PR people, editors and assistants.

So what are we saying here exactly?

That it’s fine for large, well-resourced leaders to publish regularly because they have a whole apparatus around them, but individuals with limited time and no editorial support should stay quiet unless they personally craft every sentence by hand?

That starts to feel less like a defence of craft and more like a defence of access.

Personally, I find it incredibly useful being able to dictate a long stream of consciousness into a tool like ChatGPT and have it create a rough first draft. Sometimes I’ll edit that draft manually. Other times I’ll go back and forth a few dozen times in the chat interface, working on the flow, tone and content until it feels right.

That might still take a few hours. But it doesn’t take the days it might once have taken. More importantly, it helps me get ideas out while they’re still alive, rather than leaving them buried in an ever-expanding folder of unpublished notes.

The other day I was listening to Ben Rhodes talk about writing speeches for Obama, and the process sounded oddly familiar.

Obama didn’t write the majority of his speeches. He had other things to do. But effective communication was still hugely important, so he worked with a professional speechwriter.

That doesn’t mean Obama simply asked someone to “write a speech about healthcare” and then read whatever came back.

He brought the argument, the structure, the tone, the lines he liked, the thing he wanted people to feel. Rhodes would turn that into a draft, and then Obama would revise, push, sharpen, tweak and keep working it until it sounded like him.

So yes, you could argue that if Obama “couldn’t be bothered to write his own speeches,” why should anyone be bothered to listen?

But I think most people would see that as a pretty weak argument.

Because the value of a speech isn’t only in who typed the first draft. It’s in the thinking, judgement, editing, taste, experience and intent behind the final piece.

That’s how I think about AI-assisted writing at its best. As a tool to help people get more of their ideas into the world than they otherwise could. And I think that's largely a good thing.

Today, if you want to start a business and you do not already have assets, the options get thin very quickly. Banks are not generally queueing up to fund unproven new businesses with no collateral. Younger founders are less likely to own property, and if they do, they tend to own it later in life, with more debt attached. The old mechanism of “borrow against the house and have a go” no longer works for large numbers of people.

So the funding route splits.

If you come from a wealthy or comfortable background, you might raise money from parents, relatives, friends, or family friends. That money may come with softer terms, more patience, and less paperwork. It also comes with social pressure. You know these people. You see them at Christmas. You know that if you lose the money, the cost is not just financial. In some ways, that makes founders more careful. You are much less likely to spray money around on growth experiments when the cheque came from someone’s pension pot. Or if you do, you probably know that they can afford to take the loss. 

But this route is obviously closed to lots of people. Not just working-class founders, but plenty of middle-class ones too. Most parents do not have £50,000 or £100,000 sitting around to fund their children’s business ideas. The polite phrase is “friends and family round”. The less polite phrase is inherited access to risk.

At the other end sits venture capital.

The problem is that venture capital is not just “money for startups”. It is a very specific financial product with a very specific return model. Most people outside the industry do not really understand this, and frankly a lot of founders only understand it after they have already shaped their company around it.

A VC fund raises money from its own investors, known as LPs. Imagine a seed fund raises $100m. Over the life of the fund, it needs to return enough money to justify the risk, illiquidity and effort of investing in private companies rather than something simpler and more liquid. A 3x or 4x return target is not unusual. So the fund is not really trying to turn $100m into $120m. It is trying to turn it into $400m. 

That changes everything.

If a fund owns 10% of a company at exit and wants that investment to return $100m, the company needs to sell or go public for around $1bn. That is why VCs are obsessed with unicorns. It is not merely greed or Silicon Valley mythology. It is baked into the maths of the fund.

Once you understand that, a lot of VC behaviour makes more sense. They are not looking for nice, profitable, sustainable companies that might make £2m a year and employ 30 people. Those may be excellent businesses. They may make their founders wealthy. They may serve customers well, create good jobs and improve a local economy. But they do not move the needle for a venture fund.

VCs need companies that could become enormous. Usually global. Usually software or software-like. Usually capable of growing very quickly. Usually capable of becoming valuable enough that one or two winners can compensate for all the failures.

This is not a moral failing. It is the model.

The problem is what happens when this becomes the dominant story about startup funding. Founders with perfectly good small or medium-sized business ideas start pretending they are building venture-scale companies. They write decks about billion-dollar markets, network effects and category creation when what they actually want to build is a solid, profitable, owner-operated business. They contort normal businesses into venture-shaped narratives because that is where the visible money appears to be.

This creates a strange kind of market distortion. VCs see more and more companies claiming to be fund-returning opportunities, even when most are not. Founders waste months pitching investors who were never structurally able to fund them. Businesses that should have been built slowly and profitably get pushed towards an unnatural growth model. Some raise too much money, hire too quickly, and lose the discipline that would have made them good businesses in the first place. Others fail to raise and conclude that the idea was bad, when really it was just not a venture-backed idea.

We have become oddly bad at funding normal ambition.

There are, of course, exceptions. There are investors experimenting with “seedstrapping”, revenue-based finance, shared earnings agreements, indie funding, and models where a company only raises one modest round and then aims to become profitable. In those cases, an investor might put in £250,000 or £500,000 and not require a billion-dollar exit. They might be happy with dividends, buybacks, or a modest acquisition. They are not asking every company to become a unicorn. They are asking whether the bulk of them can become a strong, durable business.

This feels much better matched to the majority of companies people actually want to start.

But there are far too few of these investors, and their capital base is tiny compared with venture. So the market remains lopsided. At one end, family money. At the other, venture capital. In the middle, not enough.

Government-backed schemes help, but they are not enough to rebuild the missing ladder. A £10,000 or £25,000 loan can be useful for some businesses, especially sole traders or very lean startups. But it does not replace the old ability to borrow meaningful working capital against a relationship with a bank that understood your circumstances. It does not solve the problem for a founder who needs £75,000 to £150,000 to quit their job, hire one person, buy equipment, build inventory, or survive the first 18 months.

The deeper issue is that we have financialised entrepreneurship while pretending we have democratised it.

We celebrate founders. We tell people to start companies. We run accelerators, pitch competitions and innovation programmes. We talk endlessly about ambition. But the actual capital pathways are still heavily shaped by class, assets and network access. If your parents can write a cheque, you get one kind of start. If you have a house, you may have another. If your idea can plausibly become a venture-scale company, you have a third. If none of those are true, you are often left bootstrapping from salary, credit cards, consulting work, or exhaustion.

This matters because not every good business should become a VC-backed startup. In fact, most should not.

A good café does not need venture capital. Nor does a small software tool for a niche market, a design studio, a specialist manufacturing business, a local services company, a training business, a profitable community platform, or a B2B product that might one day make £3m a year. These companies may never produce a unicorn exit. But they can create wealth, jobs, craft, independence and resilience. They are part of the economic fabric, not failed startups.

We need more ways to finance those companies.

That might mean expanding government-backed lending. It might mean requiring high street banks to do more genuine small business lending in the communities where they take deposits. It might mean tax incentives for patient local capital. It might mean more support for community development finance institutions, mutuals, credit unions, and alternative lenders who understand smaller businesses. It might mean building a proper market for revenue-based finance or dividend-oriented investment, rather than treating everything that is not venture-scale as somehow uninteresting.

The old bank manager model had plenty of flaws. It was probably conservative, relationship-driven in the wrong ways, and full of its own biases. We should not be nostalgic about it. But it did contain one useful idea that we have mostly lost: the idea that a normal person could start a normal business with patient debt from an institution that had some responsibility to the local economy.

We do not need to recreate the past. But we do need to rebuild the middle.

Because right now too many founders are being asked to choose between inherited money and unicorn theatre. That is a ridiculous way to fund a country’s entrepreneurial energy.