Understanding is the new bottleneck
Your agents are writing code, but do you understand what they’re doing? argues we can use agentic systems to help us understand their output. Basically, bootstrapping our understanding of the system. I distinguish between the work we do and the meta-work that enables it: AI can expedite both.

AI math breakthrough
Seemingly, a contradiction to the value of tacit knowledge when interacting with LLMs: Jarred Sumner, an Anthropic employee, coaxed Claude to make progress with “the most notorious problem in all of math,” the 167-year-old Riemann hypothesis. The kicker: Sumner himself didn’t understand the problem. Instead, his contribution was giving Claude pep talks. I take most everything from the frontier labs as potential propaganda, but this case raises interesting questions. Perhaps tacit knowledge doesn’t matter as much? (WSJ gift link)

LLMs for theory-building
There are three kinds of reasoning, and LLMs aren’t equally good at all three. Alas, one of them — abductive reasoning — is essential for theory-building, and therefore, strategic foresight. explores how we may architect systems to compensate for LLMs’ shortcomings in abductive reasoning. Bookmarking this one for some work I’m doing now.

The first Unfinishe Conversation
Greg and I hosted author for the first Unfinishe Conversation, a new series on how leaders can steer through this time of change. The subject of our first conversation was Stef’s new book, What Your Machines Should Do. TL;DR: AI is an accelerant, but that doesn’t mean you’ll move faster in the right direction. And yet, as my friend put it, you must still move faster.

has an upcoming book called What Your Machines Should Do. It’s about how organizations can use automation more intentionally — that is, to support their strategic agendas.

We read a preprint and were pleased to discuss it with Stef in the first of our Unfinishe_ Conversations, a new series about how leaders can successfully navigate the current moment.

One of the main takeaways: AI is an accelerant. It’ll get things moving faster. But that doesn’t mean they’ll move in the right direction. And that, of course, is the key.

Transcript

(AI generated — likely contains errors.)

Greg: Well, hello and welcome. Greg, you and I have done several live stream conversations, and we decided to do something a little different today, and we have Stef Hutka here. Stef, is that how you pronounce your surname? I’ve always called you Stef.

Stef: Yeah, no, that’s great. Yes, I think more than the North American version, hutke, the Euro version hutke, I’ve really… I’m happy with either, so you did great.

Jorge: Well, welcome. You are our guest in the very first of what will hopefully be a series of conversations about a whole range of subjects, but usually hovering around this moment of change that we’re going through, right? And I don’t know, Greg, if you have any words of welcome for Steph. This is the first time y’all meet, right?

Greg: Yeah, it is.

Stef: Exactly.

Greg: It’s so interesting to, like, have read something before you meet… Most of the people in the UX community, I know them before the book comes out, and I read the book, and I’m like, “Oh, that’s you.” You know, like, you can connect the dots between the two. But this is the first time I’ve actually read sort of a book from our community where I actually haven’t known the author.

That just means that we haven’t bumped into each other along the way. And, yeah, I’m excited to get into the conversation today because I think you posit a bunch of really thoughtful and maybe, hopefully optimistic points of view about where we could be. And, you know, Jorge and I have been on this conversation for a bit around, uh, we’re not, uh, you know, Reid Hoffman has this two-by-two where he has, you know, zoomers and doomers and gloomers and bloomers, right?

And, um, I’m not a zoomer, but I’m not a doomer, you know, and I’m not a gloomer either. So I guess I’m in the bloomer category, which is I believe we have agency in creating a future that’s viable for us. And part of the thing that’s interesting about your book is I think there’s a story or a thread about that in it and how to do it.

So I’m very excited about the conversation we get to have today.

Jorge: I’m very excited as well. I really enjoyed the book. And it’s like you have a book, right? So we’re gonna get into the book, but before we do, would you mind giving folks tuning in a bit of an overview of your career, who you are, and what brought you to write this book?

Stef: For sure. So I wear a couple of different hats. I’ll start with the present. So the first hat is as a researcher. So I’m the founder and head of design research at a boutique design research consultancy called Sendful. And so anyone who does any action sports, especially anything on trails, there’s the term full send, where you’re going to do some sort of action.

You’re fully committed. It might look pretty wild from the outside, but you actually need to have a lot of experience and expertise to kind of get to that point. But there’s… You know, you’re fully on it, and I love that idea of that sort of energy, that forward motion, that expertise behind it, and wanted to kind of play on words.

So that’s where Sendful comes from. I always clarify kind of where that name comes from. Then the second hat is as an educator. I teach UX courses at UC Berkeley, Introduction to User Experience Design and two new courses that I’ve designed and taught, one on systems thinking, Designing Future Systems, and AI, which was most recent.

And that wrapped up a couple months ago, and that could be fun to get into. I teach primarily professional master’s students, so designers, product managers, design researchers, and that’s a really interesting space to be in. And particularly Intro to UX Design, I was… I started teaching that in 2022. And, you know, November 2022, of course, ChatGPT came out, and everything changed.

Every year I’m like, “Oh, it’ll be easy. I’ll just be able to reuse the course content.” But what is intro to UX is a very loaded question, and so there’s evolution each year. And then the third hat is as author. So of course we’ll chat more about my forthcoming book with Rosenfeld Media, What Your Machine Should Do: The Science and Strategy of Human-Centered Automation. On any given day, I’m wearing typically two or more hats. And where I came from, so I mentioned that first researcher hat, that’s kind of the one keyword that remains constant across my rather nonlinear journey. So I started off way back when, finishing my PhD in cognitive neuroscience at the University of Toronto.

I’m born and raised in Toronto, and I was studying how the brain processes sound. I’m a lifelong musician. Played piano since I was four, violin since I was… and I think we’ll come back to that around the theme of embodiment, which is very prominent in the book. So I was a researcher in a very academic capacity, was at this crossroads of doing a postdoctoral fellowship in Helsinki, Finland, or join an augmented reality startup in Los Angeles. Two very different potential futures, and you can probably guess which path I chose. I worked on sensor validation, brain-computer interfaces, and working with designers writing up patents was kind of my foray into UX and learning more about what designers were doing every day, and they had questions about designing spatial interfaces. What should lists and menus look like when they’re volumetrically represented? And I helped them out with what I now know as a usability test, and that was the first of a long and storied career in design research. And I moved on to some bigger companies, Adobe, Meta Reality Labs, and then about three years ago started Sendful.

So that’s my not-so-brief history of how I got to where I am today.

Jorge: You mentioned that the book is forthcoming, and both Greg and I have read a preprint, so it might be premature to be sharing something. It’s like, “Well, this is a really great book,” and then you’re like, “Well, can’t buy it yet.” Well, by the time a lot of people watch this video, it might be out, right? I’m curious, you know, given your background, why this book and why now?

Stef: Yes. So why this book is… There’s a longer timescale answer and a more immediate timescale answer. So given the history I just shared with my background in cognitive neuroscience, I think coming into the world of UX, I’ve always been fascinated about what part of our brain and behavior are we delegating to technology, what part is innately human.

And even at those early days at this augmented reality startup at my first gig out of grad school, we were building helmets with augmented reality displays, so we had to work overlays. At one point we were discussing building this sort of similar to an Iron Man suit, and there’s always this idea of technology kind of extending capabilities very early on.

And I just sort of took it as a given, but really dove into that from the book. So I think that’s the long-timescale answer of the brain-behavior connection. I think more immediately, I’ve been working on these augmented reality, virtual reality systems for a good part of my career working in industry and leading design research on these types of wearables. And of course, when generative AI became mainstream in November 2022, it seemed like we had another big moment. It was another, like, mother of all demos, 1968. Like, whoa, human-computer interaction is changing. This is a new chapter. And as I started to use these systems more hands-on, I was really taken at what I’ve coined 10X cognitive offloading in the book, and that actually came from a paper I wrote in 2024 called Designing AI to Think With Us, Not For Us.

And seeing these systems, generative AI systems, it was like, all right, we used to… You know, we use calculators. I can no longer calculate the tip for a dinner because I’ve outsourced that. I outsource my cognition to Google Maps for navigation, you know, for relatively discrete tasks, and I’m generally okay with these trade-offs.

But seeing the potential and how fast these systems were developing, like, whoa, this idea of outsourcing our thinking has a real potential that seemed pretty unprecedented, and then, you know, the pace of development, the breadth of use cases. That was really, I think, fascinating to me because it was kind of this primordial ooze of this could go one of two ways. One is, you know, cognitive offloading is fairly neutral. We are doing a thing. We are offloading cognition. Can that be good offloading? Maybe we’re offloading tasks that were really boring or undesirable, kind of freeing up bandwidth, if you will. We can get into the nuts and bolts of how technically accurate that is.

But freeing up bandwidth to do other, maybe more meaningful tasks, or maybe be able to extend our cognition, create new connections. Or are we offloading things that are really core to our craft, to our identity, and that through bad offloading is another potential future. It really struck me that this is an urgent question, that we’re at this 10X cognitive offloading precipice. And just like the cognitive offloading research I’m sort of synthesizing here, there’s a lot of prior art on this, and similarly, we’ve been designing automated and autonomous systems for a long time. There are planes flying above us right now with autopilot systems in them, and we’re generally comfortable with that, and it’s quite a safe system.

So it occurred to me, what if we made learnings from human-computer interaction, cognitive science, human factors digestible to people who are building this technology to be able to address this urgent question and hopefully steer us towards a more desirable future where we’re moving towards more of that cognitive expansion, cognitive, good cognitive offloading.

I’ll pause there. That was a long monologue. There’s a business and strategy connection there too, but…

Greg: Yeah, I would love to pick up on the cognitive offloading piece too, because I think it’s a fascinating thing that we’re observing. I think there are a bunch of different factors at play here right now. I mean, one of the things these tools let you do is generate very dense and accurate documents if you’re working with them well.

Then if you sort and send them to your colleagues at work, you’re also the recipient of dense and well-formatted documents to review. And I think one of the things that I, just out of my own personal experience, is that there is a moment in your day when you work with these systems where you’re exhausted because our brains only have so much capacity to have cognition during the day in a way that makes sense to us, and we’re filling those moments with very rich content.

And, you know, I think that I’m not sure everyone’s gonna be willing to do that, right? It’s like heavy lifting. It can be heavy lifting. And I think one of the things that we’re also starting to learn right now are what are the boundaries of that for our own selves? Like, what piece of our work product do we offload to an agent or a tool to do for us?

But then when we receive the content back, how do we participate with that in a way where we’re landing in the right way? I don’t exactly know how I feel about it, but it just feels like it’s an emerging trend. And, you know, you have people talking about what they call AI brain fry right now.

As a psychologist, do you have a perspective on that right now? Like, from the work that you’ve been doing and maybe even part of what you’re trying to tell us about in your book.

Stef: Sure. So thinking I know exactly the output that you’re talking about, the three pages, the overly detailed report, and I think there’s an irony in that we’re getting maybe an AI system to generate this report, and then the other person, the recipient, is using an AI system to interpret that report, and they’re getting a similarly long report. And I think there is a risk in that, depending how much we’re actually engaging with the initial creation or the interpretation of what is getting lost in terms of our tacit knowledge, what is getting lost in sort of the surprisingness of when we’re having this dialogue. I don’t… You know, we had talked about some questions that might be asked ahead of time, but there’ll be some interesting spark, and we’re gonna go and follow that, and that’s inherently different than these, what I like to call powerful regression to the mean machines.

So I question if we’re just getting kind of a flattening by doing that. We’re getting a lot of well-formatted… Well, you could argue maybe not so well-formatted, but at least the headings line up, of a flattened content. And what does that sort of flattening spiral look like?

So I think if you’re doing that very intentionally, like I really try and be really strict with my output in that I want it to be in bullet points. I want it to be like a one-pager. And really, there’s a lot of curation that goes into before sending it. Like I’m co-chairing a conference, and if I send a one-pager to my co-chair, I really want to make sure that I’m infusing as much of that sort of stuff and surprise, if you will, into the document so we’re not getting that sort of packet loss of just AI systems reading other AI systems.

Jorge: It feels like we’re living through a moment where we’re trying to use these new tools to automate. And I want to circle back to the word automating because it’s very important to the book, right? But we’re using it to automate legacy workflows. And one of the stories that you have in the book, I think it’s about the introduction of electricity, right?

And when the early days of electricity and how people could tell that this was a new source of energy that would change industry, but it wasn’t really until factories were reconceived around electricity that the productivity gains became evident. Is there, like, an analog to that in the current space? And I’m thinking of things like sending these big reports. It’s like, do we need that?

Stef: Yes. Yeah, I think the equivalent to that, like what we need to be doing, like redesigning the workflows, like where we’re redesigning information structures and information flows. But I think we’re really… Okay, we had some information exchange. It might have actually been more rich in some ways.

Maybe it was a little bit more chaotic, and now we’re sending this nice report. Like, maybe to give an example from research, one of the classic design research deliverables is some sort of form of report. Where the richness often lies is actually the informal debrief after the user interview, and we’re going back and forth informally, and that’s really where those nuggets come in.

It’s not from necessarily the polished report. Sure, there’s a time and a place for that type of format. And I’m thinking we’re looking at this like the new electricity, but is it even that? And are we using it in the right context? And then I think, okay, if we are going to replace it with these polished reports, okay, where is that other sort of offline conversation happening where we, if we divorce ourselves from where that meaning-making, that sense-making is occurring. I don’t know. The long report example, I don’t know if is necessarily the best, as I’m talking through it, the best of the productivity paradox examples. I think maybe it’s like bolting on, you know, and like we saw this maybe a year ago, bolting on an AI chatbot to an existing system where it didn’t actually add any sort of value to it. It’s like, okay, we need to maybe redesign the entire experience and see where AI fits. Maybe that’s something that’s maybe generic but closer to that.

Yeah, I mean, so I want to build on both of your comments there because I think one of the things that I find missing in the conversation right now and one of the things I liked about the frameworks that you’re introducing in your book is that I think there’s a general lack of imagination.

Greg: It goes back to the electricity construct, too. A lot of AI efforts right now are looking at existing processes and looking for incremental automation gains.

Stef: Hmm.

Greg: They don’t think of them as being incremental, but they ultimately are because they’re just taking the Rube Goldberg machine inside of the enterprise and adding capabilities to deliver the same outcome without people or with more efficiency.

And while that’s useful, it misses one key point, which in my mind is people aren’t talking enough about, which is these tools are becoming less and less expensive to build applications and software and components that allow you to do things. So why aren’t we talking about in organizations what could we do?

It’s not what should we do, it’s we’re not talking enough about what could we do. And the debate isn’t really about how might we intentionally create a new future for the business, you know? What capabilities could we now empower us to do new things? It’s really about how do we do the things that we do right now, you know, faster?

And it feels like we miss something in that translation, and I don’t know if you have a point of view on that, but…

Stef: I love that you brought that up, Greg. I was listening to your previous podcast earlier today in preparation for our conversation. I’ll paraphrase this, please poke holes, but I think you were describing how there’s a missed opportunity to have a team of people who are just exploring what are new workflows, what are new ways to use this technology, and there’s this…

I think we’re… This comes back to a key theme in the book, this over-pivoting, this over-focus on efficiency and not necessarily effectiveness, or in our case of what we’re talking about here, possibility and creativity, and I think that that is a big missed opportunity. I think there’s something going back to maybe the productivity paradox example. I think we’re over-focusing on sort of, like to reference sociotechnical systems, where you have social subsystems, the people, the relationships between them, the technical subsystems, the tech, the processes, and there’s, like, okay, what… We’re going to build the heck out of the technical subsystems. We’re gonna ignore the social subsystems and not really talk about what does that handshake in the middle look like for joint optimization. And even if we do that correctly, there’s what we know, how people work today, but then there’s this whole sort of potential futures piece, and by over-pivoting on the now, we’re missing out on those longer term horizons.

So I don’t know. I think there is a huge opportunity there to build towards different potential futures and think what does a new, like, I don’t know, future of work… Future of work is a well-trodden phrase, but maybe taking even a strategic foresight view on that, I think there’s real value there.

Greg: Yeah, and I mean, I think one of the things I also really enjoyed in your book is this idea of your automation quadrant, a two-by-two that you’ve created. I think one of the things that Jorge and I have been investigating when working with clients is how do we help them become practically capable?

How do we help them discern what, you know, the things they should work on and why? Could you talk a little bit about what you’re trying to posit with the framework that you introduced and maybe an example of how you developed it?

Stef: For sure. So I’ll give a bit of context on the framework depending when this is coming out. So we’re talking about a two-by-two matrix called the autonomy decision matrix, and I very specifically called it autonomy and not automation matrix because that is really what we are deciding. How are we going to allocate autonomy between humans and machines, in our case, AI systems, so that it’s the two axes. You have could you automate on the X axis?

Should you automate on the Y axis? And you have different confidence levels. How confident are you that you could or that you should? Kind of goes to the classic phrase, “Just because you could doesn’t mean you should.” Could is generally tied up with technology capabilities. What can this ML system actually do, as well as our organizational readiness to build it, to use it. Then on the should, it gets more to value, not just to the user, but to the broader ecosystem. And what do I mean by that? I can go back to my earlier roots in augmented reality systems. If you put a $10,000 machine on someone’s head, no surprise it’ll make them more effective, more efficient, safer.

There might even be greater customer satisfaction. But unless you also digitize all the 3D models that are served up, as… Unless you also integrate that with the ERP system, it’s just going to be sitting on a shelf. So how do you integrate the solution, and can you integrate that solution? Does it overall uplift the value of the broader ecosystem into which it’s fitting?

So two axes, and then depending on, so what is going into this two-by-two? So the input for this is an automation solution. So meeting people where they’re at is realistically, you’re probably talking about some sort of a technology solution, something you’re gonna build, something you’re gonna adopt.

So let’s just take that as the reality, put it on a sticky note and use that as a starting point. And so depending where you are on this quadrant, if you’re, you know, pretty confident that, hey, we can… This can actually work today, this technology is capable, we have the right folks to kind of pull this off, but we actually don’t have any evidence that this is actually gonna be valuable, the idea is maybe you’re gonna put that in the quadrant that’s on the bottom right.

That’s like, question what this is. Let’s have a conversation about it. Or maybe another context you could use this in, “Hey, we want—we think this is a killer use case and the capabilities are there. We really feel we should automate this, or we feel like this is the direction we should be going.” Now we can work backwards from that. And I talk about this analogy from mountaineering, climb high, sleep low, where that is the goal, that is the big ambition. Now we can use this matrix as a common language that ICs, that leadership can use, ideally to be saying the same things, to be looking at these same quadrants together and having a conversation around a shared artifact.

So that’s another use case. There’s also a very sort of pragmatic use case that was one of the earliest forms of how I developed this, is if you have a team and you have 10 features of things that you could build, let’s put them in here and prioritize and see where they line up. And if you’re in the, “Well, we’re not quite there yet with the capabilities, but this would be super powerful,” so let’s start with assist.

There’s more human in the loop, and as you move from assist to automate, there’s increasingly more machine, less human, and you can design what that handoff looks like. But those are kind of the three different ways that you can use it. It’s really a map and it serves as this kind of shared artifact for these different parts of the organization.

That’s a thing that’s happening a lot just in AI development. You know, you have leadership saying, “We need to go in this direction.” Builders are saying either, “We don’t have the capabilities,” sometimes the capabilities aren’t even known, and you have this kind of talking past each other, and we can get into this.

I call that the automation strategy gap in the book. But yeah, that’s… Let me know if there’s anything to double-click on. That was a lot of me. I love talking about the autonomy decision matrix, as you now know.

Jorge: One of the things that is implicit in the matrix and in everything that you’ve been saying, actually, is to think about these interventions more systemically.

Stef: Yes.

Jorge: You know, you talked about integrating with other pieces, the fact that you can’t really think about how they will work in isolation from the rest of the systems in the business. And implicit in this is a more kind of strategic framing of the technology, and this is happening in a context perhaps because of the fact that we’re still kind of in the early days of this new technology. Although maybe that’s something to discuss, right? Like how—where are we on the adoption curve? But it definitely felt like in the first few years, the energy was like, “Oh, you know, we’re gonna be left behind.” There’s this kind of FOMO thing happening, and let’s implement… You talked about bolting on chatbots. It felt like every product out there was like, “Now with AI,” right? How do we help business leaders kind of take a step back and do this more intentionally?

Stef: Yes. So there are two parts to this. One is learning to recognize what I have called this automation strategy gap in the book, and it’s very much the precursor to this gap is exactly that, that urgency and FOMO that you’re describing, Jorge. And I think everyone is feeling it. It’s kind of… There’s this existential energy in the air if you’re building something.

You need to be automating everything all at once yesterday. I think the common response to that is this default of what I refer to as dreams of automated futures, and this is not a new concept. We see this in some of our oldest Western literature. We could talk about Homer’s Iliad and the origins of automation as a word, but dreams of automated futures, and it’s kind of reactive if you think about it. We want to jump to that sort of top right quadrant and not necessarily have high confidence in those two axes of could we do it and should we do it. And so you kind of develop this cascade. You get this reactive vision, automate everything in response to the FOMO. You have this defensive maneuvering that I think a lot of the times when we hear AI-first strategy, that’s what’s happening here.

The choices are made to keep up rather than truly serve, you know, to reference Lafley and Martin’s strategy choice cascade, you know, winning aspiration, where to play, how to win, and then you get kind of disconnected execution. You’re setting the wrong metrics. I always joke that you can say, “Hey, our call resolution time for customer service dropped from 11 minutes to two minutes.”

That looks great on paper, but it’s not so great if your customer’s actually rage quitting because they were trapped in an infinite loop with an agent. The quality of that experience is not good, but it’s harder to measure. So I think that’s the default. That’s sort of what is happening.

And so how do you get out of that, I think, is the question. So how do you learn to recognize it? That’s sort of where I started here. And to your point about systems, I think this is where understanding the underlying system is so key. So we talked about my background as an educator as one of the hats that I wear, and I know, Jorge, you also teach systems thinking, design schools as well. I think a key takeaway from this whole process of writing this book is that AI accelerates any system to which it is attached. It is gonna amplify the dysfunction, and it’ll amplify good strategy. If I have a great idea for a prototype, now I can… I, you know, the cognition is kind of front-loaded, and I can build that really, really quickly.

