What do Google +, the DeLorean, New Coke, and Windows Vista all have in common? They are all pretty large failures in product development. In fact, the list of failed products is very long and the money wasted on developing those products is very large. While there is no magic formula for building great products, there are some common, avoidable mistakes.
At Hard Yards, we describe these mistakes in a vicious cycle we call THE ASSUMPTION TRAP.
Assumption 1: We Know What the User Needs
We all have our own intuition and experience that leads us to conclude that we understand the user’s needs and can therefore build the right product for them. However, we recognize that we can’t know all their needs and we sure don’t want to build the wrong thing so of course we try and collect requirements from users and stakeholders.
Wow we definitely know what the user needs, right? WRONG!
In our opinion, no one really knows what the user needs, not even the user. We try to create a contract with users by gathering, cataloging, detailing, and approving requirements. Yet, we still find out, usually late in the game, that we missed some things. Or that those ”darn users” can’t make up their mind and they changed the requirements on us.
Assumption 2: We Have to Build the Entire Product (or most of it) for it to be of Value
Since we know what the user needs (see Assumption 1), we know how and how much to build to generate value, right? WRONG!
There are two problems with this assumption:
1) Value isn’t always in the eyes of the user. Many times, the value we can get by building something very small is learning. We may learn something very valuable about what it takes to build the end product, or be able to test ideas with users, or validate how our product interacts with other aspects of our user’s lives.
2) There are often opportunities to deliver incremental value to the user. Decades of big bang releases of products have conditioned us (and our users) to believe we have to have it all done when we deliver. If we work hard to understand the user’s true needs, we will often find out that we can solve problems incrementally and therefore create value more quickly.
Assumption 3: Our Product Works
We know what the user needs, we know how/how much to build, so it will obviously work, right? WRONG!
Without actually measuring the outcome, how can we possibly know it works? Outcomes can come in many forms. Sign-ups, registrations, transaction volume, basket size, cost reduction, repeat customers….the list is very long. Often getting alignment on the true outcome measure and actually measuring it are significant challenges, but it’s a crucial challenge to accept. We find that the lack of outcome measurement is the biggest and most widespread gap in an organization's product development process. This is making a huge assumption!
How do you break out of the Assumption Trap?
At Hard Yards, we work with clients to implement Design Thinking, Agile Development, and Analytics practices. It is our belief that these disciplines contain the theory, tools/practices, and mindset necessary to break each piece of the Assumption Trap.
Discover Requirements, Don’t Gather Them
Design Thinking has its roots in creativity practices from the 1950s and 60s. The Stanford d. school started teaching Design Thinking in 2005. Since then it has become widely adopted as a product development practice in a range of both federal and commercial industries. Design Thinking teaches us that through a set of practices we can empathize with users, clearly define and select the problems we want to tackle, ideate on a range of solutions, and quickly build and test prototypes. By artfully and continually embracing these techniques we can begin to discover user needs and validate our hypotheses on the right solution. This can be done strategically to determine what areas we may want to invest in all the way down to a tactical level to test mock ups, and low fidelity prototypes.
Build As Little As Possible To Learn, Repeat
Agile Development contains a set of principles that help teams quickly and consistently deliver increments of product. Frameworks like Scrum and Kanban can be utilized to organize and execute work at a team level and scaling frameworks like SAFe and Scrum@Scale can be employed when many dependent teams must collaborate to deliver a product. The key in any of these approaches is that we embrace the value of learning along the way. The often debated idea of a Minimum Viable Product can be used to build progressively more detailed and robust product increments to allow us to progress from a state of learning to ultimately delivering value for the user.
Measure, Measure, Measure
You must use data to validate your products and guide the decisions you make. If you can’t define the value you are trying to create and find a way to measure it, how can you justify the investments you are making in product development? The discipline to gain stakeholder alignment on outcomes is the first step followed by the discipline to meter and monitor your product. Often this requires building measurement capability into the product as you go. It can feel like this is slowing down delivery but it will ultimately accelerate the ability to meet the business objectives. There are many ways to approach measurement. At Hard Yards we tend to start with Pirate Metrics to help guide the type of measure based on product lifecycle and Objectives and Key Results (OKRs) to document and communicate those measures.
What Next?
The Assumption Trap is a common one. We encounter it every day both in our work with clients and in our daily lives. It takes focus and commitment to ingrain the mindset and embed the practices in how you build products. Hard Yards was founded on the premise that by bringing together Design Thinking, Agile Development, and Measurement we can help you build winning products and solutions.