Developing great products is hard. The most conservative estimates place new product failure rates at 50% or more. Many of us can relate to working on an exhilarating project with talented colleagues, where the solution was architected brilliantly and even delivered on-time, only to see the product fall short of expectations in the marketplace.
Mark Interrante and I had the privilege of hosting a workshop on how to think about designing the right thing. During our presentation at Mind the Product 2013, we talked about how our teams use four practical tools to execute product design: Desired Outcomes, Product Box, Back Planning, and Requests and Agreements. Based upon the reaction and feedback from our audience, the challenge of product design is universal. So let me take this opportunity to recap some of the material we covered and give some additional commentary on how our teams engage in product discovery. I hope you will then share some of these “tricks of the trade” with your design teams to produce successful products for your organization.
We have to design the right thing; not just design it right. This phrase seems obvious, but it is overlooked more often than you would believe.
At Rackspace we employ a number of tools to help us not only design well, but to define and build the right product. Holding a Sprint Zero formally makes the space to use these tools and others, which sets the project up for a greater probability of success.
- Product Box
The goal of Product Box is twofold: 1. To clearly articulate the value your product provides, and 2. To make the future real by orienting your team toward a shared vision. Again, it would seem obvious. I mean we all understand what we are building, right? But, if that were really the case, then why are half of our products failing? Product Box allows teams to ensure all members have a clear understanding of the exact specifications needed for the project. Employing this first step will help mitigate workflow stops and wasted time leading to frustration for team members caused by unclear or misunderstood instructions. For more information on Product Box, I recommend checking out Innovation Games, at http://innovationgames.com/product-box/ - Desired Outcomes
The Desired Outcomes framework provides a powerful structure for describing what success looks like. How do we know we have what we set out to produce? The key to a successful Desired Outcome is to understand, from a specific perspective, how the persona or “atomic segment” will know when they have what is wanted (or what we believe they want). It is critical when defining the Desired Outcome that the evidence for what is wanted is expressed in terms of the five senses. Note: the Desired Outcomes framework is adapted from the Well-formed Outcomes pattern within Neuro Linguistic Programming. - Back Planning
Back Planning, also called Assumptive Goal Setting, begins with a desired future state, which clarifies the real path to success by working backwards from end to the beginning. Dividing the project into logical work streams and conducting the back planning exercises against each stream, one at a time, reduces the complexity of this exercise. The key benefits realized using this method are creating a clear picture of the dependencies that exist in the system, as well as obtaining across the board alignment on the plan from start to finish. - Requests & Agreements
This protocol is utilized for creating clear requests and ensuring durable commitments. In this model, creating a clear request is paramount. The Desired Outcomes framework, identified earlier, is a useful tool for making a clear request. When a clear request is made, there are five and only five valid responses: 1. Yes, 2. No, 3. Commit-to-commit (if more time or information is needed to make the commitment), 4. Counteroffer (‘I will do this instead’), and if you committed to a task and later find yourself unable to complete it, it is crucial that you 5. Renegotiate the commitment. Proper Requests & Agreements ensure handoffs within the system are consistently executed well.
Utilizing dual-track Agile dramatically improves the likelihood of success, by making a distinction between Discovery (building the right thing) and Development (building the thing right). If you’re unfamiliar with dual-track Agile, I highly recommend the work of Marty Cagan; you can read his work at www.svpg.com. Dual-track Agile provides space for the up-front thinking work and experimentation to get products off the ground with greater likelihood of success.
I hope these principles help you build more successful products. Thanks to the fine folks at Mind the Product for the opportunity to share a few of our thoughts on building products more successfully. I am interested to hear what tactics you and your teams utilize as well as your feedback upon using the four I outlined above. I look forward to seeing you at the next Mind the Product event!
Comments 1