I’m not in Figma moving around little design elements anymore. But if I have a not-so-great idea, I can build that just as fast, and we have automation bias. We tend to trust things that come out of automated or just computers more than our own judgment and others. And it looks shiny, and we may move past, you know, is this thing useful and just focus on the aesthetics. So all of that said, accelerant mechanism for whatever is underneath, and I think this is where systems thinking, or systems mapping, are really valuable tools to understand what are those deeper structures of your organization. A tool that I talk about in the book, one of the most, I’d argue, accessible systems mapping tools, the Iceberg Model, classic, literally looks like an iceberg.

You have events up top, what you immediately see. You have the patterns as you start going deeper underneath the water, the structures, and the underlying mental models. So putting that in an example in an organization, let’s say you have… I talk about this in the book as well, maybe you have a perpetually overloaded product roadmap, probably a pretty relatable experience for all of us. And the tip of the iceberg is you immediately just always see, you know, the roadmap is overloaded. We’re constantly slipping, and you start zooming out a little bit, and this is all in service of seeing what’s driving that system. What is AI actually accelerating here? Is it your strategy? Is it just dysfunction? And so you see, okay, this is a pattern over time. This keeps happening every quarter. Teams are overcommitted. And you look at the structures. So what are the processes? What are the incentives that are producing that pattern? And maybe it’s KPIs are reporting shipping more features than saying no.

Maybe it’s the sales team keeps making promises to customers, and that’s what’s driving the roadmap. And then if you go the last step deeper, the bottom hidden part of the iceberg, you have those mental models. Maybe it’s like saying no means we’re not ambitious, or customers only see value in those new features. And recognizing that is really core to fundamentally redesigning what is driving your organization. And of course, that requires a lot of reflexivity. But I think to really see, okay, what’s driving our decisions, and what are the values driving our behaviors? This is something that I had amazing tech reviewers, and this is something in the book.

It was just… The book was pretty much written, as you know from being in tech review, but it was just this fantastic conversation with one of my reviewers talking about values driving behaviors. When everything is moving so fast, you don’t necessarily have time to have a ton of foresight, so you better have your values in place that are gonna direct how you’re gonna navigate the fast-flowing white-water rapids of AI. So I think systems thinking gives you access to what’s beneath, what’s driving those behaviors, so you can make some sort of a change such that when you bolt on the accelerant, you’re going in hopefully a positive direction.

Greg: I love the idea of this notion that it accelerates everything, right? So you could accelerate just a faster way to get to a bad outcome, is one potential path. You know, and strategy in general is really, in my mind, about creating a map, right? Like a path or a direction and being intentional about the choices that you make.

You know, and one of the examples I think that we’re seeing in organizations is they’ll start on an idea, and their perspective is, we’ll just iterate our way to success by getting feedback with customers along the way, and we’ll get there. And the reality is, if you think about it like a compass, they’re heading southwest, but the real true idea is northeast.

But they’re heading southwest, and they’re pivoting and pivoting and pivoting, and maybe they land in south, but they’re not northeast, right? And so they’ve incrementally gotten something better, but they’re way off product market fit because they just didn’t spend the time to look at the system to understand the problem, the social structures of the customers that they’re trying to build for, et cetera.

Whereas if you have some kind of way of having values and perspective and you act intentionally, maybe you don’t know you’re northeast, but you at least know you’re in that side of the world to start, and so you can pivot closer to that truth over time, right? And, you know, I think that this is one of the challenges I think these tools do is that a lot of us get artificially enamored by the results and we have a little bit of a sunk cost fallacy where we’re like, “Look at all this work we’ve done.

We must be on the right path.” And we’re just on the path to a bad outcome, you know? And I think this is one of the reasons why a lot of AI efforts have struggled is that it’s this sort of ready, shoot, aim approach to implementing the technology versus fundamentally recognizing what we are trying to accomplish and then working backwards from that.

And anyway, I’m massively aligned with your point of view.

Stef: I love that, Greg. No, there’s a part maybe to build on that. I think you could probably see me getting excited there. This acceleration insight, I think it all sort of came together. There was a Harvard Business Review study that came out earlier this year that talked about how AI ultimately just intensifies work.

It’s not actually saving us time, and this has been true for a very long time about technology. Email was supposed to take away meetings. I’ve had back-to-back meetings all day. Email has not actually given us that time back. But what struck me about that intensification of work piece is, let’s say even if you’re generally moving in the right direction, let’s just take a positive example, and that’s certainly not always the case.

Oftentimes we’re kind of accelerating that dysfunction. There’s also a cultural piece to this. Everyone is moving so fast, we’re getting burnt out faster, and that time to actually assess, “Hey, are we going south or are we going northeast?” I think there’s a cultural element here that is underappreciated in that when we’re moving so fast, we can only see so deep, essentially.

And so how do you, if you’re in a leadership position, make the space at the right time to actually put deep thinking where it needs to be and then move fast where it needs to be as well? But I think there’s something to it, to your point of now we can run faster in the wrong direction, but the fact that we can do that is also just making everyone run faster, and by virtue of doing that, pay less attention toward the direction in which we’re running.

Greg: Yeah. Yeah.

Jorge: There’s a saying in the military, “Slow is smooth and smooth is fast.”

Stef: Yes.

Jorge: And that saying has been on my mind a lot recently, and I feel like the three of us are very much in this kind of systems thinking, let’s think about what we’re doing space. And I’m wondering how this registers with business leaders who are under pressure because they have to deliver something this quarter that demonstrates that the money they’re investing in these technologies is somehow yielding results. And I’m wondering if there’s an incentives issue as well, you know? And you talked earlier about measuring the right things. I guess the question is, how do we affect the culture change necessary for these organizations that are really structured to deliver short-term results in many cases to start thinking a little bit more about the, you know, what quadrant do we want to be in, you know? Are we going southwest or what have you?

Stef: Yes. I think part of it is… And if I had the 100% answer for this, I think I could maybe retire. So I’m not gonna claim to have the be-all, end-all answer. But I think part of it is going back to, you know, what is… Like, where do we want this organization to go?

I hesitate to say vision, because vision gets conflated with, like, a statement that maybe is on your website along with mission or something, and is sometimes rather hollow. But going back to that strategy cascade, what is the winning aspiration? What is that goal that we are working towards?

And I understand that there’s gonna be some major pressures to deliver, to have revenue, but presumably you have some sort of customer at the end of the day. You want the customer to buy your product because it is good, and you’re going to have some particular part of the market that you are playing in. And I’m thinking keeping your eye on that, which is actually in some ways very classical strategy, and how does automation serve that? And maybe it’s farther down in terms of management systems or how are you orienting your metrics. I don’t know. I think it comes back to what is that winning aspiration?

Where do you play? How are you gonna win in that particular… I don’t know. It kind of, I… This is a common theme with my thinking, is like what can we learn from tried and true kind of evergreen frameworks, tools out there to guide this moment? What do we need to recognize as different, and certainly the speed is there.

But I think we’re probably not gonna go too far wrong if you have an idea of where we want to go. Sure, we need to be flexible, but how does automation help us move towards that? And I can talk about a possible example of also how designing for cognitive expansion using AI as a killer feature with NotebookLM, with whatever they’re calling it now at Google Gemini.

As of last week I had to change my book because of that. But I don’t wanna get ahead of myself. I’ll pause there.

Greg: One of the things I am finding in the work that we’re doing is that smaller teams can punch way above their weight now with these tools. But not only smaller teams, smaller organizations can potentially do things that a larger organization used to do, and might be able to do them more effectively and efficiently because there’s more intimacy in a smaller organization.

The people know each other. They can react. Do you have a point of view about that? I mean, is that just me looking for what I want to see, or do you think that there’s actually some truth to the fact that these tools empower… may change the shape of how people do things together?

Stef: No, I think there’s definitely something there. There’s an analog here. It’s from, I think it was one of your blog posts, Jorge, around Flow, the Academy Award-winning animated film, which was done, I think, in the Baltics, Estonia. I don’t know, you can check me in post, I think. But it was basically a very small team putting together this award-winning film, and I do feel that is definitely possible, and I think it’s interesting why is that possible. I think there’s less layers of information transfer. Similarly, if you have a team of eight people and you’re working in an office, there’s probably very little packet loss happening between that team, and you can work very dynamically.

Your all-hands is, like, your lunch, and you’re all on the same page. And of course, as organizations start to grow, you start getting potential for more packet loss and so on and so forth, and I think you have a buildup of tacit knowledge that is harder to automate, and this kind of gets into the productivity paradox.

I think it’s possible, but more work needs to be done to redesign the factory, so to speak, to use the electricity example. So certainly I think if you’re a smaller business or a small team, it’s incredible. I see it even in my own practice. Classically a design researcher’s main deliverable was probably insights and recommendations, and now literally, like earlier today, I’m building in Claude Design primarily right now.

We can debate the merits of that. But you know, I’m making prototypes. I’m going deeper into the making part of it, so certainly it’s enabling smaller teams to do more than before. But I think there’s something worth poking on in terms of what is required for scaling and how much of that is about how information propagates and then what’s flattened in these systems.

Jorge: Yeah, I mean, the more people in the organization, the more complex the social networks are gonna be, and to your point, it speeds up everything when you have fewer people. The quality of the tools has also improved. And, you know, we don’t have to overleverage on the example of that movie, but the fact is, you know, the kind of tools that are used to make a 3D movie now are available relatively easily, and the outcome is super high quality. We’re seeing that obviously with AI as well, that we’re getting the ability to produce results that we can quibble with their quality, but it’s oftentimes much better than what people were making 20 years ago, right? Even in the crappiest version of the AI output. So yeah, but the fact that it enables smaller teams and the quality of the output that those teams can put out is much better and much faster seem like factors in…

Stef: Yes. I wonder too, coming back to our earlier part of the conversation, as AI is an accelerant, when you have that small team that has a really clear vision of where we want to go, or I say vision, it’s really, I think I’m talking about strategy, about that winning aspiration, and how they’re gonna get there. If everyone’s pretty aligned on that, they’re using AI as that accelerant and kind of force multiplier, amplifier, so on and so forth, insert synonym here. And yes, what they can create, how they steer these systems is pretty impressive.

Jorge: And I just wanna add one more thing there because one of the things that is unique about AI as an accelerant is that it not only accelerates the creation of artifacts, like you were saying, it’s like maybe you can do a report now in two minutes or whatever, right? Like, and that’s an artifact that the LLM is writing for you. But one of the things that it also accelerates is it gives small teams the ability to come up to speed with new tools and processes that they might be unfamiliar with much faster, right?

Stef: Yes.

Jorge: The team that made that movie, I mean, I don’t know, I’m gonna make stuff up now because I don’t know the details, but if I wanted to pull together a team now to make a 3D movie, I don’t know how to use Blender.

My team probably doesn’t know how to use Blender. But we have these tools that allow us to come up to speed on something like Blender fairly quickly, right? So as long as you have a sense of the neighborhood that you want to be operating in, you can get there pretty quickly. The flip side of this, and this might be something to talk about, is if I don’t have expertise in the systems that I’m working with, I also don’t know what can go wrong.

Like, I don’t know what to look for, right? So I might be misled by these tools down a path that just goes nowhere.

Stef: Oh my gosh, yes. We might need a second podcast for this. No, I have much to say on this and it’s… So I’m, this is not meant to be a shameless plug, but I’m also a co-curator for Lou Rosenfeld’s upcoming Shift UX conference, and this is something we were just recently talking about in our curator’s group, how we talk a lot about AI blurring the swim lanes between roles for exactly this dynamic that you’re describing, Jorge, in that you can now…

You know, can prototype, and I think this is just audio only, so you couldn’t see my air quotes. But what are you prototyping if you don’t have kind of all the elements of UX layers beneath what you’re… Like, if you didn’t front-load that thinking in what you’re guiding, and what you see is maybe one role that is not design creating a prototype, and then design has to kind of clean up the maybe not so correct prototype after.

And there’s this interesting sort of accountability trade-off that we’re seeing by virtue of there actually being some boundaries. Certainly we can expand more. The floor has been raised, but I think there is still a real place for experts, whether we’re called the same title or not. Again, this comes up a lot in our discussion for prepping for the conference.

Like, will design researcher be a title? Will UX be a title? Will we even call it UX? TBD. Maybe not. But the actual expertise of what we are doing, I think something that is really unique to what we’re currently calling UX practitioners is problem framing and reframing, recognizing when the question itself needs to change.

And I have a pretty… Like, the hill that I die on is that’s something beyond the realm of automation, and I have a whole argument about how that’s related to tacit knowledge and embodiment and situated action, which we may or may not need to go into. But I think there is something around… There are some edges, and you still need to have that human expertise to complement the machine. It comes back to that joint optimization, that handshake between human and machine strength. So yes, while that floor is raised, I think we still need experts to be able to call out when the system is going off the rails, and we don’t have that expertise.

We can’t call out that system or can’t steer it as effectively.

Greg: Yeah, it’s interesting. I mean, discernment I think is a really important thing. You get tacit knowledge, the ability to know when something’s good, is based on experience and expertise, et cetera. And one of the worries I have right now in this moment is that the gap between early career and people who’ve been in the seat for a long time is large, and the apprentice-apprenticeship model is breaking.

Which means that, at some level, early career folk are jumping in and just using the tools and saying, “I don’t need all that stuff because I can learn it by just asking great questions.” And then you have kind of a ways of doing things, which have been accumulated over a period of time by expertise and being in your career long enough to see patterns emerge along the way, that is valuable.

But there may not be the curiosity to understand how to use the tools in a new way to take advantage of it, right? And there’s so these sort of gaps between these two spaces. And one of the things I’m personally concerned about is how do we create an environment in business where we actually are mentoring early career people, and we’re also capturing tacit knowledge at the senior level and finding ways to share that information.

And then there’s a connection to that that’s also culturally difficult because tacit knowledge is earned and therefore part of people’s identity and connected to job stability and a bunch of other issues that they may not want to share. You know, I’ve… Long time ago, I worked at the New York Stock Exchange, and I interviewed all the people who worked there, and there were certain people who did not want to share what they knew because it made them valuable in the organization.

And, you know, if they were hit by a bus, the technology stack would fall apart. And so they had leverage in the organization because of that tacit knowledge. So there’s all these kind of issues that are very sticky around how, as a society, we’re gonna mediate between those who know, those who are learning, those who know who may need to learn new things, those who are learning who can adopt and adopt, as Jorge mentioned, “Hey, I need to learn Blender.

I’m gonna learn it now.” You know, it’s almost like The Matrix. “Tell me how to fly a helicopter.” And that gap between those, we’re not having a conversation about that. The conversation around the people in these systems, it’s this efficiency play versus how do we make our people stronger, better, faster, you know, and at the same time hold the social contract at work where we’re all in it together at some level.

Jorge: I saw a post just yesterday from McGill University saying that the Dunning-Kruger effect might not be real, that it might be like an artifact of the data they used to collect it. I’m like, “Oh, no, just when we need it most.”

Stef: Yes. No, I want to believe that research. There’s… Oh, my gosh, I have many directions. Let me see if I can pull them together into something resembling a linear thread around, kind of around those different consequences of AI.

There’s maybe the discussion around the bottom part of the ladder, the bottom rungs being cut off. And I think this comes back to our early conversation about redesigning the management systems or redesigning the factory. It’s a 1880s electricity productivity paradox story we were talking about earlier.

I saw this, in a good way, with job postings for IBM. I spend a disproportionate amount of time looking at internship posts for my students, and I was impressed that they were hiring some… At least this is my qualitative anecdotal report. I don’t know, maybe there’s some big news report that’ll invalidate me.

But they were hiring for junior-level roles for interns, and they acknowledged that automation with AI shifts doing tasks, going hands-on with the artifact, to more upstream, like monitoring, supervising, orchestrating. That word gets used a lot. And they really… It seemed that they were focusing students, these new junior folks coming in, on things that were maybe hard to automate, like customer-facing conversations where you’re building relationships. Maybe it’s setting up systems. I don’t know what the mentorship structure looked like and… But I thought that was cool that they had rewritten the job description. That’s what I’m… Maybe a concrete example of what does it look like to redesign the factory, and I think that’s exciting, and I think there’s a huge potential for seeing my students.

They’re so curious, and across all my guest lectures, having that curiosity, being able to learn the tools, but also, you know, I see a lot of concern about cognitive offloading, to be honest, in my students. You know, they’re the professional masters, so they’re definitely more senior. But they know they need to be able to do the thing or have the judgment as well as steer the tool. So I don’t know. I’m hopeful, but I think there’s yet another dimension. I said that I… No promises about linearity, but there’s also another aspect of this that we’re asking people to come in out of the gates to be systems thinkers, and I think it asks perhaps an uncomfortable question about how… It’s like a nature versus nurture thing. Like, we can learn causal loop diagramming and system mapping and so on and so forth, and those are definitely tools that we can use. But if you don’t put in the reps, can you effectively steer it? I think that’s kind of an open question.

Is that something about personality, like openness to experience? Is it just like practice, like playing violin? If you play for one day versus 20 years, it’ll be different. And I don’t know, I think about that a lot around nurture versus nature for assistance. I’ll pause there before I throw more dots in this constellation, see if we can weave them together.

But…

Jorge: You used a phrase earlier on that I wrote down because it struck me as a really good summary of what the book is about. You said, good cognitive offloading.

Stef: Yes.

Jorge: And that strikes me as a really good synthesis of the kind of subjects that we’ve been talking about, or at least aspirationally, like where you wanna be at. Are there concrete things that you can point listeners, viewers to do, practices, exercises, ways of thinking that can help them get to a place where they’re doing good cognitive offloading?

Stef: Hmm. Yes. I’m thinking about… Maybe I can give some of the underlying principles and then maybe give a couple of… Well, let me start concretely answering the question. I think first off, trying to do the thing yourself, doing the thinking yourself is maybe the first thing you can do. I’ll start there and then I can get into, of course, I just want to go and jam cognitive science principles into everything.

It’s very on brand for me. But I think, yeah, making that first draft, maybe taking that first pass of your song that you’re composing, doing… Like what are the reference images? I have an interface that my partner and I built at a hackathon and we were looking at a different way to explore music and it was very kind of analog of brainstorming, okay, what direction we would want this to go in.

So I think, yeah, if you can at least put down that bad first draft first and then go to AI to maybe use it as a sparring partner, arguably that is, you know, that’s a well-trodden but I think great way to use these systems. See how it can take a different point of view. How can it help you expand cognition?

How can it help you think about thinking? How can it encourage metacognition? I think those are probably the two that I recommend most often, and I really try and practice myself. I think the more I use AI systems, the more I find myself coming back to more analog things. I think that’s a bigger trend as well, or at least starting analog before the accelerant.

Well, those are all really great from a personal perspective. I’m wondering if there are analog suggestions for teams, right? Because part of what we’re doing here is talking to leaders who are grappling with the moment we’re in, right? Like this moment of change. How can they steer their teams, their organizations toward good cognitive offloading?

The entry point for this, I’ll start with maybe something that is not necessarily where you think I’d go with this, which is building a culture of experimentation by going hands-on with the tools. And maybe, you know, two years ago or a year and a half ago, that looked like feeding in a standard sort of day-to-day workflow and trying to automate parts of it.

Now it’s probably building out more agentic capabilities. But making space in that organization to learn what these tools are good at, so you have a sense of what are your human strengths, not just at an individual level, but maybe at a team level, and how those work together versus machine… How do I say?

Yeah, human strengths versus machine strengths. So I can give a concrete example of what this experimentation looks like, which I think at an organizational scale can enable good cognitive offloading. So Canva had this thing called AI Discovery Week. Last year was their first time. They took a whole week off, where they had everyone from engineers to chefs at the company spend some time learning about core AI concepts, kind of boosting general AI literacy, and then they had a company-wide hackathon where they generated, I don’t know, hundreds of different ideas. And I think that was their goal, building a culture of experimentation. Everyone is familiar with these tools.

And I talk a lot about this in the book and in the paper that sort of eventually grew into the book around this building intuition, intuition building, however you… I think I called building intuition officially. And I think that is really key for developing that muscle, and they did it again. So presumably you had some value from that.

They did it again this past year, and what they were building was more in-depth. It was building out workflows. It was more agentic systems rather than general literacy. But I’d say that’s probably something that organizationally, again, good cognitive offloading, and feeds into the sort of bigger discussion around how do we build the sort of culture and adapt the factory, going back to our productivity paradox electricity example.

Greg: That’s great. I would add one thing that I think is interesting right now, which is do more in less time instead of do less, do the same in less time. And what do I mean by that? There are certain activities in product development, some of which take a lot of time to do, or historically took a lot of time to do, and therefore didn’t get done because of time exigencies.

You know, you didn’t have the time to do it or the staff to do it or the ability to do it. But now you can do them, and you can do them rather quickly. And so you should because they will inform you and allow you to understand the problem space better. I read about this recently.

There’s an example around a company I would help where we evaluated the information architecture of all the competitors, and we did that in like a day. It would’ve taken us probably two to three weeks to do it in the past, and we wouldn’t have done it because it would’ve been perceived as a low-value activity, because it was too hard to do.

Turned out to be insanely useful for us because we understood something that was unique to us, and understood something that was happening in the market by doing that. So this is a new activity. It wasn’t new. It’s something I’ve done before in my career, but one that was very difficult to argue for because you just didn’t have the time or the capability to do it.

Now you can, right? And so I think one of the things that we’re missing the opportunity on is understanding what is the more that we can do as teams? What is the more that we can do with these tools? And I love this idea that think for yourself, partner with AI, but I think the next thing is what more could we do to understand this problem?

And given the fact that these tools are basically reducing the cost to do that, at some level I feel like it’s negligent not to do the more.

Stef: No, I have another example of that as well, like thinking about this comes back to that human versus machine strengths and, as a side note, nerdy backstory. This is the Fitts’s List concept from, for any human factors listeners, but adapted to modern days.

Like, this idea of, say, generative AI. One thing that it’s gonna be way better at than me is going through a mountain of data and quickly finding the patterns. Now, if I’m running a big workshop with a client, instead of taking a week to synthesize, even if it was a few days, if I’m able to do that by the end of the day and give some high-level overviews, and then have a discussion about it while we’re still in the same room, like that’s super powerful, versus doing that the quote-unquote “old-fashioned way” and waiting for that couple days or week lag time.

