Pattern #3: From Delivery to Discovery

From delivery to discovery

We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. – T.S. Eliot

Building the right thing(s)

As a software development team you support the product owner whose job is to find out what your customers need and are willing to pay for. Instead of focusing on building the thing right, they focus on building the right thing. Now that AI takes care of the coding and we have automated delivery, developers can help discover what they should be building: there is more collaboration time together to discuss and experiment with different ideas and options.

The usual discovery process revolves around researching product ideas collected from three main sources: team brainstorming, customer submissions, and competitor analysis. Traditionally, we select a single idea and move into the delivery cycle. However, with today's affordable compute, we can now leverage AI to generate and deliver multiple ideas simultaneously. This parallel approach enables us to gather feedback more quickly and efficiently, accelerating our product development timeline.

Related article - https://www.stevesmith.tech/blog/build-the-right-thing-and-build-the-thing-right/

Vibe coding is discovery

When you’re in the zone, coding feels like jazz—improvisation with good vibes. This kind of exploration is really powerful to go beyond the usual ideas or solutions. We are less focused on the perfect sound but on the novel way things sound. This is similar to what Andrey Karpathy calls “vibe coding”.

What if we blindly accept the code being generated by the AI and just keep exploring? If it doesn’t do what we want, we tell it to course correct. We don’t care too much about the coding but focus on figuring out what we need to build and the problems and solutions we will face. Now, many have frowned upon this method as it obviously does not build the best code, and blindly accepting the code is a risk. I would say in the exploration phase and discovery this is perfectly acceptable. Once you have a better understanding of what you want and how you want it, you can repeat the process with the usual engineering scrutiny.

Turning incidents into innovation 

Discovery is not just for product owners or developers: when things go wrong, you have to find the cause and figure out solutions. We have to discover what was going on, looking at the context and making decisions. AI can really help with triaging what the issue is.  But why stop there? Why not have AI generate different solutions? Building a hypothesis during incidents is similar to selecting the right features for the product. Thanks to the code generation, the system can now build multiple fixes, try out different solutions and report back to use for choosing the best one. This closes the feedback loop way faster than just using AI to triage and send it off in a ticket to the next person.

Customers in control

“The customer is always right.“ is a frequently used quote. It highlights that the customer knows best what they need. Yet, they also have to go through a discovery process. They see your product and that challenges them to use and formulate new ideas. 

A/B testing has proven valuable for understanding customer preferences, but it’s limited by the need to pre-code different options into the product. What if we flipped this model and allowed customers to modify the application themselves?

Some products have enabled this via extensions, with AI this can be taken to the next level. End-users could directly influence product development by personalizing their own experiences, generating valuable insights that flow back to the product team. This approach essentially democratizes innovation, empowering users to shape their own experiences and ultimately leading to more intuitive, user-driven products.

A/B testing has been used to better understand what different customers want. It still requires the coding of the different options in the product. What would happen if the customer could change the application? AI would empower end-users to directly influence product development by personalizing their own experiences, which then feeds valuable insights back to the product team. It’s like democratizing innovation, letting users shape their own experiences, which can lead to more intuitive, user-driven products.

Related - https://keak.com/ - The first AI agent that continuously improves your website. 

Service-As-Software

In the extreme form of customer customisation, you can argue: why do customers still need Saas companies if they can have AI for everything they need themselves? Just point it at an existing service, have AI implement the features you need. And have it adapt to how you want it. This is roughly the premise of “Service-As-Software”: why would you pay for services if you can build it all yourself? Well, someone needs to manage the systems, needs to understand what good looks like, and also evolve the system, so you shifted it from external to internal services again.

Related - https://www.forbes.com/sites/joannechen/2024/04/29/ai-leads-a-service-as-software-paradigm-shift/

We’re swapping code for curiosity.

As AI handles more of the repetitive, time-consuming parts of development, it opens up space—not just in our calendars, but in our thinking. That’s time we can spend sketching out smarter architectures, testing bold ideas, or simply exploring what’s possible beyond the backlog. It’s not about doing less coding—it’s about doing more of the thinking that matters!