Building Is No Longer the Hard Part
Some things change and some things don’t. What is changing is how fast anybody can build. Features and functions that used to need a team, a budget and a long wait can now be produced with AI, often to a very high standard. Faster building is real, and it’s good. It has liberated some people and made others scared.
What hasn’t changed is that building for building’s sake is a waste of time. It always has been. AI has just made the waste easier to see, because things move faster now, and when output is the measure, what nobody needed shows up sooner. Many teams have been through a “move fast and break things” phase at some point, and in some areas, payments and critical infrastructure among them, breaking things was never allowed.
In startups especially, a lot of people still run straight into “let’s just build it, let’s build it now”, because AI makes it so easy to start. That’s much less likely in a multinational, where deploying something carries far more weight than developing it. You can build almost anything. If you’re building to learn, testing what’s worth building, that’s great. But even if you’re building to earn, shipping something to make money from it, do you know what you’re actually earning from it? Have you asked the right questions? In AI Makes the Work Faster. Enabling People Makes It Compound. I wrote that just because you can build doesn’t always mean you should.
None of this is about slowing down. It’s about being more confident in your convictions that you’re doing the right thing, which sometimes means slowing down to speed up. The time AI gives back is a choice, and everybody should now spend more time than they would have in the past working out what’s worth building, and why.
The Hard Part Keeps Moving Up
For a long time I’ve thought about product as a Maslow-style hierarchy, as plenty of others have. It’s one way of looking at product, not the only way and not a definitive one, and each layer gives people something different. Features and functions at the bottom give people the basics. Look and feel builds trust. Ease of use strives to remove any process friction. A good experience builds delight, where positive usage habits form and users become advocates. Meaning sits at the top. Every layer can drive some growth, but a meaningful product is where growth really compounds. I’ve laid it out in more detail on my product page.
Features and functions are entry-level table stakes, with their development and deployment being commoditised through AI. The coding of a look and feel is going the same way. However, creativity and the emotional attachment people can form to new or original designs are not.
In a past role, I was general manager of ZURB, a product design agency that also built Foundation, an open-source front-end design framework. Bootstrap was its main competitor. Bootstrap came with a visual opinion, so designers could recognise a Bootstrap site straight away. Foundation offered more components but no fixed visual style, so companies built their own look and feel on top of it. Between the two of them, and plenty of others, coding a decent-looking front-end stopped being the hard part. Frameworks did to front-end code then what AI is now doing to features and functions.
When AI creates a visual design, it can produce a good one, but it tends to be a familiar one. It goal-seeks towards what it has seen most often, so it won’t go outside those norms unless a human directs it to. That’s not a knock on its quality. But the familiar gets cheap first, so the hard part keeps moving up.

As features, functions and a lot of look and feel get commoditised, ease of use follows, because known frictionless patterns get easier to deploy. New patterns are coming as well, for interactions where the user isn’t a person at all. Payments is working through this now. A checkout built for people expects someone to create an account, choose a pricing tier, enter card details and approve the purchase, and an AI agent acting on someone’s behalf can get stuck at each step. The Machine Payments Protocol, from Stripe and the payments company Tempo, is one attempt to take that friction out for agents, and patterns like this will get commoditised too.

Within my product hierarchy, the familiar, where everyone agrees on the expected result, is the easiest to test, and therefore to automate. Most of the lower layers can be tested in this manner; you can test whether a feature delivers the expected result, or whether a payment flow has friction points that need removing. Andrej Karpathy, a founding member of OpenAI, makes the underlying point for AI generally. AI most easily automates what can be checked. The upper layers of experience and meaning are more abstract, more opinionated, and they take more judgement and critical thinking.