So I think that’s another great example, and we shouldn’t… Like, what can we do… Looking at that list, like pattern detection, generativity. It’s not gonna be necessarily creativity, but producing a lot of variants of something or stamina, being able to just run something for a really long time in deep research mode or something.

I think we’re… Yeah, that’s probably underexplored.

Jorge: The acceleration basically transforms the… You used the phrase old-fashioned, you know, like the old-fashioned technique. It transforms it into something new, right? Because if it’s close to real-time, batch computing is different from interactive computing.

It’s qualitatively different. But anyway, it sounds like we have so much more that we could talk about, but we are running up on time. I don’t know, is the book available for pre-ordering? Where can folks find the book?

Stef: For sure. I can share a link with you as well, but on the Rosenfeld Media site, if you look for What Your Machines Should Do: The Science and Strategy of Human-Centered Automation, it is coming out this fall, and there is a pre-order link.

Jorge: Well, I don’t wanna pre-commit you, Greg, but I would love to have another conversation with you at some point, maybe after the book launch, because this is, first of all, it’s moving so fast, and it is such an important subject. So good luck with the launch, and thank you for joining us today.

Stef: Thank you, Jorge. Thank you, Greg. It was my pleasure.

What do consultants get paid for?
What jobs can AI actually do? Certainly not the most complex. Luis Garicano’s post focuses on consulting, but his framework applies to many other messy jobs. (The title of his book, which I now want to read.) The upshot: AI may help you do analysis cheaper and faster, but that’ll only move the bottleneck downstream.

Intelligence as architecture
Luc Beaudoin argues that intelligence is best understood as a property of information processing architectures. This may sound abstract, but it has real implications for how we design AI-enhanced systems. For example, consider the role culture and social commitments play in intelligent human behavior. AIs don’t (yet) have that. My read: intelligent behavior is more complex than many people are assuming; building scalable intelligent systems will require structure.

Systems and delays
It’s wonderful to see someone learn about systems from Donella Meadows. This post explores the counterintuitive effects of delays, one of the most impactful insights from systems thinking. I’ve seen this dynamic at play; it can be disconcerting. Remember: AI will accelerate and amplify these behaviors.

What IA is for
I wrote this primarily for practitioners, but the underlying claim is also relevant for you: the ultimate purpose of information architecture is increasing agency by making systems more legible — for you, your employees, your customers, etc. IA isn’t just for the World Wide Web: If your people and AIs aren’t getting the information they need when they need it, they won’t produce good outcomes.

IA is foundational for AI
Patrick Neeman argues for something I’ve said for at least the past two years: information architecture is the foundation for good AI implementations. AI is leading organizations to rediscover the value of IA, at long last. Patrick names me as part of IA’s history, but the AI challenges in this piece are what my practice focuses on now.

What’s really happening to jobs?
A recent report from Stanford concludes that claims about AI impact on the job market may be overstated. There are two ways of understanding AI: as a “normal technology” that will change the world over time (“transformative but gradual”) or as an unprecedented disruption with immediate world-shaking implications. I’m firmly in the former camp: you should invest in AI smartly, with a look to the long term.

Stateless MCP
An important upgrade this week: the Model Context Protocol (MCP) maintainers announced version 2.0 of the spec. These are Simon Willison’s notes on the release, which go deep into tech details. My read for business leaders: this version is more secure and therefore better suited to enterprise applications than agentic coding harnesses (e.g., Codex, Claude Code), at least for operational workflows.

How Swatch saved the Swiss watch industry
A fascinating case study of an industry (apparently) facing technological disruption. Much of what I thought I knew about the near-death and restoration of the Swiss watch industry was wrong. Cheap Japanese quartz watches weren’t the culprit. What almost killed the industry were protectionist policies and bad incentives. What does this have to do with AI? Tech disruption was the coup de grâce that almost flatlined the patient, but there were deeper structural issues. How ready is your industry/organization to compete in our time of technological disruption?

Smart businesses are realizing they don’t have to blow their budgets on frontier AI. At least, that’s the conclusion of a recent article in the Wall Street Journal. Models come in different levels of cleverness, and the “smartest” cost more. But not all tasks require the highest level of intelligence. A mix of models will give you the biggest bang for your buck, at the expense of upfront architecture.

The Journal cited an excellent example:

Cursor recently ran an experiment to evaluate the cost of building a web browser from scratch. Doing the entire task on OpenAI’s GPT-5.5 cost a little more than $10,000. Using Cursor’s Composer coding model in combination with Anthropic’s Opus 4.8, cost $1,339.

The focus here is cost, but that’s not the only concern. The most intelligent models — those offered by frontier labs such as Anthropic and OpenAI — are closed and proprietary. That has implications for your business. For one, you risk becoming dependent on others for critical cognitive tasks — a strategic and privacy risk. If a provider can turn off the intelligence spigot (or, more likely, raise its price) you’re stuck.

The solution is breaking down jobs into tasks that can be done by a variety of models. Some tasks, such as planning, will require more powerful models. But many others can rely on cheaper, less powerful models. Open weight models are becoming a commodity: not only are they cheaper but also mostly interchangeable. Not happy with how a model is performing at a particular task? Switch it out.

This is how business has been organized forever. Some jobs require greater expertise and capabilities than others. For example, neurosurgery can only be successfully done by a very small number of people who have the necessary intelligence, training, and experience. On the other hand, cleaning the operating room can be done by someone with less training, expertise, and smarts. Hence, neurosurgeons earn more.

How do you determine the right mix of intelligences? Think of your AI operations as an “intelligence stack.” At the highest level, you have the vision and strategy for the system. At the bottom, you have particular one-off tasks that carry out system functions. In-between there are workflows with various degrees of complexity. All three levels call for different kinds of intelligence.

The goal is to bootstrap this stack by using expensive frontier models to design and implement the system and more commoditized models to operate it.

When developing the vision and strategy for the system, you’ll research competitors, build scenarios, and explore possibilities. These are open-ended tasks with uncertain outcomes; it’s hard to specify what good outcomes look like in advance. For this kind of job, you want the cleverest sparring partner you can buy.

The system you design to implement that strategy will include lots of frequent tasks that will likely require less clever models. For example, imagine your business responds to lots of RFPs. Each RFP must be triaged. Some will be a good fit, others irrelevant. Those that fit must be routed to the right people in the org, hopefully with draft suggestions on how to respond.

You could prompt a frontier model to analyze each RFP as it comes in, perhaps using a ChatGPT project or Claude Cowork space for context. But that would be costly. A better approach is to break down the process into discrete steps and assign particular tasks to models with lower capabilities. If you know what “good” looks like for each step (which is much easier to do at this level), you can architect model interactions for optimal performance in each step — much as you would when delegating tasks in the real-world.

This approach doesn’t just reduce costs, it also makes the system work more predictably. Without upfront architecture, frontier models must parse each task from scratch, leading to variance over time. A more structured approach can be tuned for the exact range of outcomes needed for each step in the process.

Because the system is modular, you can use different models at each step in the process. Higher-level tasks that require orchestration can use more expensive closed models, whereas granular tasks with predictable outcomes can use less expensive (or even free) models called from deterministic programs. You can also switch providers at various steps in the process, preserving optionality.

Using a mix of models also lets you adjust for latency. Some tasks require faster reactions than others. Smaller, less clever, models can often have lower latency than frontier models. And of course, you can also be more selective about what information leaves your network: open weight models running in your infrastructure preserve your privacy.

Sounds ideal, right? You use expensive (and proprietary) models sparingly to design systems that use cheaper, open models for the day-to-day. What’s the catch? It’s the same one we had before AI: you must define what “good” looks like beforehand and architect the system to deliver expectable results.

That’s not bad, as far as catches go. Thinking through your workflows will force strategic decisions. It makes more sense to automate some workflows than others, and some will be more critical to the business than others. Mapping and architecting the flows will let you focus on what matters.

Yes, architecture can be expensive and time-consuming. But frontier models make it faster and less expensive. (Thats part of the top layer of the stack.) They also allow us to make richer prototypes faster than before, reducing the risk of over-specifying complex systems upfront.

This modular approach can scale and improve as new models come in the market. Today’s frontier models will be tomorrow’s entry-level. When that happens, you’ll want to reconsider the mix. Whether you can will depend on how you structure your systems today.

Unfinishe helps growth-minded leaders automate drudgery so their people can do human work. What's your bête noire? Reply or comment. 👇

On those new Chinese open weight models
All this talk about optimal model use is spurred by a couple of new Chinese open weight model releases that aren’t far behind the leading (closed) U.S. models. Ben Thompson offers a counterpoint to the item above: he expects the frontier U.S. labs to also dominate the tier below. Either way, I’m leaning toward designing model-agnostic systems.

DoorDash’s AI code reviewer
Details on DoorDash’s AI code evaluator system. Different stages, using different models. That is, a system architected to make optimal use of models with different characteristics (and importantly, costs.) Key line: “‘best’ is meaningless until you say best at what, on which cases, at what cost.” (H/t Benedict Evans)

AI helping (not replacing) workers?
A new Google study reinforces a trend we’ve followed for some time: AI isn’t really replacing workers, but augmenting them. Most people aren’t fully delegating their jobs to AI. Instead, they’re using it as a collaborator that leverages their expertise. Google has a horse in this race, so solve for the balance — but I believe AI job replacement fears are overstated. (WSJ gift link)

Claude Cookbook
I used to love O’Reilly’s “cookbook” series of books, which showed how to solve practical problems with particular technologies. This is like that, but for Claude. A tremendous resource that suggests your organization could benefit from becoming more AI literate. (We can help with that!)

Replacing software with AI
Starbucks spends $400m/year on software, so they’re using AI to roll their own. The losers: Microsoft, IBM, Oracle. The resulting software might be better-suited to Starbucks’s needs, but they must also tally maintenance and support. More importantly, in-house software needs to be designed and stewarded. Who’ll do that? (Hint: not AI.)

The Reverse Information Paradox
On X, Satya Nadella called for organizations to control their learning mechanisms, which are at risk of being ceded to AI labs. By delegating to the labs, you also pay twice: in cash and in knowledge you hand over to make models work. My sense is that if given a choice between outsourcing all your intelligence to frontier labs and building your own using less-powerful models, the latter gives you greater control. It also requires more forethought and structure — but you own your intelligence.

Information work as responsibility work
Tim O’Reilly, after chatting with Claude: “[AI] has no agency of its own. Humans set it in motion, evaluate its output, and should be held responsible for what it does.” I.e., you can outsource cognition, but not responsibility. What can you do about it? Invest in more upfront architecture, not more compute.

The new ChatGPT superapp
OpenAI launched a new all-in ChatGPT app. I haven’t used it, but it sounds bad. Gruber doesn’t explicitly call it an information architecture problem, but I will. It’s predictable: companies tend to ship their org charts, and OpenAI’s is a mess. AI doesn’t alleviate the need for IA, it amplifies it. New concepts need relatable labels, metaphors, and hierarchies. Who owns the structures your intelligence depends on?

A Script for Mark Zuckerberg
What will Mark Zuckerberg say in Meta’s next earnings call? Ben Thompson has suggestions. This isn’t just satire: the post spells out the connection between capex and strategic vision more clearly than Meta itself has. Can your board do the same?

The Control Layer
A pitch for Otari, Mozilla’s open source LLM control layer. It makes a point I’ve reiterated over the last few months: we’re past the initial point of experimentation with AI. Production requires infrastructure architected to deliver value.

After Forty Years, Still No Silver Bullet
In 1986, Fred Brooks argued there are no tech shortcuts to making software that’s radically easier, simpler, or more reliable. Many people think AI is the ultimate silver bullet. They’re wrong.

Kinetic Coffee Panel
The Kinetic Council invited me to join a panel with Abby Covert, Jessica Talisman, and Larry Swanson about the evolving role of information architecture. My position: practitioners focused for far too long on how to make information easier to find and use at the expense of what to do about it and why that matters. But AI forces organizations to think more strategically about how information is structured.

Forty years ago, computer scientist Fred Brooks published a paper called No Silver Bullet: Essence and Accident in Software Engineering. As its title implies, the paper argues there are no technological shortcuts to making software radically easier, simpler, or more reliable. You may think AI is the ultimate silver bullet. It isn’t.

Moore’s law was in full force in 1986. Hardware was getting more powerful, faster, and cheaper. Surely, some technology would come along to do the same for software. Brooks argued this wasn’t in the cards, since software is fundamentally different from hardware. For one thing, it’s of a different order:

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

Specifying, designing, and testing this construct is difficult. The challenge isn’t implementation but design: “We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.”

Technical advances usually make development easier. No Silver Bullet traces the history of time sharing, unified programming environments, and high-level languages. Object-oriented programming was a promising new technology at the time and there were even rudimentary AIs in the form of expert systems. Brooks examines them and concludes they’re not enough.

Why? Because coding isn’t the hardest part of making software. Instead, the hard part is knowing what to build:

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

What will the system do? How will it serve strategic objectives? How will it enable better judgment and allow people to derive meaning from data? These aren’t implementation questions, they’re design questions. Somebody must define the “construct of interlocking concepts” that define the system, aiming for good fit between the system and the context it serves. LLMs can help, but they can’t replace human understanding and judgment, at least not yet.

Brooks calls out four inherent properties of modern software systems:

• Complexity: Software systems are among the most complex human constructs. They’ve only gotten more so as computers and operating systems have grown more powerful and capable.

• Conformity: Software solutions must conform to the goals, needs, constraints, and interfaces of the organizations that bring them forth. This is true whether it’s bought off-the-shelf or developed bespoke.

• Changeability: Anything that lasts does so because it’s able to adapt to changing conditions. Software is inherently more malleable than other complex designed systems, such as buildings.

• Invisibility: Whereas complex physical systems (again, think of buildings) can be represented with mechanical drawings, software specs are inherently abstract. This makes them hard to design.

There’s been progress in the last four decades, but these properties remain fixed. LLMs haven’t changed that. Non-deterministic components add immense complexity and unpredictability to software systems. The ease, speed, and volume of code generation make software more malleable and opaque than ever. And LLMs promise to ease bespoke development, tempting orgs away from one-size-fits-all solutions.

Which is to say, LLMs haven’t changed the nature of software. Instead, they’ve made it more so. So far, the technology’s killer application is developing software: teams can now produce more software, faster. (It’s unclear yet whether it’ll ultimately be cheaper, especially when you consider maintenance costs.)

What LLMs haven’t done yet is replace software wholesale, at least not for tasks that require predictable behavior. And as their true costs and constraints become evident, it’s increasingly doubtful they will. Instead, LLMs will likely become part of systems that include traditional deterministic components — both inside the systems and as part of the development process.

The resulting systems will be more complex, malleable, and abstract than prior ones. They’ll also be better fit to purpose than off-the-shelf solutions. But that requires design, which remains primarily a human challenge. And it’s hard:

it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.

Replace “software engineers” with LLMs, and this sentence still stands. But it also hints at where LLMs come closest to being a silver bullet: in their ability to spin up rapid prototypes. Good software is grown, not built. That is, it evolves from an initial core to a more complex system through an organic approach that respects Gall’s law:

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built.

So it must be with our software systems.

What was true then is true now: technology moves the bottleneck from production to orientation. LLMs make coding easier, much like high-level languages, IDEs, and compilers did in the past. But without shared models, structured context, feedback loops, governance, and clear interfaces, they won’t provide the results leaders expect.

As always, how to build gets easier — knowing what to build doesn’t. AI can help with that too — but it needs steering. The question isn’t “Which systems can we replace with AI?” Rather, it’s “How can AI help us grow systems that better fit our needs?” The answer will consider AI as a system component and a production tool. But forty years on, there’s still no silver bullet — just better ways to find good fit, faster.

AI’s effect on middle management
A small study of how consultancies are using AI concluded that both juniors and execs are getting the most value from it — at the expense of middle managers, who now have to verify that the output is good. Subsidiarity is a key design feature of effective complex adaptive systems. Your org is one of them: your managers hold local context. Think twice before overloading (or worse, firing) them. (HBR gift link)

Gen AI and Taxonomies
Large language models work best given the right context — including the ability for agents to find the stuff they need. “Old school” taxonomies help a lot. And conversely, LLMs can help us create better taxonomies. Heather Hedden covering what feels like an essential — and for the most part, underappreciated — idea: that smart systems must be propped up by a lot of structure.

How AI is changing marketing
McKinsey claims over half of consumers are using AI to make purchasing decisions. But that’s only part of it: AI is fundamentally changing how marketing is done. But it won’t happen with ‘bolt on’ solutions. Instead, reinventing marketing calls for a complete redesign of how organizations market their wares. I’m biased, but several of the “new” roles described in here read like “information architect” to me.

Traction Heroes Ep. 39: Pace Layers
AI makes prototyping easy. But moving from prototype to production requires lots of architecture. In the latest episode of our podcast, Harry Max and I nerd out on one of the models that has most influenced my work: pace layers. If you think design is about making screens frictionless, easier to use, or (for Pete’s sake!) more attractive, you’re focused on the wrong layer.

CTO Report on cognitive debt
This feels ai-written, but I still found it useful: an informal report from a gathering of CTOs on what they’re seeing on the field. TL;DR: the AI free ride (i.e., unlimited budgets) is over; it’s time to invest in architecture. If your leadership is still suggesting replacing complex workflows with AI, send them this one.

Building Reliable Agentic AI Systems
An in-depth case study on how Bayer built a reliable AI research assistant for their (highly regulated) business. They turned decades of latent data in unstructured PDFs into highly structured context, implemented specialized agents to use that data, and created mechanisms to anticipate and correct the inevitable failures. Bottom line: it’s not enough to give LLMs access to your data; reliability requires architecture.

Big-time self-disruption
Tide is P&G’s biggest brand. Every thirty years or so, they risk it by introducing a new form factor (e.g., pods.) This cycle is about to start again with new detergent “tiles” — a bold risk. How far is your organization willing to go to disrupt itself? You likely don’t have a $2b annual R&D budget, like P&G does. They also have structures in place (including decades-long brand equity) that allow them to make such bets. The challenge for the rest of us? AI makes innovative moonshots more feasible, but bold bets without support structures and solid market signals aren’t reinventions, they’re expensive gambles.

The Birth of the Flywheel
If you and I have spoken at length, there’s a good chance we ended up discussing the Walt Disney Company. I’m a big fan, and have written about what we can learn from them when designing complex information environments and beyond. But this four-plus hour episode of the Acquired podcast goes much deeper, diving into the company’s history up to the early 1980s. The focus? Disney’s (accidental?) discovery of the synergistic business model they exemplify. It’s a history lesson on the successful merging of art, commerce, and technology. Takeaways: 1) build a diversified yet cohesive business model that creates self-reinforcing loops and 2) honor the Walts (i.e., creative geniuses) in your team willing to bet the farm — so long as you have Roys (financial geniuses) keeping the company alive. (The business model, you can design for. The geniuses… not so much.)

See you next week!

— Jorge

In systems thinking, this principle was best articulated by John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

I’ve long promoted Gall’s law to students and clients. It’s been hard going. We want to see products and services in their full glory ASAP. But you can only throw so much cash and person-hours at a problem. Ergo, we got the time-tested idea of a minimum viable product. (It’s no coincidence that orgs with more resources violate Gall’s law more often than scrappy startups.)

But the value of an MVP isn’t just that it allows you to get something that works quickly and cheaply. Instead, the value is that that first try isn’t overspecified to theoretical conditions. It’s only a draft meant to kick off an evolutionary process that leads to a system that meets real-world customer needs.

AI removes these constraints. An afternoon with Claude can yield a comprehensive spec for a very complex system. Further sessions can architect the system and build an initial release that includes bells, whistles, timpani, harps, violas, and all the other instruments in the orchestra. All this, at a fraction of the cost and time it would’ve taken in the past.

That’s amazing. It means we can now design and build much larger systems, faster. This opens new possibilities. Not just one new feature, a new product. Not just a new product, a suite. Not just a suite, a platform. The possibilities seem endless.

But in removing architecture and development constraints, we’re also removing the need to focus on what matters most and the discipline to run it by the market. All that upfront complexity doesn’t necessarily address real-world needs. Instead, it reflects a singular top-down vision that may or may not provide value to others.

Whereas MVPs in the “before times” called for minimal investment before validation, LLMs promise a much more realized vision from the first go. But there’s a significant difference between a sexy concept car and a vehicle customers will take grocery shopping. AI-augmented workflows will give you the former, but not the latter.

Here’s an example. Two years ago, I started building a product called SiteRanger, an AI-powered agent to help small teams manage large websites. This was before Claude Code or any of the current coding agents. Still, I got surprisingly far by using Claude to augment my basic PHP skills.

Together, we built a functional MVP that implemented what I considered to be the core functionality. The problem: my “core” was in fact an open-ended platform. Rather than solve a particular customer problem, it was designed to solve classes of problems.

By the time I got alpha users on board, the system was wildly over-architected. Worse, I learned new agentic systems could provide ~80% of its value. When I looked to pivot, I realized I’d have to move in a completely different direction, one with entrenched incumbents. It wasn’t worth it.

It wasn’t all a loss. This experiment taught me a lot about developing AI-powered software products using AI. But the most important lesson I learned is that AI makes it VERY easy for individuals and small teams to land in the same trap as resource-rich orgs: no constraints.

Which isn’t to say you shouldn’t use AI. To the contrary, I’m all for accelerating MVP design and development. But the word “viable” is fungible, especially when you have robot engineers. You want to expose the product to the discipline of the market. That means releasing something embarrassingly simple at first. And that requires discipline and constraint — the two things most scarce when working with LLMs.

My friend Karl Fast pointed me to a wonderful scene in the movie A RIVER RUNS THROUGH IT. The main character, a child, brings an essay to his dad, a strict preacher, for evaluation. The dad’s only reply: “Half as long.” The child does, and returns with the edit. After scribbling with a red pencil, the preacher looks at him and says: “Again, half as long.”

Step away from the console and ask yourself: What would I cut if there were no AI building it? Cut, cut, cut. Then imagine Tom Skerritt staring at you over his schoolmaster glasses and saying drily, “Again, half as long.”

A frontier without an ecosystem is not stable
Satya Nadella offers a refreshingly adult perspective on the relationship between AI and human capital. The two are interdependent; AI isn’t a replacement for people. My take: in a world where AI labs want to lock you into intelligence-on-tap (at an initially subsidized cost), architecting context around your data and IP becomes your moat.

