Products and product feature set inspiration can come from anywhere. How many times have any of us dreamed up something we thought could be the next big thing, or saw the next big thing and said to ourselves, “I had that same general idea years ago, why didn’t I build it then.” The imagination dreamed it up because we had a problem we needed solved ourselves or watched someone with a problem we believe they needed to have solved.
The imagination can run wild with possibilities, if we let it. Often we don’t, rejecting progress because it isn’t practical for us in that moment. We look at existing competitors information, we do survey’s of potential users asking them what they believe they would want, or we just go with our own gut intuition for what’s right. There can be value in elements of each of these methods and sometimes they individually do work. However, it’s not always applicable, replaceable or sustainable for growth to function this way.
Conceptually, there are not wrong ideas. Realistically though, there are wrong products. Identifying what is wrong in some ways is more important than what is right. Investing (for too long) in a wrong product is a surefire way to destroy a business.
So how does one avoid such a painful debacle?
Test your theory.
Of the many things I’ve learned in agile environments one of them that I hold most dear is the guess->test->iterate workflow.
It borrows from the scientific method of hypothesis formation and testing, coalesces between-group design in building the experiment and employs some of the Dynamic Systems Development Method (DSDM) feedback loop of Study, Explore, Engineer, Deploy in order to provide structure to the development cycle. The end result can be used to make determinations about what works or doesn’t in order to make better decisions on to abandon, proceed or pivot.
That determination is, of course, provided you do the following three things diligently:
1. formulate a viable hypothesis to test
2. formulate a series of test that actually can validate or refute the hypothesis
3. use the correct data generated from the test in formulating a decision.
Assuming you can do all three of those, the final challenge, and the one that is most difficult to explain is understanding if the data is really telling you to abandon, proceed or pivot and personally accepting that path. This is the part you will struggle with the most.
One of the classic blunders is to discredit the data because it didn’t tell you what you wanted it to. It is ok to be wrong. Ideally, in many of these cases it isn’t about being right, or wrong, it is about gaining insights and direction to move toward a clearer, and hopefully more profitable future.
Of course, you may not have the capability to test everything you want to test. Resources, including the experience level, may not allow you the luxury to extensively test.
So how to you know where to begin?
With the Hypothesis, of course.
Each great idea you want to test should be wrapped in an estimation of what you believe about it. This estimation is what will be test. Thus, if you are unable to express clearly what it is about the product or feature that you want to learn then you shouldn’t be building it in the first place.
Say, for example, I am watching a friend or family member struggle with their child’s desire to play with their mobile device. I think to myself, wouldn’t it be great if there was an easy way to lock everything on the phone except for the apps the kid is allowed to play with. Sounds like a great idea, right? Something we’ve probably all observed.
Turns out there are a number of solutions to the problem out there. One could benchmark what competitors were doing and creatively produce differentiating features to go to market with. But, how would you know that your unique selling proposition was viable?
You would test the concept before you even began the process of building out all the features.
Re-frame your observation to a series of questions about what you saw.
For example, you might start with
1. Why do moms/caregivers give their devices to children?
Then come up with some assumptions as to what you think the answer is
Assumptions why mom/caregivers might want to give the device to the child:
1. Want an entertaining distraction for the child that acts like a virtual babysitter
2. Want a(n) (perceived) educational way to keep the child occupied with minimal supervision
This should raise more questions you can ask, such as:
2. If they do, what are their perceived biggest concerns about the child’s behavior on it?
3. If they do, how do the children actually use it?
4. Is there a walled garden approach protects the parents perceived needs while maintaining the child’s engagement?
5. If so, will someone pay for access to the walled garden?
To which you can begin to create an Overview of Related Assumptions:
Assumptions on why to use an app rather than manually locking down the device:
1. Convenience of a “one click” setup rather than having to navigate all the different settings on the device
2. Guarantees no in-app purchases, no chance for unforeseen expenses
3. No ads, no ‘mommie I want this’ moments or clicks off to unapproved sites
4. Curated content, popular entertainment and education all in one place
5. Age appropriate content, no chance of stumbling other stuff
Assumptions about the product itself
1. Child age group segments will have different UX needs/expectations
2. Kids are brand savvy so recognizable, branded content is important for engagement
3. The market for the app is different based on socio-economic and other demographic status of the users (working class immigrant/ ESL versus upper middle class urbanites, etc)
1. Kids drive parental decision making more than parents, at a certain age it’s more about what the child will accept than what the parent presents
From there generate a Hypothesis. One I came up with went something like this:
If parents need a virtual baby sitter then the app needs to entertain the kids in a safe and predictable way.
I got there by making a more specifically detailed one that touched on as many of the underlying assumptions as I felt were relevant and narrowing it down
When asked parents may say they want educational products to entertain their children but what they really want from a product like this is a virtual baby sitter that will predictably keep the child out of their hair.
If that is true, then:
It’s more about keeping the kids occupied, and kids will only engage with a product that has a) recognizable content and b) a look and feel that fits their expectation (ie: maybe looks like what they see mommy/caregiver using)
And, subsequently for our business, parent will pay for ease of use (simple setup) and ‘guarantee’ of kid’s engagement
You’ll notice a couple of things about how I’ve framed this complicated hypothesis:
First, that the entire thing is one giant IF / THEN statement broken it out into component assumptions.
I did this because determining need does not have to mean surveying or prototyping around the primary hypothesis, as parents and/or kids may not actually know what the need is. Validating some of the other assumptions it could provide insight into fulfilling the actual rather than expressed need of the consumer (kid) and customer (parent).
My underlying hypothesis, encapsulated in the IF, is based on previously discovered insights that what people say they need isn’t necessarily what they really need. While we will be testing to determine if there’s truth to the statement about what parents really want it’s more qualitative and not quantitative in nature.
The THEN portion of the statement sets up some quantitative elements we can test toward which, if true validate the if.
Second, you’ll see
Testing the Hypothesis:
In this case there’s two paths that need to be tested separately but are interdependent. First is based on the consumer (the child) and how they will use it and second is the the customer (the parent) and if they will pay for it.
Determining need does not have to mean surveying or prototyping around the primary hypothesis, as parents and/or kids may not actually know what the need is. Validating some of the other assumptions it could provide insight into fulfilling the actual rather than expressed need of the consumer which is why I chose to divide up in this way.
Crafting individual tests around each component then takes the large task of determining if the product is needed into smaller, manageable tasks about the underlying elements. These can then be broken down again, and again, until you’re testing feasibility of very specific parts of what you believe the product to be, feature by feature.