In our last post, we covered gathering feedback from humans and the practical ways to do it. Now that we’ve put our product or idea in front of humans and started gathering feedback, we can start learning and making adjustments.
As a reminder, here are the steps we use to eliminate uncertainty, fail quick, and fail cheap so we can build the right product for the right people:
- Step 0
- Build in small increments
- Get feedback from humans
- Learn and adjust
Learning From Feedback
We can adjust our direction a little or a lot depending on what we’re hearing. We look for trends in feedback and ask qualifying and open ended questions to better understand it. We employ The Five Whys here as well. We don't want to blindly “increase the size or the logo on the home page” or “add a green button next to the other green button”. We want to have feedback and evidence to support our decisions.
We’re able to quickly make adjustments because we kept our initial solution simple. At this early stage, in our product or our new feature, we might be testing a paper prototype to see if the user can accomplish the goal you’ve set out in front of them. In this case, as you get feedback about the flow or the layout of a particular page you’ve presented them, you can adjust it in real time. Draw up a new page with a new layout right then and there. Then ask user to start over and gather feedback again.
Maybe what you’re testing is already live in production. You originally implemented the solution very simply, leaving some of the functionality to manual tasks for your internal team to take care of. You don’t know if the feature will even be used or if or how often those manual tasks will be done.
Now your analytics are saying that no one is using the feature. What you likely won’t learn from analytics is why they are not using your feature. If you can get this information from a survey or a customer interview, you can adjust how the feature works or what it does. After you’ve made some adjustments in the design, the user experience, or the feature, it starts getting some traction. Initially, the effort required by your internal team to accomplish those manual tasks is no big deal. But soon you’re hearing feedback from those users who've found the level of effort is too high and now it’s time to automate them.
The more simple our solution, the more flexibility we have to adjust going forward. We can roll out our solution, get feedback, and adjust in shorter periods of time. Depending on whether we’re working with a paper prototype or a live production app, this can be anywhere from minutes to days. By waiting weeks and months to make these adjustments, we get further and further from solving our user's true problem. This makes it more difficult and more expensive to get back on track.
Remember how we chose to build in small increments? That left us room to iterate, to extend, to adjust, to fix, to swap out, or to scrap our solution altogether without breaking the bank. We continue to repeat this entire process, from identifying the problem, building in small increments, gathering feedback, and making adjustments, through the course of building our product. This helps us become more confident that we're building the right thing and solving the right problem for our users.