Doom Trolling
Cal Newport on frontier labs’ incessant fearmongering as a way to gain attention or regulatory capture. Or perhaps they believe their rhetoric, which would put them in an ethical bind. Anthropic’s fearmongering has now led (perhaps wittingly) to the U.S. government slapping export restrictions on them. This is a risk if you build solutions around these proprietary systems. (NY Times gift link)

The Heart of LLMs
Melanie Mitchell on the intrinsic limitations of LLMs. Experts have differing opinions on these systems’ capabilities and constraints. I’m with Yann LeCun: “A system trained on language alone will never approximate human intelligence, even if trained from now until the heat death of the universe.” That doesn’t mean they’re not useful, but the degree of intelligence they demonstrate at performing day-to-day tasks is almost entirely dependent on how you architect their context.

What it feels like to work with Mythos
Last Friday, a client and I experimented with Anthropic’s Fable. I’m glad we did: a few hours later, the U.S. government slapped export restrictions, forcing Anthropic to pull the model for everyone. It’s still unavailable, but if you want a sense of how Fable/Mythos differs from other models, check out this post by Ethan Mollick. My take: these advanced frontier models are very expensive and energy-intensive for most day-to-day tasks. But for a certain range of problems (e.g., research, which is what my client and I did with it,) they’re unparalleled. The risk: you lose visibility and agency in the decision-making process.

See you next week!

— Jorge

In the third of our Open-Ended Sessions, we discussed how AI is changing how product and design work are done. In particular, we’re tracking the shift from feature- and screen-level work to more strategic and human-centered system design.

Lots of orgs are choosing to deploy AI as a means to do more of the same, only faster and cheaper. But AI can also be used to unlock new possibilities by augmenting (rather than replacing) humans.

As Greg put it,

The efficiency play can be in service of unlocking human potential, right? So they don’t have to be either-or paths, but they do have to be both at a minimum.

Ultimately, the key question isn’t what the technology is capable of, but what it’s for.

Links

Books and posts mentioned in the conversation:

• Magnifica Humanitas by Pope Leo XIV

• I think Anthropic and OpenAI have found product-market fit by Simon Willison

• The Cost of Being Busy by Craig Hepburn

• The Feature is Dead. The Job Remains. by Greg Petroff

• This Moment We’re In, Ep. 3 (Greg’s conversation with Cindy Chastain)

Transcript

(AI generated — likely contains errors.)

Jorge: All right, hey Greg.

Greg: Hi Jorge, how are you?

Jorge: I am doing all right.

Greg: Yeah.

Jorge: It is interesting times.

Greg: Oh my gosh, yeah. You know, I think when we were talking about perhaps hosting one of our sessions here, it was really about the zeitgeist, like what’s happening this moment. And there are these peaks where all of a sudden there’s some kind of thread that shows up that just begs to be probed. So thanks for encouraging me and us to have these conversations. And for those who are joining us, welcome to number three of our Unfinishe sessions, where Jorge and I just talk about stuff that we think is interesting that’s going on. And we hope you find it valuable as well.

Jorge: Yeah. And it might be worth recapping beyond the open-ended conversations. This is not just something that we’re doing because we want to talk about things that interest us. In some ways, it feels like the transformations that we’re seeing are, sounds kind of heavy-handed to say it, but they’re existential. They kind of are. And these conversations I see as an opportunity to name the things we’re seeing. You have your note taker just joined when he’s trying to join. You see, it is existential.

Greg: That’s right. There we go. Goodbye.

Jorge: It might be worth unpacking what that means, but we have not pre-scheduled these, to your point. We’re kind of calling these conversations when we have sensed a shift in the zeitgeist. And this is the third one we’ve had so far. And I’m going to try to sketch out the conditions that precipitated this one. And then we’re going to circle back to a post that you shared, which I see as kind of like a way to deal more skillfully, for organizations to deal more skillfully with the situation that they find themselves in now. But there are several factors at play here. One is the big shift toward the end of last year. I think we saw a big shift in how people in general are thinking about AI. Agentic software development tools like Claude Code started proving their mettle in the organization, right?

Greg: Yeah.

Jorge: And Simon Wilson recently had a blog post where he said that Anthropic and OpenAI have found product-market fit. And he was referring specifically to these tools, right? So there’s been this shift from a modality that is more focused toward software development. And then we have things like Claude Code that build on that agentic way of working with these systems. So that was a big shift toward the tail end of last year. And then I would say that around the end of the first quarter of the year, we started paying the piper, literally. Organizations have started realizing that that kind of usage can get very expensive, right? And we’ve started to see some organizations start to pull back, capping their people’s budget for using these tools.

Greg: I would just build. I’ve been working as a fractional for a couple of different companies, fractional design leader, for those who haven’t heard that term before, over the last year. And to watch how product organizations have started to use these tools, and then the uptake in them, and then the capabilities that they unlock, and then the speed that teams can work at, and more importantly that you can do more, it’s been really remarkable to watch. And at the same time, it’s causing all kinds of churn because teams are struggling with who does what, how, when, and they’re hitting some of these issues too around utilization and use of the tools and the cost of using the tools, and not just the financial cost of using the tools, which can be significant when teams burn through their tokens, but the cognitive costs of using these tools, because you can build incredibly dense, rich, powerful documents now, but then your peers have to have time to consume them. And one of the things I’m noticing is that many of us are collaborating with our AIs more than we are collaborating with each other. And so there are all these kinds of things that we’re learning in the process of using these tools. And I also think there was some hyperbole around what was going to happen and how this might change things and the number of people, etc., that I think is starting to not show up. I think there are some things that we can think about that are different. So in this moment, yeah, we saw toward—

Jorge: Beginning of the year, organizations were starting to boast of how many tokens they were using, and they had leaderboards for this stuff.

Greg: Yeah.

Jorge: Which is another factor here that I think the emphasis was clearly on adoption as opposed to value creation. And one of the things that has shifted is, well, first they’ve stopped doing that because I think they realized, like, hey, this is really expensive. But also, that’s no way to measure progress, right? What you want to do is you want to be actually creating value. You don’t want to be boasting of how much you’re using the tools, right? So it feels like we’re kind of speed-running the process of maturing into how—

Greg: These tools can serve human needs. Yeah, there’s a whole set of new problems that are showing up inside product organizations around utilization. Are you using the right model? Are you leaving your context window open too long and therefore every time you ask for something you’re burning through credits like mad? Did you budget appropriately for the amount of credits that your team is using? What does finance think about all of that, right? I think there’s a whole bunch of things that are popping up right now. And some of that showed up in some recent announcements with Microsoft deciding to turn Claude off inside of their environment. There’s been conversation about bringing their own code development tools and their own models to bear, so maybe that has part of it. But I also, from what I understand, they were spending a lot of money. And my own experience in watching the team that I’ve been helping, the startup that I’m working with, is we run out of credits on a regular basis, or tokens on a regular basis. And then we have to go and ask for more. And there’s no real governance or process in place for a small company where they’re kind of making it up as they go and trying to understand what it means. They want to go fast, and so they’re willing to spend the money, but they have finite resources. So they can’t spend as much as they maybe think they should, or as the team wants to spend potentially. And there are all sorts of stories around teams that have burned giant holes in the budget of their organization by doing things which may not have been valuable, right? And it goes back to your point around this leaderboard thing. And I think one of the things that there’s a really great post by Hepburn about the cost of being busy that I think is really interesting to me. It was really about the teams that give the tools so that AI can be adopted throughout the organization and people sort of adopt them at their own speed are not really getting all that much productivity gain. They’re getting richer content perhaps, but they’re not institutionalizing the work in a way that takes the work that’s repetitive or less of priority and maybe building agents around that so that you can unleash your people towards new things. And I think there’s another aspect of this, which you and I started, I think this is one of the reasons why I wanted to talk this week, was Pope Leo’s encyclical came out, and it kind of fits a notion that we’ve been talking about for Unfinishe, our practice, which is we want to help organizations discover how they can, you know, the possibilities of unleashing their talent towards new efforts versus a productivity gain where you’re laying people off because you don’t need them anymore, right? I think it’s a very different mental model. And I think that there’s something about this conversation that needs to come up around the humans in the system and the value that these tools create for us, but also the value of work, etc., that I think is a notional, the conversation’s happening now and that’s good. And I think that document was a really important document to come out. And there’s been a lot of conversation around it. I know you have a take on it, but some people will leave it at that and hear what you think.

Jorge: Yeah, and I’m glad you brought that up. And even though this is turning into a kind of long preamble, I also want to bring to the table the conversation that you had with Cindy Chastain on her podcast.

Greg: Yeah.

Jorge: Because that conversation also circled around some of these issues. And I’m going to try to name it, just hearing you talk about it. I’m going to try to name the connecting thread for all of these things that we’re observing. And the thread is the question: but what is it for? It’s like, what are we doing with this, right? What’s the point? The conversation with Cindy, one way to summarize it might be something like: for design and product teams, there are two possible things that you can do with this. You can approach it as a way to do the things you were doing before more efficiently, faster. I don’t know if more cheaply, as is becoming evident, but do, let’s say, more with fewer people, right? Or another possible approach you could take is you could take this as an opportunity to do more with the people that you have, or maybe even with more people in your team, right? Just empower them to explore possibilities that were previously unattainable because of the natural constraints of a team of humans and their limited cognitive abilities and attention. And I wanted to bring that up because, A, I think that we, well, I’d love to hear your take, but I think that we’re both in the second camp. It’s like, hey, let’s see how we can augment people to do more. Because one of the things that motivates us in our shared practice is possibilities, like opening a broader space of possibilities, right?

Greg: Yes, I think with possibilities, intention, like what future do we want to have and how do we help teams and organizations fulfill that in an intentional way? And I love that you brought that up because I think the conversation that Cindy and I had was really about two stories. I’ve been doing this fractional work, and over the last year I’ve worked with two different companies, and sort of not at the same time, too. So one was sort of last year to the end of last year, and the second one is I’m currently engaged with and I started with in January when all these tools started to mature. And there are sort of two conversations. The first one was sort of dabbling with AI, learning how to use the tools, some experiments with vibe coding, etc. The second one was the design team and the product team not only using those tools, but exploring whole new territories that we just didn’t have time for in the past to do. So we were imagining a new product capability, a new product category for a company, not a pivot, but an expansion of this particular organization’s remit that they want to serve. They had a really good idea of a set of problems they wanted to solve. And we just did things that were just hard to argue for in the normal timeframe that software development gets built. And we were able to do them. So we did a bunch of work on information architecture. And one of the things that we did is we looked at competitive tools that were out there, other people trying to solve the problem in similar ways, and we did really deep analysis of how they structured their experiences so we could try to understand why they were doing it. And that helped inform a better architecture for us. We did a bunch of work looking at agentic systems and emerging conversations around how to build MCP apps. And that was exploratory. Frankly, I think it’s exploratory for everyone who’s working in that area. And so we were able to help use the process of making to define the product requirements. And in some ways, we were leading product development in that conversation because we were really trying to understand meaningful outcomes. And we came up with this thing we called the job brief, and it worked for us very well. So I think the opportunity right now is to build much better products. The concept of an MVP to me is sort of like something that needs to be reexamined because most MVPs were always insufficiently great because they were constrained by time and engineering resources. And now, where engineering resources are less constrained, why do we put product into the market that isn’t foundationally awesome? And so we can do that. And I think there’s an opportunity to really ask the organization to rethink how it takes the time of their customers and fulfills their needs and their goals. And we can be much more clear and more polished and build things which on launch make people feel seen, the users of them feel seen in a way that we couldn’t do before. And so I think that to me is an inkling of what these tools should be doing. And that’s just a product development example. But I think you could do this for organizational change. And I think any organization could take a look at it and say, I don’t just want productivity. I want to unleash the creativity of my people towards new outcomes. And that’s the kind of work I want to work on. I think it’s the kind of work that you want to work on. And it’s the kind of work that I think that the Pope’s encyclical talks about, which is meaningful work and placing humans in the system and not just this sort of technocratic cost-out perspective.

Jorge: Yeah. There’s been a, well, you wrote a post about this and I want to get into the post.

Greg: Yeah, sure.

Jorge: The very title of the post has the phrase, “The feature is dead.”

Greg: Yeah.

Jorge: Which is kind of provocative, right?

Greg: Yeah, sure.

Jorge: Why is the product feature dead, Greg?

Greg: Well, I think we’re designing something different now, right? Feature was a component, a widget, a tool that helped humans solve a problem. And in the traditional way of product development and user experience, the actor was the user, right? The user’s on a journey. You build a capability for them to complete a task that’s important for them. They use that tool. They get it done. And so product development would think in increments of capability, features. That’s what we call them in product. And we would build those features in support of customers accomplishing their goals that were important to them on their adventures at work. And what’s changed now is we have this intelligence that we’re working with. And it can be the actor, right? It can make the choices and decisions on the process, especially when you think about more agentic workflows. And so the notion of product discovery and creating and making is different. We’re not making a widget or a tool. I mean, those are still important, and by the way, yes, thank you for calling out it’s a provocative title. Features don’t disappear; they still are important. But I think what’s more important is encoding the intelligence in a system so that it can support humans and their goals, but also allow some autonomy for agents to do things. And that’s a new skill, a new pattern. And the way I was thinking about it is Clayton Christensen coined this term jobs to be done. And jobs to be done is sort of evergreen. It doesn’t go away. You have to balance your checking account or you have to pay, make payroll, or you have to answer a customer call. But the way that you can do that can change over time with the way technology shows up or how an organization chooses to solve that problem. And ironically, a lot of organizations don’t actually really understand what they do. They’ve built sort of Rube Goldberg machines of technology that allow them to accomplish tasks, and individuals in the organization are actors in that to solve a business problem. But very few people in the organization actually understand the outcomes and business goals that an organization is trying to solve for. So I’ll give you an example. The reason why this came up is there’s also something very different in the way that we can build software right now, where it’s more structural and more of a system and less bespoke custom feature development. So this particular startup that I’m working with, we are building a system that can add new capabilities, and we wanted those new capabilities to show up almost like a feed of content, right? The application would be much more like Spotify, where you’d have a playlist of things that you can, instead of a playlist of things you listen to, a playlist of things that you can do. But to do that, then you have to kind of understand, like, what do those things do and why are they valuable and how do they achieve outcomes that are important for the end user or the company that’s buying a product or a service. And so we built this thing. I’m calling it a job brief. It’s a little bit of a hybrid. It’s influenced a little bit from the Josh Seiden sort of outcomes over output construct, being an outcome-centric notion. But what I wanted to do is try to create a recipe. And I built this sort of recipe card. You can’t really see it here, but I’ll share this with folks if they’re interested. And it was really very straightforward: find the job. What is the problem? Sit with a practitioner or a person at work and find out what is the thing that they need to accomplish. Write a job statement, one sentence: who’s the user, what are they trying to do, whether they want to know or decide. Don’t make it about technology at all. What’s the outcome that they’re trying to get to? And then the next layer, which is new, I mean, this is something we’ve done forever, but the next layer is what is the context that we understand in the system? What data do we have access to? Where is the user or the person who’s acting in a moment in their day, in their workflow, in the ebb and flow of an organization? You have to define what done means. When the job is completed, what does success look like? And then the last part of it is really understanding what expertise is around that. And working with people who have deep knowledge of what that outcome should look like, what’s meaningful for an organization. And I would argue that for every organization, that expertise might be different based on the values of that organization, the people they have, the things that they find important. And this is an opportunity to add that human layer into what differentiates company A from company B. Don’t just use a novel solution that everyone uses. Build something that’s respectful of what’s important to you as an organization. And then finally, the last part is find some way to measure it by how often it’s used, by invocation, like how often it gets done. And so that construct is really about understanding how humans in the system work. Now, I’m not naive. Some of this work turns into agents that do the work for you. And ideally, in an organization, you could use this as a way to look at the things in your organization that you can codify, the domain expertise, to gain productivity and to gain efficiency where you can. But my next point of view on that is in service of being able to do more interesting, more valuable work that pushes your objectives farther forward. And so that’s the notion behind it.

Jorge: This is all in the context of design and the projects that you have been working on. You’ve been working, your role has been like a fractional chief design officer, right? So you’ve been leading design teams. Another one of the signals that we are picking up from the environment is that it feels like many organizations are questioning the value of investing in design.

Greg: Yeah.

Jorge: And I was thinking, there was a time when a lot of organizations did not have big design teams internally, right? The idea that design is a function of the organization, I would say at least the current wave, because there have been prior ones, but the current wave, we can probably date back to around 20 years ago after it had become clear that Steve Jobs had saved Apple through design, right? And people were upholding the iPod as an example of a well-designed product. And there are still business leaders out there who are thinking in terms of, like, I want something that is as useful, beautiful, whatever, as the iPod, right? So it became like a touchstone that articulated the value of design for organizations. And that seems to have shifted significantly as a result of AI. And I suspect that it might not be coincidental that Jony Ive and company’s latest product to hit the market has not been well received by a lot of people. I’m talking about the new Ferrari.

Greg: Yeah, right.

Jorge: And I have no, you know, I’m not an expert in that space. I’m not a Ferrari fan or anything. To me, it looked like—

Greg: I lost your audio. Oh, no. I can’t hear you. Now I can.

Jorge: Okay, great. What I was saying: I am not a Ferrari fan, so I don’t have as strong feelings about that product as other people. But it did strike me that at least a lot of the commentary I saw online, I got the sense that it felt like this, like it was over-designed or like it’s precious. Or it’s like it’s a product that is trying to make design, like it’s a design-forward thing. And in some ways, that almost hurt it because it feels like it’s a rethinking of what a Ferrari is supposed to be. And I almost found it to be like a metaphor for what’s happening elsewhere in design. It’s like, I guess the question is: is design necessary now that there’s a Claude design and Figma will do design work? And I think that I’ll stop after this. I think that a lot of organizations have built design functions that are primarily production functions.

Greg: Yeah.

Jorge: And by production, I mean they are set up basically to crank out screen-based experiences.

Greg: Yeah.

Jorge: And they have staffed up with people who are tasked with doing that kind of work. And at least to me, it’s been pretty clear that that’s going away, and it has been clear for a while, right? The tools have been getting better. The kind of design work that you’re talking about when you talk about job briefs. You said that the jobs-to-be-done construct is evergreen. And I think that one of the reasons it’s evergreen is because it moves the level of abstraction. It’s not about how do you execute on the hole in the wall. It’s about how do you determine what it is that the customer needs. And then you can figure out how that’s delivered to them, right? And I’m wondering, I’m just, again, this is open-ended and unstructured, right? So I’m thinking out loud here. I’m wondering if what we’re seeing is a shift from an understanding of design as this kind of screen-level production function to, and then there’s a question mark. And I think that your article tries to answer that question by saying to a role that is more strategic, which is something that designers have been trying to do for a while with not a lot of traction, I would say.

Greg: Yeah, many haven’t. Yeah, there have been some examples of people who have, but yes, you’re right. Let me respond to it. I think when we build products, there are different roles that are really important. And I think when design is seen as only craft and only as screen building, it misses the value that design can bring to the table. Those things are important, but they’re not the only thing. And the challenge is that at some level for many people in many organizations, the AI tooling is capable of doing, I wouldn’t say excellent, but reasonable results on the sort of production-level quality of building a user interface. However, I think one of the things that designers bring to the table is a deep understanding of human behavior and building products that recognize humans in the system and the mental models that people have. And it’s connected to empathy. It’s connected to having the ability to do ethnography, basically sit with customers and understand how they solve problems and what they’re trying to accomplish. It requires some new skills now because when we look at the capabilities of these tools, you can incrementally make things better or you could radically change things. And it doesn’t mean one or the other is the right path. It’s actually what is the right path for the group of humans that you’re responsible for delivering a solution for. Too much change may require a group of people to do things they’re just not unwilling to do or unable to do cognitively. Not enough change is a missed opportunity toward functionally changing the game in a way that produces some really interesting results for an organization or for the people who work in the organization. And we’re in this really messy period where the old rules don’t really apply and people are trying to apply the old rules. So you still see PRD, product requirement documents. You still see engineering burndowns. You still see JIRA tickets created. You still see, this is a software development process, because people anchor to that. That’s what they know. They kind of organize around it. But it’s unclear to me if that process of how we built software is still usable and useful in this new moment. And there’s an opportunity to change that. So where am I going with all this? I think designers bring a couple of skills to a team that are really valuable. And if not there, it’s a missed opportunity for organizations. And they can be very strategic. We are adept at the art of juxtaposition. We can take two different ideas and put them together and discern a net-new outcome. Because we make the think, we make things, we make artifacts, and those artifacts inform us. And that conversation we have with the things that we make allows us to find truth or an answer or a solution or a novel way of solving a problem in a way that can be faster than other methods. It’s not the only way to solve those problems, but it’s a super valuable way to do it. So that’s kind of just one path that designers take. The second part of it is I think it is my personal perspective that it’s inexcusable that you don’t make things great now because the tools let us do that. And that requires discernment. That requires someone who can look at a small radius or a small curve on a user experience or looking at accessibility and making sure that a product is useful for all of us, regardless of our abilities. That we can choose words carefully so that it aids people in the direction of the path that they’re trying to take. We don’t just build a piece of software and expect them to learn how to use it. We can now frame a product in a way that fits the mental model of the people that we’re serving, and we can actually get closer and closer and closer to that because these tools allow us to actually iterate and understand that more successfully. So I guess a long way of saying is I think designers are very important. There are some new things that we have to look out for, like I think interfaces are starting to collapse. We’re doing more of our work in language models, right? We’re speaking with AI. We’re having a conversation with AI. AI systems can not only answer words, they can answer in interfaces, so they can create custom experiences for us or custom tools for us in the conversation. You could just do that. But I think the thing that design brings to the table is an intentional way of doing it, shaping the grammar of an organization, inserting a value set of values into an organization, shaping how answers are delivered. Are they long? Are they short? What’s the structure? What’s the organization of them? Left alone, a large language model may choose to answer a problem differently every time you ask it, and that may not serve the audience that you’re trying to serve, right? So I think there’s a role for design to be very much involved in intentional curation of these experiences and bringing human values into them explicitly. I remember, I’m forgetting who told me this. I’ll think of it in a moment. But all software has opinions in it, whether they are explicitly or implicitly embedded in the software. Some teams are very explicit about it: this is what we do, certain things. Others, it’s just the end result of the people who built it and what they valued. But it’s there, right? We have an opportunity to be very explicit about how we serve people. And again, I think design is the discipline that not just solves business problems but figures out ways to make it deeply human. And I think our opportunity is to help organizations at a different layer, at a different level. And it may not be screens we’re working on. It could be orchestrating the flow of how work happens in a way that makes sense for people. And that’s a new skill. Not all designers are going to pivot or understand how to move into that space. But I think the things that we bring to the table are very useful there. Anyway, that—

