These last few months I have had a realisation that really changed how I view product development.
"Good software practices do not translate into making better products faster."
For a long time, I have been going deep into software architecture. I genuinely enjoy reading about it, discussing it with my colleagues, designing systems and so on. I have learnt a ton over these years, but I never really stopped to think why I was doing it, or what the purpose of it was, besides "I like it". After some thought, it really was all about productivity. I hated to see products being slowed down because of broken processes, bad practices, and bad decisions, and I wanted to do better.
It was only after building Neurosuite that I understood it: even if you do the technical side perfectly, clean architecture, software designed for change, that doesn't make you fast. It just stops you from being slow.
After much investigation, reading and self-doubt, I came across various ideas that really opened my mind. It felt like putting the matrix glasses on, you know the feeling, right? The "now I see it all for what it is". That moment for me was getting to know much more about the product lifecycle (not the software development lifecycle), especially when reading about why what most companies are doing is not even close to being agile. As I was reading these topics, it just felt like the authors put my thoughts into words and made them make sense. It is still hard for me to convince people of the importance of changing the way we do product development, but I believe this could be a starting point.
The main problem I see is that we have failed to understand what it means to create good products fast. In particular, I think speediness has been greatly misunderstood by our industry. See, we are obsessed with increasing the pace at which developers ship code to production. We have invented all kinds of metrics to measure it, and now we have AI, so it would seem like we have accomplished our ultimate goal. Don't get me wrong, I have nothing against speeding up coding with AI or other tools, I'm all in on that, but do not believe for a second that the increase in outputs that your team ships will translate into equivalent value for your customers. It is just not feasible.
Solving a problem is relatively easy, and that is more true now than ever. But finding a solution that will please a sufficient amount of customers is the difficult part. When you read things like "coding was never the bottleneck", they are right, this is! It is just as true that there are a million ways to solve the same thing, so how do you know you are building the right thing for your clients? With each solution you have shipped, you have made a bunch of assumptions about your customers: the way they use your product, what bothers them about it, what other pain you could solve or just do better, how hard it would be for your engineers to actually build it. I'm guessing by now you see my point: how is it possible to increase the amount of time needed for this kind of product discovery to keep up with the crazy amount of code shipped? Again, it is not. I'm sure that if someone with a management role is reading this, they will probably be thinking: "So my team of developers writes code faster and then they have to wait for the discovery process?" NO, make them part of that process. Use the extra time that AI lifts from development to include them in your product discovery habits. Some will say that's a waste of time; I just like to quote Alberto Brandolini at this point: "It's the developer understanding, not the expert knowledge, that becomes working code." I believe it's time to ask yourself this question: where should I be investing the team's extra free time? If the answer is that they do not have any extra free time, this means they are not productive enough with AI, which means you do not even have this problem yet, just stick to the basics and fix the mess first. But if you do see an increase in quality software being shipped, it really is the time to answer that question.
If you answer "shipping as many features as demanded or possible", at some point you will see that the discovery process (talking to customers, experimenting with them, doing live sessions, demos, forms, etc.) will not be able to keep up with the new development speed, and you will start guessing. You will say things like "let's just build it and see if users like it". This is just guesswork, and as we will see, it turns out to be much more expensive than it sounds. Because most of the time you will go straight from problem to solution, 1:1, and we agreed that there are a million ways to solve it, so there's a good chance your users might have picked another one. At this point you are testing implementations, when you should be testing assumptions.
Recently, I posted a phrase I liked a lot from the book "Continuous Discovery Habits" by Teresa Torres, where she quoted the philosopher Karl Popper:
"Good tests kill flawed theories; we remain alive to guess again."
There is so much truth in this. The whole point of a company is to remain alive, and the only way of doing that is to keep growing. You probably already know that you are either growing or dying; there is no middle ground on this. One thing that we must always keep in mind is that we will make mistakes, there is no way around this. We will be wrong sometimes, even most of the time, I would say. Given this not-so-optimistic scenario, the only way to survive is to make these errors as painless as we possibly can, and this means identifying them as soon as we can. If our process is anything like: stakeholders or C-level people discussing which features we need, planning them into the roadmap, discussing timeline with the PM or development team, team breaking new features into small tasks and sprints, A/B testing (or any other technique alike), how is that agile? If you are working like this, you are still doing waterfall all the way until you have finished coding. Even if your development team follows Scrum methodology, it is not agile. You are waiting through this whole process to test a single idea, and given how easy it is to have made wrong assumptions, most likely you will have failed, and the price to pay is all the time, energy and resources your company has spent in each step of the way.
We should stop working like this altogether. Instead, start testing your assumptions early. The idea is simple: if you are in pursuit of a certain business outcome, write down all the possible solutions that could lead to that desired outcome. Once you have done that (ideally you are not doing this on your own, but instead a group of people is doing it and then sharing each one's ideas), start writing, for each idea, which assumptions you have made for that solution to be successful. After this, you just have to figure out a way to test those assumptions as quickly and cheaply as possible. The beautiful thing about this is that many solutions will share assumptions, which will speed up everything. The main goal here is not to have the perfect solution, it does not exist and you will not have it, but to remove as much risk as possible from each new feature. We will have a way to evaluate how risky each solution is by seeing whether the assumptions we have made were correct or not, combined with how difficult it is to implement and the value that we would get from it. Of course, for all this, you will need to be talking a lot to your customers, and you will have to involve the team responsible for building the solution. If understanding what we need is the bottleneck, why would you keep the people who will build it away from the source of knowledge?
If understanding is the bottleneck, and it always has been, moving product people as close to the customer as possible just feels like the natural move.
