Learning by sharing since 2006.

(Blogging on Friday the 13th … that would scare some people. Not me! Here we go…)

The focus in product development now is a lot on output and making the individual product engineer more efficient. But in most interesting products I’ve been involved in building the challenge is really in how we coordinate and manage many people together.

Until now this has been done in teams of 4-10 people usually. With the advent of more building power at our fingertips, that kinda breaks down. When you can hash out a new feature in hours rather than weeks, our practices doesn’t make sense. Or we still use them and increase the work and contextual loads a lot.

I think there are better ways and I think those way will challenge us, our ways of working and steering. It will be awesome!

Yes this is a follow up to What if the sprint was 1 day long?

A few years back I wrote about some of the sayings that I like so much that I have them as daily reminders, in the form of screen savers.

Yesterday I was reminded by another and I thought I’d write a blog post on it - it’s just one word, and turns out to be great career, leadership and business advice - Others!

Here’s the list of the others (pun very much intended):

• Kindness is better
• Complex == Bad. Simple == Good
• What would Jesus do?
• (DO(SOMETHING(SMALL(USEFUL(NOW())))))
• Turn up the good

I have written many times about how I feel about the current obsession of output over outcome. Here’s an example of numbers that I see presented with a bit of a worried look.

+2450% lines of code, 400% increase in files touched, 240% more commits and 170% increase in number of PRs, but only 30% more releases. So bigger releases a bit more frequently is how I read that. To be honest 30% increase in number of releases is mind blowing, but in combination with the other metrics scares me.

I’ve spent a hefty portion of my career preaching the opposite. Smaller things more frequently rather than bigger things seldom. Here we see bigger things more frequently.

And there’s another thing that is not even tracked in the picture above - what happened? What was the outcome of the increased output? For example, did the increase in the number of release have to do with failure demand since our releases now also were bigger?

The agile, and lean, answer to this problem is clear; smaller batches. Let’s play with the idea.

I believe in this concept, but the implementation above is risky and invites failure

This is a line, on page 2, from the 1970-ies paper that defined Waterfall model (although named like that in the paper). It is, if you continue to read on, “risky and invites failure” because things pops up that might change what we thought earlier. To my understanding the author, Dr Winston Royce spent the rest, not only the paper but career trying to explain that people misread his first diagram as something good.

Digital product development is changing in foundational ways. Close to everything we used to “create” is very likely to be done by an agent going forward. Code, design, tickets, tests and what have you. The most likely first of those is code (as in code will not be written by humans - there I said it) so I’ll use it as an example.

My immediate feeling is one of almost dizziness over how much that changes and what we will actually do… well no one knows yet. But it will be very different from today and that has my head spinning.

To have something to hold on to I started to think about whether I could come up with some values or quality gauges that would always be the same to steer after, regardless of how the output is created.

Like this - let’s say that the agents write the code, design, test and all of that instead of you; how would you know that the created product is good? That the code is good? That the process is good?

Yes, I’m looking for outcomes that are good to steer towards, regardless of how the output is created. It’s that simple. And we have probably measured most of these before, but now I’m coming at it with a different pair of eyes.

I make no claim of having a definite list here, but I felt a bit calmer after doing this and have a direction to navigate towards regardless of how my ship is propelled.

In this age of automation and AI I enjoy the simple physical things where I can get them. Like finding a proper kanban card to help my work flow just-in-time.

I was just in a meeting where we rattled of a few basic features to build on top of a database. It sounded a bit like this:

• Ok - let them browse the projects by name
• And by tags, of course
• Sure, and probably filter by location
• Wouldn’t it be cool if they could see how many other companies in their industry have been involved in the projects in our database?
• Oh - and then, just for fun; let’s put an LLM in place so that they can chat with the data, so to speak.

And at this point I just realized that the other features were now redundant. Because with our database hooked up to a LLM Chat that is operating on the data using an MCP server, all those questions would be possible to answer.

Are features not our main deliverable any more?

The paradigm shift that we are in is now real. I just realized how much my own world has shifted in what and how I do things at work, in less than a year. December 2025 was the first time I allowed an agent to write a feature from a prompt and felt safe that the result would be good enough to use.

I’ve been thinking about welding and punch cards - and that has helped me think more freely about where we are heading. And what my value will be in that world.

Since I started to see people use AI to build digital products something has always rubbed me the wrong way. It is like we are forgetting value, outcomes or impact and just keep clapping for the output. Token-maxing is real and I often have a hard time reaching through to people with this message, just because we are so happy that we close more (and bigger) pull requests.

Let’s not forget that. Let’s bring a value-obsessed, outcome measured and impact focused way of working back. Right now we are wasting the human capacity on keeping the agents busy.

I’ve written a few posts now on flow in the age of AI and to be honest, the other posts have been a setup to this post that is like the main idea (or itch I needed to scratch). Let me bring you up to speed with a short summary of the concepts so that you don’t have to read all of the posts, and provide links back to them.

I’ve written a few posts on AI and how it changes the flow of value, looking at it using my Theory of Constraints glasses.

But are we really moving up in the value chain or is it actually deskilling and we end up baby-sitting an AI robot?

You can find them here, if you want:

• What is throughput in our domain
• Theory of constrains in an AI world
• AI as robots - haven’t I been here before?

But I had a few more things that I wanted to get out of my system. The first is the fact that with automation, such as robots, the workers moved up in the value chain. This is happening again now, as AI is being used to do much of the writing, creation and generation.