Jorge: Was a long answer to your question. Well, and it kind of prompts some follow-up questions. You said earlier in the conversation, and I’m going to be—

Greg: I lost you there for a second there, Jorge. I think your internet took a—

Jorge: Yeah, something’s glitchy. Can you hear me?

Greg: I can hear you now, yes. I wanted to repeat your question or insight.

Jorge: Yeah, so you said, I’m going to paraphrase and probably get it wrong, but you said something earlier in the conversation along the lines of one of the things that we’re grappling with, and this was talking about as designers, is the fact that many of the things that we were doing as humans working with tools are now being delegated to agentic systems, right? And I’m going to put on my CEO hat, right? Like I have to make, I have to determine how I’m going to invest, how I’m going to allocate the organization’s capital, right? And there’s a lot of incentive right now for organizations to invest in capability, like technical capability, right? Compute is what they’re calling it, right? And you said that one of the things that designers bring to the table is a deep understanding of human behavior. Yeah. But if the systems that we’re building are not going to be used by humans, why does that matter? If I’m a CEO looking to invest, what’s the argument in favor of investing in a design team that is going to be crafting experiences to be used by humans? When, hey, isn’t AI going to do all of it? Why am I investing in human experiences?

Greg: Well, I mean, that’s a great question. I think if you’re a cost-out CEO, that may be what you think about, right? You’re like, I don’t need a design team. We’re going to use all these tools, and we’re going to deliver this service with as few people as possible. And we’re going to look at generating as much revenue as possible. And this is a path for us to get there. And my guess is there’ll be many parts of our economy that are going to be efficiency plays like that, that are going to be things that people are worried about from a job perspective. And it’s sort of inevitable. However, I also think that there will be a group of CEOs that have a growth mindset who look at what their organization does in their community or wherever they serve and look for opportunities to provide better services or better outcomes or better products. And I think one of the things that’s missed is there’s this bottom-up and top-down conversation that’s missed. So as an example, I think small organizations benefit massively from these tools because they allow them to punch way above their weight so they can compete at levels that they couldn’t compete with before. And small, intimate teams with these tools that communicate well with each other now have the ability to expand their horizons around the things that they can offer, the services they can develop, the things that they can provide for whoever their customers are, or users are, or whatever their goals are, whether they’re for-profit, not-for-profit, etc. In large organizations, I think the transition is going to be identifying also where in the aspect of the services that they provide that humans are actually important for their customers, right? So I think as humans, people want to hang out with people, right? And I mean, there are people apparently who have chat, cheap, and girlfriends, but I think most of us are, especially even post-pandemic, and I still think we’re in the post-pandemic phase, we want to have a sense of community and connection to each other. And so I think there’s huge opportunity for organizations that recognize how to place their people front and center with their customers or the people that they care about or the things that are important. So I guess what I’m trying to discern is I think there’s an opportunity space for the people who are good at unlocking possibilities and discerning new things to service, developing better outcomes for all of us. And it’s a little bit of a, you know, it needs to be seen, but I think that’s the path that I want to see. I would love to see our politics in this world focus on the opportunity to service and support everyone. I’d love to see our businesses look for opportunities to grow their businesses in new and creative ways. And I would love to see human potential be the big story about being unlocked by these tools versus being laid off. And I think we need to think about that very hard. I think we need to find this is going to be a transition. There’s not going to be without, there already is massive transformation going on in organizations. And I think we are, as a culture, need to be managing this carefully. And again, I’ll come back to why I think design is important, because I think designers can find opportunities to potentially mitigate some of the challenges with AI, from an employment and cultural perspective. But they’re also just going to be great at finding new things to do that we didn’t know we needed before and that are exciting and fun and fulfilling and helpful. And so, if I were a large CEO, one of the things I would be investing in is a creative design team that is just exploring and looking for net-new things that could benefit, that are adjacencies to a company’s core mission that might be new growth opportunities for them. And I think that the tooling allows creatives the opportunity to really shine there. I don’t think we’re there yet. I don’t think people have talked about it yet enough. But I do think that there’s really an opportunity for us to look for ways to be more future-focused and actually try to tackle some of the real problems that we have in the world.

Jorge: I kind of want to double down on what you’re saying there, because in playing devil’s advocate earlier, it may not have been clear just how much I agree with what you’re saying there. But my read is that organizations that are kind of restructuring themselves to maybe, like a phrase that you could, maybe a phrase we could use is something like a post-design world, or like a world in which they’re not placing their emphasis on human experience, right? The organizations that are investing in AI as a way to gain efficiencies by automating the sort of touchpoints that humans have relied on so far, they’re doing so from what I see as like a, like in my mind, I have this Venn diagram that has fear, bad incentives, and a kind of like spectacular lack of imagination. Yeah. The phrase that often comes to mind is this Warren Buffett thing where he says that he advises being bold when others are fearful and fearful when others are being bold. And I just want to kind of double down on what you said about this being a time of unique opportunity, particularly for the organizations that are willing to zag where everyone else is zigging in the direction of efficiencies. Just because there are, like to your point, there are now possibilities that were just previously unavailable. And to only think about the path of, like, how can we make, how can we deliver the minimum possible experience as cheaply as possible is one possible direction, but by no means the only one, right? And I suspect that we are still in the throes of, like, hey, this is a new technology and let’s double down on efficiencies where we have not yet truly explored the possibilities of other ways of using the technology, right?

Greg: Yeah, I mean, I love that framing. I’ve been a big, one of the things I’ve talked about for the last 10 years is this notion of incrementalism versus really understanding the problem, right? And for a lot of organizations, incrementalism was the path towards success because you took small pieces and you got better and you got better over time and you got better over time. It kind of fits the Agile Manifesto. It’s how organizations work. They’re risk-averse, so they don’t want to try to take on too much. We’ll make one small change, we’ll make a change of, you know, and. But it was connected to the fact that things were very difficult to do well, and therefore you had to be careful about doing it. And so instead of going for it and doing something big or trying an experiment and failing, you just made your product slightly better over time or your outcome slightly better over time, your system slightly better over time. And there’s nothing wrong with that as a strategy, by the way. It makes sense and allows you to do things in a sustained way. What is interesting about this moment is that these tools allow us to build things that used to be very, the very expensive part of building software is far less expensive than it used to be. And so an incrementalist mindset may just be a faster way to get to the wrong place, you know? And I think one of the things that we don’t do enough of is discovery work, understanding what is the problem and what would really be meaningful for people. And now we can spend a lot of time in that, right? And in the design space there’s this diagram called the double diamond that came out of the British Design Council that’s a very popular way of describing the process of design. And the first half, the first diamond, is discovery. And then you sort of evolve that into a product, and then you go into an execution phase, and then you deliver and you learn from your customers. And my argument now is that these tools allow us to build the first part of that diamond much bigger and the rest of it much smaller. And what do I mean by that? It means that we can spend, in a short period of time with these tools, we can learn way more about who we’re serving and have a much better understanding of what their problem is and iterate on not just one, but hundreds of solutions that could possibly satisfy those needs and outcomes, and then discern which one is the best, refine it, make it great, and then deliver it at fairly low cost from an execution standpoint. And so that upends the process. It used to be the other way around, that the execution part was so hard that that’s where all the energy was, right? And so it was like, make a small bet, get it out to market, make another small bet, make it out to market. So it goes back to your point of lack of imagination. And I think there’s an opportunity right now for companies to at least have some part of their organization that is thinking boldly and broadly and unhampered by an incrementalist mindset. And I think if I were a CEO of a larger organization, I would be setting up a lab to think about not how to use these tools to do what I do better now. I would be setting up a lab on how do I use these tools to do something I’m not doing now that would help me grow my outcomes that are important to my shareholders or to my customers or to the business community that I’m trying to connect to.

Jorge: I love that framing.

Greg: And I think designers are great at that. They’re not the only one. There need to be other parties in that conversation. It’s a multidisciplinary effort, but it doesn’t work without designers in the room.

Jorge: You know, to circle back to the Pope’s encyclical, the central metaphor that he uses to talk about the possible ways forward for the development of AI-based systems, he uses this architectural analogy from using two stories from the Bible. One story is the construction of the Tower of Babel, which is a kind of technocratic, top-down effort to, now I’m kind of reading into it, right, to control. And it’s an effort that kind of flattens differences between people. And he contrasts that with another story from the Bible, which is the rebuilding of Jerusalem after it had been torn down. And he talks about Nehemiah. I don’t know if that’s how you pronounce it, but this person who rather than dictate top-down this technocratic solution, gathered the people who inhabited the city. And through this kind of consultative approach, led to the rebuilding of this kind of organic, more organic city that responded to their needs. And part of what I’m hearing you say is that, and I think that this is also implicit, if not explicit, in the encyclical, is that AI allows for both of those approaches. We can do the top-down thing really fast now and really comprehensively, and it can turn into a real dystopia. Or we could employ it in this more kind of bottom-up, consultative, human-centered way, and it could also do it much faster with greater scope, with the possibility to explore many, many more alternatives just because the tool allows us to do so much more. So it becomes a matter of how do you choose which of the two approaches you’re going to take? And I think what we’re saying here is we would like to foster a world that follows the second path, the more kind of designerly path, the path that puts human beings, their needs, including their dignity, which is an important word in the encyclical, front and center. And the tools are amazing. They can empower us to do much more than before, as long as it’s in service of that, right?

Greg: Yeah, creating a better world. And the irony is you can have both of those things happen. The efficiency play can be in service of unlocking human potential, right? So they don’t have to be either-or paths, but they do have to be both at a minimum. If we just go the Tower of Babel path, I don’t want to live in that future. I’m very much interested in being intentional about the choices that we make. And again, that’s why I go back to why designers are important. We’re good at that. We are good at intentionally helping craft a narrative and artifacts and things which connect to the way that we want to live. And then we’re good at telling stories around that with the things that we create. Those things that we create inspire people. And it’s a really part of being human that there are things that delight us and bring us joy and make us cry and help us understand and live fulfilling lives, all the things that I think are important, which by the way, that’s not the longest list of important things, but nonetheless, I think we’re coming to a close.

Jorge: I was going to say that feels like a good place to wrap it up. If you want to follow our work, we do have a Substack. It’s called Unfinishe Thoughts, and it’s at thoughts.unfinishe.com. Remember, it’s Unfinishe without the D. And Greg and I post there periodically. It feels like almost as infrequently as we do these live streams, but we should write these things up more.

Greg: Yeah, our plan is to be a little bit more prolific in the rest of this year. But thanks for hanging out with us today. And Jorge, as always, I love hanging out with you and talking about our stuff. And we’ll see you at the next Unfinish.

Jorge: Same here. Thanks, Greg. Bye.

Product and design work is changing as organizations embrace AI. But how so? Greg explored this question in the third episode of Cindy Chastain’s podcast, This Moment We’re In.

His answers weren’t theoretical, but based on his experience as a fractional design leader, a role that allows him to perceive high-level patterns from a relatively impartial vantage point. This leads to important insights.

I’ll summarize the key ones here, adding my observations. Then, I’ll circle back to Greg’s parting recommendation — a framing that teams should start adopting immediately. Let’s get into it.

Roles are blurring

Traditional team boundaries between product, design, and engineering starting to blur. As Greg put it,

one of the things that was interesting in that particular group was we were moving away from a PM culture and an engineering culture and a design culture, or a design discipline and a product discipline and engineering discipline to a product culture that it was inclusive of all those roles, and that the who was what was situational and based on need.

This has upsides and downsides. On the plus side, team members can step in to perform others’ functions as needed. The result? Sustained velocity.

The main downside: a potential lack of alignment and control. But also, team members may find themselves making decisions outside their area of competence. Roles still bring discernment to the table, which is essential.

As an example, Greg recalled a case in which a PM vibe-coded a design artifact in a week. They were celebrating the fact this could be done at all, when a designer in the team observed they could’ve done it in four hours.

That a tool exists doesn’t mean it will be used effectively.

Two primary uses for AI

Greg called out two distinct modalities for teams using AI:

• As a way to increase velocity — i.e., doing the same kind of work, faster. Design is often framed as an internal service function, taking requests issued from other teams. AI can help design orgs provide this service faster.

• As a thinking tool — i.e., a medium that allows teams to frame problems, explore possibility spaces, and inform organizational strategy. This includes improving research operations and lowering the cost of producing high-fidelity prototypes.

Greg cited real-world examples of both. In either case, AI accelerated or increased scope. But — and this is critical — it didn’t replace the need for discernment and clarity. We’re squarely in augmentation (rather than automation) territory.

But it was the second modality where there’s most potential. Greg shared an exciting example from a recent engagement, where he worked with a small, distributed team to design a product North Star. Previously, such efforts were constrained by engineering bandwidth, but

That model doesn’t hold up as much anymore, and one of the things we learned in the process of doing this is not only could we move fast, we could insert more things into the process that were hard to argue for under tight time frames that made the product richer. So, when we’re in a sort of divergent phase, we looked at the information architecture of multiple competitors and deeply understood them very quickly, and figured out why they made those decisions.

…

Then, we built hybrids of those just because we could. And normally, you or someone would say, “Well, why are you doing that?” And I say, “Well, the juxtaposition of those things might inform us in a way that we haven’t thought about, and there might be an accident of doing that that might surprise us.” So, we did lots of that. And there were a couple of happy accidents in the process, where we were informed by a mashup of something that would have been very difficult and time-consuming to do, that really, you could do in like a couple of hours.

This isn’t just the same kind of work, faster. The ability to move faster changes what kind of work can be done. Designers explore solution spaces by making — “make to think,” as Greg put it. AI lets that happen at a different level.

Think jobs, not features

How can design and product leaders effectively navigate these changes? Greg suggested an insightful reframing: rather than think of the focus of design work as product features, think of the jobs that the product is meant to fulfill:

People never bought features anyway. They only bought outcomes. Features were a way to get to an outcome. But I think the artifact right now is the intelligence that you’re designing. And then, the delivery mechanism is also in flux. So, is our life going to converge on one of the large models and those become almost like operating systems for us? Or is there space for custom products that recognize and have contextual insight about us that make our lives more easy and more straightforward?

Which is to say, the capabilities afforded by AI open new possibility spaces that aren’t well-served by the “feature” framing. We must approach design at a more systemic level — known territory for designers:

At the end of the day, we benefit product teams by understanding it better. And we, as design teams, have been doing this for a long time. Think about journey mapping, journey mapping as a tool, a way to understand how a job was getting completed.

Christensen et al’s “Jobs to Be Done” framework provides an excellent conceptual foundation for this reframing. Check out Greg’s post on Improbable Futures for more on how this plays out for product and design teams.

Key takeaways

As a product or design leader, you must use AI intentionally. This conversation offered three key insights for doing so:

1. AI isn’t just a way to move faster. It also offers new ways for teams to think, unlocking strategic possibilities.

2. Humans still need to decide what problems to solve and prioritize those that matter most to the organization and its customers.

3. Leaders should use the tools themselves. Don’t assume you can delegate hands-on experience to your team. Work with heavy adopters to enable new ways of working.

In the interview, Greg said he wants to disrupt himself. That doesn’t mean starting anew. Instead, it means learning how new technology plus experience unlocks new possibilities. As he noted, our work at Unfinishe reflects that value.

This is an exciting (and unnerving) time. It’s important that seasoned leaders like Greg and Cindy share their experiences implementing AI at scale. If you’re a product or design leader, this conversation is a good investment of your time.

Check out This Moment We’re In wherever you get your podcasts or on YouTube.

Leadership entails acting intelligently — i.e., moving in the right direction for the right reasons. This requires seeing clearly. Tools can help… or they can make it harder while seeming to help.

The question is, how do you do it? I’m a big fan of understanding the technology firsthand. But we must also understand how the technology changes the nature of the work.

AI calls for moving up the abstraction stack. It’s similar to what happened with computer programming, which went from flipping bits to assembly language to higher-level languages and now coding agents. The question before design and product leaders isn’t whether this shift will happen to design: it’s whether they’re ready to lead at the right level.

A bifurcation is coming. The organizations that figure out the role the technology plays in this shift will thrive. Those who do it poorly will crank out work faster — but it’ll be increasingly misaligned with the business’ need.

As I said near the end of the episode: if you come out of any of these conversations feeling like you’ve got the answer, you’re probably wrong. The technology is changing too fast. What you can get is a clearer read on the context. Hopefully, this conversation helps.

Finding Our Way, Ep. 69: In a World of AI, What is the Work Really About?

This post first appeared on jarango.com.

In the second of our “Open-Ended” livestreams, we discussed the anxiety many design and product leaders are feeling from AI-driven changes. The intent wasn’t to offer suggestions, but to think out loud about what we’re observing.

That said, we surfaced a couple of important insights:

• Organizational structures must change. How? Greg suggested empowering smaller (e.g., two-pizza) teams with enough agency to move and learn quickly.

• In response to the “AI will replace SaaS” narrative, Jorge countered that for many products, information architecture is the moat.

We’d love to know what you think; please leave comments in the YouTube video.

Links

We referenced several articles and at least one book during the conversation:

• The cognitive cost of AI by Giu Vicente

• Why AI Adoption Stalls by Keith Ferrazzi, Wendy Smith, and Shonna Waters

• The A.I. Disruption We’ve Been Waiting for Has Arrived by Paul Ford

• Welcome to the Intelligence Era by Craig Hepburn

• Managing Priorities by Harry Max

Transcript

(AI generated.)

Jorge: Well, hello Greg. I think we are—let me refresh—yep, so we are live, sir. It’s good to see you.

Greg: Nice to see you, Jorge. Happy Thursday!

Jorge: Happy Thursday to you as well. I’m having a weird echo.

Greg: Well, anyway, we’re here today to talk a little bit about what’s going on with sort of this zeitgeist moment. It feels like there are a bunch of messages kind of moving through our communities. Jorge and I have been talking a lot about this stuff, and we thought we would get together and run one of our Unfinishe sessions—Open-Ended is what we call them—but I thought maybe we could start and talk a little bit about Unfinishe, and then we’ll get into today’s topic, which is really about the psychological tax of AI initiatives and how all of us are feeling. But before we do that, Jorge, what is Unfinishe?

Jorge: Unfinishe is an emergent practice that you and I have taken on to develop to help teams navigate this new era. I think that that’s kind of like the highest level description that I can offer. What teams might mean might be up for grabs; it’s emergent, right? But we are trying to be responsive to what we are hearing in our various communities and contexts. It’s very clear that everyone is cognizant at this point of the fact that we are in a different space. This technology is massively disruptive, and it requires new approaches and new thinking, so that’s clear. The other thing that’s become increasingly clear is that many of us—and I’ll put you and I in this—are trying to come to grips with how to navigate this time skillfully. You and I bring particular perspectives and life experiences to bear on this problem that we believe are helpful to folks. So that’s my kind of 10,000-foot view on what Unfinishe is. What would you answer? How would you answer that question?

Greg: Yeah, I mean, I echo what you’re talking about. I think part of it is the opportunity to disrupt ourselves and explore the meaning of these new tools and do it in a way where we can sort of be all in, but at the same time be intentional and try to understand what it might mean, and then share what we learn with folks. I think we named this endeavor Unfinishe with the ‘D’ missing on purpose because I think one of the things that we’re all experiencing is that the moment you feel like you’re on solid ground, the ground shifts, and we need to find an understanding of what to do next. I think the journey we’re on is to help organizations and teams navigate that. We’re taking the experience we’ve had in our careers, but we’re also super willing to experiment and adapt. We’re trying to be curious and mindful in the practice. So that’s how I might answer that. Maybe that’s a good segue for today’s conversation, which is, you know, there’s a lot of anxiety around what’s going on with these tools. We’re starting to experience it in our own work, but we’re also seeing it in the teams that we help. There seems to be a conversation bubbling up in the zeitgeist around AI right now about what it might mean. I think there are also some seminal moments that have happened recently that have demonstrated that we’re actually in a new place. You know, this isn’t the announcement of ChatGPT two and a half years ago. This is the arrival of coding tools, the rapid improvement of the models, and the fact that we’re now starting to see teams use these things. There have been some really salient conversations around that. So that’s what we’re starting for here today, and we want to help and have a conversation around it. Also, folks online, you’re welcome to come and ask questions. We’re going to try to be vulnerable and transparent, if possible, about our own insecurities and feelings. This is an experiment, and we’re glad that folks are here with us today.

Jorge: And for a bit of context for folks who, for whom this might be the first live stream of ours that they join, this is only the second one that we’ve done. Right. And in the Unfinishe spirit, this is a very open-ended conversation. It is very loosely structured. I would say there are not going to be any decks. There are no pitches. That’s not what we’re doing here. What we’re doing is we’re trying to think through the moment that we’re in, and we’re trying to think out loud. Because the time does require kind of fast responses, I think that we can’t be too precious about what we’re doing right now. So with that in mind, you said that we want to be vulnerable and that we’re both feeling a bit of anxiety. I’m going to kind of pinch and zoom on that. The live stream you titled it “How Are You Feeling?” How are you feeling, Greg?

Greg: Yeah, I mean, there have been a couple of articles that have encapsulated my experience lately. I would say I’m both super intrigued and excited and super freaked out at the same time. And what do I mean by that? I mean, I’m enamored by the capabilities that I have at my fingertips and blown away by the things I’m able to accomplish with the tools that I’m using. I’m also recognizing that I don’t have good boundaries with how I operate with Claude, which is the tool that I use, Anthropic’s AI. At the end of the day, my brain is like, I’ve gone through a lot of work, and I’m wondering if it’s sustainable. I’m mixed about all this stuff; it’s exciting, and I’m enabled to do some really incredible things. But at the same time, I’m trying to track if I’m being changed by this experience.

