The best way to develop a software product is one feature at a time. For the first feature, that includes the minimum foundations required to support it. Then you wait for users to try it out and give you feedback so you can refine it.
Once you have it in a good state, you do the next feature. Work on the foundations should be easier, but this time you have to consider ripple effects.
How does this new feature impact the first and where does that impact surface in terms of change for the user? So, when you ship this new feature you need to take account of feedback on it and on any changes you’ve made to the first feature.
And so it goes on, growing with each feature.
That’s why limiting the number of features is so important for the product and for the user. It’s also why you have to do them one at a time. Otherwise you end up buried in a snowdrift of conflicting feedback and change.
Coding faster doesn’t help you here. Quite the opposite. Very little of the time is spent coding and your product team never needed to be engineer heavy. Doing more than one feature at a time also doesn’t help. You can’t anticipate how the features will coexist because you don’t know how either will end up once user feedback has been taken into account. Believing you can is just arrogant folly heading for a fall.
The assumption has always been that the thing holding up product development is the software part, but this has always been wrong. The bit slowing it all down is the desire to do it properly.
There never was a bottleneck, and it certainly hasn’t moved. You can either build a product quickly or build a good product. You can’t have both.
Unfortunately, the conclusion the speed merchants will draw from this is “the user is the bottleneck”, and they’ll move on to removing the user from the process. They’ll do this either by suggesting products should be built for agents to interact with, or they’ll claim user feedback can be simulated by AI.
Both of these conclusions are merely the product of confirmation bias. They’re fighting reality rather than working with it. An AI can’t simulate a user because it doesn’t “feel” things the way a human does. It will merely give you false confidence that you got it right. You might as well skip the feedback part entirely.
Furthermore, you can’t build products for agents that haven’t been widely adopted yet. That’s just a way to learn the lesson about timings. There is a very long list of products failing because they were ahead of their time.
So, that just leaves you with one option. Work on one feature at a time, together as a team, and get it right. It might feel slow and cumbersome, but ultimately it’s the quickest way to build a winning product. You can even call it agile if you like, because it is.
Never has “more haste, less speed” made more sense.
The feature image for this post is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.
Attribution: cc-by-sa 3.0 © Marcus Cyron