Avoiding product schizophrenia
“People don’t know what they want until you show it to them.” — Steve Jobs
Scenario: You’re on a team that’s developing a new product. One of your team members mentions the possibility of co-developing with a group of users that your team has identified as early adopters. How will you as a UXer, listen to your User’s needs without building a clunky Swiss Army Knife of a product that no one will use?
How do you determine which features to include in your MVP and do you determine the difference between “Need to have” features and “Would be nice to have”? You can’t include every feature every user wants or needs, but you do need to empathize all of your users and try to not alienate them.
Align internally
Ask your team, “what does your product do”? Do you and your team all align on the basic functions and features of your product. You may think you do but if you haven’t tested your theory, it’s just an assumption.
Take the internal temperature of the team vis-a-vis internal testing. Here’s one effective group activity ask your group to meet in a common space. Have your Personas, Lean Canvas, Empathy Maps, all visible (this may be harder in a virtual office setting, if you use Zoom or something similar you can just screen share).
Ask your team to write out all of your product’s features on post-it-notes. Make sure they write one product feature per post-it-note. After you’re done, it’s time to create an affinity diagram group the features by similarities. This is a great way to identify any group misalignments.
Talk about the misalignments and DO NOT DISCARD THEM. Instead, add them to your team’s backlog. You may want to re-visit those proposed features in the future. If the feature is trying to solve a User’s problem, the idea isn’t bad, it may be a kernel for a new product or a future feature and it should be documented.
Prioritize Your User’s Needs
Now that your team is internally aligned, it’s time to reach out to the Users you are co-developing with. When trying to gather feedback on features, keep in mind, Users are bias because you are personally trying to solve their problems. They may love everything that you give them.
Our team ran an experiment early on that presented a set of features to a group of 30 users. We sent out a survey with a video presentation about the product overview and asked them which features “stood out to them”. Our hypothesis was that we would be able to narrow down our list of core features for our MVP. The result was evenly mixed, none of the features stood out.
So the conclusion…user’s like being presented with the idea of new features that benefit them in some way. So the problem becomes, how do you collect data from your Users that can help you define “Need to Have” product features?
One methodology I recommend would be card sorting. Commonly used for taxonomy and information architecture, you can easily adapt it to categorize features in to “Need to Have” “Nice To Have” and “No Need”.
First, present the user with your product vision. Provide them with as much detail as you can. This can be done using a lo-fi prototype, Power Point Presentation, or a video. Communicate to them that this is far from the final stage and that you need their feedback to get to the final version. The important part is that they understand the product vision
Next, present the features to the user. The experiment can be run IRL using index cards, or online using free sites such as https://note.ly . Have the user sort the cards into categories “Need to Have” “Nice To Have” and “No Need”. Hopefully, it ends up looking something like this:
If your User places them all under “Need to Have”, ask them “if you could put only have three features under ‘Need to Have’, which ones would they be?”. Repeat this experiment with the rest of your early adopters and compare how they grouped them.
If you selected your early adopters based on how closely they were aligned to your Primary Persona, you should start seeing trends emerge with how they grouped the features.
Ideally you want to run card sorting experiments with 15–20 Users but in the case of early adopters, run the experiment with all of them. If you have a low amount of early adopters (you should have at least 3–5 to even consider co-development otherwise you are building your product à la carte) and you haven’t seen a pattern, consider running the experiment with similar potential users. Just don’t go over 20 otherwise you’ll run the risk of diminishing returns.
Good luck with building your product and keep it simple.