Jorge: It might be worth calling this out because some folks tuning in, this might be the first time they hear from you. I think that we have slightly different backgrounds. I would say that your background, your trajectory, and your career has been mostly around design leadership, very senior roles, managing teams and organizations, whereas my background is more as an individual contributor for hire. I’ve been a consultant for the bulk of my career, and I’ve been brought in to do very specific things. I’m just calling that out because I hear you talk about this being torn between excitement and apprehension, and I’m feeling like that too. But I think I’m feeling like that for maybe different reasons than you are. How does this tension show up in your work as a design leader?

Greg: Yeah, I mean, I think there are a couple of things. Paul Ford wrote something recently about feeling obsolete at some level and at the same time superpowered. Right? I have some of those feelings. I’m able to help a couple of companies right now from a design leadership perspective, and I can help them in really fast ways that would have taken weeks to accomplish, and I can do it in like days. That’s really great, but at the same time, it feels like the flattening of my expertise. It’s an interesting moment to see how we show up. I think there’s some anxiety around that. I might flip the bit for you, and you’ve been spending decades thinking about how humans navigate information. Does AI feel like an extension of that work or a threat to that work? How does that fit into how you operate in this moment?

Jorge: Well, the first thing that I’ll say here is that anything I say today, I say with more interest than conviction, meaning my mind is still exploring this, and I’m trying to develop my positions. What is very clear to me is that large language models in particular change our relationship to information considerably. I realized this; I’ve been working with AI—in general, what we call AI—for a long time with client projects. But when ChatGPT was released, I kind of went all in and said, “Okay, let’s see how this can help me do the work of an information architect.” It became very clear to me very quickly that the work I was doing needed to change and was going to change. You talked about acceleration as one of the things you’re experiencing in your design leadership role. I also felt that this is going to greatly accelerate certain processes. It’s also going to change how we interact with information. The object of the things that we design is likely going to change, but that might take a bit longer. I don’t know that I felt as threatened; I’ve felt more excited. I’ve been more excited than I’ve been threatened, I think, by all this stuff. There’s a flip side to it, which is the fact that there’s a lot more information being generated. Not all of it is useful, perhaps. These tools have the potential to generate a lot of misinformation. But this is the kind of upside bit. I might sound like I’m taking a very kind of positive perspective here. The more I worked with these tools, the more evident it became to me that their effectiveness is highly reliant on the information that you are giving the tool. Initially, there was this idea of prompt engineering, and then people realized it’s not just a prompt; there’s more stuff that you’re feeding the AI. The phrase became “context engineering.” To me, the upshot of all that is that language models are as useful as the information that they’re given to work with, and I suspect that people who do information architecture work have a big role to play in creating and structuring the information that gets fed to the LLMs. That’s going to have a very important effect on the degree to which the systems produce good results. So I’m excited. It is a time of great change, and great changes always produce anxiety, so I’m feeling anxious too, but I think I’m also feeling like, my gosh, there’s so much potential here—unexplored potential, right?

Greg: Yeah, and I think you and I did a consulting arrangement last fall where we helped an organization sort of organize their business information. I think you’re right that there’s this notion of understanding how work gets done and what content exists in an organization. Most organizations can articulate that very well; they just kind of tacitly know this is how they operate. These systems work better if you can be clear and crisp about the terminology. I’ll use a fancy word: the ontology or the model of information in it. I think for folks like you—who I love the fact that you called yourself an architect of information now versus an information architect…

Jorge: An architect of intelligence.

Greg: That’s right, architect of intelligence. I think there’s some truth to that because I think one of the things that we need to talk about—one thread that needs to be in this conversation—is to be intentional about how you use these tools. One way to alleviate anxiety is to understand the structure of the entity that you work for, the organization that you work for, or the thing that you’re trying to accomplish—so that you can make conscious decisions when you interact with these tools, and then you know your intent. That’s where these tools are actually really valuable. If your intent is clear, the quality of the answers that they generate or collaborate with you on improves, and that’s where you can start to have a conversation that leads you to new insights or new outcomes. That’s the part that I think is super fascinating. Every day I’m surprised by something. There’s something I’ve done, and I’m just sort of like, “Oh my gosh, how did I do that? Wow, how did it do that?” That’s part of it. Is there something that you’ve noticed about yourself, though? Have you changed at all in terms of how you’re operating with these things?

Jorge: I’ve always been very hands-on with the tools that I use, and one of my directions early on with this stuff was I did not want to learn about it or just learn about it in the abstract; I wanted to have hands-on experience. I think that I’ve been maybe more hands-on with code than I have been more recently in my career just because I’ve been really trying to lift the hood on this stuff to get a sense of how it works. You referenced the Paul Ford op-ed piece in The New York Times earlier. We have been having conversations with other folks and also reading stuff that people have been publishing. One of the things that I read in one of the articles that you and I were discussing on Slack over the last week or so is something that resonated with me, which is the idea that all of a sudden you have this tool that lets you do so much stuff that you tend to fill your day with stuff. It’s the kid in a candy store thing where, left unchecked, you end up with a really bad bellyache. I don’t remember which one of the articles it was. I think you shared this one where this person was saying, “You know, it’s taken over. Now I’m thinking about it during my lunch break and thinking about how I can prompt this thing.” Or, you know, “Before I go to sleep, I want to leave it doing something overnight.” There’s so much potential. All of a sudden, there’s an unlocking of so much potential that we want to—well, and then there’s the incentive to move very fast, to take advantage of that potential. We run the risk of not leaving enough space to be mindful about what we’re doing, to prioritize what we’re doing. I’m saying this because I am feeling that. I’m feeling like there’s so much that I can do. Let’s do it all! Now that we have these things that can do it for me, I’m feeling a little burned out by that. I’m suspecting that other people are as well based on what I’m reading.

Greg: Yeah, I think that, first of all, we’re hitting a cognitive barrier. I mean, humans can only process so much information. Individually, I think there’s a challenge. I’m feeling exactly the same thing. I generate, you know, I’ll take some information, I’ll process it, and I’ll work with Claude to tune it up in a way that makes sense to me. I’ll get a very professional document. Part of my process is I usually print them. I know it’s very old school, but I find that I don’t edit very well if I’m just looking at a screen. If I look at a piece of paper, I can distance myself for a second and read it, take some notes, and then go back, and that’s kind of the way that I operate. But I’m starting to build these very useful and deep content pieces for the customers that I’m working with that are highly valuable. But I’m filling my day with like doing that work. Earlier in our conversation, I was talking about how sometimes my brain is just like, “Oh, I’ve done… I can’t process it anymore.” One thing I’m noticing—I don’t know if others are noticing this online, but if you are, let us know. One of the things in organizations is the socialization of ideas. We’re used to operating, especially in product development teams, at a certain clock speed. There’s a group of people who start working on an idea, and they start building prototypes and making, and they’re learning in that process. Then they need to bring other people along as that idea starts to gain momentum to empower those people to contribute to or execute aspects of that idea or that project to move it forward. Part of that is human nature; you want to co-create and be a participant in it. Part of it is you need to understand the decisions that have been made so that you can operate and feel like part of something. I think the velocity that some of these tools allow you to operate at is not just about the individual’s cognitive ability to manage; there’s anxiety around it that fits the organization’s ability to grok or understand and then ingest so that they can focus on, “Okay, this is how I can contribute or I can join the conversation.” I worry about that because I feel like we haven’t learned good boundary skills with these tools. It’s a little bit like a version of doom scrolling where you generate an endless amount of stuff. How much of it is still relevant the next day? Maybe not as much as you think, right? I think that I have some anxiety about being in that. One of the things I’m anxious about is that we’re going to have to learn new behaviors to manage that. What does that feel like, and how does that change us? A lot of people talk about discernment; that’s an important skill. Anyway, it’s a long-winded way of saying I think we’re only capable of grokking so much in a day.

Jorge: Yes, and I think we’re talking about it kind of at the individual level, right? We can do all this stuff, so we’re doing it all, right? There is an organizational variation of this, which is we have this design or product team which maybe is not growing. I see some folks posting job openings on LinkedIn, but if anything, I think the tendency has been for teams to shrink. All of a sudden there’s an insurgent request for new features and capabilities. There’s this drive to AI all the things. You have AI, so it’s easy to do, right? It’s like, no, it’s not easy to do. Now we’re overloaded with stuff. I’m thinking you were talking about this and our mutual friend and my podcast co-host, Harry Max, wrote a book on prioritization, right?

Greg: Yeah.

Jorge: What you’re pointing to is that we need to, on the one hand, move fast because this does indeed call for a fast coming to grips with the capabilities and constraints of the technology. But we need to do it in a way where we’re focusing our energy, our limited resources, on the things that matter most. It feels to me like right now, for a lot of organizations, at least from what I’m hearing, there’s not very good prioritization happening. It’s more like let’s throw everything against the wall and see what works coming out the other end. I’m kind of making a note here; that might be one practice that we could encourage folks to do to be more conscious as a team of the things that they are taking on and to take it on with the dual purpose of building useful things for people—obviously, we want to create value—but we have to keep in mind that part of what we’re doing here is also becoming competent with the new tools.

Greg: We have to create new skills, yeah. I think you’re—oops, I just unplugged myself. I can still hear you, though. Okay, I’m back. I think you’re right. One of the things that I think many teams are struggling with is that these tools also allow us to do each other’s jobs, right? So the notion of a product organization creates a lot of anxiety around that. You know, I’m a designer, but the engineering team can now write code for the UI. I’m an engineer, but the design team can now write code. I’m a product leader, and I can do both of those things. I’m a designer who can write a PRD, right? Those are very specific to the product development process. The notion of how we work is also in radical change because the boundaries between the disciplines are fuzzier. We need to be open and in a conversation around exploring it together versus in our disciplines; at least that’s my belief. I led a workshop with a client recently on who does what, how, why, and when? It wasn’t really to say that design only owns design and product owns product and engineering owns engineering; it was, “Hey, these tools allow us to be in each other’s camps.” There may be appropriate moments for us to be in each other’s camps. We don’t have the capacity to do something with the staffing we have, but as a team, we can use these tools to help us fulfill that capacity. We need to be in dialogue about that. One of the things I’ve learned is that discipline and having expertise still really matters, right? Discernment is a powerful thing. Just because someone can write code doesn’t mean the experience is a good one. Someone who has the ability to look at that and say, “Here’s how I might modify that because I have expertise in this area” is valuable. Similarly, on the product side, product market fit is still required—just because you can ask these tools to help you find product market fit doesn’t eliminate the need to have people on the team who have experience in bringing products to market, working with customers, and understanding how you create motion and market demand. All the things of modern product development or building things are still in play. But we have a lot of anxiety about whether our roles are still important. Going back to your central point, I think smaller teams are probably what’s going to be. Smaller, more empowered teams are going to be the future, and the smaller, more empowered teams can punch above, using a boxing metaphor, their weight. There are two reasons for that: one, because the tools allow you to do that, and the second goes back to my notion of cognitive dissonance and being able to communicate as a team. You need to have the intimacy of a small group to be able to share your thinking at the speed that this thinking is happening. It starts to break down if you’re in a larger organization that has organized people doing pieces of the work. I think the future is more empowered teams with more agency and clarity about what they’re about, and then just let them do their thing.

Jorge: And smaller—I heard you say as well, right?

Greg: And smaller, that’s right.

Jorge: Yeah. Do you have like, we all know about the two pizza team—the Amazon pizza thing. Do you have a size in mind?

Greg: Yeah, it’s not bigger than that. I think the notion of the two pizza team is that you all know each other, and you have a human relationship with each other, right? You have the ability to communicate and anticipate and complete each other’s thoughts and know who’s good at certain things. I think it breaks down once you go above that.

Jorge: I wanted to circle back to something you said because it made me shudder a little bit. You said something like designers are writing PRDs, and all of a sudden, we don’t need as much expertise because we can all do these roles.

Greg: Yeah.

Jorge: One bit of caution that I would drop in here is that a common mistake that many people make is to confuse the outcome of a piece of work—the artifact that comes out the other end—with the value of the work. I’m thinking of an exercise that I was part of many, many years ago, which is something a lot of designers have done. We were part of this workshop where we locked ourselves in a conference room for two days and made this enormous wall-sized journey map, right?

Greg: Yeah.

Jorge: The artifact that came out of that diagram was valuable per se because it informed a lot of important design decisions. But the artifact was only part of the value that the company got out of that. The other part of the value was the alignment that happened by getting a group of—I think it was like 24 people—to work together for two days building the artifact. If you could just prompt Claude to feed it a bunch of research and then say, “Draw me the journey map for this thing,” you might get a really useful diagram in the end. It might even be better than the one that the people put together. But you’d be missing out on the opportunity for people to use the artifact as a MacGuffin to have conversations that need to happen. It’s a little bit like the stone soup thing, right? The story about the stone soup that I’m sure people have heard. We’ve gone from having a bunch of basically stones to get important conversations to happen to now having the equivalent of the Star Trek replicator where you say, “Just give me chicken soup,” and you get the plate of chicken soup, but then you don’t get the collaboration that happens in making the soup, right? That collaboration is really important.

Greg: Just to build on that, I think one of the risks that we have is that we spend our day collaborating with AI and not with each other. It’s very easy to do. It came up in one of the workshops I recently led that folks were in a product team spending less time talking with each other and more giving each other things to read. Not all the things that they were giving each other were as tuned as they could have been, but they felt very clear to the person who had been participating with their AI assistant. I think we are at risk of finding our way into that relationship with the AI versus finding our way into a relationship with the cross-functional peers that we work with. Again, it goes back to the healthy boundaries. I think we need to find how we manage that, and I have anxiety around that because I spend a lot of time with these things. I think there was another piece of the story that we wanted to talk about today. There was an article that I really loved, and I excerpted part of it last week, and a lot of people responded to it by Hepburn on going fast and how this was a moment for generalists to be really successful. I felt seen in that article, and at the same time, I recognized that maybe it was a little bit of wishful thinking on my part. I think we’re all guilty of finding the things that reflect well on our own personal point of view that reinforce our vision of ourselves. There was a piece in that about moving fast—not about velocity, but it was more about, you know, one of the things I think we’re in this moment is, some people are using the tools effectively, and they’re using them with their teams and gaining a certain sense of momentum. They’re being intentional about it, learning how to do it, and course correcting. Others are not, and I think there’s some anxiety around that too because some organizations don’t enable teams to do that. Are you feeling like you’re left behind? I think for my own self, I have anxiety around keeping up. I know there are people who are way more into this than I am, and so therefore my keeping up is a worry.

Jorge: The article you’re referring to is a Substack post called “Welcome to the Intelligence Era” by Hepburn. What I’m going to do is, when we release a recording of this, I’m going to add links to these various posts in the description for the video. The metaphor Hepburn uses for this speed thing is learning to ride a bicycle. He makes a good point that one of the risks you run when learning to ride a bicycle is that you try to take it too slow. If you’ve ridden a bicycle before, you know that it’s not until you reach a certain speed that you can maintain your balance. He’s advocating for getting up to a certain speed to get your bearings. He doesn’t say this in the article, but there’s a flip side to this: if you’re learning to ride a bicycle and you strap a jet engine to the bicycle, you’re going to be really stressed out, right? You’re probably going to get in an accident. I think there’s a Goldilocks thing here; I’m trying to reflect back what’s emerging from this conversation. You’ve already said we need smaller teams that have greater agency. It also sounds like they need to focus; they need to prioritize the stuff that they’re working on. There’s the notion of speed—meaning they need to move fast. Maybe the phrase is they need to move fast enough, but it’s possible to move too fast. The organization, the team, the individuals might not be able to handle being asked to do so much so fast with such new stuff because, to your point earlier, there’s cognitive load involved.

Greg: Yeah, I think the velocity conversation has many vectors to it, too, some of which are super anxiety-producing. You hear a lot of leadership in the Valley right now talking about speed and how fast we have to deliver product outcomes. Now that Claude can write most of the code, we can go 10 times faster. I don’t think that’s necessarily what we’re talking about. By the way, I think there’s a huge risk in going faster; it doesn’t necessarily mean that you get to a good outcome. At the same time, I think what Hepburn is talking about is you need to dive into understanding how these tools work because they are changing the way that we work and, for each of us, they’re changing who we are and the roles that we have and the impact we can make. We can push back on it if it’s going too fast, but you really don’t learn how to use them unless you’re using them. The advice I have for folks is to get your hands into it and be using it. Then you can be intentional about how you want to use it. One of the opportunities I think in this space now is that especially in product development, a lot of time was spent on execution and not enough time on defining the outcome or the product fit. Now, I think we can use these tools to do a lot more discovery earlier and have more clarity about what problem we’re trying to solve, why that problem is valuable to the end customer or end user, and get validation that we’re solving the right problem. Execution—building that piece—should be something that can go much faster. This inverts how we look at the work that we do, and that part of it is exciting to me. But it’s different.

Jorge: I want to maybe pinch and zoom into the word invert. But before we do that, I want to circle back to the chat. We have a couple of comments in the chat, and I think the first one here is relevant to what you’re just talking about now. So RPUXD671 says, “I agree. We can’t be too precious. Yes, and we need to show up with calm and help the teams we’re advising through trade-offs they face.” Here’s the question: how do you hang on to and transmit that calm through teams?

Greg: Yeah, that’s right. I think a couple of things are important. One is being curious, right? Having a culture of curiosity, being conscious that you don’t know the answer, and being public about it. One of the challenges is when we think we know the answer, and then it pivots and changes—it just undermines team health. It’s a notion that we’re on a collective journey together, and we’re going to explore and find out where we’re headed. Those are some things I would consider. I think there needs to be—you said this earlier around how to prioritize the efforts you have because you can go everywhere all at once and not get anywhere. Practice some exercises around what are the experiments you’re going to do as an organization or as a team and create some space for evaluating the success of those experiments. This is something you and I did with one of our customers last fall, where we sat and kind of helped them understand how they worked, looked at the activities and workflows that were important to their success, and helped them stack rank the things that we felt AI could help them with. Instead of doing all of them, we said, “Let’s pick one and do that.” How did that work? Did we learn something? Okay, let’s go do the next one. I think a structured approach could help teams have a little bit more comfort.

Jorge: I think this question was framed around how do you, as a leader, communicate with your team? That’s the way I read it anyway. But I think what you’re saying also applies to how do you manage up, right? Because as a chief design officer, as a VP of design or product, you are reporting into the organization’s leadership. They have expectations—whether fair or not—that this stuff is going to change things quickly, right? It’s worth acknowledging that leaders need to manage their teams and the mood of their teams, but they also need to manage upwards, right?

Greg: Yeah, and there have been all kinds of crazy statements made in the last two years around the possibilities, role definition, and how product is going to be made based on the lens of where a leader might come from. I think we’re learning right now that those lenses are incomplete. You bring up a really important point; this curiosity and openness and adaptability need to be shared when you manage a team down or when you’re working with people collectively. It also needs to be flipped on the opposite conversation: what are we learning right now? What advantages is this giving us, and what challenges are we creating? There are challenges being created. Many teams are spending a lot of effort on AI, but their productivity isn’t improving. Many teams are spending a lot of tokens, but their costs are going up in the organization. Some organizations are letting people go because they think AI will fill the gap, but they’re letting them go before they figured out how to do that work. Those are the things that I think are building anxiety right now. The sad part is that we’re having the wrong conversation. People are talking about, “Here’s our current business model; here’s how we work, and now we can just do it faster and more simply.” The conversation I want to have in organizations is, “Here’s the community of people we serve. Here’s how we can deliver better outcomes for them. Here’s how we can grow our business, and here are the new things we can do with the people that we have that are valuable to that constituency.” I just don’t think we talk about that enough.

Jorge: We have another comment here. It’s not a question, but it’s a comment from Albie underscore G. They say, “I agree with Greg. Without intention, it’s easy to lose control of the output. Planning and guardrails are essential.” I will chime in here and say, even though your name is checked in this comment, I want to point out that when you talked about smaller teams, you did not use the word control; you used the word agency. That is an important distinction. As I hope is becoming evident from this conversation, one of the footballs that is being tossed around the field right now is precisely control—control over the outputs, control over the process—which is part of why there’s this anxiety happening. I think it’s going to be important to live with the—I’m going to use the word—discomfort that comes from not feeling like you have full control over the output. What you want, I don’t think that you want control; I think you want agency. That’s my take anyway.

Greg: My personal belief is that teams do better when folks have agency. I’ve always tried to build organizations where there’s clarity, and the gift you’re giving is, “Here’s where we’re trying to go. You figure out how to get there.” I do think where I’ve seen AI being used well is in groups that are willing to experiment and communicate and not try to own or control the process of how it works. Instead, they have a conversation with each other about how it’s impacting the way that they’re operating and how the outcomes for which they are responsible are improving or not improving by using the tools. That’s the part that I think is fascinating. My hope is that we’re responsible about it, and we have these conversations, but it’s not easy, and sometimes we don’t have the frameworks to have those conversations. I think you and I have talked a lot about this, and it’s part of what we’re trying to do here with Unfinishe: help people have healthy conversations around how they can use these tools in their environments and provide some structure that allows them to make progress.

Jorge: That makes a lot of sense. We have only about nine minutes left here. If folks who are viewing have any questions or comments, please do post them in the chat. Greg and I want to have conversations about this. We have been monitoring what people are writing, but we are also having conversations one-on-one with folks in organizations. If you want to talk with us, we would love to meet up to compare notes and have a quick meeting. I’m flashing on the screen a URL that you can go to set up time; we’d love to hear from you. If you are watching this now and have any questions, please do post them in the chat. Let’s start rounding the bend here. We are running out of time. Our intent here, as we said at the top of the hour, was not to offer a very structured conversation; this is really kind of thinking out loud. It does seem to me that there are a few points that are worth noting. The first is acknowledging that we are in a time of anxiety, and I keep tying this time to the early part of the web when the web first came out. That was a time of big disruption, a big new technology; it was clear to many of us that it was going to change things much like it is now. I don’t remember there being this level of anxiety of, “It’s going to replace my…” I mean, there are a few people who saw the writing on the wall that I wouldn’t be making any more printed financial reports for organizations because all that stuff is becoming digitized. That was pretty clear. For the most part, there wasn’t the level of replacement anxiety that we’re feeling now. It does feel like there is angst, and there’s an HBR article that I’ll include in the description that names it “AI Angst” and outlines what that means and why it might be caused.

