Discovery Vs Delivery

Discovery is the moment where you are trying to figure out what to build in order to solve a problem for your users. Discovery is heavily around product and user research, prototyping, testing ideas and validating assumptions.

However, it’s also necessary to have someone from technology doing discovery; otherwise, you transfer slowness, confusion, and risk even to be attempting to build something that is not feasible or too complex to deliver.

Delivery should be focusing on engineering, and once we know what to build (often captured as requirements and figma prototypes for the frontend) we can start building it. The question is how do I build it right. Sounds simple right? But here we have one of the biggest dilemmas in software development.

If you just go from discovery to delivery, you are very likely working in a waterfall fashion. So this is not linear, but (which I consider an anti-pattern) happens all the time: the moment you touch discovery, people assume discovery is done or correct, and then you only care about shipping it fast.

You need speed, but it’s not just speed of delivery but actually speed of learning. The goal is to learn fast. Sometimes you can learn before production but often times you can only go to production to learn.

If you need to go to production fast to learn, should we embrace the Tech Debt plague and be Tech Debt First? No. Because you might learn what the users want or don’t want, you might find what can bring revenue to the company, but the code is there (likely forever) and we need to balance this. So you can’t just pick a side you need to balance both sides.

Why you need to know this?

Because such tension it’s constant. It’s a regular day of product and engineering teams. Being good on this “game” it’s game changer for the company like Mark Zuckerberg said “Product strategy is: IF we can learn faster than any other company, we’re going to win”.