Discovery vs Delivery

Avoid wasting your team's time and resources

✨ This article appeared first on my weekly newsletter where I write about product development, entrepreneurship and productivity. You should subscribe here.✨

Here is fact in case you didn't know: The majority of new products or features end up failing to achieve market traction or lose engagement after an initial spike. Many teams often find out way too late that what they are building isn't really what users need.

By incorporating product discovery to their development process, engineering teams can avoid this trap by refining their ideas based on their customer's existing pain points and needs. I'll explain further below:

🤜🤛 Product teams are faced with two challenges

In order to build software that actually provides value to their users, product teams need to:

Discover what to build – So they don't waste their efforts on products/features that are ignored by their users (building production-ready software takes time).
Ensure that they deliver robust and scalable software – Software that is reliable, maintainable, secure, has the right analytics implementation, etc.

These two challenges seem to be at odds as teams on the one hand need to learn fast with rapid discovery while at the same time delivering stable and robust software which is time-consuming.

Generally speaking, modern software teams have become better at the delivery challenge as they have adopted techniques to deploy small incremental changes which allows them to release periodically with confidence. This is not a process that you'd like to mess with.

🧭 How product discovery reduces uncertainty

To avoid wasting the team's engineering efforts on building stuff that our customers don't want we run discovery activities in parallel.

With product discovery, we simply want to get our ideas in front of real users customers early and often so they can be validated before they are written down as backlog items.

Instead of running experiments in production, you could invite a set of customers to spend some time talking to them in person, discuss what their main pain points are and test new ideas with experimental versions or even dummy prototypes.

Getting your ideas in front of customers early and often doesn't require the developer's time and will allow you to define a product roadmap based on backlog items that have been validated by your own customers.

Thanks for reading,
Manolo
@recio_sjogren

Here is the link to the article