Greg: I would just build on that. This is a moment where our identity is challenged. Each of us, no matter what you do, has made decisions in your life and constructed a story around your expertise. That is part of who you are. This moment can feel very unsettling because a lot of that narrative can be challenged. How do we manage through that? I think about this moment personally—I used to lead large teams, and my identity was a chief design officer. Now I’m not doing that anymore. Now I’m helping organizations as a fractional leader. I come in and support teams and do some work. You and I are doing this work for helping organizations prioritize. I’m coming to terms with that: what does the new version of me look like moving forward with these capabilities and tools? It’s not the chief design officer that I used to be. That’s unsettling. I spent a whole lifetime building that narrative. I have adult kids, and I have curiosity about how that happens. The attitude you have to have is to be curious, mindful, and intentional. I don’t know. What are you anxious about in these final moments?

Jorge: I’m smiling because this hits so close to me. I’ve been calling myself an information architect for almost three decades at this point. Information architecture is so deeply part of my identity. A few days ago, someone posted on LinkedIn saying, “Oh, I had a conversation with someone who was talking about getting into information architecture.” They asked where to begin, and I said, “Look at this person’s work. Look at this person’s work.” There were three references, and the third was me. It stated something like, “Look at Jorge’s website, but he’s more focused on AI and LLMs these days than information architecture.” I felt like, is that true? I immediately wrote back and said, “It is true that a lot of my efforts have been focused in this direction, but I don’t see it as a replacement of my identity. To me, it’s the contrary. I don’t think you can be an information architect and not be all over this stuff, because it’s so obviously important.” The way that I put it on my website is that information architecture changes as a result of AI, and AI is made better as a result of information architecture. With all these SaaS replacement narratives from the mainstream media, my canned retort is that information architecture is your moat. You can’t just replace a system that has a lot of carefully structured information; it’s not going to be replaced by a chatbot with no context. I’m seeing an evolution of my identity rather than a replacement of it, so I don’t feel as much anxiety there. Where I do feel anxiety is the question of, how do I make a living doing this? Because, to your point, if nothing else, the perception out there is that now that we have these tools, they can structure information for you. Yes, but there are a bunch of asterisks following that. My last three years have been about investigating those asterisks. I think that’s going to be true for a lot of knowledge work. That’s a big part of the anxiety here: the narratives out there say you’re going to be out of a job. I’m not entirely sold on that, because I think these are tools that will definitely change the work, but they still need expertise to produce really good results. That’s where I stand right now on that stuff.

Greg: I love that. I think this goes into, you are on the bicycle or not, like we talked about earlier. I think there are some things that, I don’t know if it will happen, but if the cost to deliver a software outcome reduces significantly which is where we’re headed—the amount of engineering required, the tooling that allows you to deploy something is lowering—does that mean less work for all of us? Or does it just mean that there’s a whole set of new use cases that were too expensive to solve before are now solvable? I don’t know that the equilibrium around that will be. My hope is that we’re intentional about the problems we’re trying to solve in this world and that these tools allow us to solve more of them. I think you’re right: the architecture of intelligence, the organization of the information, and the organization toward the outcomes that matter will be a skill set that’s really important in the future. Not everyone will gravitate towards that, but I think folks like you will be very valuable. You are very valuable.

Jorge: Thank you. You are very valuable too, Greg. We are out of time. I just want to acknowledge there are a couple of comments in the chat we can get to after we release the recording, but there’s one comment that speaks to this from RPUXD671 again: “It’s not going to be replaced, well, by a chatbot, but some organizations will try.” I’ll say this: we are living through the very early days of this, and there are going to be all sorts of really poor decisions made. We’re going to try all sorts of things that are not going to work, and we just have to go through it. This is the bicycle thing: you have to keep going, and you have to find stability. We are out of time, unfortunately. It’s been brilliant catching up as always. Thank you.

Greg: Awesome. Thank you all for joining us today. We’ll try another one of these soon.

Jorge: I’ve flashed the slide on the screen. If you want to set up time to talk with us, please visit unfinishe.com/connect, and you can set up some time. All right. Thank you, sir.

Greg: Thanks, Jorge. See you soon. Bye.

Recently, I had a conversation with an architecture studio lead that went something like this:

Architect: We’re using AI in the studio.

Me: Oh yeah? What are you doing?

Architect: A few things. [Person A] is using one of those meeting bots to transcribe meetings. And [Person B] is feeding renderings into ChatGPT to explore materials and colors. Clients are impressed.

Me: Interesting. Anything else?

Architect: Yes, [Person C] has used ChatGPT to create social media posts. Although we haven’t really scaled that.

This is actually a composite of several similar conversations, and I’ve changed the details — but the spirit stands. I believe this short dialog accurately represents how many service organizations are embracing AI: by dabbling.

Dabbling — or, more gently, “undisciplined adoption” — is experimenting with AI without understanding how information actually flows through the organization to create value. Instead, team members use AI ad-hoc on whatever interests them most. It can happen officially (i.e., using company-provided licenses) or unofficially (bringing their own.)

While dabbling has upsides, it also carries significant risks. It also precludes getting the most value out of AI. Let’s explore how.

Upsides of Dabbling

I can think of at least three pros to dabbling with AI:

• Quick learning. By now, most folks in service industries have heard about AI. Many are wondering how it might help their business. But reading about a technology isn’t the same as using it. Dabbling gets them rolling quickly: Setting up an account is easy, and getting a useful reply to a prompt highly satisfying. A nudge to go deeper — good!

• Low friction. Basic LLM accounts are free and the pro versions around $20/month — not a big commitment. A ChatGPT account and YouTube will get you rolling. No need for big culture change initiatives, reorgs, or IT investments. And unless your IT department put the kibosh on it, you won’t be stepping on anyone’s toes.

• Nice spread. AI is a general purpose technology: it can help with research, production, marketing, finance, etc. With different people experimenting, as in the example above, you’ll get glimmers of possible applications. Letting a thousand (or, more likely, half a dozen) flowers bloom will give you a sense of what the garden might include.

Given these “pros,” it’s understandable why firms dabble: it’s a nonthreatening way to get started on the journey.

But It’s Not All Roses

Dabbling is better than nothing. But it has significant downsides:

• No governance. Let’s start with the scariest. Undisciplined AI use is a privacy and security risk. Unless you have a properly configured pro account, your chats will likely be used to train models. Meaning, your private data might show up as an answer to someone else’s prompt. There are good reasons why your IT team wants visibility and control!

• Learnings don’t scale. Yes, dabbling lets team members get into AI. But that learning won’t be evenly distributed. And their focus will be on narrow problems (e.g., crafting a social media post, tweaking a rendering) that can’t be leveraged more broadly. They’ll likely have no plans or means to feed data back into the org’s broader data repositories.

• Wrong mental model. Fast learning doesn’t mean good learning. By dabbling, team members will come to understand AIs as freestanding tools whose abilities reside in vendors’ clouds. They’ll assume utility lies in the chatbot’s cleverness rather than how they leverage structured information. This is a bad mental model. AIs should be understood as adding smarts to (and with) their firm’s IT infrastructure.

• Opportunity cost. By focusing on “paper cut” problems, org leaders can boast that the company is already “using AI.” As a result, they’ll fail to invest in projects that have greater upside potential — something that can only happen when they consider initiatives as holistic responses to strategic directions. By dabbling, the org gets a false sense of closure while leaving lots of value on the table.

What To Do Instead

Ok, so dabbling isn’t a good strategy. But that doesn’t mean you shouldn’t use AI at all. So how should you proceed instead?

1. Identify your business’s “soul”

Start where your organization shines. What makes it stand out from competitors? What’s the secret sauce? Where does it create most value? Don’t threaten those things. Instead, look to automate the chores that keep you from delivering your particular kind of value in a timely and cost-effective manner.

2. Define your knowledge pipeline

And how do you do that? To begin with, you must grok the organization’s “knowledge pipeline” — how information is created, transformed, passed on, searched, used, etc. All businesses generate and consume data: leads, proposals, research, responses, invoices, documentation, etc. The more structured this data, the easier it’ll be to integrate into AI-powered workflows.

3. Understand AI’s real capabilities

Many people are pushing unrealistic ideas of what AI can do. The reality is that while LLMs are a powerful general-purpose technology, you can’t just point them to a problem and say “fix this” — at least not in a scalable, and repeatable way. Understanding what the technology can do today is essential to designing systems that create real value consistently, rather than one-off automations.

By mapping how information flows through the organization, where the real value lies, and what AI can (and can’t) do well, you can determine how it might best alleviate information bottlenecks — without threatening your people.

A Real-world Example

Recently, Greg and I helped an architecture studio define a coherent direction for their AI use. Outlining the studio’s knowledge pipeline led to an interesting discovery: a significant portion of their time was spent responding to questions during the construction administration (CA) phase of projects.

Given current LLM capabilities, we determined that helping build CA dossiers would be a good place to start. It’s a time-consuming task that few people want to do, but which must be done to deliver value. But it’s also far enough removed from the studio’s core deliverable — excellent architectural design — that it doesn’t threaten their soul.

This isn’t the “sexiest” use of AI, the sort one brags about. But it solves a real problem in a scalable and repeatable way. It enhances the overall value to clients and improves working conditions for team members. It’s a win-win all around — but you don’t get there by dabbling.

Moving Ahead — With Discipline

Dabbling isn’t dangerous just because it’s uncontrolled. It’s dangerous because it gives the firm a false sense of progress. It teaches people to think about AI in the wrong way — as a clever ad hoc tool rather than as part of a broader system — while distracting them from more fruitful explorations.

The opposite of dabbling isn’t stasis; it’s moving ahead in a disciplined way. Starting undirected is natural and easy. But eventually, you must move more deliberately and strategically. The goal of using AI shouldn’t be replacing what makes you special. Instead, it should be freeing your people so they can deliver excellence — and enjoy the process.

If this resonates, unfinishe can help. We work with small and medium-sized service firms to move beyond AI dabbling and deliver real value.

Jim Moylan died recently. He was the Ford engineer who proposed that little arrow on the fuel gauge of most cars that indicates the cap’s location. It’s handy when you’re pulling into a gas station to refuel, especially when you’re driving an unfamiliar car.

The Moylan arrow is such an obviously useful idea that it was immediately implemented by Ford and widely adopted by other manufacturers. It’s also an excellent example of good information architecture — and one that provides important lessons as we navigate the AI age.

How Is This Information Architecture?

Information allows us to act more skillfully. Imagine you come to a fork on a road. Without a sign, you’d need a compass or a great sense of direction to choose correctly. But with a clear sign, you’d quickly know which road to take. The sign reduces ambiguity.

The Moylan arrow, too, disambiguates a choice. Pulling in on the wrong side of the pump is an annoying inconvenience. By making the driver smarter, the arrow improves the car’s UX. Critically, it does so without much cost to the manufacturer. That’s why it’s become pervasive.

“But,” you may protest, “this isn’t IA; it’s user interface/icon design.” That’s partly true. As usual, users experience IA in an interface. The arrow wouldn’t be as effective if it wasn’t clear and recognizable. Visuals — the choice of symbols (an abstracted gas pump and a triangle) and colors (usually white on black) — are key.

But there’s more to it than that. A big part of the arrow’s effectiveness is its location: on the dashboard, next to the fuel gauge — exactly where you’re looking when your car needs refueling. Consider how much less effective it’d be if it were only noted in the owner’s manual.

The Moylan arrow works because it’s:

• Clear: legible and understandable

• Findable: located where you’re already looking

• Relevant: provides the exact answer you need

• Contextual: available when needed, but “quiet” otherwise

• Obvious: doesn’t need further instructions

• Cheap: of negligible cost to manufacturers

The arrow isn’t just a clear icon. It disambiguates a key structural distinction of the car. The mental model is clear: most current ICE cars have their fuel cap on either the left or right side. The question is, “which is it for this car?” The answer is obvious once you know where to look — and it’s cognitively respectful (i.e., it doesn’t scream, “LOOK AT ME!” while you’re driving.)

Which is to say, the Moylan arrow:

1. answers a latent question (“Which side is the fuel cap on?”)

2. at a time when the user is making a key decision (pulling in to a gas station)

3. by showing them just what they need (left or right side)

4. where they expect to find it (on the dashboard, next to the fuel gauge)

5. cheaply, efficiently, and respectfully.

That’s classic information architecture.

What Does This Have to do With AI?

This is the opposite approach to many of today’s AI-powered systems. The arrow is low tech (just a bit more paint/pixels!) and therefore relatively cheap. It does just one job — resolving structural ambiguity — effectively and efficiently. It’s there when needed and blends into the background otherwise.

Admittedly, its elegance is due in great part to the binary, static, and universal nature of the information it conveys. The cap can only be in one of two positions: left or right. These concepts are unambiguously represented with arrows across cultures. (The pump is more complicated but still recognizable.) Also, the information is static: the cap won’t change sides between fuelings.

This is a very constrained set of requirements. But compare Moylan’s solution with many AI products today, especially those with chat interfaces. Rather than a constrained structure within an expectable construct (dashboard → fuel gauge → [left|right] arrow), chats offer completely open-ended interfaces. This may be appropriate for systems that require extraordinary flexibility, but it’s overkill otherwise. And while flexibility adds power, it opens the door to complexity and errors. (Consider the risk of hallucinations!)

Chat interfaces also have higher latency than more structured UIs. Conversational interfaces require explicit instructions — either spoken or typed — before they can provide utility, and getting there may take multiple rounds. To put it bluntly: for many tasks, chat UIs are inefficient. Compare this with the low latency inherent in Moylan’s “ambient” approach: just glance and turn the wheel.

Finally, many AI-powered products call too much attention to themselves. The value to the user (e.g., avoiding the inconvenience/embarrassment of pulling in to the wrong side of the pump) takes a back seat (sorry!) to the fact the product now “has AI.” Lacking good system models, users can only guess at what pressing the pervasive “sparklies” and “copilot” buttons might do. Many users recoil when products add complexity through seemingly gratuitous features.

What Can We Learn From This?

I’m not poo-pooing chat UIs. They’re appropriate for some use cases. But they’re also overused. I expect this is because of two reasons:

• Chat = AI. Many people associate chat UIs with AI, so they expect conversational interactions.

• Laziness. It’s easier to graft a chatbot onto a product than redesign its IA to accommodate new capabilities.

Both reasons are bad. If you believe your system’s value will come from making it more “intelligent,” it’ll likely turn out overwrought. Users get most value from systems that help them effectively and efficiently and otherwise get out of the way. They don’t want to “AI all the things”; they just want the right information when and where they need it. Everything else is noise.

Rather than ask, “how might we add AI to this system?,” consider the following questions:

• What is the person trying to do?

• Do they understand the system?

• What’s keeping them from choosing skillfully?

• What questions do they have? Which come up repeatedly?

• Which structural distinctions are ambiguous?

These are information architecture questions. AI might play an important role in answering them — even in real time, as the user interacts with the system. But it won’t happen by simply “adding AI.” Instead, you must understand the user’s needs as they work with the system. Then, you can determine where to judiciously apply AI.

Also, rather than an open-ended UI (such as a chat,) consider whether your system might be better served by a UI that offers clear distinctions and affordances. Buttons and menus don’t just give users means to act: they also help them understand the system. A thoughtful IA will make your AI-powered product easier to use — and likely do it more cheaply and elegantly than a chat UI.

Closing Thoughts

I doubt Jim Moylan thought of himself as an IA. But that doesn’t matter. We can study manifestations of an area of practice retrospectively even if they weren’t explicitly produced as such. (For example, we think of many ancient buildings as “architecture” even though their designers didn’t think of themselves as architects in our current sense.)

As the practice of designing AI-powered systems matures, I expect we’ll move away from general-purpose interfaces to systems that use AI on the back end while presenting a more traditional UX. There’s room for delight and intelligence in simple, less open-ended systems. The Moylan arrow is an excellent example.

In the spirit of working with the garage door open, we’ll do periodic livestreams to share what we’re learning at unfinishe_.

In this first “Open-Ended” session, we discussed:

1. The principles that led us to start the business.

2. Insights from Reid Hoffman’s and Greg Beato’s new book Superagency — especially as they apply to small and medium sized businesses.

3. Workflow archaeology, our approach to designing solutions that are aligned from both a strategic and human perspective.

We’d love to know what you think.

Transcript

(AI generated.)

Jorge: All right, Greg. Good morning, sir.

Greg: Yeah, good morning. Well, it’s good to see you live streamed.

Jorge: I’m excited, yeah, same here, and just before we jumped on, we were having a bit of a fingernail-biting moment trying to get everything set up right. We’re very much figuring it out as we go. But we are doing what I think are interesting things, and we were hoping to share with folks. And this seems like an easy way to do it. Do you want to explain a bit about what this is all about?

Greg: Yeah, thank you for setting it up nicely and actually talking about how this is an unfinished moment in and of itself. Jorge and I have known each other for a long time, and we’ve worked together at moments. And we’re both really fascinated by where we are right now—the culture and the implementation of technology and AI. I think we both feel like a lot of the things that we’ve learned in the past aren’t really applicable in this new environment, and that we have to learn new things. At some level, learning those new things means disrupting ourselves and examining practices that we’ve held dear over the last 20 years in our careers and seeing if they’re still valid, and then also exploring the territory that’s available in this new space. Right? And I think we started that conversation and decided, hey, let’s put something together. And so we started this thing we’re calling Unfinishe. The D is missing on purpose. It tells a story about, I think, the market, the space, and the place that we find ourselves in. I don’t know, maybe you could talk a little bit more about your… I’m taking some airtime here, so you jump in and talk a little bit about what you think Unfinishe is.

Jorge: Well, I just wanted to touch on something you said. I think you said that the things we learned in the past aren’t applicable. Is that what you said?

Greg: I said that we need to re-examine. I did, but I think what I really meant was we need to examine whether they are still applicable.

Jorge: Right, right. Well, the reason I started there is because there’s a flip side to that, which is that as disruptive as the current moment feels—and we’re talking specifically about AI, right? Like, there is a new major technology that is upending a lot of things. And as disruptive as this moment feels, both you and I have been through another disruptive moment like this, which was the dot-com era, you know, the appearance of the World Wide Web in particular. Right? That was a major, major thing. And we now kind of take it for granted because it’s become so pervasive in our world. But I remember going through that time when design was up in the air, and publishing was up in the air, and there were all these things where it’s like, well, this needs to be reinvented clearly because we have this different thing happening. In retrospect, it feels like, well, of course that’s how it would turn out, but it wasn’t obvious at the time. And it entailed a lot of experimentation. And part of the reason why, circling back to Unfinishe and the concept of making things that are unfinished, is I think that we have this drive for closure. We want things to be neatly wrapped up. But in times of transformational change like we’re going through now, we don’t really know how things are going to turn out. We don’t really understand the technology’s implications yet. We’re in the process of discovering that. And one of the things that I learned—and maybe you can chime in on your experience—but one of the things that I learned from the previous wave of disruption that I was part of was that you can have these big ideas about how technology is going to transform things. You can have ideals about how it should transform things. But the changes actually happen more incrementally through a bottom-up approach with people trying things, seeing what sticks, and then that is what affects the transformation.

Greg: So, yeah, it’s a maker-builder mindset, right? You know, I oftentimes talk about how some people think to make, and others make to think. I think we’re both makers. One of the things that’s interesting about this space is it’s emergent, right? There’s a conversation going on. It’s really fast. So I think that’s one of the things that’s a little bit different. I don’t know if the dot-com era moved fast, but this era is moving super fast because every week there’s some new model, capability, discovery, or insight. So it’s challenging. I actually think that’s one of the things that we’re thinking about with Unfinishe; it’s also helping organizations make sense of the moment by making practical things. Our insight is that we’re not suggesting that we’re super experts in this space, but what we are saying is that maybe we’re eight weeks ahead of you. We can help be a little bit of a Rosetta Stone or a wayfinder for organizations around how to understand how to use these tools and think about it in a really practical way. I think that’s the basis behind why we think Unfinishe as a consulting practice is actually valuable and necessary right now. In the space that we’re looking at—which is small and medium businesses—and this is something we should also talk a little bit about: why are we looking at the SMB space? There are a whole bunch of opportunities to help organizations punch above their weight, to help them manage some of their complexity more effectively so that they can focus their attention and energy on the things they really love or growing their business in a way that makes sense to them. Some of these tools do give you some superpowers. So how can we help organizations make sense of which ones to use and which outcomes are more applicable now and are most useful? I think that is a journey that we want to help people on. Just back to why we’re calling ourselves Unfinishe. I think one of the things that business leaders have to recognize in this moment is that you are either evolving or you’re not, and that transformation is something that you need to continuously invest in and have a mindset around. Your point earlier that you talked about closure or completion or having it all figured out— I think the ethos now is to dive in, experiment, make, find your way, and keep on that path while recognizing that you need to keep moving forward.

Jorge: I love that you use the word evolve. I will draw a distinction between evolving and reinventing. Because so much of what one reads out there—when people write about AI—and I’ve seen this with a lot of other consultancies, it’s like the pitch is, you need to reinvent your business for the AI age. I think our approach is more, “You know what? That sounds like premature optimization for a world we don’t really understand yet.” It’s much better to try these very carefully defined, pragmatic experiments that help you make steps towards an alternative future, as opposed to this whole huge initiative where it’s like, let’s reinvent everything and rethink everything from the ground up. All right. Let’s not belabor Unfinishe itself. We’ll have more opportunities in the future to talk about what we’re doing in the business. We’re talking about Superagency. This is a book that I had not read. You suggested this book, and I was hoping that you could talk a bit about why Superagency? Why this book? And what is this idea about?

Greg: Yeah, I mean, I think it’s one of the pieces of content this year that tries to unpack where we are in this moment. Hoffman’s book has a couple of tenets in it that I like. One, he talks about technological transformations historically and sort of recognizes the societal disruption and the ramifications of that in those moments to give us a compass for what’s happening right now. What do I mean by that? He talks about the invention of the steam engine, the reaction to industrialization in the Luddite movement. He has a kind of model for a two-by-two of different characteristics of people who have a point of view about where AI is from, you know, when he calls it doomers who believe it’s the end of everything and, you know, the zoomers who are like, “No regulation, no AI at all costs,” etc. And that framework, I think, starts to establish, you know, and then there’s bloomers and gloomers, right? So there’s the four quadrants. I tend to see myself as a bloomer, but that’s because I’m an optimist, and I believe that we get to choose the future we want to live if we’re intentional about how we operate. I think this is one of the things that’s very important, actually, about right now—that we need to be looking at these tools in a really smart way and make sure that humans are in the center of the conversation. The last tenet in his book is around agency, and that these systems should enable us to have agency—that we get to make decisions, that we get to make choices, that we get to use them for things we think are valuable. Obviously, there’ll be some disruption in employment, for sure, but there’ll be new opportunities that emerge out of this technological change as well. That’s why I thought the book was interesting—because it was trying to put this into a context of, “We’re in a messy moment. The way out of that is to actually be intentional about doing things that have a positive impact.”

