Subscribe
Share
Share
Embed
Tom and Jonny dig into the outcomes of Tom's Mostly Working event featuring James Storer from Monzo, unpacking how leading design teams are using AI not to ship faster, but to learn faster — and why the language of "design vs. product" is getting in the way. They get into the state of Figma: is it losing its grip on the design workflow, or is it actually thriving? And they draw an unexpected parallel to the smartphone camera era to ask whether AI will democratise design the same way. Plus: upcoming events, what they're each building, and some honest holiday parenting failure.
- 0:04 — Mostly Working: AI in Design at Monzo — Tom recaps the event with James Storer, prototyping at Monzo, and why the team focuses on learning speed over shipping speed
- 6:11 — Three Use Cases for AI in Design Workflows — Jonny breaks down the emerging buckets: shipping production code, faster prototyping, and building internal tools
- 13:12 — Is Figma Losing Its Grip? — Jonny's spicy take on Figma overreaching, seat cancellation stats from a 90-person design org, and the Adobe comparison
- 18:17 — Figma's Growth vs. The Designer Exodus — Two things can be true: enterprise growth numbers and a slow professional exodus
- 21:29 — The Smartphone Camera Analogy — Did smartphones kill professional photography? And will AI do the same to design?
- 25:52 — Upcoming Events: Berlin, Shoreditch & Brighton — Jonny's "Tools That Shape Us" talk at Hatch Berlin (Sep 18), the live build session at Product Unleashed Shoreditch, and the Brighton workshop
- 35:37 — What We're Building — Jonny's prototype hosting tool, a Notion CRM, and Tom's AI-powered family holiday journal idea
Creators and Guests
What is Near Future Podcast?
A regular podcast covering design and AI from the founders of Near Future, a boutique AI consultancy focused on teams that care about craft. We cover both what we're seeing on the ground and industry trends, ways of working and occasional guests from the design world.
Jonny: Hi, and welcome to
the Near Future Podcast.
This is episode two with Tom and Johnny.
We are gonna get straight into it.
So first of all, Tom, I would love
to hear about the event that you ran
yesterday, Mostly Working: Fire Away
Tom: Yeah.
Let me, let me tell you about it.
So we had, these are events.
This is the fourth one we've run now.
They're monthly-ish, and they are
mostly for, senior plus designers who
are exploring AI in some capacity.
so it's really a chance to get practical
hands-on and get a sort of glimpse behind
the curtain of what people, designers,
practicing designers at leading companies
are doing, in incorporating AI into
how they work and how their teams work.
So yesterday we had, featured
James Storer, local London, or UK
consumer design Extraordinaire.
at every, every consumer company I
can think of in London, a consumer
startup related company in London.
and most recently has been at Monzo.
He joined there nine months ago
as a staff product designer.
and it was a, it was a great morning.
really interesting hearing his
perspective on how he's building out
AI infrastructure for, prototyping
at, at Monzo more broadly.
I have a bunch of reflections
around that, but a couple of
things I wanted to call out today.
one, was this interesting or reflection.
He didn't really mention
the word design that much.
I think this relates to something else
I've been talking with other leaders
in companies and teams about recently,
which is, this idea of an internal
stack rank of like, oh, the product
managers are doing loads of stuff with
AI, but design is further behind or, or
maybe design is much further ahead and
product's behind or engineering's behind.
and there's kind of this interesting
adversarial competitive relationship
between these different disciplines.
But the thing that really s- came s-
through very strongly with how James was
talking about it is team was, less focused
on what designers are responsible for and
more about how to build bridges with other
disciplines and focus on the outcomes
that matter most to the business or to
users and the artifacts that are kind
of shared across different disciplines.
So specifically, the wedge they were
focusing on was around, learning faster.
So that wasn't at all related to shipping
designs to production more quickly.
although that's a common theme
in the conversation around this.
It was much more about how do we
learn whether this is even the right
direction as quickly as possible.
So a lot of their experiments have
been around, doing things to accelerate
or improve the quality of prototyping
that helps guide more effective user
research, helping product teams more
broadly, generate or create prototypes
that will get and ideas in front of
users to test much faster to lock in, a
direction that feels like there's more
conviction behind it to move forward.
So the, the theme I was reflecting on
around that is the, the importance of
language and focusing on the artifacts
and the outcomes rather than like
design does this or product does this.
think that has a nice sort of side benefit
of having some shared, shared ownership
of what is most important to the overall
team rather than, what is most important
to designers or product managers or
Jonny: Mm.
Tom: So
Jonny: interesting
Tom: yeah, yeah, that, that I think
that was sort of like, yeah, one
really interesting piece of it.
And I think the other that sort of
ties into that is this idea of not,
trying to solve everything related
to AI all at once, but being really
specific about where is the, the
highest leverage point right now.
And for that team, it was really about
that sort of initial learning loop and
product discovery, rather than just
trying to get something into production
quicker, which on the surface, if
you're looking at metrics of the amount
of change that's being shipped to
customers week by week, it probably
doesn't move the needle that quickly.
but there's all this foundational work
and this foundational muscle building
in how the team think about using AI
is, long-term, huge thing that is,
building up as an asset to the team.
So I thought that was just quite,
liberating as well to not have
to have this emphasis on like
caring or tran- directly forcing a
translation between AI and faster,
Jonny: Hmm
Tom: they're sort of building the muscle
and the foundation across the team that
puts a much more solid foundation in
place so that when there's a bit more
maturity around how things, workflows,
tools for actually shipping to production,
the team is really well positioned to
take advantage of that and to establish
standards and, and ways of working
that are more in line with where the
tool set is at that s- at that time.
So bunch of thoughts there
Jonny: Awesome.
So it sounds like I, I've seen
a little bit of James' tool.
I wasn't at the event yesterday, but
What you're describing is
effectively no real goal around
production-ready code for this.
It is pure, pure exploration for--
As you know, this is what designers
have been doing forever, is exploring
ideas, trying to validate, trying to
get to something that feels good, that
feels appropriate, that will work.
And actually, this is really just
a way to bring that to life with
the tools that we now have to bear.
I was having a conversation with a
director of design at a very fast-growing
company yesterday who was talking about
building internal tools for themselves,
and it made me start to think that maybe
there are these-- It's hard to bucket this
stuff up, and it's, and it's, it's messier
than, than what I'm about to describe.
But there are three-- starting to be
three clear use cases for why you--
where you would implement AI in a,
in a design workflow, and potentially
reaches into product and research
and engineering at the edges of this.
But, one is, I can ship production
code, and that might be bugs.
I'm squashing bugs or, like, tweaking
pixel alignment in the live product.
There's, what, what James, I think,
is describing, which is, "This is just
another tool in our tool- toolkit to
be able to prototype faster, to p- be
able to put something higher fidelity
in front of a user or, better describe
what we want to the engineering
team with no actual code handover."
And then there's the sort of meta one,
which is also interesting, which is what
can we build for ourselves by way of
tools that we then maintain and sort of
have as, something new in our toolkit
that then will allow us to do all of
the other things that we do better.
So that might look like workflows for
better research, analysis or, tools
to, build like a mini Photoshop,
but only using your brand colors
and your assets, for asset creation.
There's all sorts of different things
you can do within there as well.
But it feels like in the last six months,
as AI has crept into more, more of the
product lifecycle outside the engineering
organization, we can have a bit more
of a nuanced conversation about what
exactly we're using AI for, and it's
not just use AI for design full stop.
It's, it's appropriate here for our
organization because we're Intercom
and we want everyone to be able to ship
production code versus we don't do that
here, like the engineers ship production
code, but there's other interesting ways
we can use AI as part of our workflow.
It's interesting what you're saying
also about design and product
having a shared conversation and
that tribalism breaking down.
I suspect that will also be
really culture dependent as well.
We've definitely seen cultures
where that wouldn't work, as a
as a duo, in, in places in, in,
companies that we've partnered with.
So, there's, all sorts of nuance and
challenges and, and things like that.
And I suppose maybe this is a big vote
for like find your own path through it
rather than look at lots of Twitter posts
and think that's what you should be doing.
What do you think?
Tom: Yeah.
Yeah, 100%.
although I do think I definitely support
find your own path through it, but I
like the idea of getting really crisp and
precise about what is the most valuable
place to start, the place that has--
where AI gives most leverage to teams
and helps them try things out, test new
ideas, and find enough value in just
that step of the process, rather than
trying to redesign the entire product
development life cycle, Because I think
that is, very disruptive to a lot of
teams, but it's also there's so much
evolving and moving quickly with design
tooling and various other things that I
think it's hard to completely overhaul
things at this current moment in time.
But I think there's a lot that can
be done to target specific things
that help build the experimentation
and the muscle into things.
But I think your point about
culture is completely correct.
And as someone who has previously
spent time working at Monzo, I think
there is a very strong culture is very
cross-disciplinary, cross-functional,
and focused on impact and outcomes
to the business and to customers.
and that's not necessarily the
same culture in every organization.
so yeah, your mileage may vary there.
there was maybe one slight, twist on
that, that James mentioned, which is,
his-- he built a bunch of prototyping,
tooling that sounded like it was sort
of soft rolled out to the team and
people could start playing with this
stuff, but it wasn't forced on anyone.
It wasn't mandated that everyone
should use this, but enough people
from enough disciplines found enough
value in using it that that sort of
pull started the momentum naturally.
And I think there is something subtle
there that's less about culture
change across the specifics of an
organization and more about change
that people feel a part of and that
they, about, or at least they can see
the value for themselves before it's
Jonny: Mm-hmm.
Tom: them.
That I do think is maybe more-- a more
universal quality that I think is worth,
enabling in whichever approach feels
right for the culture of your team.
Jonny: Finding this low pressure
state of play or, exploration and
yeah, because there is this meta
goal that exists more or less maybe
within different organizations, which
is get everyone comfortable so that
when we do decide what we want, we
don't have to cross that bridge.
There's a, there's a base
level of comfort with it
Tom: Yeah.
Yeah, exactly.
So yeah.
it was super cool.
It actually raised,
it was sort of hinted at with James, but
this led into other conversations I was
having with other designers, other design
leaders who were there afterwards, around
the role of, Figma in the design process
and Figma as, as the source of truth.
And I was kind of surprised that
it feels like if you just read the
internet, all design teams everywhere
have have migrated away from Figma and
are now working in code all the time.
but a consistent theme that I keep hearing
is, AI tools are really good for discovery
and prototyping and trying out new ideas.
many teams who are even quite AI advanced
are then taking the concepts that they've
put in front of users and, and have
some confidence behind are bringing
those back into Figma and are spending
days manually crafting interfaces
Jonny: Mm-hmm.
Tom: hand over more easily with engineers.
and I was kind of surprised that the--
was true in like early stage startups
that have a single designer on the
team through to much bigger companies
that have, a substantial design team.
So, as much as we've had advances in
what AI makes possible, that handover
point and that sort of source of truth
of what is, what is the real design, at
least right now, still in Figma's world.
Jonny: Hmm.
Tom: but I'm curious
about your perspective.
There's obviously been a bunch of
changes recently or last week, I
think, Figma rolled out a- their agent,
Jonny: Yeah
Tom: skipped code and allowed
you to design straight into
production, at least in theory.
but I think, it'll be interesting to
see how that unfolds over the next
six months as to whether Figma remains
playing the role of source of truth or
how much that's gonna move toward code.
curious if you have any
thoughts on that, Johnny?
Jonny: Well, I have spicy opinions
about Figma and, that come from-- They
are not Figm- in any way Figma's fault,
but just come from a m-more broad
opinion, which is that these tools have
overstretched themselves in terms of how
much they want us to do within them to
the point of not being useful anymore.
They're appropriate for exploration,
which is where they started, and have
now become-- started to reach into
full sort of production suite as well.
And then you start to get to the source
of truth being in the wrong place, which
is-- which I do think is a problem.
I actually do have a good anecdote,
which I hadn't told you yet, from a
conversation this week, which is an
organization with 90 designers, so
big, you know, decent sized design org.
They put in place a, an automatic
Figma cancellation, seat cancellation
if you don't open Figma for 30 days.
So after 30 days, if you try and log into
Figma, you'll find that your account no
longer exists, and you then have to go and
ask IT or whoever it is to, to get your
seat back, and you have to justify it.
And he said that in the last week,
he had 12 of those requests, and
that means sort of two things.
I think that means, you
know, 12 designers out of 90.
I mean, presumably some are already
out of Figma by this point, but 12
designers out of 90 in any one week not
having used Figma for 30 days when they
are full-time designers at a design--
at, at, at a company that is-- that
values design tells you something.
But then the fact that they
actually did want the seat
back tells you something else.
There is some need for what
Figma offers very well.
it's an excellent tool
at, at a lot of things.
but I wonder if some of those things
that Figma does very well are moving
out of the center of gravity and, you
know, the, the-- Figma is no longer
the sun and tools revolve around it.
It is becoming,
a, a tool that sits more at
the fringe of your workflow.
A little bit like, to be honest, Adobe
has been for a very long time for me.
I held an Adobe account for years because
sometimes I needed to create something
for a print job or, use Illustrator for
some old file that I needed sometimes.
You know, like terrible reasons
to be spending 100 pounds a
month on, on the software.
And I've been, free of
Adobe for over a year now.
I'm very proud of that.
But you do start to wonder if Figma
doesn't look like everyone suddenly
switches and starts to just look like
It becomes less important as
part of a workflow, and then that
annual renewal for, for Figma
gets harder and harder to justify.
so I mean, so I, in, in that
sense, it will be patchy.
There'll be-- This organization that I
spoke to is very f-f-far forward, I think.
They're, you know, they're working almost
entirely in code as a design organization.
Like, that's where they, that's
where their center of gravity is.
They're gonna be in a m-massive
minority at the moment.
Most design orgs will be very much still
in Figma, and in fact, a, a client of
ours have-- they are still Figma-centric,
even though we've been working with
them on, using code-based tools.
They're-- It's, it's an enor- It
would be an enormous lift for them
to do anything other than still base
themselves in Figma for the near term.
But it does creep.
It creeps along, and I remember opening
Figma for, for the first time when we
were all in Sketch, and everyone was
joking around joining the same Figma file
and messing up each other's designs and
saying, "Why would anyone want this?"
So, you know, I don't know if that, when,
when that will have been 2015, 2016 maybe.
But,
we're, we're, we're in the middle of a,
a change again, and I think it-- Figma
need to move very fast with their agent
stuff or whatever they-- however they
manage to work out how to stay essential.
They need to stay essential,
and their shipping cycle isn't
massively fast on this stuff.
They announced Make, you know, a year ago,
and it's just about good now, I suppose.
so, so they, yeah, they're--
I don't envy their, the
decisions they have to make now.
But I do also have to disclose
that I would love for us to not
be so tied to Figma or s- nothing
personal to Figma, but th-those
kind of tools, over the medium term.
So, I may be talking my book, as you say
Tom: to a counterpoint to that
argument, I know, Figma's, valuation
has increased by, I think, is it 40%?
Jonny: Hmm.
Tom: don't quote me on these facts.
I, I, I remember something about
40% increase in, in some numbers
that are important to the business,
recently, which seems to be in direct
competition to the narrative of
designers moving away from Figma.
curious if you have any theories about
why that might be happening, or if that's
Jonny: Hmm.
Tom: blip, or if there is this bigger,
bigger use case that may not be as obvious
to product designers who are using Figma
or typically traditionally associated
with the sort of core customer for Figma
Jonny: Yeah.
I don't know.
I think they beat earnings.
I think that was the thing that
happened, but I'm not sure.
I don't, I don't, I don't have a detail.
But
yeah, I think two things can
probably be true at the same time.
I think they're probably doing well
in the enterprise and, you know,
their customers are growing and, will
undoubtedly be benefiting from that.
I haven't looked into their,
their, their financials.
I suppose I could.
But I think when you look at sort
of generations of designers or
generations of product teams, is
the next generation committing
to Figma when they don't have to?
Maybe still are now, but will
they be in a year's time?
Hard to say.
so I think that's where
you sort of get to this,
disconnect between what the numbers
look like within a business and,
and the future of that business.
And maybe Figma is no longer
a growth stock to hold.
It's, it's like a, a safe stock that
they'll still do well for a while, but
they're way down on their IPO price,
but that's maybe unu- not, not unusual
Tom: Yeah.
that's interesting.
Hearing you talk about that
made me think of the amount of,
people that maybe wouldn't classically
consider themselves a designer but
have increasingly been doing design
work through these AI tools and,
and what they've made available.
People, using Claude, Claude Design
and, var-various other design tools
that aren't classically Figma.
And I'm kind of curious if there's a
similar effect to when the smartphone
introduced cameras, and then everyone
started becoming a photographer.
And then I, I actually, when I first
got my smartphone and in the, back in
the day and started taking pictures
of things, I suddenly got a lot more
interested in photography, and then I
took this darkroom photography course
and could like learn the mechanics
of using like analog photography.
And I, I kind of wonder if there's any
sort of underlying themes of expanding
the number of people who might consider
themselves designers, and that having
this long tail effect of actually
audiences has increased massively
because now there's all these, like a
much larger pool of people who might
consider themselves now a designer, and
therefore the audience is, is much larger.
Even if there are, at the same
time, people moving away from
Figma who are the sort of hardcore
professionals that have been-- who have
Jonny: Mm.
Tom: 10 years in it day-to-day.
Jonny: Yeah.
Tom: know if that-
Jonny: The, the photography analogy
is really good because I think
there were quite a lot of losers
as smartphone cameras became good.
You know, the, the traditional
camera companies were big losers
from, from people not-- no longer
needing to buy a personal camera
just to take pictures at all.
And then there were, and at the
same time, the market for people
taking pictures massively grew.
So presumably there's win-- I mean,
Apple presumably is a winner from that.
You know, more, more people
want a smartphone suddenly
because it's got a good camera.
And then maybe there's some also second
and third order beneficiaries of like
people getting into-- more people
getting into photography to the point
where they do buy a high-end camera,
and maybe the sales of those go up.
But, but I do think that there's--
that's a possibly a good analogy, which
is more people get into design, more
people are able to design, the floor
rises and, you know, the-- we get
engineers and product managers and CEOs
all, all, you know, being able to put
together something coherent increasingly
And then the question is
whether there's still a demand.
I think there's still a more of a demand
for professional photographers than there
were in the years before the smartphone.
So I don't think that market
has been damaged by the
smartphone is my understanding.
And that may well still be true.
There'll still be
designers who are valued.
I would hope so anyway, but that feels
the tools, w- the winners and losers
amongst the, the sort of companies
that support that industry, who knows?
Like it could still be Figma, but they,
they shouldn't take it for granted.
and you look at like Canva, which is much
more of a, a tool that allows anyone to
design and is much lower barrier to entry.
Figma's quite complicated.
You have to sort of know how auto layout
works and like what all the different tool
shortcuts are and what all the buttons do.
It's a, it's a professional grade tool.
So whether this new group of designers
that are the equivalent of you sort
of getting into it more would ever
want anything that complex or by then
actually they're working in tandem with
an agent and maybe that's Figma's agent
or maybe it's someone else's agent.
It does feel like Figma going into
agents puts them in competition with
a lot of other companies that they
weren't previously in competition with.
So,
Tom: It's
Jonny: so that's, yeah, that
Tom: I imagine the same is true
from the other side though.
if Claude Design are coming out
with a design tool that seems also
directly stepping onto Figma's turf.
So,
Jonny: Yeah.
The good thing for us as
consumers is competition is great.
It means we get innovation, it means we
get fair pricing, et cetera, et cetera.
So,
the net beneficiaries of all of
this is not in a monopoly, which is
what Figma has effectively had over
interface design, but actually in the
competition, which is forcing them
to ship really interesting features.
And whether those features are appropriate
or enough is for the market to decide.
But,
be fun to watch at the very least.
Tom: Yeah.
Yeah, definitely.
I, I feel like you could listen back to
this episode in a year, and I think it's
gonna be really interesting to see where
Jonny: Yeah
Tom: source of truth for these types
of decisions lan- lives at that stage,
'cause I could see a world where that--
where Figma have cracked this challenge,
and there is like a, a age agentic and
sort of code-oriented layer to Figma that
has managed to solve for this problem.
Jonny: Yeah
Tom: Figma will be in a really
strong position, but that's, that's,
that's a big, that's a big ask.
and maybe one of these other
AI native organizations will,
solve the design tool part of
Jonny: Hmm.
Tom: base instead.
Don't know.
Could go either way.
Just check
Jonny: It's the-
Tom: a year and see how it is.
Jonny: yeah, it's theirs to
lose 'cause it's very sticky.
Like, moving off Figma is hard at scale.
Tom: Yeah.
Jonny: yeah, we'll check back in.
Re- note to self
Tom: Yeah.
okay.
Shall we move on to, events?
We have some events coming up.
Jonny: Yeah, we do
Tom: we have a bunch, a
bunch of stuff booked in.
So, you're giving a, a, a, a keynote
or a, a presentation, a talk, at Hatch
Conference in Berlin in September,
which sounds, super exciting.
do you, do you want to give a flavor
of what that talk will be about?
Jonny: Yeah.
Tom: Or is it,
Jonny: and
Tom: to go into
Jonny: no,
Tom: there?
Jonny: no, I, I mean, I, I decided
what it was called, the, the talk,
which it's funny how, these things,
the tail can wag the dog sometimes.
But the talk is called
"The Tools That Shape Us."
And I knew I wanted to talk about tools.
It's very much what we've just
been talking about, in a sense.
and how this new diversity of tools and
this choice that we're, we're getting,
we can build things in different ways.
We can choose exactly how we're set
up individually or as organizations
around our design tools for the
first time in-- since forever.
You know, engineers have had this,
that they can choose their exact stack.
They can choose everything from
their code editor through to the
individual, packages they put into their
software and everything about their
developer experience they can, they
can design or build for themselves.
Whereas as designers, we have been
locked into these, these tools
that, that we've been given are
industry standard and proprietary.
So in this world where we get to build
our own tools, what does that mean for us?
do we have to become tool
maintainers at this point?
You know, who owns them?
And how much do we really want that
versus consistency across an industry?
And then as we do shape our
own tools, how does that impact
our work and us as individuals?
And so, I mean, the history is
awash with examples of tools shaping
tool users and all sorts of things.
So I'm excited to put it together.
I think it will be great fun for me
to think through this and come up with
a coherent, narrative for 25 minutes.
But yeah, it's in, in
Berlin, 18th of September.
There are still tickets, I think.
And yeah, I'm on, I'm on main stage at
2:30, and Paula Scher closes a couple
of hours later on the same stage, so
it's pretty, a good pinch me moment.
Tom: Yeah.
Yeah, big, big name.
I'm sure that's gonna be a
fascinating talk as well.
Jonny: And, and then, we also have,
well, more th- in the very near future,
probably before this even comes out,
so by the time anyone listens to it or
watches it, we'll have completed this.
But we have a 15-minute,
build your own tool session at a
Product Unleashed event in Shoreditch
tomorrow, which is the 5th of June.
I think there are still tickets for that
as well, but we're running it twice.
And Tom, what do you think?
I mean, we've been planning this today.
How do, how do you feel about it?
Tom: I feel excited for it.
I think it's one of the, the, the classic
of agreeing to do something and being
like, "Oh, that's like a fun idea."
And then 24 hours beforehand, you're
like, we actually need to build this now.
We actually need to make this good."
but, but I feel, I feel pretty good.
So I think the, the idea of actually
building something and trying to do
that live on stage is, I think a really,
really exciting, idea, but we have to
pray to the, the Wi-Fi gods and the
token gods, make sure we don't use too
much of our tokens before, beforehand.
would be a grave error to run into
Jonny: Yeah
Tom: stage.
but, but I also think there's,
there's something, m- more
exciting and, cool about trying
something from scratch, on stage.
And yeah, I f- I feel,
I feel good about it.
We're going to beâ¦
I don't know if we should mention any
spoilers about what we're planning to do.
but I think, I think the conversations
we've had in planning it around how
serious should it be versus how,
like, fun and silly, have been, kind
of interesting to, to think about,
like, what an, what an audience at n-
at, like, 8:00, 9:00 PM on a Friday
night is interested in hearing about.
Probably less, less on the
serious end of things and more
on the what's fun and engaging.
So I think we're gonna lean into
that, and, I think it's gonna be
a good, test of how we improvise
under those kind of, constraints.
But, yeah, it's, it's
amazing to see evenâ¦
Well, I'm kind of curious to see actually
how, people who are fairly, fairly
new or even experienced with this,
building with AI already, whether this
will feel like new territory for them.
Like, oh, I hadn't really thought
about the potential possibilities
when you can actually make, make
something usable in 15 minutes, versus
whether it will, whether 15 minutes
is enough time to reach the point
where it's, like, actually meaningful.
Don't
Jonny: Yeah.
Tom: What are your thoughts?
Jonny: I think one thing that we learned
very quickly when we started running
trials of this this week is two minutes
of Claude thinking when you're on your
own and you could read the internet
or check your emails or whatever, two
minutes feels like not a very long time.
Two minutes when you're imagining
yourself on stage and you're all
just watching Claude thinking
feels like a very long time.
So we really had to-- I think we planned
to do this before we really thought
about what we would be doing in the gaps.
W-watching someone live build
something for 15 minutes when
they're working constantly throughout
might be kind of entertaining.
Watching Claude work is less
entertaining, I suspect, for people.
So we've had to think about how to
do crowd work and fill, fill the
void with, interesting anecdotes
and things to think about.
So it's turned into a bit more of
a, bit more of a talk than maybe
I would've imagined at first,
but I think it will be good.
I actually think it'll be interesting
to see where we get to, and that means
that even if, even if we run out of
tokens or the internet fails, then
we'll be able to sort of get to the end
and it won't be like, "Well, everyone
go and get a beer because we're done."
And, the dream is we get something live on
Link by the end of the 15 minutes as well,
so people get to walk away with it, and
that has involved building some software
as well, which is my favorite thing to do.
So I'm in my happy place doing it.
Tom: Great.
I feel like, so I justâ¦
I think we've both been asking
Claude, like, do you have any
tips for how to go faster in a
Jonny: Yeah
Tom: And I feel like there's
this interesting point of, like,
you can use a faster model.
We're probably gonna use Sonnet 4.6,
and then you can use lower effort,
which in theory would make it faster.
where is the line between, like,
low enough effort that is still it's
still sort of fairly decent-ish,
Jonny: Yeah
Tom: versus just, like, purely
optimizing for speed, and it can
be complete rubbish on stage or on,
Jonny: Or just not work.
It would just build something that
doesn't work, and then, and then
you've got the most boring scenario,
which is where you're debugging live.
That's not what you want, so
Tom: Yeah.
Yeah.
So I think, I think a few more test
runs at like that effort level and
getting that calibrated to something
that feels right, feels important.
But
Jonny: Yeah.
Tom: who knows?
Jonny: Yeah
Tom: It might fail completely, but
hopefully someone will take something away
from it even if it does fail completely.
one other thing for this workshop
is that it is all, it's a preview
of what is happening in September,
so we're gonna be running
Jonny: Hmm.
Tom: four-day workshop, for
Product Unleashed, which is an
event happening in Brighton, inâ¦
I think it's in September.
I forget the exact
Jonny: 24th or 25th?
One of those days
Tom: Yeah.
So, s- oh yeah, of course.
It's the week after Berlin.
Jonny: It is indeed
Tom: yeah, so, guess we
can make it into a tour.
We should fit in some other
dates somewhere in between, I
don't know where, or something.
Jonny: Yeah, we could do a tour poster.
I've, like, always wanted to doâ¦
You've probably done tour posters
already, Tom, but I've never done one
Tom: Yeah.
I, I have and I- it was my favorite,
probably my favorite part of, that, that
sort of poster design phase of my life.
Jonny: Yeah
Tom: so yeah, maybe there, maybe
there's a chance to do that.
Maybe we should find some other
companies or events that are
interested in, doing stuff together
in Berlin, London, Brighton.
So if you're listening to this and
you run a company that wants people
to come and do things, let us know.
but anyway, so the event
tomorrow is a preview of what's
happening in, in September.
So the event which, have yet to
firm up the full content of what
that workshop is gonna be like.
It will be building on and inspired
by a similar theme of helping people
build, build with AI senior designers,
design leaders building with AI to, make
meaningful, useful changes to, to how
they're operating and really amplifying
what, what they're capable of doing.
Jonny: Yep.
While, while keeping the joy
Tom: Yeah.
Yeah, yeah.
Keeping the joy, keeping the fun.
That is, definitely
Jonny: Absolutely
Tom: so I think we- we're probably coming
up to the end of our recording time.
Is there anything else that you've been
thinking about or bu- building recently
that you wanted to share, Johnny?
Jonny: Yeah.
Well, I'm building something, and
it's not quite ready for primetime
yet, but I am quite excited about it.
I've-- Through conversations over the last
probably six months with design teams,
I think we've seen that one of the real
pain points, not just design teams, but
more, more broadly non, non-engineering
teams, one of the pain points is actually
publishing stuff and getting it live.
We've got at least two, maybe more
examples of scaled design organizations
where Vercel and Netlify have been
banned across the board because people
build something in local host, and then
they're like, "I need to share it with
someone," and then they'll just like
set up a personal Vercel account, and
then that prototype will live, live
on the internet forever and ever, way
after they've left the business or way
after, it should be on the internet.
You know, it's built for one user test
the next day, found 10 years later on
your personal Vercel account isn't ideal.
So
it feels sort of unsolved, and as an
extension of that, even being able to
run code in a, a cloud environment,
not locally feels beneficial.
So I've been building
something in that space.
I'm hoping that we get to test
it tomorrow at this event.
it's consumed a lot of my time,
actually more on the infrastructure
side more than the design side.
So I sort of feel like I've done the
anti-designer thing of building something
that's a complete mess to look at and
then hoping I can clear it up at the end.
Claude has made way too many of
the design decisions so far, so I
need to clear, clear all that up.
But, excited to get something out
and see what people think of it, so
hopefully in the next couple of weeks.
The other thing I've been building is
we've finally decided to get serious
about how we run processes at Near Future.
And, so I've been building a CRM entirely
in Notion, and I think it's pretty good.
We'll see.
We'll see if it scales as we get
deeper into, our sort of new business
process and pipeline and things.
How about you, Tom?
Tom: Yeah.
Yeah, always good examples there.
Well, the one, one thing I've been
thinking about but haven't actually
done, I was away on holiday last
week, and, a good chance to disconnect
and to not on my laptop at all.
I didn't take my laptop with me.
but I still was thinking about AI and
what is relevant, what is useful today.
something that I used to do before having
kids, and now I have two young kids and
feel like less time for this on holiday.
But I would used to, maybe write
a journal, while I was away, maybe
it was throughout the course of the
time away or every day of, like,
what we got up to, what we did.
didn't have the energy for that this
time round, but I was thinking about the
idea of coming home from a holiday and
putting, like, your phone in the middle of
a table, with voice transcription on maybe
Granola or Notion AI notes or something.
And then just asking everyone what
their, their favorite part of the trip
was or what their favorite memory is.
maybe even showing some photos of
different things and asking likeâ¦
having a conversation as a family
around the table, of like, "What
were the best parts of this trip for
you or the most memorable parts?"
And then, turning that transcription into
something that, like maybe packaging it up
in a, in a book or, or something that you
can, like, revisit in a, a year or two.
and I feel like it's a
like, I like the idea of it.
I tried, I tried to do it, but then
I realized my kids are five and two,
and so the two-year-old can't speak
properly or he c- he can barely speak.
the five-year-old, every time I sort
of got to a point where I was maybe
like, "Oh, maybe now's the right time
to do this," was too hungry or too
tired or too something else that it
just wouldn't have led anywhere good.
So it's a concept that might work for,
Jonny: Give it five years.
Tom: yeah, older kids or, or
maybe no kids at all, as a way
of just like, I don't know.
The idea of, like, focusing the
interaction about, like, actually
just sharing memories together.
Jonny: Yeah
Tom: But a byproduct of that is recording
that transcription and then feeding
that into something that has this sort
of shared, shared document of, of the
mem- most memorable parts of that trip.
could be fun.
So if you're listening to this and,
about to go away on holiday somewhere
or just come back from holiday and
you think this might work, love for
you to try it out and tell me if this
actually was a terrible idea or not.
yeah.
There's something about that interaction
with, like, knowing that you're being
transcribed that probably changes
the dynamics of what you would say.
but at the same time, you're
not gonna give-- get everyone to
individually write a, a journal
and then collate that together.
It's like no one wants to do that.
But, but yeah, I don't know,
maybe there's something fun there
Jonny: I like it.
It's a, a granola conversation.
The problem with young kids is you
just-- planning is futile, isn't it?
So that conversation will happen,
but it'll be in the car while
there's background noise and snacks
and, you know, it's, it's not
gonna be a structured conversation.
It's gonna beâ¦
Well, at least if, if your two are
anything like mine, it'll be some random
blurted out statement at some point
in the future that you don't capture.
But
Tom: Yes.
exactly.
Or there's just like very
strong recency bias or like
Jonny: Yeah.
Tom: Like,
we actually, we did get, on
the way home from the airport
when we landed back in London,
immediately after that w- I
asked my five-year-old, "What was
your favorite part of the trip?"
And he said, "Getting, getting the
toy from McDonald's, on the way home."
Jonny: Could have been a cheaper holiday.
Yeah.
Tom: yeah, could haveâ¦
Didn't need to go all the
way to Portugal for that.
Jonny: well, hopefully you're nice
and rested and ready to vibe code
some design tools with me tomorrow
Tom: Yeah.
Yeah, I feel may- maybe not rested,
but I feel, ready to work on some
design tools and, yeah, I think
that's gonna be a lot of fun.
Jonny: Right.
Well, I th- that's it.
Is that it?
We got to the bottom of all
of our ideas for, for today,
so I think we should call it.
Thank you anyone that has made it to
the end, and we'll see you next week
Tom: Yeah.
See you soon.