More features and completed tickets can look like progress while the product gets harder to use. As agents speed up delivery, who in the team is responsible for making sure all that work actually helps people?
A product can gain features and still become harder to use. Adding one more feature feels simple. A customer asked for it. A competitor has it. It might help close a deal. And if it only takes an afternoon to build, why wouldn’t we?
It is possible for every feature to hit its targets while the product becomes worse at the thing people need it for. In Someone behind the software, Karri Saarinen writes about the judgment behind a good product. That judgment becomes particularly valuable as building and adding things gets easier. I agree, and his post raises another question for me: how much room do teams actually give this work when progress is measured by what gets shipped and how fast?
Figuring out what the product should be, how it helps people, why it makes sense for the business and making sure all the good ideas add up to a good product sounds like a role worth having.
A list of completed features tells very little about how well your product works. Each addition may solve a problem, pass its tests and make sense on a roadmap. Yet a person using the product has to make sense of everything together.
We count features shipped and tickets done as signs of progress. Outputs over outcomes. And we automate that whole process with agents.
The problem? Business requirements often guide development teams. What is requested gets built. And each feature is approved one at a time. An afternoon of development can leave years of small costs behind it. Those costs are difficult to see in a release report. We can count what we shipped and measure whether people clicked the new button. It takes more effort to find out whether the task became easier, or whether people understood why the new button was there. Even usage can be misleading. People might use something every day because their work requires it. That tells us very little about how much time they lose along the way, or how much cognitive load and stress our new feature just added to their days.
We need to know what we’re trying to achieve with the product. Who is it for? What should it help them accomplish? What deserves their attention? What are we willing to leave out? Does this addition make the product better as a whole? The decisions and choices have to be made by someone. And we need to follow up with customers to make sure we actually improved the product.
If progress is measured by how much gets shipped, that work can be difficult to justify. Rethinking an existing feature might take longer than adding another one. Removing something might improve the product without giving the team much to announce.
As building gets faster, we should give those decisions more attention. A team needs a clear understanding of what it is trying to improve, especially when agents make it so easy for people to make additions on their own.
Perhaps the most useful release question is: can people now more easily do what they came here to do?
If only there was a role dedicated to understanding what people need, what the business needs, thinking about the service concept and improving the whole thing. What could we call that role? Strategist? Designer?
Maybe we already have that one.
