For many years now, and for many of us, Marty Cagan’s book Inspired has been a guiding star when it comes to product development.
The idea is heavily centered around dual track agile and expert product teams that consist of a tech lead, PM, designer and a couple of software engineers. In essence, while developers were writing the code, the rest of the team would spend time on research, defining the problem, and optimizing the process around what used to be the most expensive part of building digital products, writing the actual code.
Inspired was written for a world where code was the bottleneck and product teams existed to feed the engineering machine. That world is gone.
The bottleneck moved
This shift didn’t start with AI. If we go back 10 to 15 years, software engineers were rare, very technical, and obsessed with code quality, performance, patterns, testing. Then JavaScript took the whole landscape by storm. Suddenly, with technologies like Electron, two or three people could ship a cross-platform app that used to require 10 to 15 engineers working in C++ or Qt. Sure, you’d get a front-end app that weighs 100 megabytes, but businesses were fine with that because they could ship faster with fewer people.
That was the first move from engineering-centric thinking to product-centric thinking. Quality declined, but speed went up, and speed won. The trend was already in motion long before AI showed up.
Now, with AI, that same shift went into overdrive. As it always happens, once you optimize one thing, the bottleneck moves elsewhere.
We’ve reached a point where, as engineers, we can output way more than we can agree on. Product discovery, “what should we build, and even more importantly, when”, became the new bottleneck, a new frontier that needs optimization.
Things are moving really fast. The future is literally now, not even tomorrow. This isn’t about values or morality, about whether AI is good or bad. I hear opinions from every bracket and ideology, and they are all equally right or wrong. And equally meaningless. The core bottleneck at this point is people’s ability to adjust, accept the new reality and embrace it.
The new engineer
As I’ve discussed in my video Death of the Software Engineer (and the Rise of the Product Engineer), we don’t only need to optimize the discovery process. Software engineers also have to understand that they are no longer valuable just because they can write code.
When I’m hiring people for my team, I don’t look at how many frameworks they know. I look at how much they care about the product. What was the outcome for the customer? For the business? Did we make money or lose it? Was this a waste of time or not? That’s what matters now.
Any AI model today can write an API. Let’s not pretend that’s where our value is. If a business has to make compromises, and they always do, they will skip premature optimization every single time. Nobody is going to write perfect code for a billion users when they have none. The value is shifting towards being semi PMs, semi designers, people who can navigate the full picture.
The value of engineers hasn’t decreased. If anything, it increased. But only as long as we understand what our new roles are, and what they no longer are.
The new workflow
The fact is, we can build products so much faster, which means we need new workflows and new ways to validate them.
We used to spend months in waterfall or agile rituals, researching every edge case, trying to figure out every potential thing that can go wrong before writing a single line of code. That’s over. You no longer need to spend two months building something to see whether it works. You can build ten things in two days, throw away seven the same day, then test the other three with your customers.
The quality of that code can be amazing or absolutely terrible, and it makes no difference. Once you know that what you’re building is what your customers actually want, your engineers will refactor and make that code production-ready in hours, if not minutes.
Blur the lines
Speed alone isn’t enough. We also need to rethink who does what.
As engineers, our job is no longer just to build the product. It’s to build the product in a way that enables everyone on the team to contribute directly. PMs, designers, even stakeholders. Not by writing code, but by prompting their way into things.
This is already happening. Think about component libraries and tools like Storybook. If we break our UI into well-isolated, self-contained libraries, a designer can maintain and iterate on visual components without ever worrying about the underlying codebase. They prompt, AI writes the code, engineers review it. The designer stays in their domain, the code stays clean, and the whole team ships faster.
The same applies to discovery. Tools like Gemini Deep Research, NotebookLM, MCPs and countless other AI tools are making it possible for non-technical team members to do research, synthesize data, and arrive at product decisions that used to require weeks of cross-functional meetings. The entire team becomes more autonomous.
The boundaries between roles are dissolving. Everyone on the team can now touch parts of the product that used to be locked behind technical gatekeeping. Our job as engineers is to architect for that, to build systems that are open enough for the whole team to move through, not just us.
The harder problem
Engineers changing is only half of it. Organizations have to change too, and that’s the harder problem.
If your company still operates with rigid, hardcoded views on who does what, none of this works. If an engineer can’t challenge a PM’s assumptions because of hierarchy, if a designer can’t push back on a product decision because “that’s not their role”, you’re stuck in the old model no matter how good your AI tools are.
This requires a culture where the best argument wins, not the highest title. Where an engineer can say “I don’t think we should build this” and be taken seriously. Where a designer can contribute to the product backlog, not just the Figma file.
Yes, this makes things more complicated. Clear responsibility becomes harder to define when everyone can touch everything. Team dynamics get messier. That’s just where we are. The alternative is pretending the old boundaries still make sense, and they don’t.
We need a new playbook, one that acknowledges that the hardest part of building products is no longer writing the code, but figuring out what to write and why. And that figuring it out is no longer one person’s job.
Marty, we need a new book.