We came across this picture while writing the Agile C’MON Man post. The irrational exuberance in this picture gave us a chuckle, but it also reminds us of an engineering group driving product development. As we articulated in the previous post, engineering driven product development can lead to BUFD. At the same time, we articulated the lack of business driven product development is due to ill equipped product management. In this post we will lay out a high level business approach to product development.
We think this is the new frontier for Agile and software development. The Lean Startup and David Joyce’s talk, 21st Century Portfolio Management, are great resources to start shaping how we need to think about driving product development. The fundamental principle that these two resources drive home is learning. Our ability to deliver higher value products hinges on our ability to learn. These resources also champion the fact that learning on the business side does not end after a business case has been delivered, nor after requirements captured, nor after a team has showcased working software at a demo. No, learning needs to happen with real customers. Therefore, we need to consider how we are going to learn throughout the whole lifecycle, including customer consumption.
Learning is not a new concept, especially when we talk about feedback loops in SDLC’s. However, the difference here is the measured approach to learning. We should not just ask what should be built, but why it should be built. Therefore, we should wrap measurements by which value returned can be measured and validated. It is this process of being intentional about quantifying results based on predetermined measures that helps accelerate learning. Documenting measures that align to our assumptions, force us to gain a deeper understanding of why our customers want what they want.
Experiments – You may have heard these forward leaning thinkers refer to this process as “running experiments.” At face value, this conjures up thoughts of lab rooms and scientists, but we’re doing software development…right? Well think about it. If we’re making assumptions and documenting what to measure after a capability has been delivered, it’s safe to say that this sounds like a hypothesis. If we build out that hypothesis and then measure the results, we essentially are running an experiment So it’s not that crazy after all.
Recently, a new “xDD” (x Driven Development) has hit the radar. Hypothesis Driven Development(HDD). Its so new, that there isn’t even a Wiki page for it! Mind blowing…I know! Whether you call it HDD, Lean Startup, 21st Centrury Portfolio Managment, or whatever, we think this is an area business product developers can gravitate towards to build better products. If you have thoughts to share on this topic, we’d love to learn with you! Please comment or DM us to continue the conversation.