The Time Has to Go on Higher-Level Thinking
Judgement and taste are where creativity quotient (CQ) and emotional quotient (EQ) come in. To me, IQ looks at the past, at understanding what’s already there. CQ and EQ create the future. When every AI-built screen looks like the next one, the standard look stops earning trust on its own, and somebody has to see the work differently. People who are creative, and people with the agency to look at the work differently, matter more now than ever. Work that’s mostly doing what you’re told is the part getting commoditised.
Product is still a young discipline. Very few universities offer a degree in it, because it’s multidisciplinary, sitting across business, technology and design, and it’s something you get better at through experience and time.
In my post, Reimagine to Deploy, I outlined five stages I use from reimagining an idea to deploying it, as a process you can go through. My product hierarchy is more a set of lenses you think through. As you build a product from the bottom layer up, the kind of thinking starts to change in the middle, at ease of use, where you stop asking only whether it works and start asking how it feels to use. As you move up through experience and meaning, you’re moving into higher levels of thinking, not just up a stack.
For me, systems thinking runs through every layer, and people who are good at it are involved all the way up. For the experience and meaning layers, though, there’s no up-front test that tells you you’re right, so critical thinking has to lead, and building to learn is how you test it. None of it replaces timelines and execution; the thinking still has to ship, to learn the answers to your questions. The upper layers are where the time AI frees up should go, into more thinking about experience and creating meaningful products.
A Good Experience Is the New Baseline
Easy to use is no longer enough. Sure, a product is easy to use, which is good. But does it save me time? Is it really that valuable? A product offering can be easy to use and still create a bad experience in certain scenarios, which was a challenge we had to solve at SnapStyle.
At SnapStyle we built product identification from TV images, so you could shop what you were watching. A partner we were working with, a multinational with TV devices in people’s homes, wanted the service on the interactive TV, to create the engagement on the first screen. We could see the advantages as well, not least because the multinational was prepared to pay us for it, but I didn’t want the TV app to be the primary option.
If you’re watching TV and suddenly start to shop from the TV, the experience is jarring for anyone else with you. It might be good ease of use for the one person who wants to buy something, but it’s a terrible experience for everybody else on the sofa. So I pushed back, and the primary way to buy became either a QR code or listening-type mechanism on the phone or tablet in your hand. Anyone who wanted to buy from the TV still could; it was a secondary option. Moving the buying off the TV and into your hand made the experience better for everybody in the room, whether they were our target audience or not.

For a lot of people, buying something they’d seen on TV was going to be their first engagement with us, and a one-off transaction doesn’t bring anyone back. So we built a library of images into the app, with enough breadth to keep people interested and scrolling if they chose to, more like a Pinterest board than a single-item engagement. Once people saw the library, they stayed longer and could buy more. It also gave them a reason to come back without seeing anything on TV first, which delivered a separate acquisition channel and a separate way to engage people.
A good experience delights people, generating confidence that the product is worth their time and gives them value, and they come back to get that feeling again. Here I’m building on someone else’s foundations. Nir Eyal’s Hooked Model shaped how I think about this layer more than anything, and it’s the clearest account of it I know. There’s a trigger, an action, a variable reward and an investment, and around that loop a good experience turns into a habit.
Even a product a person may only use once needs a good experience. A customer might only pass through a specific merchant checkout once, but a poor overall experience can lose the merchant prospective sales. It doesn’t have to be the greatest experience; it always has to be a good one. A product people are meant to come back to needs an experience worth coming back for, and ease of use alone won’t get it there.
Meaning Has to Work Both Ways
You can have a poor feature, a bad look and feel, a product that’s hard to use, or a poor experience, but I’ve never heard anyone say a product was poorly meaningful. To any one person, it’s either meaningful or it isn’t.
Buyers and users rate an experience and dictate how it’s perceived. Meaning goes further, and brings the company in as well. A product has to mean something to the people who buy it and the people who use it, who aren’t always the same people, and to the company selling and delivering it, including the team building it. That goes for services as much as products.

