I’m a real stickler for finding value in what I buy. There are few times that I go for the “fancy trends”. For instance, when it comes to cars, I want it to get me from point A to point B without fear of breaking down at a high level of comfort. I want it to be durable, long lasting with the fewest visits to the repair shops possible. It doesn’t need to be fast nor slick. That’s my definition of value. However, a good friend of mine loves fast and slick looking cars, even if that means a few more trips to the repair shop. Clearly our definition of value is different and I shouldn’t have him choose my car for me and vice-versa.
This same values applies for the software people use. Understanding the value of what you are building for your end client base (the users) is key to sustaining and growing your business. In Agile, this takes on the form of the Product Owner who represents the end user. Often, the best Product Owners are the ones that are also users.
However, getting input via one source is risky and when millions of dollars or more is invested in a new or updated product, you want to ensure that all that investment hits the right target. Traditional Agile delivery methodologies don’t focus on further validations that the right product is being built.
Horror stories of companies of building the products and “no one comes”. No “Field of Dreams” is automatically received. Hope is no longer a strategy for success.
Dominant in the past up through the 1990’s and still often present today, the IT organization lead the construction of software and more times than not, the result was software the end users disliked or tolerated at best.
Then Business took on a more direct role with SME’s, the Product Owner or Product Manager and under Agile, that communication increased and now more quality software that end users liked has been built. Today the majority of software development is led by a line of business (LOB), not Information Technology. About time our workforce got there.
The discovery path
So success for a project shouldn’t be restricted to just delivered software, but instead how well received and the end user feedback of the software. There are many approaches to address this lingering gap, and one that is very effective is called the discovery path.
The discovery path is based on the lean principle of value stream mapping and the ideas introduced by Jeff Patton called Dual Track Scrum.
The main concept of the discovery path is to hold sprints for determining that the right product is being built by have repeated sprints of reviews with the user community in parallel with the delivery path used in traditional scrum.
The discovery path includes several methods to validate your ideas with your target users as early as possible. Examples include:
- Building an opportunity backlog
- User research/interviewing
- Story mapping
- Quick visualization design studio
- Detailed personas
- Right fidelity prototypes
- Key Performance Indicators (KPIs)
Carrying this out can be scalable, but certainly adds expense to the bottom line delivery of a project. However, the value of building excellent software versus building good software can make your business an Uber instead of clone such as a Lyft or Grab. Mobile solutions are typically excellent candidates for using the discovery path. If your software only needs to be “good enough” and have limited budget, then implementing the discovery path may fit for you in only the barest approach.
