I have been reading Yuval Noah Harari’s wonderful book, Sapiens: A Brief History of Mankind. The book traces the journey of Homo Sapiens through many distinct periods of time - “the Cognitive Revolution”, “the Agricultural Revolution”, “the Unification of Humankind”, and “the Scientific Revolution”. I thoroughly enjoyed reading the book. I highly recommend you read the book as it was not only informative but featured great storytelling and analysis. It was hard to put down, and that is saying something about a non-fiction book. Plus Bill Gates recommends the book too!

This book might not seem like one directly applicable to software development, agile ways of working, or product best practices. As it is written and normally interpreted, I agree with that assertion. However, there were two terms used in the book that resonated with me and that hit me as great metaphors for some of the biggest challenges I see in product development practices prevalent today.

Discovery of Ignorance

Let’s start with the “Discovery of Ignorance”. Harari used “The Discovery of Ignorance” as the name of the first chapter of the section on “The Scientific Revolution”. He contends that a torrent of scientific exploration and achievement was ignited by the discovery of our ignorance - what we didn’t know. Specifically, he states that the willingness to admit we did not have all the answers about how the world works and a desire to address that ignorance through scientific experimentation is what has driven the major advances in human civilization in the last 500 plus years. All you need to do is compare the pace of change over the last 500 years with the pace of change for the millions and billions of years before that.

Let’s apply this to how we develop software products. The way we have traditionally developed software products is that we do some analysis up front, create a product strategy, and then spend the rest of our time focusing on the delivery of the software product via the plan we developed. This only makes sense if we believe that we can determine everything we need to do upfront and thereafter, there is nothing new we need to learn or explore beyond the execution of our well-thought out plan.

Along come agile practices which supports iterative development, allowing for, and even encouraging learning and adaptation as we consistently deliver new working software. This was the beginning of our “discovery of ignorance” in the world of product development.

So far, so good, except… in practice, the learning and adaptation seems to be narrowly focused on how we implement the specified solution, not on continually wondering if we are going down the right solution path for the given customer problem we are working to solve. In many companies, even when they get good at delivering continuously in a regular cadence, they are simply executing against a fairly fixed plan, schedule, and roadmap. Good execution is a big positive, as long as we are working on features our customers will most value and use.

However, study after study shows that about 80% of features we develop and put in our software products are rarely or never used! That’s a lot of ignorance about what our customers will value.

How would we run our product development efforts if we would fully discover, and more importantly, accept our ignorance? Maybe we would focus on the things we don’t know that we need to know to have a better chance at creating a successful product. Maybe we would list out the critical assumptions that need to be true for our product to create value for our customers and then determine the fastest way to validate or invalidate those assumptions, starting with the most critical and uncertain of those assumptions. Maybe we would continuously seek more information and continuously keep in mind other possible solution ideas that emerge. Maybe we would use something like opportunity solution trees to guide our journey and form the basis of regular discussions between the product development team and company leadership.

Just as Harari’s book shows us that those in history who recognized their ignorance and focused on continuous learning and exploration found greater paths to prosperity and a higher quality of life, I strongly believe that the product companies who recognize their “ignorance” and focus on learning through continuous discovery will have many additional paths to product success than their brethren who continue to hold fast to fixed schedules and road maps.

Empty Map Sections

Speaking of road maps, the second observation from Sapiens that made me think about product development is that on many 16th century European world maps, they left empty room on the maps for areas that had yet to be discovered. Prime among these maps was the Salviati World Map from 1525.

So what do 16th century world maps have to do with product development, you ask? Have you ever noticed that there is never any empty space on our product development road maps? Why is that and what does it imply?

Our roadmaps don’t have empty spaces on them because we equate more features with more customer value and we want to continuously add value to our products so that we can attract more customers and retain more of our existing customers. We, especially in leadership, also value efficiency, so having a full roadmap ensures our teams are always working on something. While those beliefs are both understandable and very prevalent, I have questioned the wisdom of both. You can read my past blog articles on the questionable value of more features and the dangers of too much focus on efficiency.

The implications of having no empty spaces on our product road maps are that we know exactly what we need to do and that we have no time to explore or look at alternative solutions. Don’t get me wrong. I think roadmaps are quite useful as long as we are transparent about what is definitive on the roadmap and what is just our best current guess as to what we will be focusing on. Roadmaps are most useful when we revisit them at least once every few weeks to reassess and update.

Even so, what kind of statement would we be making if we created roadmaps with actual blank spaces on them? Would that encourage more adaptability and drive continuous discovery activities? Would that give our teams room to decide that if we didn’t quite get the results we wanted from a feature, they could circle back to build something better? One thing I know for sure is that publishing a roadmap with blank spaces will definitely spark discussion!

The takeaway here is that by being more transparent about what we actually know and focusing on what we need to know, we can get much more effective at our product development efforts, driving greater customer value with less overall investment. Turns out that admitting your ignorance and embracing continuous discovery can put us on a path to creating better products!