Marty Cagan’s work on empowered product teams runs through how I think about meaning. His work is about giving teams the room to be empowered and inspired, with good outcomes for the company and for the buyers and users. Marty doesn’t put it in these words, but for me, that makes the work meaningful for the team and for what they create, and empowered product teams are about building meaningful products faster, and building better outcomes together.
To a buyer or a user, a product means something or it doesn’t. For the company, meaning also has to include a business that can keep going, and thrive. That’s where the business viability risk Marty names comes in. Business viability comes in degrees. A venture-backed company can keep going while it has access to funds to pay for its losses on the way to critical mass. For most companies, though, not understanding your path to profitability is a problem. Build a product customers love while burning money, with no path to profit and no more funding, and you’re dead; the business isn’t viable for anybody.
Meaning for you personally, as the person building it, is a different thing again. You know if you care, but do you know if anyone else is going to care? That question is outward looking. You can build something because it’s meaningful to you, and that’s fine, but it doesn’t make a company.
Meaning also has to keep being delivered. A product can wow you on day one, and by day thirty you’ve stopped using it. Do you know why your product is meaningful for its users? If you do, you have something to drive towards, version after version. If you don’t, you’re in trouble with your users and as a company.
The why behind a product matters, and for me the why is meaning. Why is this product meaningful, and to whom? You have to figure that out. “Build better products faster” just got easier with AI, but those products still need meaning. Meaningful products don’t need the word better, because if you build meaningful products faster, by implication you’re building better products faster. Meaning gives the whole company something to aim at, not just the users.
Standing Out Gets Harder, So Build to Learn
In Zero to One, Peter Thiel’s rule of thumb is that a company’s technology has to be at least 10 times better than its closest substitute in some important dimension to give it a real advantage. For me, the 10x idea doesn’t go away; it gets heightened. When a product has the features, looks right and does exactly what it says on the tin, how are you going to get people to change? How are you going to stand out? Standing out gets harder, and less predictable. Marty Cagan said much the same in a recent talk, Strong Opinions, Loosely Held: “You actually have to solve problems in ways that are dramatically better than your competition if you’re going to get people to switch.”
Building to learn is how you spend the time AI gives back, and building to earn just got cheap. It’s a split Marty uses, from Jeff Patton, and in my update to Reimagine to Deploy I mapped it onto the five stages. Building to learn is how you test the two layers that have no up-front test, experience and meaning. You still develop and deploy when you’re building to learn, but you’re doing it to learn. Much of the building-to-earn piece has been commoditised. The building-to-learn piece is where you work out what the best experience is for a customer, and what outcome is meaningful for everyone involved.
Right now the easy thing is more output without thinking, putting something out there and asking “do you like this?” again and again, with no hypothesis behind it. That’s scattergun, and a waste of time. Building to learn is different. You reimagine and research first, and whatever you put in front of people is a test of something you want to find out. You can run so many more hypothesis tests now, even with live customers, before putting it all on red.

Cheap building changes what a first product should be. When building was expensive, we built the minimum viable product. Jiaona Zhang’s take on the minimum lovable product is that a big part of what makes it lovable is what she calls “pixie dust”, the moment in the user journey when somebody sees that this product is different from anything they’ve used before. Minimum matters less as a constraint on cost now that building is cheap. Knowing what makes a product lovable matters more, because that moment of delight is a big part of what gets people to switch, and it’s a way into something meaningful.
None of this is a case for waiting. Don’t fall into analysis by paralysis, but don’t use the need to analyse, understand and commit as an excuse to skip the critical thinking up front either. You have to make the decisions, and sometimes you’ll be wrong, and you have to be okay with that too.
Protect the Time, Then Spend It on Meaning
Earlier in my career I built a social rewards network, and when I look back, I knew for a long time it was never going to get to the scale I wanted. I kept going for non-business reasons. Time is the one thing you don’t get back, so the why questions need asking again and again, not just at the start.
Just getting going and saying “we’ll figure that out later” is a terrible way forward, because you get the good feeling that you’re doing something and making progress, while the hard calls about what you’re doing, and what you’re not, haven’t been made. If you’re going down the wrong path, you might feel like you’re making progress, but you’re not.
So before you build, do your homework. Why do people want this over what’s already in the market? If other people tried and didn’t succeed, how are you going to? Building to learn is how you find out what not to build. Deciding what not to build protects the time AI gives back. Building something meaningful is what grows the business.

The features, the look and feel, even a lot of the ease of use, are getting cheaper to build. Can we all now spend more time on the positive experience and the positive usage habits we’re trying to create? Can we spend even more time honing down what not to do, so that we build meaningful products rather than just more products?
How do you recognise when you’re building something meaningful? And when do you feel that pull from the market that tells you they feel it too?
Sources
- Peter Thiel with Blake Masters, Zero to One
https://en.wikipedia.org/wiki/Zero_to_One - Marty Cagan, Strong Opinions, Loosely Held, where he credits building to learn and building to earn to Jeff Patton, and says you have to be dramatically better to get people to switch
https://www.youtube.com/watch?v=fF3lkTCM5-c - Marty Cagan, Empowered Product Teams, SVPG
https://www.svpg.com/empowered-product-teams/ - Stripe, Introducing the Machine Payments Protocol
https://stripe.com/blog/machine-payments-protocol - Nir Eyal, Hooked: How to Build Habit-Forming Products
https://www.nirandfar.com/hooked/ - First Round Review, Don’t Serve Burnt Pizza (And Other Lessons in Building Minimum Lovable Products), with Jiaona Zhang
https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/ - John Leenane, Reimagine to Deploy
https://jalco.ai/writing/reimagine-to-deploy - John Leenane, AI Makes the Work Faster. Enabling People Makes It Compound.
https://jalco.ai/writing/enabling-compounds - JALCO, Product
https://jalco.ai/product - Andrej Karpathy, Verifiability
https://karpathy.bearblog.dev/verifiability/