Jorge: You talked about the four profiles. And I think the way they—it’s two authors, Hoffman and Beato—but I think of this as Hoffman’s book in some ways, right? They talk about these four profiles as people who are part of the conversation. They say these are voices that need to be in the room—you have to accommodate that discussion. You said that you associate or think of yourself more as a bloomer. When I read the book, I too thought, “Totally, I’m a bloomer.” People watching this might not have read the book. Could you give a brief outline of the bloomer profile? And while you’re thinking about that, I’ll say we do have people tuning in. I’ll just put it out there. This series is called Open-Ended Sessions. The idea is to make this a conversation because it’s unfinished, right? So if you, who are tuning in, have any questions for us or any comments, please drop them in the session chat. All right, Greg.

Greg: Yeah, so bloomers, right? I think bloomers are optimists. They believe in progress, and they believe there are opportunities that can be created by the emergence of new technology, identifying opportunities to use that for positive outcomes. I feel like that is my mindset. I’m not unaware of some of the challenges and issues and problems that are materializing because of this change or this moment we’re in—the environmental consequences of building data centers, the background of how the content has been created. But I feel for me—and one of the reasons why I think I want this partnership you and I are putting together—is to be intentional about helping organizations make the choices that make sense for them and allow them to be successful and do it in a way that’s human and places humans in the center of the conversation. That’s the kind of work that I want to do. I think the bloomer category is someone who believes that the long-term impact of this is actually going to be good for society. It may be rough in the beginning, but there are positive outcomes to be had. But it means that we have to put in the effort and the energy to make sure that that happens.

Jorge: The phrase that kept coming to my mind when I was reading the book is this is a glass-half-full mindset. But that doesn’t mean—it’s an optimistic approach, right?—that doesn’t mean a Pollyanna approach. To your point, there’s a recognition that this is a very powerful technology, and like all powerful technologies, they need to be deployed mindfully. Now, the devil is in the details, right? The question is, what does that mean? They get into a bunch of things about regulation in the book, which I don’t think we’re going to touch on here. But you mentioned when you were introducing the work that we’re doing that we have decided to focus our offerings toward small and medium businesses.

Greg: Yeah.

Jorge: I’m curious about this idea of superagency and what it might mean for small and medium businesses. I have ideas about that, but I’d love to hear your take on what those are.

Greg: Yeah, I mean, I think one of the things that’s interesting is that small teams can do more things in a way, right? That’s evidenced by some of our work. If you think about, you know, one of our more recent engagements, we discovered that an organization we were helping was spending a significant amount of time doing administrative tasks to fulfill legal requirements and compliance requirements for their work. We’re talking vaguely because they just don’t want to say who it is or what they’re up to. That number was increasing over time, hitting their margins, and they didn’t really understand what was going on. At a certain level, it was sort of like they were like a frog in water—turning up the heat, they’re getting boiled by more and more content they had to manage. This was preventing them from doing the things they wanted to do, the things they valued, and the things they felt differentiated them in their marketplace. One of the things we did was work with them to try to understand how they operated. From that, we discerned what might be simple, small, practical things that they could automate or use AI to assist so that they could focus their attention on things of high value to them. That’s an allegory for what we can help small and medium businesses with. You said it right: no one loves to do the laundry. Some people do, but most people don’t like to do the laundry. So let’s help you do your laundry so you can focus on what’s truly important to you. We can talk a little bit about how we’re doing that. The second thing is small and medium businesses are much more willing to try things and experiment. You don’t have the layers of bureaucracy that might hinder a larger organization around what you can and can’t do. The opportunity for innovation could be higher.

Jorge: I want to be fair; the laundry analogy comes from—I’m not sure how to pronounce her surname—but Joanna Maciejewska. I must be butchering that. She put out a tweet saying that the problem with AI was directionality—we’re trying to automate the wrong things. We’ve been automating writing and creating art. What we want is for AI to automate doing the dishes and the laundry so that we can focus on writing and creating art. I think that’s fundamentally right. I think it’s also more… It feels to me correct regarding the state of the technology itself.

Greg: Yeah, I agree with you there, too. Is it ready for all of this agent-to-agent conversation stuff that’s going on? I don’t think so. Maybe at some point in the future, but what we found in the engagement I was just talking about is that, in the abstract, technology alone isn’t something that will land in an organization. You need to understand the culture of the organization, how people work, their mental models, and the flow of information. We came up with this term; we call it workflow archaeology. It’s a bit different than service design practice or the UX space we’ve come from because it requires some additional investigation, but it leverages that skill set. It’s understanding the journey from start to finish of an outcome or a job—something valuable for an organization. Then you have to dig in and see how that happens. You need to understand the information flow, the shape of the data, where it’s stored, and how it’s managed. You also need to understand how people expect it to show up on their desktop or in any way they work, and then you can affect change. You can add a small intervention or a small evolution— I like the word evolution versus reinvention. Evolution enables a performance gain or improvement or unlocks some extra capability they’ve always wanted to do but haven’t been able to do before. You do that incrementally. This moment isn’t calling for us to blow up the firm and say to start over; it’s much more about getting you up to speed on one thing so that not only do you have something valuable, but you also start to understand how these things work so you, as an organization, can recognize how you want to use them and what they mean to you and what’s meaningful. In the case of the organization we supported, we delivered an outcome that led to productivity gains, but their intention wasn’t to let go of people; their intention was to spend more time on things they viewed as high value. Every organization is going to have a different calculus about what matters to them, but right now, these things have to be small; they benefit from prototyping your way of making. We talked about this maker mindset earlier. That’s part of the journey we want to help people take on—practical, straightforward things you can do that add value as quickly as possible.

Jorge: And I think that’s part of the actionable outcome of an engagement like this—the thing you can fire up Monday morning and start doing that changes your workflows and hopefully relieves people in your team from drudgery. But I think there’s another level of value that comes from these engagements, which is that they help the organization get a sense of direction.

Greg: Yeah. I think this is an important piece of the puzzle. Maybe you can talk a bit about how we do that, but this is a really important perspective because many organizations—probably most—don’t know where to start. If they are doing things, they’re often in an unintentional way. There’s a fair amount of evidence that says people are using AI, but it’s not giving them any positive outcomes; it’s just burning time as people sort of goof off or experiment with it. What’s your perspective on that? Why is that so important, and how are we doing it?

Jorge: Well, the sense I get is that there must be a sense of the emperor’s new clothes in people’s minds right now—in that you read the news and see these huge investments happening in data centers and organizations cutting human positions to invest more in AI. There must be a lot of people wondering, what is the AI doing? The experience most people have had with these tools is through chatbots like ChatGPT. What I’ve observed, and I think you’ve seen this as well in talking with folks—especially in small and medium businesses—is that there is curiosity about AI. You can’t help but be curious if you hear about it in the media and everyone is talking about it. Oftentimes, what happens is the organization’s leadership will take someone in the firm—usually from IT—and say, “Okay, you’re our AI person, figure this out for us.” What that person does is get a ChatGPT business account for the firm, give a few people in the company accounts, and then people start dabbling with trying to automate their workflows without any clear step in the process where they are provided a mental model about these tools, how they work, and how they can help. They’re also not given a holistic understanding of where these tools fit into their information workflows because it’s being done ad hoc.

Greg: Yeah.

Jorge: I think one of the tenets that is somewhat unacknowledged, but is central to the work we’re doing, is the fact that all businesses nowadays—all modern businesses, anyway—are, in some sense, information businesses. They have to move information; they have these information workflows where data moves through the organization. If you understand what the technologies can do (and you talked about us being like eight weeks ahead— I think that’s a fair assessment), the idea is to try to grip the capabilities and constraints of the tools. So that’s one aspect of this: understanding what the tools can do. Then you can gain an understanding of the organization’s information flows—how is this organization operating so you can identify areas where people are expending inordinate amounts of time and resources doing things that are necessary for operations but aren’t necessarily adding value to their customers? All companies have to deal with some degree of bureaucracy, and my emergent sense is that particularly large language models can be valuable in helping alleviate some of that tedium so people can focus their time on things that, A, add more value to their customers, and to their companies, but also that they enjoy more. No one likes having to deal with red tape. The point is that part of the value we’re trying to bring to organizations through this process of workflow archaeology is that by understanding the information flows and where the tools might help, the organization gains a new understanding of what the tools can do and a sense of direction. It’s not that we’re going to reinvent the company from day one, but at least we start developing an emergent roadmap of where the low-hanging fruit is and let’s start with a few pragmatically chosen areas to focus on, so we can begin gaining the competency internally to evolve toward that different state of being.

Greg: Yeah, and I think you bring up a couple of important points there. One, it’s a journey that we are bringing our clients on so they gain competency, right? One of the things we’ve built into our engagements is that part of what we’re doing is teaching. We’re showing you a methodology; we call it workflow archaeology, but we’re showing you a methodology for understanding how to make the tacit explicit in an organization, how to identify the IP of an organization—the things it cares about, the culture, the business processes that matter, the things that make them valuable. I think people may think in the back of their minds that many organizations—including small ones—might have a role in which someone’s only job is red tape. That’s also something to help people recognize: as these tools enable us to do more routine, repeat tasks more effectively and efficiently, you need to help your people gain and acquire new skills or focus their attention and energy on things that will benefit the business in new ways. I think we’re trying to promote is a perspective of the evolution of your organization, not revolution. The people who work with you and for you are there with you. That’s another reason why I like small and medium-sized businesses: small and medium-sized business owners are much more in relationship with their employees; many of these kinds of organizations are almost like families. If they care about what they’re trying to accomplish as a business and they care about their people, we can help them transition their organizations to take advantage of these tools while also growing their business or managing it in a way that’s meaningful for them. It’s an interesting moment to be in.

Jorge: There’s another dimension to this, which is that the information itself—if you buy into the idea that all businesses have these information flows as part of the lifeblood of the organization—the truth is that most organizations, even though that is true, probably don’t understand themselves in that light. A lot of that information is managed in a very ersatz way. It’s certainly unstructured. One of the things we are learning—and maybe we can pivot to talk about some of the lessons we’ve learned as part of this initial engagement—is that when you start working with AI, you’re going to have an easier time if the information you’re working with is structured. And hey, guess what? AI can help you do a first pass at structuring the information. I’m mentioning that because I talked earlier about our being eight weeks ahead as one of our differentiators. I think another one of our differentiators, frankly, is that we come at this problem space from the perspective of information architecture and this designerly approach of understanding how information is structured. The idea is like you were saying: to augment your people so they can create more value and enjoy their work more, as well. One way that happens is not just understanding the flow of information but also the state of the information and doing something about it. That might be that the doing something might have nothing to do with AI; it might be that you discover that your information systems are not up to speed to work with AI. You might need to upgrade those. What ends up happening, maybe, is that the AI thing ends up being a MacGuffin for this broader transformation that probably needed to happen anyway. This is just kind of the reason to get it done.

Greg: Yeah, and I think you’re bringing up an important point: that’s why we don’t call it workflow anthropology. I think we both have a design and research background, and we certainly want to research and understand how people work and see them at work. But the reason we’re calling it archaeology is that there’s this new element: the structure of the data in the environment we’re working with. Small businesses tend to not even understand that; they just build it incrementally over time, connecting different technologies, using different stuff. It becomes how they work. You need to be able to unpack it and see how the humans in the system use it; that might be the more anthropological or research lens. But you also need to see the structure of that information and its compatibility for large language models to make sense of it. You hinted that there might be some work to do organizing it more successfully so you can get better accuracy or make it machine-readable. It’s almost like there are layers to the organization that you have to appeal to in this new moment—some of service design, some user research, a bit about spelunking into the technological platforms that organizations use. It’s looking at the files— the artifacts they have— and seeing how they’re formed and shaped and the degree of variety or variation that exists in them. One of the interesting things about us is that we’re not really focused on a hypothesis when we come in; we want to start with artifacts. We want to look at the substrate of the organization and explore it. Like archaeologists, you dig a little of the dirt, find the first layer of civilization, and come up with some thinking about what’s going on. You dig the next layer of dirt and find the next piece. It’s important to understand how people actually get things done, and then you can make suggestions about what to do. One of the lessons we learned recently with this engagement was we saw a process and were like, wow, if you did this differently and this differently, you could achieve this huge productivity gain and here’s how you could do it. It was almost like the management consulting version of showing up with a hypothesis, and the ROI would be an enormous number. Our client just looked at us and went, that doesn’t feel right to us. We don’t believe you and don’t understand this. We had to reset and ask, what’s important to you and the way you work? We found this key insight that drove an outcome they didn’t want to change. It was cultural, and it mattered to them. So from that, we said, Oh, okay, now we know this: We have to get really small, micro. We have to look at one small improvement we could make. We did it—it was valuable to them. Now they’re on this path of, hey, this makes sense; what’s the next small thing we could do? This part of our perspective is to take people on a journey one nugget at a time or one, you know… I’ll probably overuse the archaeological metaphor, but we’ll dig down another layer.

Jorge: I think you started touching on something there that I wanted to expand on because we actually have a question from Katherine in the chat. She asks, “Can you talk more about the deliverables to the organizations and businesses supported? I like the term emergent roadmap. What would that include? Detailed documentation? How-to guides?” So, what do we deliver, Greg?

Greg: Yeah, so I think one of the things we’ve done is we prototype from the beginning. We’re constantly making. I can give you an outline of the things we did and want to continue doing. We ran a workshop with our client around how they work, helping them identify jobs to be done or workflows or outcomes that were particularly important to the firm but where they were spending a lot of time. Then we started making stuff with them. We explored the art of the possible together. As we went through this process, two things happened: one, they started learning to use these tools and were surprised by the efficacy of the results. We were surprised sometimes—like, wow, that didn’t work, or that could work if our data structure were more organized. Oh shoot, we need to do that before we can make this happen. In the end, we built, you know, we built an agent. It’s not an autonomous one—it’s one that you work with. There was a huge aha moment in there. I don’t know, maybe Jorge, you were more involved with this and want to talk about the importance of understanding the discernment of an organization and the collective knowledge in being able to build something that sorts through, triages, and does the right work. How did you do that? Talk a little about the last mile of the effort we did.

Jorge: Yeah, and you talked about starting with prototypes and the last mile, which is right: it’s about prototyping throughout the process. You mentioned skepticism, which I expect we’ll encounter a lot, because many suspect there’s a lot of hype around this stuff. The quicker you can get to testing hypotheses and validating hypotheses… When we did the first pass at the workflow archaeology thing in this engagement, we came out with a couple of hypotheses about what might be good uses for AI in this context. The immediate next step should be, “What’s the minimal test we can do to validate this hypothesis?” It might be that the data isn’t there; it might be that the culture isn’t there. It might be, and this is now going to your question, that the knowledge that needs to be articulated as part of this AI assistant or agent or whatever you want to call it is so dispersed culturally in the organization and not described explicitly. A lot of the knowledge—if you want to use tools that help augment people’s work—you have to get people to express what it is that they do.

Greg: And that’s important, right?

Jorge: Exactly. The thing is, people don’t tell you what they do—you have to find other ways of getting that out. Prototyping is one way to do it, right? It’s a way to get that done. That is one of the, I think, deliverables to Katherine’s question. But also to honor the notion of the emergent roadmap, the other thing we worked on in parallel is basically a business case. It’s not just about building a proof of concept here—something that is like a minimal test, a minimal validation of whether there’s any “there” there. If that test proves successful, then what would it mean to scale this? What would it mean to get it into production? You want to come out of this process—not just with a tool that someone can use to automate a particular workflow, but also a sense of direction of where we could go next and how to take this initial experiment and start moving it so it has a larger impact. One way to do that, I think the grown-up way to do that, is to start putting numbers to it and having the numbers be realistic so leadership can make decisions about whether this is something they want to invest in or not.

Greg: Yeah, I think we had another aha moment. We invested in building a pretty comprehensive model; we did time on task, understood the billable rates, the team costs, and how much time it took to accomplish things. We could give a very accurate picture of if the evolution we were promoting—the prototype we had—was utilized at a certain level by the organization; they could achieve this outcome. What was really interesting was and unexpected—they asked a really good question: “Okay, now that we have more time because this effort we solved is going to give us time back, what do we use it for?” That was a really interesting and valuable question and one of the things that’s interesting about small and medium businesses: their perspective was not that they needed fewer people but that they reduced some aspect they didn’t want to manage. They asked how they could use this gift of time toward something meaningful for them and what the value of that would be for the firm. That’s harder for us to solve for, but we can facilitate conversations around goals and outcomes. One of the interesting things about our work is our last client walked away with a recognition of part of their business they didn’t even understand and its implications. They didn’t understand that part of their business they’d been doing forever was consuming more time. It was like a frog boiled in water; if they hadn’t paid attention to it, it would cut their margins to the point where the business would be less successful, and they wouldn’t understand why. This process of workflow archaeology isn’t just about the technology; it’s about helping identify and see yourself as an organization and then ideally craft a path toward a better outcome. To come back to the question that was asked, part of what we did early on—and this is really important—we helped them prioritize the outcomes and workflows against the current state of AI. That gave them confidence: we had this two-by-two framework where the upper right quadrant was high value and easy to do. So we said, “You should just work on those right now.” The other things all sound cool and could be transformational and amazing, but let’s work on practical things of high value that conceptually have high value. Let’s help discover what those are because they may not be the things that people talk about—the things they think are high value are the things they love to do. But in terms of pushing an organization forward or allowing it to achieve its goals, the necessary things often are the important things. If you can make those more straightforward, the benefits accrue over time. Part of what we left them with was a roadmap of what’s the next workflow they should tackle. They don’t need us anymore to do it, which is interesting, too. We taught them how to do it.

Jorge: I wanted to circle back to something you said because it was intentional on our part: helping the client understand their current state better. When we originally discussed the offering, we riffed on an old Velvet Underground song and called it “We’ll Be Your Mirror.” You remember that?

Greg: Right, right.

Jorge: That’s because this technological disruption—this opportunity—presents one of those rare moments where you can step back and examine the state of what you’re doing. Organizations are systems, and long-running organizations are complex systems that have evolved over time to perform their functions. These engagements present the rare opportunity to take a step back and take stock of how the whole system is operating. Obviously, you want to improve how it’s working; that’s the whole point of the engagement. But, at a minimum, if you get nothing else out of it, having that high-level picture—even if we’re just a part of the business—is really valuable. I want to pivot here because we have about six minutes left.

Greg: Yeah.

Jorge: By the way, Katherine is following up and saying they work in government, and this process is very applicable there in addition to small and medium-sized businesses. Yes, I believe that’s right, Katherine. When we say small and medium-sized businesses, departments within large organizations sometimes function like small and medium-sized businesses. Enterprises have different constraints, making them slightly different. I suspect that government does as well. That’s a good point. What I wanted to suggest, Greg, given we only have about five minutes left here—and we didn’t plan this beforehand, so again, very emergent, unfinished conversation. What would be one takeaway for folks tuning in? Something that maybe they can do differently or think differently about this new technology that, I don’t know if I want to complicate by saying, might be counterintuitive or might be surprising. Something we’ve learned that might help them.

Greg: Yeah, I mean, I think culture is really important. People talk about how culture eats strategy for lunch, right? You need to understand what’s important to people. You can anchor this kind of work into that so it feels like it’s part of a journey people are on together. That may sound altruistic and optimistic of me, but personally, I think one of the reasons you and I are doing this is that we want to see real impact and see that impact is meaningful, where humans have agency in the conversation. If you just talk about the technology, you won’t understand that aspects of the way people currently work will stop you from making progress unless you understand it. If you understand it, then you can use that as an anchor to drive something forward. So don’t ignore…

Jorge: Culture. I love that you said culture is important, and I will add that culture is also fragile.

Greg: Very much so.

Jorge: Organizations with a dysfunctional culture probably want to change it, but I would expect those folks might not be looking to institute or add AI to the mix necessarily. So assuming that the culture in your organization is healthy—which was certainly the case with our client—then I think a question becomes how do you introduce such a disruptive technology without ruining it? That’s yet another reason to delve into this new space, but do it mindfully, not with the goal of transforming the whole thing from the ground up day one, but rather, let’s take this one step at a time. Let’s ensure it’s true to who you are as an organization and helps you become more of who you are, as opposed to trying to change you into something completely unrecognizable.

Greg: Also allow you to recognize what change you will have to go through. This isn’t going to happen overnight, right? Even for small and medium-sized organizations, there will be some disruption and impact and roles that will change. But do it in a way that’s intentional and mindful, so you understand the implications. Don’t just do it. I know that’s more than one thing, but I think that’s important. I think you should also make stuff. That’s something to help impress people with—don’t just make anything, but be focused on what you make first. That may not have a benefit immediately, but at least you’re focused on it. Then you learn and make the next thing. Don’t try to do everything at once. Be focused and intentional about the evolution of your organization. If we can help organizations do that, then I think you can give them comfort about their trajectory. Leadership will have agency and ideally communicate that to their employees so they can evolve together in this new environment rather than have it imposed on them.

Jorge: Yeah, that’s a superagency thing, right? It’s not being imposed on me; I’m a participant in this. We are at time. I think this was a great first conversation. We will have more of these. For those who want to follow up with us, our website is unfinishe (without the D)—unfinishe.com—and we do have a Substack where we’ll be posting hopefully fairly regularly what we learn; that’s at thoughts.unfinishe.com—so Unfinishe Thoughts, basically. All right, Greg, thank you. We will let folks know when we have another one of these scheduled.

Greg: Thanks. All right.

Jorge: And thank you to everyone who tuned in, by the way.

We’d love to know your thoughts—especially since we plan to do more of these. Are there questions or topics you’d like to bring to the table? Please let us know in the comments below.