I am motivated by a good technical challenge, and by working with friendly, knowledgeable people. But above all, my motivation is a function of the extent to which I believe in the direction a product is heading. This predisposition is good for everyone involved. If I can explain in a few words why I’m working on something, and how that benefits the user and the company, then the product function is working. When the work is done, the customers are happier, and so is everyone else.
LLMs have made me faster at delivering software. But my job is not to deliver software: my job is to deliver value, and to solve problems. Software is just the medium.
Product decides what to build and why, and engineering builds it.
#
Product is the bottleneck today [#](#product-is-the-bottleneck-today)
If we take the assumption that executing has become faster, then I believe it’s no longer the bottleneck. Today, more than before, the bottleneck is the quality and meaning of each move the product function makes. Companies are still working out how to turn their investment in AI into real productivity, and it’s tempting for leadership to assume the win is engineers writing code faster. That is only a small part of the problem, and chasing it means optimizing the wrong thing. What leadership should be clearing the way for is product making more and better decisions about what to build. We can attempt more than before with these new tools, but it matters more than ever that the direction be correct and well thought out. It doesn’t matter how fast we got anywhere if nobody was paying attention to where we’re going.
You can see the confusion in who is suddenly writing code. I’ve seen product managers, and even people in customer support, opening pull requests of their own. That’s fine, but it isn’t where product’s time pays off: every hour product spends shipping is an hour it doesn’t spend on the one thing only it can do.
Experimentation is cheap now, and a prototype can be thrown away. But the things you decide to keep get built into the product. You can roll them back later, though rarely for free: by then users have adopted the new concepts, worked them into their habits, and perhaps forgotten old ones. Every step within a domain compounds, and the product can get harder to understand and navigate. Deciding what to keep, not building it, is what shapes the product, and that decision stays expensive even when the building is free. Done carelessly, this can make people lose trust that there is somewhere we actually want to get to.
#
What I think good product work looks like # I want to see product teams that:
- Become experts in the domain they are trying to model, and know how to share and inspire the same expertise in their engineers.
- Spend most of their time in a loop consisting of collecting, processing, and consolidating feedback from customers, and then producing clean, non-overlapping problem statements at different levels.
- Brainstorm and carefully design high-level solutions that cleanly address the problems that are most worth tackling.
- Partner with engineering to make sure the domain is well-modeled and that there is a ubiquitous language.
- Communicate their plans and findings with other teams in a way that’s clear and results in alignment.
AI can make the work of product faster as well, especially for information gathering and for spotting patterns across sources it would have taken far longer to connect by hand. It can arm product with data they would not have known how to reach before. But better inputs are not the same as better judgment. AI can surface the information and the connections. It cannot decide which problems are worth solving, or what the product should become. That decision is the work, and it is the bottleneck.
Cheaper code also means engineers need a stronger product mindset than before, and that they be involved in product development as early as possible. I have long been a proponent of this, and like the Shape Up process for it, as I’ve written about before.
So here is what I ask of each:
To software engineers: take ownership of what you’re building and the time you spend building it. Your years of work and experience deserve a good plan in front of you. It is your job to defend the quality and simplicity of the product you’re building.
To product managers: your software engineers can ship faster than ever. Make sure you can wield this power to the users’ advantage. Now more than ever is the time to do your deepest work, not the broadest.