On the heels of Apple’s WWDC last week, the keynote address undoubtedly had savvy entrepreneurs and developers already thinking about how to leverage new releases; specifically, the dramatically expanded API, and integration with maps, messages, phone, and Siri.
While this opens the door to new possibilities, it doesn’t change the very fundamental need to test ideas, theories and products on users early and often. But where do you begin? How do you know if you’re testing the right elements?
Whether it’s an app, a physical product or a piece of software, here are five questions every product team should be able to answer at any point in time. It’s core to the work that we do at Tallwave, and something we challenge ourselves to ask of every project and in every interview along the way.
Question 1: Do your customers need it?
There’s a big difference between a need and a want. People will use what they need, but talk about what they want. Prior to building a prototype, you’ll want to validate there is in fact a need in the market for your product, and seek to identify all potential pain points.
Is your product actually addressing these pain points? Or did you find that perhaps these pain points don’t truly exist or that you’re not targeting the right customer. Maybe there’s another segment who would find more utility from your product. Or maybe you find you were on the right track with the pain points you predicted, and now you can tweak your idea to better fit the needs of your users.
Question 2: Does it solve their problems?
After you’ve validated your assumptions, made the necessary adjustments, and developed your prototype, you’ll need to test with your users to confirm it resolves their problem and adds value to their lives in some fashion. If it doesn’t or only partially fulfills their need then tweaks can be made to create the best product possible.
During this phase, you’ll also want to identify whether your potential customers will be willing to invest the time required to learn how to use your product, and if they will pay for it. This process significantly reduces the risk of building something that nobody is going to use.
Question 3: Is it easy to use?
Ok, so you’ve proven your product is fulfilling a need, but is it intuitive? If there’s a learning curve, how long will it take for your user to feel comfortable using your product? More importantly, will they stick around that long?
One of the worst scenarios you can have is a product that creates another problem or complicates the process. If it takes two hours to resolve an issue that normally would’ve taken just an hour without your product, it’s time to go back to the drawing board. In many cases less (features), is more.
Question 4: How do I prioritize features and create a product roadmap?
If you tell 100 friends about the product, you’ll likely get 100 feature suggestions that should be added. It’s easy to be cornered into a ‘jack-of-all trades’ product that isn’t particularly great at anything. To avoid this fate, find the core features that will satisfy the primary needs of the customer to get the product to market.
However, if 80 of the 100 users you’re testing are requesting a specific feature, it’s something that should at least be considered in the next version. If this is the case, you may have stumbled upon a new pain point that could be a defining benefit of your product.
These steps will determine the right balance between a minimum viable product and a product that is too light or too heavy on features.
Question 5: How do I monetize?
There are many options out there for monetization, such as advertising, subscription-based, or just a single purchase transaction. Research into your competition to see what they are doing and how much they are charging. More importantly, however, ask your users how much they are willing to pay and what features are needed to justify that amount.
When in doubt, ask existing or potential customers for feedback. Be careful not to attempt to add all suggestions to your product roadmap, but do look for trends and patterns in the feedback.
Written by Terri O'Shaughnessy