There's a lot of talk about agile these days. Does it work? Does it not? Should we try something else?
I don't care what you call it.
Product development is fundamentally about two things.
First, the business and the users. Are we building the right product? Things that are truly making a difference, things people will actually value.
Second, the actual hands-on product development. Can we create a quality product? Something solid and stable, maintainable and extendable for the rest of the product's life. And can we do so cost-effectively, building only the things the business and users actually care about.
The magic is in making those two things work together efficiently and effectively. Each can prevent or enable the other. And you can accidentally create so much noise around those two that neither of them works.
The right product problem
Getting the product idea right is incredibly difficult. And it's arguably the most important of the two. If we don't build the right product, nobody cares about its qualities.
But we can't just do a big analysis upfront and ask users what they want. As Henry Ford allegedly said: "If I had asked the users what they wanted, they would want a faster horse." Twitter started as a podcast platform. Instagram began as a location-based check-in app where photo sharing was just a side feature until users showed what they actually valued.
You never truly know what users want, what they will value, which parts they will actually use.
In software, we have the luxury of making much smaller gambles. We can build incrementally and deliver to real users. See how the market reacts. Are we on the right track? Should we change direction?
This continuous refinement — learning from real feedback from the product itself — requires constant back-and-forth between those who understand the business and those who hands-on build the product. The better this interaction works, the faster you iterate, the better product you make, the cheaper it is, and the faster it gets to market.
None of this is new.
The scaling problem
Almost every larger organisation I've visited has struggled to optimise this. Most of the obstacles have been created by themselves — solutions built to address local problems that collectively destroy the shared goal.
Development teams get measured on velocity, so they optimise for story points over long-term quality. Sales teams get measured on quarterly numbers, so they promise features that don't exist yet. Infrastructure teams optimise for what's easy for them to maintain over what product teams actually need.
Each group is solving their local problem. But the organisation's actual goal — building products that users love and that make business sense — gets lost.
In smaller product development teams, this is much less of an issue. There's nowhere to hide from the shared goal.
The company of one
For many years I worked as a consultant for large companies. But I've also built products on my own — most recently a diabetes management app, because the existing ones didn't meet my needs as someone who has lived with Type 1 diabetes for over 30 years.
When you're a company of one, every decision you make, every day, you think about its impact on the whole. Is this the right product? Is this feature really what people will want? Is it worth the cost? Can I build it more efficiently? Is the quality right?
This happens automatically because you're wearing all the hats: CEO, marketing, sales, design, UX, test, development. You constantly shift focus based on what's most important right now. Today you might fix something confusing in the interface because you noticed it while testing. Tomorrow you might rethink a feature entirely because a user showed you something unexpected.
This fluid prioritisation happens naturally when you own the whole picture.
I can't help but reflect on how the same insight would play out in some of the larger organisations I've worked with. The developer would need to write a story, get it prioritised by the product owner, wait for the next sprint planning, discuss it in refinement, get approval from the architect, coordinate with the UX team — and maybe, if they're lucky, actually fix it three months later. By then, users have already formed their opinion about the product.
What this means at scale
Scaling starts when you are more than one person.
As long as you can, make sure the concerns of all those "hats" are integrated into every decision, without getting in the way. Add only enough structure to support this. Nothing more.
Everybody working toward the same goal. No sub-goals per function. No managers intervening between the people who understand the users and the people who build the product.
This is the most efficient and effective way to develop products. It was true before agile had a name. It remains true now.
Once the product development grows to a size where people can't sit in the same room, you need to add some process and structure. Getting this right means adding just enough to support communication without getting in the way. Constantly making sure you're not sub-optimising and forgetting the shared goal. Constantly breaking down silos so business and developers can work together directly.
The good news: once you recognise these patterns, you can start designing around them. The challenge isn't knowing what to do — it's creating the conditions where it can happen naturally, even at scale.
You might call it agile. You might call it something else.
I don't care.