Menu Close

Continuous Discovery – The need

It feels weird to jump into the middle of a random topic after an 8 year gap, but I’m really itching to write about this. So I’m not going to give much in terms of context and dive straight in. For those of you who are really crippled without context, I’ve been doing a variety of roles like Business Analyst and Project Manager in ThoughtWorks since 2011, although for the last couple of years I’ve been playing an ambiguous operations role, heading the Capabilities function for ThoughtWorks, India. More on all that experience in a separate post.

The inspiration for this topic is an excellent product management workshop that I attended recently. That, coupled with a number of things that had been puzzling me over the past couple of years. There’s still a lot for me to synthesize, so this blog post is as much a thinking tool for me as it is information for you.

Continuous Delivery is not enough

There’s a LOT of software that gets written in the world. Most of it is quite bad but we don’t really see it. The software that we see is from big tech giants (google, amazon, microsoft, netflix, etc) and small startups that have done really well for themselves (zomato, walnut, instagram & whatsapp even before being bought by Facebook). So also, there are businesses that want to build more software whether it is directly for general public, internal users OR other businesses.

Most of these businesses have understood that the traditional way of building software is not useful and have started adopting agile software development in some way or the other. There’s a wide spectrum here from “I have started doing stand-ups” to “I do continuous delivery”. But even the organizations that have reached the promised land of continuous delivery may not necessarily be successful! Remember flickr? They achieved 10 deployments / day back in 2009! And they were a successful product back then.

“So if a big, successful business that has achieved 10 deploys / day can’t survive this market then what chance do we have?”, I hear you ask. And you’re right. It’s a really difficult market environment that we have created for ourselves and that is why it is important what we keep constantly re-inventing the way we succeed in this world.

The elephant in the room

Agile addresses the question of what good delivery looks like. While it has a vague concept of “business value” that every story is supposed to deliver, this business value only helps in slicing user stories in the correct way. When done well, you can add or take out stories to tweak value at a micro level, without needing to make big changes. But who decides whether what we are building is actually valuable to buyers & users of our products?

Even some really mature organizations have a cop-out answer for this question. The Product Owner.

The Product Owner has been defined as this person who holds the vision of the product. That’s a great definition but a very big job. It is also fundamentally flawed to rely on one person’s intelligence to drive the product’s vision. So, in less mature organizations, the Product Owner ends up just documenting the wishes of all the stakeholders and getting those wishes delivered. These wishes are nothing but features that may or may not achieve the goals of the product. More mature organizations understand that validating their ideas with real users, before the development starts is important than their personal fancies. So the PO spends time talking to the end users and validating her ideas before putting them on a backlog. This is what she would call “Discovery”.

This is a great start but still far from ideal. We’ll see why in the next part.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.