Lessons from Pitching a Hypothesis
It’s one thing to find a problem. It’s a whole other adventure trying to solve it.
That’s what we tried to tackle this week in our product development class. In this class, students are looking to develop news products to better serve specific groups of users in Tucson, Ariz. We’ve spent the last few weeks learning how to dig deep and find out what causes problems for the user group we each are focusing on. We’ve interviewed dozens of people in supermarkets, parks, concert venues and more, using probing questions as a magnifying glass to search for a problem.
Well, we found one. And now we’re looking for a solution. This week we presented hypotheses for our solutions, some even including prototypes. Afterward, our class mentors provided feedback on each of our ideas. Here are three key takeaways I learned from the experience:
1. Don’t be fully sold on your first idea.
It can be easy to fall in love with the first hypothesis you flesh out, especially when you’ve worked so hard on it. But don’t let the excitement of getting those ideas on paper blind you from the fact that it may not be the best solution for your audience. Don’t be afraid to rework your idea if you find that it’s just not as practical as you thought it would be. I went into my presentation thinking one particular feature wasn’t that important and would likely not make it into our final product pitch, but it turned out to be the star of the show. Clearly, we will have to change our prototype to accommodate our user groups’ needs, and that’s okay. That’s what this process is all about.
Creative commons photo: mohamed hassan
2. Sometimes less is more.
It wasn’t until I heard the feedback for my hypothesis that I realized something: our proposed product had too many features. We had designed our prototype to include a variety of features, served up to users on a brightly colored menu of options. We were proud of our ideas, but the feedback made me realize the problem there: with all those features, it could be hard to tell what the audience actually wants and what are just extraneous ideas. We need to go after the MVP — the minimum viable product necessary to fulfill the needs of our users. We need to focus on the one or two features that could do that, and the prototype to find that out is much simpler than our original one.
By showing users a prototype of a menu with all our proposed features, we can see which they click on first. Just that simple action alone can spotlight which feature we need to focus on — because that’s what users are most interested in — and which isn’t as important to users. And at this stage, when we are still trying to find the perfect solution, that may be the most important takeaway of all.
Creative Commons photo: FirmBee
3. Remember, there is still much more to learn.
Presenting our hypothesis was exciting — we made a clear move forward in our quest to solve our user group’s problem. But it also revealed how much more we need to find out. Our hypothesis is an informed guess at this point, and now we need to test it to see if it actually solves the problem for our user group. From there, we can learn what would be more helpful, make adjustments to our prototype, and try again. It’s a continuing cycle, and each time, we get a little closer to solving the problem and doing a better job of serving our community.
